Автоматическое коммерческое предложение — это не шаблон в редакторе, а сборка документа из трёх независимых источников данных. Номенклатура, цены и остатки живут в учётной системе, условия конкретной сделки — в CRM, реквизиты покупателя — в карточке контрагента. Задача автоматизации в том, чтобы менеджер не переносил эти данные руками между тремя окнами, а видел готовый документ и правил в нём только то, что действительно требует его решения.
Отсюда сразу следует главное ограничение. Если в номенклатуре дубли, прайсов три штуки и они расходятся, а скидка каждый раз согласуется в переписке — автоматизация ничего не исправит, она просто начнёт выдавать неверные документы быстрее. Порядок в данных — не желательное условие проекта, а его предмет: значительная часть работ приходится именно на него.
Ниже — разбор всех трёх источников по строкам документа, устройство матрицы скидок и согласования превышений, честный сценарий для нетиповых позиций, расчёт цикла и экономии на потоке 150 предложений в месяц, механика защиты от ошибок цены и перечень того, что компания обязана подготовить до старта.
Из чего собирается документ: три источника данных
Полезно один раз разложить готовое коммерческое предложение по строкам и напротив каждой написать источник. Обычно это упражнение занимает час и сразу показывает, где проект застрянет: строка, у которой нет системы-источника, будет заполняться руками и после автоматизации.
| Что в документе | Откуда берётся | Что ломается без источника |
|---|---|---|
| Позиции, цены, единицы измерения | Учётная система: 1С:УТ, 1С:УНФ, МойСклад | Менеджер берёт цену из старого файла, документ уходит клиенту с прошлогодним прайсом |
| Наличие и срок поставки | Остатки и заказы поставщикам в той же системе | Обещанный срок не подтверждается складом, сделка срывается после подписания |
| Объём, скидка, условия оплаты и доставки | Карточка сделки в CRM | Условия живут в переписке, при выставлении счёта их приходится восстанавливать |
| Реквизиты покупателя | Карточка контрагента, подтягивается по ИНН из открытых реестров | Опечатка в КПП или адресе всплывает на этапе оплаты и стоит одного-двух дней |
| Себестоимость и минимальная маржа | Закрытая часть учётной системы | Нет контроля рентабельности: скидка выдаётся вслепую |
| Шаблон, юридические формулировки, срок действия предложения | Утверждённый макет документа | Каждый менеджер отправляет свою версию, и юрист узнаёт об этом последним |
Первые две строки требуют рабочей связки CRM с учётной системой — это отдельная задача со своей ценой и своими подводными камнями, мы разбирали её в статье об интеграции CRM с 1С. Строка с реквизитами закрывается автозаполнением карточки контрагента и почти не требует ручной работы. А вот строка с себестоимостью — самая чувствительная: без неё документ можно собрать, но нельзя защитить от убыточной скидки.
Карта связей. Слева три узла-источника: «Учётная система (1С:УТ, 1С:УНФ, МойСклад): позиции, цены, остатки, себестоимость», «CRM: объём, скидка, условия оплаты и доставки», «Открытые реестры по ИНН: реквизиты контрагента». Стрелки от них сходятся в центральный блок «Сборка документа по утверждённому шаблону», от него две стрелки вправо: «Коммерческое предложение» и «Счёт». Снизу отдельная ветка к центральному блоку с подписью «нетиповые позиции — 18 %, считает человек». На стрелке от себестоимости пометка «контроль минимальной маржи». Чертёжный стиль, подписи по-русски.
Матрица скидок — это правило, а не договорённость
В большинстве компаний скидка живёт в двух местах: в голове коммерческого директора и в переписке менеджера с ним. Пока предложений десять в месяц, это работает. На ста пятидесяти это превращается в очередь на согласование и в разброс цен, который клиенты рано или поздно замечают между собой.
Автоматизация требует, чтобы скидка стала таблицей с явными осями. Обычно их две: объём заказа и характеристика клиента или условий оплаты. Ниже — рабочий пример; конкретные ступени берутся из своей статистики сделок, а не из этой статьи.
| Условие | Скидка | Кто утверждает |
|---|---|---|
| Заказ до 100 000 ₽ | 0 % | Правило, согласование не нужно |
| Заказ 100 000–500 000 ₽ | 3 % | Правило |
| Заказ 500 000–2 000 000 ₽ | 7 % | Правило, потолок полномочий менеджера |
| Постоянный клиент: три сделки за 12 месяцев | +2 п.п. | Правило |
| Предоплата 100 % | +2 п.п. | Правило |
| Итого свыше 12 % либо ниже минимальной маржи | по решению | Руководитель отдела, с указанием причины |
Механика согласования встроена в сам документ, а не вынесена в мессенджер. Если рассчитанная скидка превышает полномочия менеджера, предложение формируется, но встаёт в статус «ждёт согласования», а кнопка отправки блокируется. Руководитель видит позицию, сумму, итоговую маржу и поле для причины; согласование занимает секунды и остаётся в журнале. Через квартал по этому журналу видно то, чего иначе не увидеть: какие именно клиенты и какие товары систематически требуют превышения, и не пора ли изменить сам прайс.
Если менеджеру разрешено согласовывать любую скидку, вернувшись «на словах», матрица становится украшением. Потолок полномочий — это не про недоверие, а про то, чтобы решение о марже принимал тот, кто за неё отвечает. Практический ориентир: потолок ставится на уровне, который закрывает 85–90 % обычных сделок, иначе согласование превращается в постоянную процедуру и его начинают обходить.
Схема расчёта в две части. Слева лестница ступеней по объёму заказа: «до 100 000 ₽ — 0 %», «100 000–500 000 ₽ — 3 %», «500 000–2 000 000 ₽ — 7 %», рядом две надбавки «постоянный клиент +2 п.п.» и «предоплата 100 % +2 п.п.». Справа развилка: итог до 12 % и выше минимальной маржи → «документ отправляется»; итог свыше 12 % или ниже минимальной маржи → «статус: ждёт согласования, отправка заблокирована» → «руководитель: сумма, маржа, причина» → «журнал согласований». Чертёжный стиль, подписи по-русски.
Нетиповые позиции: частично автоматом, остальное руками
Любая компания, которая продаёт не только со склада, упирается в позиции, которых нет в прайсе: изделие по чертежу заказчика, монтаж в нестандартных условиях, срочная доставка в отдалённый регион. В модельном потоке такая позиция встречается примерно в 18 % предложений — то есть в каждом пятом.
Соблазн автоматизировать и это велик: подставить коэффициент к похожей позиции и получить документ полностью машинным. Так делать не стоит, и причина не в технике. Ошибка в цене нетиповой позиции — самая дорогая из возможных: типовая позиция ошибается на проценты, нестандарт — в разы. Правильный сценарий устроен иначе.
- 1Типовое подставляется само
Позиции из номенклатуры попадают в документ с актуальной ценой, единицей измерения, сроком поставки и рассчитанной по матрице скидкой. Менеджер их не трогает.
- 2Нетиповое помечается и уходит в задачу
Позиция, которой нет в справочнике, отмечается как требующая расчёта, и по ней создаётся задача на сметчика, технолога или руководителя направления — с описанием, файлами и сроком.
- 3Отправка блокируется до закрытия всех позиций
Пока хотя бы одна позиция не рассчитана, документ нельзя отправить клиенту. Это единственная надёжная защита от предложения, где половина цен настоящие, а половина взята из похожего проекта прошлого года.
- 4Рассчитанная позиция возвращается в справочник
Если такую же позицию посчитали трижды за полгода, она перестаёт быть нетиповой и заводится в номенклатуру. Через год работы доля нестандарта в предложениях обычно падает на треть — не потому, что клиенты изменились, а потому, что справочник догнал реальность.
Сценарий «частично автоматом» честнее полной автоматизации ещё и потому, что он не обещает того, чего не может. Заказчик, которому продали «полностью автоматическое КП», через месяц обнаруживает, что каждое пятое предложение всё равно проходит через человека, и считает себя обманутым. Заказчик, которому сразу сказали про 18 %, видит ровно то, за что заплатил.
Цикл и экономия: расчёт на 150 предложениях в месяц
Модельная компания: оптовая торговля с монтажом, шесть менеджеров, 150 коммерческих предложений в месяц, из них около 60 доходят до счёта. Замер до автоматизации делался по журналу и по разговору с менеджерами: сколько минут уходит на каждый этап сборки документа.
| Этап | Руками | После автоматизации |
|---|---|---|
| Сбор цен, остатков и сроков по позициям | 22 минуты | 0 минут |
| Сборка документа и проверка реквизитов | 18 минут | 3 минуты |
| Расчёт и согласование скидки | 5 минут плюс 40 минут ожидания | 1 минута, согласование в один клик |
| Правка нетиповых позиций | включена в сборку | 8 минут в среднем по всем документам |
| Итого активной работы на один документ | 45 минут | 12 минут |
| Медиана цикла от заявки до счёта | 2,5 рабочих дня | 3,5 часа |
Про вторую строку расчёта стоит сказать отдельно, потому что именно её обычно завышают в коммерческих предложениях подрядчиков. Возвращённые 82,5 часа — это не «плюс 82,5 часа продаж». Часть освободившегося времени уходит в паузы, часть — в другие задачи. Считать этот эффект как прямую прибыль нельзя; корректно считать его как стоимость высвобожденного ресурса, что мы и сделали. Методика такого счёта разобрана в опорной статье о том, где отдел продаж теряет деньги.
А вот сокращение цикла с 2,5 рабочих дня до 3,5 часа в рублях мы намеренно не считаем. Влияние скорости на конверсию есть, оно заметно, но отделить его от самоотбора невозможно: на понятные и крупные запросы предложение и без автоматизации готовили быстрее. Честнее оставить эту цифру как отдельный измеримый результат проекта, а окупаемость строить на часах, которые посчитаны прямо.
Две параллельные ленты времени для одного документа. Верхняя «Руками», медиана 2,5 рабочих дня: сбор цен и остатков 22 минуты, сборка и проверка реквизитов 18 минут, ожидание согласования скидки 40 минут, плюс два больших серых промежутка «ждёт очереди» между этапами. Нижняя «После автоматизации», медиана 3,5 часа: сборка 3 минуты, согласование 1 минута, правка нетиповых позиций 8 минут, серые промежутки почти отсутствуют. Справа подпись: «активной работы 45 минут против 12 минут на документ».
Защита от ошибок цены
Когда документ формируется без участия человека, ошибка тоже становится автоматической: неверный коэффициент попадает не в одно предложение, а во все, пока кто-нибудь не заметит. Поэтому защита строится не на аккуратности, а на четырёх механизмах, которые работают сами.
- Контроль минимальной маржи. Система считает маржу по себестоимости из учётной системы и сравнивает с порогом по товарной группе. Ниже порога документ формируется, но не отправляется — уходит на согласование с указанием фактической маржи.
- Жёсткая блокировка при отрицательной рентабельности. Это единственное правило без права обхода менеджером: предложение с отрицательной маржой не отправляется вовсе. Обойти его может только владелец процесса, и такое действие всегда попадает в журнал.
- Контроль актуальности цены. Если прайс обновился между формированием предложения и выставлением счёта, система предупреждает об этом при создании счёта и показывает разницу построчно. Без этого правила счёт уезжает по цене двухнедельной давности.
- Журнал изменений и замороженная версия. Фиксируется, кто, когда и какую цену изменил вручную; версия, отправленная клиенту, замораживается и хранится вместе со сделкой. При споре о том, что именно было обещано, этот файл закрывает вопрос за минуту.
Единый порог по компании ведёт себя одинаково плохо в обе стороны: по группе с высокой наценкой он не срабатывает никогда и не защищает ни от чего, по группе с низкой — срабатывает на каждом втором документе, и менеджеры быстро учатся обходить его через дробление позиций. Пороги задаются по группам, пересматриваются раз в квартал вместе с прайсом, а частота срабатываний сама показывает, где порог выставлен неверно.
Отдельная история — счёт и то, что происходит после его отправки. Выставленный и неоплаченный счёт живёт в компании как ничейный объект: менеджер считает, что клиент помнит, клиент считает, что успеет. Здесь помогает не документ, а цепочка напоминаний об оплате, запускаемая от даты счёта и останавливающаяся по факту поступления денег. И правило из статьи о воронке, которой можно верить: у сделки с выставленным счётом всегда есть дата следующего шага.
График накопления за 12 месяцев. Синяя линия — накопленный чистый эффект по 46 875 ₽ в месяц, серая штриховая горизонталь — разовое вложение 260 000 ₽. Точка пересечения выделена и подписана «окупаемость, 5,5 месяца». Слева от графика столбик-врезка со сравнением: «112,5 часа руками» и «30 часов после», разница 82,5 часа подписана. Оси: месяцы эксплуатации и рубли.
Что нужно от компании до старта
Эта часть проекта не сокращается деньгами и почти не делается подрядчиком: он может помочь методикой и инструментами, но решения о том, какая цена правильная и какая скидка допустима, принимает компания. Планировать её надо параллельно с разработкой, а не после.
- 1Порядок в номенклатуре: 2–4 недели на справочник в 3 000 позиций. Убрать дубли, привести единицы измерения к одному виду, разметить снятые с производства позиции. Это самая долгая и самая скучная часть подготовки, и она же определяет качество результата.
- 2Единый действующий прайс: 1–2 недели. Один источник цены вместо трёх файлов у разных людей, с датой вступления в силу и ответственным за обновление.
- 3Себестоимость по товарным группам и пороги минимальной маржи: 1 неделя. Без этих цифр контроль рентабельности не включить, а без него автоматизация опасна.
- 4Утверждённый шаблон документа: 3–5 дней. Один макет, согласованный с юристом: формулировки, срок действия предложения, условия поставки и оплаты.
- 5Матрица скидок и потолок полномочий: около недели, но это управленческое решение, а не работа. Именно на нём проекты обычно и стоят: техническая часть готова, а договориться о потолке внутри компании не получается.
В сумме — 4–7 недель, частично параллельно разработке. Если ни один из пяти пунктов на старте не закрыт, честная оценка проекта увеличивается примерно на месяц, и это надо закладывать в план сразу, а не обнаруживать на третьей неделе внедрения.
Когда автоматизировать документы не надо
Порог считается тем же способом, что и экономия. Чистый эффект равен числу документов в месяц, умноженному на 33 сэкономленные минуты и на стоимость часа, минус поддержка. При ставке 750 ₽/час и поддержке 15 000 ₽/мес расходы отбиваются примерно на 37 документах в месяц, а разовая настройка в 260 000 ₽ окупается за год начиная примерно с 90 документов. Ниже этого потока проект не нужен — нужен хороший шаблон и порядок в прайсе.
- Меньше 40 предложений в месяц. Ручная сборка по нормальному шаблону обходится дешевле поддержки правил. Полезнее потратить те же недели на порядок в номенклатуре — он пригодится в любом случае.
- Каждое предложение собирается с нуля. В проектных продажах, где нестандарт не 18 %, а 80 %, автоматизировать нечего: документ всё равно считает человек. Здесь работает не генерация, а библиотека готовых блоков и расчётный файл сметчика.
- Цены меняются чаще, чем раз в неделю. При высокой волатильности закупки поддержка прайса съедает экономию: правила придётся править постоянно. Сначала — стабильный источник цены, потом автоматизация документа.
- Нет связи CRM с учётной системой и не планируется. Без неё цены и остатки в документ не попадут, а сборка «из CRM в шаблон» даёт красивый документ с недостоверными цифрами — это хуже, чем медленный документ с верными.
И общее правило, которое стоит проверить до подписания договора. Автоматизация документов не увеличивает число сделок — она убирает из процесса ожидание и ручной перенос данных. Если предложений мало или они теряются не на сборке, а раньше, те же 260 000 ₽ дадут больше эффекта на приёме и распределении заявок. Проверяется это одним замером: сколько времени в среднем проходит от обращения клиента до отправленного предложения и на каком этапе оно стоит дольше всего.
Автоматический документ хорош ровно настолько, насколько верны данные, из которых он собран. Скорость ошибку не исправляет, она её тиражирует.
