продажи

Как автоматизировать подготовку КП

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

Автоматизация коммерческого предложения начинается с управляемых данных, а не с генерации красивого текста. Рабочий контур должен принять запрос клиента, выделить позиции и условия, сопоставить их с актуальным каталогом, получить цену из разрешённого источника, собрать документ по шаблону и передать менеджеру все спорные места. ИИ полезен для чтения письма, спецификации и свободного описания, но не должен придумывать артикулы, цены или обещания. Первый пилот лучше ограничить одним типом запросов и одним шаблоном. Главный KPI — время от получения полного запроса до готового проверенного черновика; ограничители — доля ручных исправлений, критические ошибки и использование сотрудниками.

Оглавление

Кому актуальна автоматизация КП

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

Автоматизация полезна и при небольшом числе предложений, если каждое требует дорогой экспертной работы. Однако ценность будет не в массовой генерации, а в подготовке: найти подходящие позиции, отметить расхождения, собрать подтверждённые данные и оставить эксперту решения, влияющие на обязательства компании.

Почему процесс тормозит

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

Признаки проблемного процесса:

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

Такие симптомы требуют карты данных и правил. Генеративная модель без этого сделает ошибку более аккуратно оформленной, но не менее опасной.

Из чего состоит правильный контур

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

Третий слой — нормализация и сопоставление. Название клиента сравнивается с утверждённым каталогом. Если соответствие однозначно, система подставляет карточку. Если есть несколько вариантов, менеджер получает выбор. Если позиции нет, создаётся исключение, а не выдуманный товар. Четвёртый слой — расчёт по бизнес-правилам и актуальным данным. Пятый — сборка документа и контроль обязательных блоков. Шестой — подтверждение и запись результата в CRM.

Экономика

Ниже — условный расчёт, который показывает структуру, но не прогнозирует эффект конкретной компании.

| Операция | До пилота | Условно после | Объём в месяц | |---|---:|---:|---:| | Разбор запроса | 15 мин | 6 мин | 180 | | Поиск позиций | 25 мин | 12 мин | 180 | | Сборка документа | 20 мин | 7 мин | 180 | | Финальная проверка | 8 мин | 12 мин | 180 |

Финальная проверка в примере стала дольше: сотрудник должен осмысленно подтвердить предложенные позиции и условия. При этом полный цикл сокращается с 68 до 37 минут. Высвобождение составляет условные 180 × 31 / 60 = 93 часа в месяц. Если расчётная стоимость часа равна 1 100 ₽, ресурс оценивается в 102 300 ₽. Из него вычитают стоимость решения и сопровождения.

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

Готовое решение или разработка

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

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

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

Схема подготовки

[Письмо + вложение]
          │
          ▼
[Извлечение требований] ──► [Список недостающих данных]
          │
          ▼
[Сопоставление с каталогом]
          │
     ┌────┴────┐
     ▼         ▼
[Совпадение] [Исключение → эксперт]
     │         │
     └────┬────┘
          ▼
[Цена и условия из разрешённых источников]
          │
          ▼
[Черновик КП → проверка менеджера → отправка]
          │
          ▼
     [CRM + журнал версии]

Эта схема запрещает модели перескакивать через источник цены или решение эксперта. Каждый спорный элемент остаётся видимым до отправки.

План внедрения

  1. Выбрать тип КП. Ограничить продуктовую группу, канал и шаблон.
  2. Разобрать реальные кейсы. Включить полные, неполные и ошибочные запросы.
  3. Назначить источники истины. Зафиксировать каталог, цену, реквизиты, условия и владельца каждого источника.
  4. Определить обязательные проверки. Цена, валюта, единицы, срок, налоги, версия и согласование.
  5. Собрать извлечение. Показывать происхождение каждого поля и направлять неопределённость в исключения.
  6. Настроить сопоставление. Отделить точное соответствие, предложенный аналог и отсутствие позиции.
  7. Собрать шаблон. Компоновать утверждённые блоки без свободного обещания условий.
  8. Запустить с подтверждением. Менеджер проверяет расчёт, текст и вложения до отправки.
  9. Измерить цикл и качество. Сравнить сопоставимый поток с базовой линией.
  10. Расширять по одному измерению. Добавлять продуктовую группу, шаблон или канал, но не всё сразу.

Как принять пилот

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

Полезно разделить исправления на четыре класса. Первый — извлечение: система неверно прочитала исходный запрос. Второй — справочник: правильного значения нет или оно устарело. Третий — правило: расчёт или маршрут не соответствует политике. Четвёртый — интерфейс: менеджер не понял предупреждение или пропустил обязательную проверку. У каждого класса свой владелец и способ исправления; простое «донастроить ИИ» скрывает причину.

Пилот считается готовым к расширению, когда главный KPI достигнут на сопоставимом потоке, критические ограничения выполнены, сотрудники действительно используют новый маршрут, а команда сопровождения умеет разбирать исключения. Если результат зависит от ручной работы разработчика за кулисами, это демонстрация, а не работающий процесс. Решение о следующем этапе и оставшиеся риски фиксируют письменно.

Как поддерживать шаблон после запуска

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

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

Статистика ручных изменений помогает улучшать компоненты. Частое удаление одного абзаца может говорить о неверном правиле применения, а не о низком качестве генерации. Решение принимает владелец шаблона после разбора причин.

Ошибки

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

Не стоит автоматизировать нестабильный шаблон, который каждый руководитель трактует по-своему. Сначала согласуйте обязательные блоки и правила исключений. Нельзя считать все сэкономленные минуты финансовым результатом без понимания, как используется высвобождённая мощность. И не следует удалять человеческую проверку только ради красивого показателя скорости.

Чек-лист

  • [ ] Выбран один тип запросов и один шаблон КП.
  • [ ] Для каталога, цены и условий назначены источники истины.
  • [ ] Извлечённые поля связаны с фрагментом входа.
  • [ ] Аналоги всегда обозначаются отдельно.
  • [ ] Неопределённые позиции попадают эксперту.
  • [ ] Расчёты выполняются правилами, а не языковой моделью.
  • [ ] Менеджер подтверждает коммерчески значимые данные.
  • [ ] Версия документа и источников сохраняется.
  • [ ] Измеряются полный цикл, исправления и критические ошибки.
  • [ ] Есть безопасный ручной маршрут при сбое.

FAQ

Можно ли полностью автоматически отправлять КП клиенту?

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

Что автоматизировать первым: текст или расчёт?

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

Подойдёт ли готовый генератор документов?

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

Связанное решение

Commercial Desk объединяет разбор входящего запроса, сопоставление данных и подготовку проверяемого черновика КП в одном рабочем маршруте.

Разберите маршрут одного КП

Чтобы оценить потенциал без автоматизации опасных решений, запишитесь на разбор процесса. Команда возьмёт один типовой запрос, обозначит источники истины, исключения и KPI пилота.