CPQ-система для B2B: архитектура, скидки и прайс-листы

Зачем B2B нужна CPQ и какие проблемы она решает

CPQ для B2B помогает менеджеру быстро собрать корректное коммерческое предложение, когда продукт не продается одной строкой, а состоит из конфигурации, опций, сервисов и условий поставки. Это особенно заметно в сделках с ИТ-оборудованием и проектами: один неверный блок питания, лишняя лицензия или неправильная скидка, и КП приходится переделывать, а клиент теряет доверие.

CPQ важно не путать с другими системами. CRM отвечает за клиента и этапы сделки (кто, когда, на каком шаге). ERP отвечает за учет и исполнение (склад, финансы, отгрузка). CPQ закрывает «середину» между ними: что именно продаем, в каком составе, по какой цене и с какими условиями.

При ручной сборке КП чаще всего повторяются одни и те же ошибки: выбирают несовместимые позиции, берут цену из устаревшего прайса или «как в прошлый раз», считают скидку в Excel и забывают про минимальную маржу, путают НДС, валюту и срок действия цены. Часто правки вносят в документ, но забывают обновить спецификацию и итог.

CPQ собирает это в один процесс: конфигурирует состав, проверяет совместимость, подтягивает актуальные цены, применяет скидки по понятным правилам и генерирует КП в нужном формате. Например, при продаже рабочих станций или серверов, как у GSE.kz, система может подсказать обязательные компоненты, предложить совместимые альтернативы и сразу показать итоговую стоимость с учетом сервисных работ и поддержки.

В работе обычно участвуют несколько ролей: продажи задают сценарии и интерфейс, продуктовые команды описывают каталог и правила, финансы контролируют скидки и маржу, ИТ обеспечивает интеграции с CRM, ERP и источниками прайс-листов.

Собираем требования: что должно получаться на выходе

Начните не с экранов, а с результата. CPQ должна выдавать документы и данные так, чтобы менеджер мог отправить клиенту КП и не править руками ни цены, ни состав, ни формулировки.

Сначала уточните, что именно вы продаете. У многих B2B параллельно есть товары (оборудование), услуги (внедрение, монтаж, обучение), проекты (поставка + работы + этапы) и подписки (поддержка, лицензии). Для CPQ это разные типы позиций: у одних есть склад и серийность, у других - сроки и объем работ, у третьих - периодичность и продление.

Затем определите входные данные, на которых держится расчет. Минимальный набор - источники цен и условий: прайс-листы, договорные цены по клиентам, себестоимость (или закуп), правила доставки, наличие и сроки поставки, если они влияют на обещания в КП. Для производителя и интегратора вроде GSE.kz особенно важно, чтобы спецификация опиралась на актуальные линейки и варианты комплектаций, а итоговый документ сразу включал корректные работы и поддержку.

Отдельно зафиксируйте ограничения, которые чаще всего ломают автоматизацию, если их не описать заранее:

• срок действия цены и дата, на которую считается КП
• валюта, курсы и правила округления
• НДС и разные ставки, если они бывают
• региональные отличия: доставка, сервис, доступность, требования к локальному содержанию
• кто может менять цену и в каких пределах

Последний шаг - требования к выходу. Согласуйте, какие артефакты должна формировать система: спецификацию (таблица строк), коммерческое предложение (фирменный шаблон), счет и договорное приложение. Уточните, какие поля обязательны в каждой строке (артикул, описание, количество, единица, цена, скидка, сумма, срок поставки, гарантия) и какие тексты подтягиваются автоматически (условия оплаты, сроки, примечания по совместимости). Тогда архитектуру и правила скидок проще строить вокруг измеримого результата.

Архитектура CPQ: основные модули и как они связаны

CPQ чаще ломается не на интерфейсе, а на связях между модулями. Менеджеру нужно собрать спецификацию, получить правильную цену, применить скидки по правилам и выпустить документ так, чтобы итог можно было объяснить и повторить.

Удобно думать о CPQ как о конвейере, где каждый шаг оставляет след: что выбрали, по какой цене посчитали, какое правило сработало. Базовые модули обычно такие:

• каталог (товары, опции, атрибуты, единицы измерения)
• конфигуратор (совместимость, обязательные опции, зависимости)
• прайс-движок (источник базовой цены, валюта, условия поставки)
• движок скидок (скидки, наценки, пороги, контроль маржи)
• генератор документов (КП, спецификация, приложения, версии)

Дальше подключаются интеграции. CRM дает контекст сделки (клиент, сегмент, стадия), ERP или учетная система - номенклатуру, налоги и учетные ограничения, склад - доступность и сроки, BI и DWH - аналитику по конверсиям и марже. Практичное правило: CPQ считает и фиксирует расчет, а внешние системы подтверждают справочные данные и ограничения.

Чтобы избежать споров «почему вчера было иначе», нужны хранилища и версионирование. Обычно выделяют справочники (каталог и клиенты), прайс-листы (с датами действия), версии правил конфигурации и скидок, а также историю расчетов (входные параметры, сработавшие правила, итоговые строки).

Пример: менеджер собирает серверную конфигурацию для госзаказчика. Конфигуратор не даст выбрать несовместимые компоненты, прайс-движок возьмет цену из нужного прайс-листа по типу клиента, а движок скидок применит согласованный процент и проверит минимальную маржу. Генератор документов выпустит КП с той же версией правил, что использовалась при расчете.

Нефункциональные требования, которые стоит заложить сразу

• скорость расчета: ответы за секунды, без ожидания «пересчета» при каждом клике
• аудит: кто менял цену и правила, когда, и что именно изменилось
• права доступа: разные роли для продаж, пресейла, финансов и администраторов
• повторяемость: один и тот же ввод дает один и тот же результат при той же версии правил
• надежность: сохранение черновиков и работа при частичных сбоях интеграций

Архитектура конфигуратора: модель каталога и правила совместимости

Сердце CPQ-системы - конфигуратор. Он должен собирать спецификацию так, чтобы менеджер не мог случайно создать «несобираемую» или неполную комплектацию. Для этого нужны понятная модель каталога и единый механизм правил.

Модель каталога

Опишите продукт как набор строительных блоков. Не пытайтесь сразу «оцифровать весь прайс». Сначала определите, какие элементы реально участвуют в сборке спецификации и влияют на цену.

Обычно достаточно таких сущностей:

• базовая позиция (основа): например, сервер S200 или ПК L200 как стартовая конфигурация
• опция: компонент или выбор (ОЗУ, диски, ОС, гарантия)
• комплект (bundle): заранее проверенная связка опций, которую можно выбрать одним кликом
• услуга: доставка, монтаж, внедрение, расширенная поддержка
• параметры (атрибуты): то, что описывает выбор (объем RAM в ГБ, тип диска, количество портов)

Ключевой момент: атрибуты должны иметь единицы измерения и ограничения. Например, «RAM, ГБ» с шагом 16 и диапазоном 32-512. Тогда система не позволит ввести «48,5 ГБ» или «9999 ГБ», а в спецификации появится корректная строка.

Правила совместимости и версии

Правила лучше хранить отдельно от интерфейса, как «движок ограничений», который проверяет корзину при каждом изменении. Чаще всего встречаются:

• обязательные: если выбран RAID-контроллер, должен быть добавлен кэш-батарейный модуль
• запрещающие: нельзя одновременно выбрать две взаимоисключающие опции
• зависимости: при выборе ОС добавляются нужные лицензии или требования к объему диска
• количественные: минимум 2 диска для RAID1, максимум N модулей памяти для платформы

Пример: менеджер собирает КП на стойку с серверами. Он выбирает S200, добавляет 2 SSD и RAID1. Конфигуратор сразу проверяет: подходит ли выбранный контроллер, хватает ли слотов, не превышена ли мощность БП, и при необходимости предлагает совместимую замену.

Нужны и версии. Правила и шаблоны спецификаций должны иметь версии с датой действия. Менять их могут только владельцы каталога (продукт-менеджер, пресейл, администратор), а все изменения фиксируются: кто изменил, что именно и с какого дня действует. Это защищает от ситуации, когда вчерашнее КП «ломается» после обновления правил.

Связка с прайс-листами: от источника цены до строки спецификации

Чтобы CPQ не превратилась в калькулятор в Excel, у нее должна быть прозрачная цепочка: от источника цены до цены в строке спецификации. Менеджер выбирает конфигурацию, а система сама находит корректную цену, учитывая договор, проект и сроки.

Цен обычно несколько: базовый прайс (каталог), контрактные прайсы под конкретного клиента, промо-цены на период акции и проектные цены под тендер или крупную сделку. Важно не смешивать их вручную. В CPQ каждая цена хранится как отдельное правило с условиями: клиент, сегмент, продукт, объем, дата действия.

Самый частый спорный момент - что делать, если совпали несколько цен. Задайте приоритеты один раз и применяйте их одинаково везде:

• проектная цена (если указан проект или тендер)
• контрактная цена клиента
• промо-цена (если период и условия выполнены)
• базовый прайс
• цена по умолчанию (если ничего не найдено, с обязательной проверкой)

Дальше идут детали, из-за которых возникают ошибки в КП. Цена может быть в KZT, USD или EUR, а счет выставляется в одной валюте. Поэтому в CPQ фиксируют дату курса, правило пересчета и точку округления (например, до 1 тг или до 0,01). Отдельно задайте, включен ли НДС в цену, и как показывать его в спецификации. То же с доставкой: иногда это отдельная строка услуги, иногда она включена в цену оборудования, иногда зависит от региона.

Хорошая практика - хранить в строке спецификации не только итог, но и «паспорт цены»: какой прайс применился, какая версия, какая дата, какая валюта, НДС, доставка. Например, при сборке КП на сервер GSE S200 для госзаказчика система может применить проектную цену под закупку с локальным содержанием, посчитать НДС по правилам компании и добавить доставку отдельной строкой.

Чтобы цены не «плавали» в середине согласования, используйте фиксацию версии прайса на момент создания КП. Если прайс обновили позже, менеджер видит уведомление и может пересчитать КП осознанно. Ведите журнал: кто обновил прайс, когда, что изменилось и по какой причине. Это спасает при разборе спорных скидок и при внутреннем аудите.

Правила скидок: как устроить расчет и контроль маржи

Скидки должны считаться одинаково у всех менеджеров и оставлять понятный след: кто дал скидку, почему и с какой финансовой ценой компания согласилась.

Какие скидки стоит поддержать

Обычно хватает нескольких типов: процент от цены, фиксированная сумма, ступени по объему (например, от 10 штук дешевле), пакетные условия (скидка при покупке комплекта, например сервер + сервис + ПО).

Заранее решите, как скидки комбинируются. Либо вы суммируете их по правилам (с ограничениями), либо выбираете лучшую из доступных. На практике часто задают порядок применения: сначала автоматические скидки (объем, пакет), затем ручная скидка менеджера, затем финальная проверка маржи.

Контроль маржи и ограничения

Скидка должна быть управляемым решением, а не произвольным числом. Для этого в расчете держат минимум три значения: базовую цену, себестоимость (или минимально допустимую цену) и текущую маржу по строке и по всему КП.

Чтобы избежать хаоса, задают ограничения:

• минимальная маржа по продукту или категории (например, отдельно для серверов и для сервисов)
• лимиты по ролям (менеджер, руководитель отдела, коммерческий директор)
• согласование, если скидка выходит за порог или маржа падает ниже минимума
• блокировка ручной скидки для отдельных позиций (например, товаров по фиксированным контрактам)
• отдельные правила для тендеров и госзакупок, где важны условия локального производителя

Пример: менеджер собирает КП на 15 рабочих станций и добавляет пакет с расширенной поддержкой. Объемная скидка применяется автоматически, пакетная добавляет еще 2%, но система видит, что по одной позиции маржа опускается ниже минимума. В итоге скидка по этой строке снижается до допустимого уровня, а если менеджер настаивает - создается запрос на согласование.

Аудит: почему скидка именно такая

Каждая примененная скидка должна иметь «объяснение»: идентификатор правила, версию прайс-листа, условия срабатывания (объем, сегмент клиента, срок действия), автора ручной скидки и результат проверки маржи. Тогда спорные случаи решаются быстрее, а финансовый контроль получает прозрачную историю.

Как менеджер собирает КП: процесс без ручных ошибок

Хорошая CPQ делает работу менеджера похожей на заполнение понятной формы, а не на сбор пазла в Excel. Важно, чтобы каждое действие вело к корректной спецификации, цене и готовому документу.

Типовой процесс:

• выбрать клиента и контекст сделки: сегмент, регион поставки, валюта, условия оплаты
• добавить базовые позиции из каталога и количество
• настроить опции и комплектацию: память, накопители, лицензии, сервис, срок поддержки
• проверить спецификацию и цену: система подсветит ошибки и предложит исправления
• сформировать КП из шаблона и отправить на согласование или сразу клиенту

Чтобы убрать ручные ошибки, нужны проверки прямо в момент конфигурации. Если менеджер добавил несовместимую опцию, пропустил обязательное поле или поставил количество ниже минимума, система не должна давать сохранить строку как готовую. Это лучше, чем ловить проблему на этапе счета или отгрузки.

Дальше включается расчет цены. CPQ подтягивает базовую цену, применяет скидки по правилам, добавляет налоги и доставку и контролирует маржу. Если скидка слишком большая, менеджер видит предупреждение и отправляет запрос на согласование, вместо того чтобы править цифры вручную.

На выходе менеджер получает КП, где уже собраны все детали: реквизиты сторон и контакты, условия поставки и оплаты, срок действия предложения, спецификация по строкам с кодами и описаниями, итоговая цена с расшифровкой скидок и налогов.

Практичный пример: при запросе на поставку серверов для госоргана менеджер выбирает профиль клиента, добавляет серверы серии S200, сервис и ПО. Система проверяет совместимость опций и не даст выпустить КП без сроков поставки и условий оплаты. Документ формируется одинаково аккуратно у всех менеджеров, без расхождений в описаниях и суммах.

Частые ошибки при разработке CPQ и как их избежать

Даже хорошая система может начать мешать продажам, если цены «прыгают», скидки становятся «безлимитными», а каталог превращается в набор исключений. В итоге команда возвращается к Excel и ручным правкам.

Ниже - ошибки, которые встречаются чаще всего, и способы их избежать.

• Сбитый приоритет цен и внезапные перерасчеты. Если система то берет цену из прайса, то из договора, то из акции, менеджер не понимает итог. Зафиксируйте один порядок источников и показывайте в строке спецификации, откуда взялась цена и почему.
• Скидки без контроля маржи. Когда можно поставить любую скидку без ограничений, CPQ становится инструментом потерь. Введите минимальную маржу по категориям, пороги скидок и маршрут согласования.
• Каталог без правил, только исключения. Слабая модель каталога приводит к постоянным ручным правкам в спецификации. Делайте совместимость и обязательные опции правилом, а исключения - редкостью.
• Нет версий и аудита изменений. Клиент спрашивает, почему цена изменилась, а вы не можете объяснить. Нужны версии прайс-листов, правил и конфигураций, плюс журнал изменений.
• Тихие ручные правки в КП. Если менеджер может отредактировать строку «как угодно», ошибки возвращаются. Разрешайте ручной ввод только там, где это действительно нужно, и помечайте такие строки как нестандартные, с обязательным комментарием.

Хороший тест: возьмите реальную сборку (например, КП на рабочие станции и серверы для проекта) и попробуйте повторить ее через неделю. Если система дает тот же результат и может объяснить источники цен и скидок, вы на правильном пути.

Короткий чеклист перед запуском в продажи

Перед тем как давать системе доступ реальным менеджерам, проверьте не «красоту интерфейса», а то, что защищает от ошибок и спорных ситуаций.

1) Конфигурация не может быть неправильной

Попросите менеджера специально собрать «плохую» спецификацию: несовместимые опции, лишние аксессуары, отсутствующие обязательные компоненты. Система должна либо запретить сохранение, либо ясно подсказать, что не так и как исправить. Это особенно важно в сложных комплектациях, например при подборе серверов, рабочих станций или моноблоков.

2) Понятно, откуда взялись цена и скидка

Менеджер (и руководитель) должны видеть, какая цена подставилась, какая скидка применена и по какому правилу. Без этого начинаются ручные правки и «я так всегда делал».

3) Прайсы и условия имеют срок и контролируются

Проверьте, что у прайс-листов и специальных условий есть даты начала и окончания, и система не позволит выпустить КП по устаревшей цене. Убедитесь и в другом: обновление прайса не ломает сохраненные расчеты, а создает новую версию.

4) Есть история и версионность

Сохраняйте полный след: кто и когда менял конфигурацию, цены, скидки, а также какая версия шаблона КП использовалась. Это помогает разбирать претензии и обучать команду на реальных кейсах.

5) Роли и лимиты скидок нельзя обойти

Проверьте ограничения на скидки и маржу: кто может давать скидку, в каких пределах, и как работает согласование. Протестируйте типовые «обходы» - ручное изменение цены, подмена позиции, копирование старого КП. Система должна либо запретить, либо отправить на согласование с понятным комментарием.

Если хотя бы один пункт не проходит тест, лучше задержать запуск на неделю, чем потом месяц разбирать ошибки в КП и недопоставки.

Пример сценария: сборка КП от запроса до документа

Запрос приходит от госорганизации: нужно закупить рабочие места и сервер под внутреннюю систему. По условиям закупки действует контрактный прайс, а скидка не может превышать установленный лимит. Менеджеру важно не ошибиться в спецификации и сразу попасть в рамки цены и маржи.

Менеджер открывает сделку в CPQ и выбирает базовые позиции: настольные ПК линейки L200, затем добавляет опции (объем ОЗУ, SSD, ОС) и сервис (расширенная поддержка, пусконаладка). На каждом шаге конфигуратор проверяет совместимость: подходит ли выбранная память к модели, можно ли поставить нужный тип накопителя, не конфликтуют ли опции. Если есть несовместимость, система не даст сохранить строку и предложит допустимые альтернативы.

Дальше система считает цену по приоритетам:

• сначала контрактный прайс для заказчика и периода
• если его нет, применяется промо-цена (если активна и разрешена)
• если нет и промо, берется базовый прайс-лист

Менеджер пробует добавить скидку, чтобы уложиться в бюджет. Если скидка в лимите роли, система пересчитывает итог, показывает маржу и фиксирует причину (например, «конкурентное предложение»). Если скидка выше лимита, строка уходит на согласование руководителю, а без одобрения КП нельзя выгрузить.

В конце менеджер нажимает «Сформировать КП». Документ собирается быстро, с одинаковыми расчетами у всех и с прозрачной историей цен и согласований. Если через неделю клиент вернется к переговорам, КП можно воспроизвести и объяснить каждую цифру без ручных правок.

Следующие шаги: пилот, метрики и кому поручить внедрение

Начните с пилота. Возьмите 1-2 типовых сценария продаж (например, одна линейка продуктов и один тип клиента), зафиксируйте правила и цены и прогоните через систему реальные заявки менеджеров. Так вы быстро увидите, где ломается логика, и не потратите месяцы на то, что потом придется переделывать.

Чтобы пилот был честным, заранее договоритесь о метриках. Обычно достаточно нескольких:

• время подготовки КП: от запроса до готового документа
• доля ошибок: возвраты на исправление, расхождения в цене, неверная совместимость
• маржинальность: средняя маржа по КП и доля сделок ниже порога
• процент ручных правок: сколько строк меняют вручную после расчета
• скорость обновления прайса: сколько времени проходит от изменения цены до применения в КП

Дальше нужен процесс поддержки. CPQ быстро обрастает правилами: новые комплектации, исключения по скидкам, изменения прайсов. Назначьте владельца правил (часто это руководитель продаж или продукт-менеджер) и владельца данных (цены, справочники). Договоритесь о простом регламенте: кто подает запрос, как он проверяется (продажи + финансы) и когда попадает в прод.

План внедрения удобно вести по этапам: пилот с ограниченным каталогом и быстрыми правками, короткое обучение по сценариям, расширение каталога и правил, затем интеграции с CRM/ERP и поставками, и после этого - усиление контроля (аудит правок, роли, журнал изменений).

Интегратора имеет смысл подключать там, где много интеграций, есть требования по безопасности, сложные шаблоны КП и согласования скидок. Если CPQ строится вокруг поставок и интеграции оборудования (серверные конфигурации, рабочие станции, инфраструктура), это можно обсудить с GSE.kz как системным интегратором, чтобы связать конфигуратор, цены, поставки и поддержку в один процесс. Упомянуть компанию удобно и на этапе пилота: быстрее проверить сценарии на реальных линейках и правилах, не усложняя модель «в теории».

Ориентир простой: если пилот на 20-30 КП показал снижение времени подготовки хотя бы в 2 раза и заметное падение ошибок, можно масштабировать решение на весь отдел и расширять каталог без риска сорвать продажи.