Наблюдали когда-нибудь, как менеджер собирает КП на сложный продукт? Excel в трёх окнах. Прайс — где-то в почте от бухгалтерии (или в чате, или в папке на сервере — никто не помнит). Скидка — «ну, этому клиенту всегда даём 15%». А потом CFO открывает итоги по сделке и хватается за голову: продали ниже себестоимости, потому что забыли про доставку и монтаж.
Винить менеджера бессмысленно. Проблема в отсутствии системы. Когда у вас сложная продуктовая линейка — опции, комплектации, зависимости между компонентами — голова не справляется. Ошибки гарантированы. Каждая ошибка — либо потерянная маржа, либо потерянный клиент (когда выясняется, что обещанное невозможно поставить).
CPQ — Configure, Price, Quote — инструмент как раз для таких ситуаций. Не маркетинговый термин, а реальный способ превратить хаос ценообразования в управляемый процесс. Ниже — как внедрить CPQ так, чтобы менеджерам стало проще, а финансовый директор перестал просыпаться в холодном поту.
Что такое CPQ и зачем оно нужно
CPQ — это Configure-Price-Quote. В переводе на человеческий: конфигурируешь продукт, система считает цену, генерирует готовое предложение. Звучит просто, но за этими тремя словами скрывается целая философия работы с КП.
Configure — собираете продукт как конструктор. Нужен сервер? Выбираете процессор, память, диски. Система сама знает, что с чем совместимо, а что — нет. Попробуете собрать невозможную конфигурацию — просто не даст.
Price — цена рассчитывается сама. Базовый прайс, скидка клиента, акция месяца, ваш лимит на уступки — всё учитывается автоматом. Менеджер видит и цену для клиента, и свою маржу. Сразу понятно, есть ли смысл торговаться дальше или уже продаёте в минус.
Quote — на выходе получается КП. Не кривой PDF из склеенного Word'а, а нормальный документ в фирменном стиле. С печатью, подписью, юридическими реквизитами — всё как надо.
Спросите: а зачем вообще что-то менять? Менеджер же справляется — открыл Excel, посчитал, отправил. Справляется, да. Пока не наделает ошибок:
Пообещали клиенту комплектацию, которую технически невозможно собрать. Выяснилось это на складе. Или ещё хуже — у клиента при монтаже. Привет, неустойка и репутационные потери.
Продали по старым ценам. Менеджер работает с прайсом полугодовой давности, который лежит у него в закладках. Себестоимость выросла на 20%, а он отправил КП по старой цене. Когда CFO увидел сделку, уже поздно — договор подписан.
Каждый дарит свои скидки. У одного менеджера «стандартная скидка» — 5%. У другого — 15%. У третьего — зависит от настроения и того, насколько настойчивый клиент. Никакой системы. Клиенты между собой общаются, узнают, что кому-то дали дешевле — и начинается цирк.
Нестандартная сделка ходит по согласованиям неделю. Клиент просит скидку чуть больше обычной. Менеджер шлёт запрос руководителю. Тот — коммерческому директору. Директор в командировке, отвечает через три дня. Клиент уже ушёл к конкуренту, который ответил за час.
Продали в минус, но узнали об этом только потом. Менеджер видел только выручку. Что там с себестоимостью, доставкой, монтажом — это где-то в других таблицах. Сделку закрыли, похлопали по плечу, выдали премию. А через месяц выяснилось, что маржа отрицательная.
CPQ решает всё это не приказами «давайте будем внимательнее», а тупо автоматизацией. Система физически не даст собрать несовместимую конфигурацию. Не даст дать скидку выше лимита без согласования. Цены обновляются централизованно — менеджер всегда работает с актуальным прайсом. А маржу видно сразу, ещё до отправки КП клиенту.
История из практики: 18 миллионов тенге за один клик
Работали с казахстанским поставщиком промышленного оборудования. У них была «таблица совместимости» на 47 листов Excel. Менеджеры должны были сверяться с ней при каждом заказе. Естественно, никто не сверялся.
Однажды продали клиенту линию, где привод от одного производителя, а контроллер — от несовместимого. Выяснилось это, когда оборудование уже приехало. Пришлось заказывать замену, ждать 3 месяца, платить неустойку. Убыток — 18 миллионов тенге.
После этого внедрили CPQ. Теперь система автоматически проверяет совместимость. Если компоненты не работают вместе — КП просто невозможно сформировать. За два года — ноль подобных инцидентов.
Конфигуратор: как настроить правила сборки продукта
Конфигуратор — это сердце CPQ. Набор правил, которые говорят системе, что с чем можно совмещать, а что — нельзя. Звучит элементарно, но именно тут зарыто больше всего граблей.
Представьте: у вас линейка оборудования. К каждой позиции — десяток опций. Одни опции обязательны, другие — взаимоисключающи, третьи — работают только в определённых комбинациях. Если держать всё это в голове — рано или поздно накосячишь. Конфигуратор держит эти правила вместо вас.
Типы правил конфигурации
| Тип правила | Описание | Пример |
|---|---|---|
| Обязательное включение | Если выбран продукт A, автоматически добавляется B | Выбрали сервер → автоматически добавляется блок питания |
| Взаимоисключение | Нельзя выбрать A и B одновременно | Либо лицензия Standard, либо Enterprise — не обе |
| Зависимость | B можно выбрать только если выбран A | Расширенная гарантия доступна только для новых устройств |
| Количественное ограничение | Не больше/не меньше N единиц | К одному контроллеру можно подключить от 1 до 8 датчиков |
| Расчётная формула | Параметр вычисляется по формуле | Мощность кондиционера = площадь × 100 Вт |
Практические советы по настройке конфигуратора
Главная ошибка при внедрении — попытка сразу описать все возможные комбинации. Садитесь с инженерами, начинаете рисовать схемы: «Если A, то возможно B и C, но не D, если только не выбран E...». Через неделю голова пухнет, а вы ещё на трети продуктовой линейки.
Не надо так. Делайте проще:
Начните с топ-20 продуктов. Какие позиции дают 80% выручки? Вот с них и начинайте. Всё остальное добавите потом, когда основа заработает. Не пытайтесь объять необъятное за раз.
Соберите знания с полей. Опытные менеджеры знают все подводные камни. Они помнят, как год назад продали несовместимую связку и три месяца разгребали. Проведите с ними интервью. Спросите: «Какие ошибки в конфигурации вы видели?» Запишите. Это и будут ваши правила.
Привлекайте инженеров. Продажники знают, что продаётся. Но правила технической совместимости должны проверять те, кто в железе разбирается. Инженер скажет: «Этот контроллер не работает с этим приводом из-за разницы в протоколах». Продажник этого не знает — он увидит две позиции из прайса и посчитает, что можно совместить.
Тестируйте на реальных кейсах. Возьмите последние 50 сделок. Попробуйте воспроизвести их через конфигуратор. Если система ругается на конфигурацию, которая в жизни прошла нормально — значит, правила слишком жёсткие. Если пропускает то, что на деле не работает — правила недостаточно строгие.
И ещё важный момент: конфигуратор не должен бесить менеджеров. Если чтобы собрать типовое предложение, нужно сделать 20 кликов и заполнить 15 полей — они просто перестанут им пользоваться. Найдут обходной путь. Хороший конфигуратор подсказывает, предлагает популярные варианты, запоминает, что этот менеджер обычно выбирает.
Нужен конфигуратор для вашей продуктовой линейки?
В CrmAI уже встроен гибкий конфигуратор с поддержкой сложных правил, зависимостей и автоматических расчётов. Покажем, как настроить его под ваш бизнес.
Получить демоЦенообразование: прайсы, скидки и защита маржи
Ценообразование — это там, где обычно максимальный бардак. Прайсы в Excel, которые «где-то лежат». У кого-то версия от марта, у кого-то от октября. Скидки на усмотрение каждого менеджера. Особые цены для «своих» клиентов, о которых знает один человек. И он сейчас, понятное дело, в отпуске.
Знакомо? Это классика. А теперь представьте, что всё это живёт в одной системе, обновляется централизованно, и любой менеджер видит актуальные цены. Не ищет в почте прайс, не спрашивает в чате «а какая скидка этому клиенту», а просто открывает карточку и там всё написано.
Структура ценообразования в CPQ
Хорошая CPQ-система понимает, что цена — это не одно число. Это слоёный пирог из правил:
Пирамида цен
Стандартная цена продукта без учёта условий. Источник истины — обновляется централизованно.
Специальные условия для конкретного клиента. Зафиксированы в рамочном договоре.
Скидка зависит от количества: 5+ единиц → минус 5%, 20+ → минус 10%.
Временные скидки на определённые продукты или категории.
Скидка менеджера в рамках его лимита (обычно 5-10%).
Система сама применяет все эти уровни в правильном порядке. Менеджер не должен помнить, есть ли у клиента контрактная цена, действует ли сейчас промо-акция на этот продукт. Он просто видит итоговую цену — CPQ всё посчитала за него.
Лимиты скидок и согласования
Вот тут начинается самое интересное — контроль. Без жёстких рамок что делает менеджер? Правильно, даёт максимальную скидку, «чтобы точно закрыть сделку». Клиент торгуется? Скинем ещё 5%. Просит ещё? Ну давайте ещё 5%. И так пока маржа не испарится полностью.
Менеджеру это выгодно — ему платят процент от выручки, а не от прибыли. Ему всё равно, что компания заработала копейки. Он закрыл план, получил бонус. А CFO потом смотрит в отчёт и видит: выручка растёт, а прибыль падает. Потому что все продают с огромными скидками.
CPQ решает это лимитами:
| Роль | Лимит скидки | Согласование |
|---|---|---|
| Менеджер | до 5% | Не требуется |
| Старший менеджер | до 10% | Не требуется |
| Руководитель отдела | до 15% | Не требуется |
| Коммерческий директор | до 25% | Не требуется |
| Выше 25% | — | Согласование Deal Desk |
Ключевой принцип: менеджер не может обойти систему. Если у него лимит 5% — значит 5%, точка. Хочет дать больше? Отправляет запрос на согласование. Руководитель смотрит, принимает решение. Если решение положительное — скидка применяется. Если отрицательное — менеджер идёт к клиенту и торгуется дальше в рамках своего лимита.
Это не бюрократия. Это защита бизнеса. Каждый процент скидки — это прямое уменьшение прибыли. При марже 20% скидка в 10% съедает половину вашей прибыли. Половину! Менеджеры часто не осознают этого, потому что смотрят только на выручку. «Продал на миллион — молодец я». А то, что маржа там 2% вместо 20% — это где-то в финансовых отчётах, которые менеджер не читает.
CPQ делает эту связь явной. Менеджер видит: база 100 тыс., себестоимость 70 тыс., маржа 30 тыс. (30%). Даёшь скидку 15% — маржа падает до 15 тыс. (15%). Даёшь 25% — маржа 5 тыс. (5%). Сразу понятно, во что обходится каждый уступленный процент.
Контроль маржинальности: не продавать в минус
Это одна из самых полезных штук в CPQ — расчёт маржинальности на лету. Менеджер собирает КП и сразу видит: цена для клиента такая-то, себестоимость такая-то, маржа столько-то процентов и столько-то в деньгах. Прямо в момент формирования предложения.
Это меняет поведение мгновенно. Раньше менеджер видел только цифру для клиента. Теперь он видит, сколько компания реально заработает на этой сделке. И когда клиент просит скидку, менеджер понимает: ещё 5% — и мы продаём в ноль. А если дам 10% — вообще в минус. Появляется мотивация торговаться жёстче.
Что должно учитываться в себестоимости
Частая ошибка — в себестоимости учитывают только закупочную цену товара. Купили за 100, продали за 130, маржа 30% — красота! А потом оказывается, что реальная маржа 10%. Или вообще минус. Потому что забыли про кучу других расходов:
- Закупочная цена — базовая стоимость товара от поставщика
- Логистика — доставка от поставщика на склад + доставка клиенту
- Таможня — пошлины, НДС на импорт, брокерские услуги
- Монтаж и пуско-наладка — если включены в КП
- Гарантийный резерв — на случай гарантийных обращений
- Комиссия менеджера — если платите процент от сделки
Когда всё это учтено, картина получается совсем другая. Думали маржа 30%? А реально 15%. Или 8%. А иногда и минус вылезает — когда продали с большой скидкой и не учли монтаж, который влетел в копеечку.
Пороги маржинальности
Хорошая практика — разделить сделки на зоны по уровню маржи. Зелёная зона — всё отлично, закрывай сделку. Жёлтая — на грани, нужно согласование. Красная — стоп, так продавать нельзя.
Зелёная зона
Маржа > 20%
Сделка одобряется автоматически
Жёлтая зона
Маржа 10-20%
Требуется согласование РОПа
Красная зона
Маржа < 10%
Согласование комдира + обоснование
Важно: пороги зависят от вашего бизнеса. Для дистрибьютора с большими объёмами и маржа 5% может быть нормой. Для проектных продаж — 30% и выше. Настраивайте под свою реальность.
Версионность коммерческих предложений
Классика жанра: клиент пишет «давайте немного поправим КП, уберите вот эту позицию». Менеджер убирает, отправляет. Клиент через день: «Нет, давайте как в первом варианте, мы передумали». Менеджер: «Э-э-э... щас найду...» Роется в почте, в папке «Документы», спрашивает в чате «кто помнит, какая там была конфигурация?».
Или другой вариант: клиент спрашивает «а что изменилось с прошлого раза?». И менеджер пытается на глаз сравнить два PDF'а. «Вроде бы скидка была 10%, а стала 15%... или там ещё что-то менялось? Не помню уже».
Версионность КП решает эту проблему в лоб. Каждое изменение сохраняется как новая версия. Можно вернуться к любой предыдущей. Можно сравнить, что изменилось. Можно посмотреть, кто и когда вносил правки.
Что даёт версионность
- Полная история — все версии КП сохраняются, можно вернуться к любой
- Сравнение версий — система показывает, что изменилось между v1 и v2
- Аудит — кто, когда и какие изменения вносил
- Связь с согласованиями — какая версия была согласована, какая отклонена
- Юридическая защита — если клиент оспаривает условия, есть документальное подтверждение
Пример: жизненный цикл одного КП
Контроль исключений: когда правила можно нарушать
Любая система правил рано или поздно сталкивается с исключениями. Приходит клиент стратегический — нужна скидка больше стандартной. Продукт нетиповой — его вообще нет в конфигураторе. Условия оплаты специфические — клиент хочет отсрочку 90 дней вместо обычных 30. Что делать?
Неправильный ответ: «Система не даёт, ничего не могу сделать». Клиент уйдёт к конкуренту.
Правильный ответ: не запрещать исключения, а управлять ими. Исключение — это нормально. Но оно должно пройти через процесс согласования, и должна быть зафиксирована причина. Почему мы дали скидку 30%, хотя лимит 15%? Потому что это вход в крупного клиента, который потом принесёт 50 млн выручки. Ок, это разумное обоснование. Согласовано, фиксируем, идём дальше.
Типы исключений и маршруты согласования
| Тип исключения | Пример | Согласующий | SLA |
|---|---|---|---|
| Скидка выше лимита | Скидка 20% при лимите 10% | Коммерческий директор | 4 часа |
| Нестандартный продукт | Модификация под клиента | Технический директор | 1 рабочий день |
| Нестандартные условия оплаты | Отсрочка 90 дней | Финансовый директор | 4 часа |
| Продажа ниже себестоимости | Маржа отрицательная | CEO + CFO | 1 рабочий день |
| Нетиповой договор | Изменение стандартных условий | Юридический директор | 2 рабочих дня |
Ключевой момент: исключение — это не «ошибка системы». Это нормальная часть жизни. Но каждое исключение должно быть обосновано, согласовано и записано. А потом эти данные дают пищу для размышлений. Если 30% сделок требуют исключений по скидкам — возможно, ваши стандартные лимиты слишком жёсткие? Или менеджеры не умеют продавать? Или конкуренты демпингуют, и нужно пересматривать ценовую политику?
Подробнее о процессе согласования сложных сделок читайте в нашей статье про автоматизацию согласований и договоров.
Интеграции: CPQ не живёт в вакууме
CPQ — это не изолированная система. Она должна быть связана с другими инструментами компании, иначе превратится в ещё один «островок данных».
CRM
Связь со сделками и клиентами. КП создаётся в контексте конкретной сделки, история сохраняется в карточке клиента.
1С / ERP
Синхронизация товаров, цен, остатков. Автоматическое резервирование при согласовании КП.
ЭДО / Электронная подпись
Отправка КП на подпись через ЭДО. Отслеживание статуса подписания в CRM.
BI / Аналитика
Выгрузка данных для анализа: конверсия КП, средняя скидка, маржинальность по менеджерам.
Особенно важна интеграция с учётной системой. Если цены и остатки не синхронизируются — менеджеры будут продавать товар, которого нет на складе, или по старым ценам. Мы подробно разбирали эту тему в статье про синхронизацию товаров и цен между 1С и CRM.
Как внедрить CPQ: пошаговый план
Внедрение CPQ — это не «купили софт, нажали кнопку, всё работает». Это проект. Нужно настроить правила, загрузить данные, обучить людей. Но вот что приятно: при грамотном подходе MVP (минимально работающая версия) запускается за 4-6 недель. Не год, не полгода. Полтора месяца — и уже можно использовать.
Этап 1: Подготовка (1-2 недели)
- Провести аудит текущего процесса: как сейчас создаются КП?
- Определить топ-20 продуктов для первой итерации
- Собрать правила совместимости и ограничений
- Зафиксировать текущую матрицу скидок (или создать, если её нет)
Этап 2: Настройка (2-3 недели)
- Загрузить каталог продуктов с ценами и себестоимостью
- Настроить правила конфигурации
- Настроить лимиты скидок и маршруты согласования
- Создать шаблон КП в фирменном стиле
- Настроить интеграцию с учётной системой
Этап 3: Пилот (1-2 недели)
- Запустить систему на 2-3 менеджерах
- Собрать обратную связь и исправить проблемы
- Провести параллельное тестирование (старый vs новый процесс)
Этап 4: Масштабирование
- Обучить всю команду продаж
- Добавить остальные продукты
- Настроить аналитику и KPI
- Интегрировать с ЭДО для электронной подписи
Как измерять эффективность CPQ
После внедрения нужно понять: а работает ли оно вообще? Не просто «работает» в смысле «не падает», а реально даёт пользу. Вот на какие метрики смотреть:
| Метрика | Что измеряет | До CPQ | После CPQ |
|---|---|---|---|
| Время создания КП | От запроса до отправки клиенту | 40-60 минут | 5-10 минут |
| Конверсия КП в сделку | % принятых предложений | 15-20% | 25-35% |
| Средняя маржа | Маржинальность закрытых сделок | Неизвестно | 20%+ (контролируемо) |
| Ошибки в КП | Несовместимости, неправильные цены | 10-15% | < 1% |
| Цикл согласования | Время на согласование нестандартных сделок | 3-5 дней | 4-8 часов |
Эти метрики нужно смотреть регулярно. Если время создания КП начинает расти — значит, система обросла лишними полями и шагами, пора чистить. Если маржа падает — возможно, лимиты скидок слишком мягкие, менеджеры научились обходить систему, или конкуренты начали демпинговать. В любом случае, цифры покажут, где проблема.
Главное: что запомнить
- CPQ — это не роскошь, а необходимость для компаний со сложными продуктами. Без него ошибки неизбежны.
- Конфигуратор защищает от несовместимых конфигураций и ускоряет сборку предложений.
- Контроль скидок защищает маржу. Менеджер не должен иметь возможности обойти систему.
- Расчёт маржинальности должен учитывать все затраты, не только закупочную цену.
- Версионность КП решает проблему потерянных файлов и путаницы с версиями.
- Исключения — нормальная часть процесса, но они должны быть управляемыми.
- Начинайте с малого — топ-20 продуктов, 2-3 менеджера на пилоте.
Связанные материалы
Готовы навести порядок в ценообразовании?
В CrmAI встроен полноценный CPQ-модуль: конфигуратор, многоуровневые прайсы, контроль скидок, расчёт маржинальности в реальном времени. Покажем, как это работает на ваших продуктах.