AI-генерация персонализированных коммерческих предложений

Почему AI генерация КП буксует на реальных каталогах

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

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

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

Третий — версионирование цен и условий. Прайс обновляется чаще, чем кто-либо успевает его перепроверять, актуальная версия нигде не помечена, а скидочная матрица живёт вне системы. Именно здесь появляется основная доля ошибок в коммерческих предложениях: устаревшая цена, потерянная строка, условие из прошлого прайса. На подготовку такого документа уходит несколько дней, и часть этого времени уходит на перепроверку, а не на работу с клиентом.

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

Что меняется после внедрения: скорость, точность, охват

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

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

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

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

Режимы подготовки предложений: шаблоны, правила, модели

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

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

Этапы внедрения: от аудита данных до приёмки на сделках

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

1. Аудит данных. Инвентаризуем источники: записи CRM, историю сделок, прайсы, каталог, складские остатки, шаблоны договоров. Смотрим полноту полей, дубли, расхождения в единицах и неактуальные позиции — здесь видно, что вообще допустимо подавать в генерацию.
2. Схема потоков данных. Фиксируем, какое поле откуда берётся, где нормализуется и что не покидает контур заказчика. Схема становится основой интеграции и критерием проверки результата.
3. Настройка правил генерации. Задаём допустимые диапазоны скидок и обязательные блоки: срок действия, условия поставки и оплаты. Формулировки модель варьирует, коммерческие условия — нет.
4. Проверка на исторических сделках. Прогоняем генерацию на закрытых сделках и сравниваем с версиями, которые менеджеры отправляли вручную. Каждое расхождение указывает на правило, которого мы не описали.
5. Доступы и журнал. Разграничиваем права на изменение правил и просмотр цен, включаем журналирование: видно, кто, когда и на каких данных получил предложение.
6. Приёмка на реальных сделках. Пилот на группе менеджеров с метриками: доля предложений, ушедших клиенту без правок, время подготовки, число ошибок в условиях сделки. Дальше передача — регламент обновления правил и прайсов, обучение менеджеров, ответственный за качество данных.

Что передаём на руки: правила генерации, схемы, регламенты

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

• Библиотека утверждённых формулировок — текстовые блоки по продуктам, отраслям и этапам сделки с пометкой, где формулировка обязательна юридически, а где допустима вариативность; письмо собирается только из этого набора.
• Схема интеграций — какие системы отдают данные (учётная система, база клиентов, каталог), в каком виде и как часто; отдельно отмечены точки отказа и поведение при недоступности источника.
• Политики доступа — кто видит шаблоны, кто правит формулировки и кто выпускает письмо; разграничение по ролям и журнал действий.
• Регламент проверки — порядок выпуска: автоматическая проверка на запрещённые утверждения, гарантии и персональные данные, затем подтверждение ответственного, затем отправка.
• Документация решения — логика сборки, словарь полей, инструкция по добавлению нового продукта или сегмента без правок кода.
• Набор эталонных примеров — пары «входные данные → корректное предложение», по которым проверяют качество после каждой правки шаблонов.
• Порядок передачи — рабочая сессия с вашей командой, чек-лист приёмки и период сопровождения после запуска.

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

Кейс: как ускорили подготовку предложений и убрали ошибки

Отдел продаж промышленного поставщика: восемь менеджеров, 40–60 коммерческих предложений в неделю по каталогу из нескольких сотен позиций. До автоматизации каждое КП собирали вручную — копировали позиции из таблиц, пересчитывали скидку, согласовывали условия в переписке. На один документ уходило от двух до трёх часов, и примерно каждое восьмое предложение уходило с расхождением в цене или комплектации.

Что перестроили в потоке данных

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

Что изменилось

Среднее время подготовки предложения сократилось с двух-трёх часов до 15–20 минут: менеджер правит готовый черновик, а не собирает документ. Доля КП с расхождениями в цене и комплектации упала с 12% до менее чем 1%, а число предложений в неделю выросло примерно на треть при том же штате.

«Раньше мы сверяли каждую строку вручную, и всё равно что-то проскакивало, — говорит руководитель отдела продаж. — Теперь спорные места система подсвечивает до отправки». «Мы наконец видим, какие формулировки и условия чаще приводят к сделке, и тиражируем их на остальные сегменты», — добавляет коммерческий директор.

Что делать, если каталог, цены и сделки живут в разных системах

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

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

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

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

Частые технические сомнения и ограничения решения

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

Кто отвечает за качество и стиль текста?

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

Где генерация заведомо не сработает?

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

Что с безопасностью данных?

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

Кто отвечает, если в документе ошибка?

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

Обсудим вашу задачу: что прислать для оценки и плана

Чтобы вернуться с оценкой проекта, а не с абстрактной вилкой, нам нужен минимум вводных. Без них состав работ приходится домысливать, и на старте проекта оценка расходится с реальностью.

• 20–30 уже отправленных коммерческих предложений: и те, что клиент подписал, и те, что ушли без ответа — по ним видно, какие блоки обязательны, а какие менеджеры дописывают руками.
• Источники данных для персонализации: выгрузка из CRM, каталог, история сделок, отраслевые признаки клиентов. Подойдёт любая выгрузка в таблицу, лишь бы были видны поля.
• Описание сегментов и правил: чем предложение для крупного заказчика отличается от розничного, какие условия подставляются автоматически, а какие утверждает руководитель.
• Шаблон и требования к оформлению: фирменные блоки, обязательные формулировки, ограничения по объёму.
• Ограничения на генерацию: что нельзя выводить без человека — цены, сроки, гарантии, персональные данные и коммерческие условия клиента.
• Сценарий запуска: кто формирует предложение, из какой системы оно уходит, нужна ли вычитка перед отправкой.
• Доступы для работы: тестовый контур и обезличенная копия данных — на них проверяем качество текста, не затрагивая рабочую базу.
• Критерии приёмки: чем вы будете измерять результат — долей предложений без правок, временем на подготовку, числом полей, заполняемых автоматически.

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