Чому AI-генерація КП буксує на реальних каталогах
Практично будь-яка автоматизація підготовки КП упирається в одне й те саме місце: пропозиція збирається руками з даних, які лежать у чотирьох-п’яти непов’язаних джерелах.
Позиції — у вивантаженні з облікової системи, характеристики — у каталозі постачальника, ціни та умови — в окремій таблиці, історія по клієнту — у CRM. Менеджер копіює рядки, звіряє артикули очима й склеює текст вручну, бо жодне джерело не є для інших опорним.
Перший технічний збій — відсутність єдиного ключа зіставлення. Артикул в обліковій системі, каталожний номер постачальника й код на сайті майже ніколи не збігаються один в один, а складені позиції збираються з комплектувальних, яких у прайсі немає окремими рядками.
Без шару нормалізації та нечіткого зіставлення модель підтягує характеристики від сусідньої позиції: рядок виглядає коректним, але описує інший товар — і це йде клієнту.
Другий — некерована термінологія. Той самий товар у джерелах названо по-різному, синоніми й скорочення ніде не зведені, одиниці виміру змішані.
Поки немає керованого довідника синонімів і правил приведення назв, AI-генерація КП або копіює формулювання постачальника дослівно, або переписує його так, що в пропозиції з’являються неіснуючі опції та несумісні комплектації.
Третій — версіонування цін та умов. Прайс оновлюється частіше, ніж будь-хто встигає його переперевіряти, актуальна версія ніде не позначена, а знижкова матриця живе поза системою.
Саме тут виникає основна частка помилок у комерційних пропозиціях: застаріла ціна, загублений рядок, умова з минулого прайсу. На підготовку такого документа йде кілька днів, і частина цього часу йде на переперевірку, а не на роботу з клієнтом.
Розбираємо, як це закривається: опорний довідник, нормалізація позицій і генерація поверх перевірених даних, а не поверх сирих вивантажень.
Що змінюється після впровадження: швидкість, точність, охоплення
Термін підготовки пропозиції перестає залежати від завантаження менеджера: запит потрапляє в обробку, і система збирає комерційну пропозицію з картки угоди, каталогу й історії листування.
Замість кількох годин ручного верстання документ готовий до надсилання за хвилини, а типова пропозиція збирається взагалі без участі людини.
Персоналізація пропозицій тримається на єдиному джерелі даних.
Систему підключають до облікової системи — наприклад, до угод у Бітрікс24, — до каталогу й прайсу: асортимент, умови та знижкова логіка беруться звідти, а текст адаптується під галузь, масштаб і завдання конкретного клієнта.
Ніхто не переносить дані руками, тому описи й цифри в документі завжди відповідають актуальним даним.
Зниження ручної роботи помітне за часткою правок після надсилання. Коли ціни та умови підставляються автоматично, пропозицію не доводиться перевипускати через розбіжності — частка повернень на доопрацювання падає з десятків відсотків до поодиноких випадків.
Цілий клас помилок — застарілий прайс, чужий шаблон, загублений блок умов — зникає, бо в нього більше немає носія: ручного збирання.
Охоплення зростає без розширення команди. Менеджер звільняється від верстання й витрачає час на переговори, тому обсяг надісланих пропозицій збільшується в рази за того самого складу відділу. Керівник при цьому бачить рух за всіма запитами цілком, без загублених у пошті.
Режими підготовки пропозицій: шаблони, правила, моделі
Жоден із режимів не витісняє інші — вони закривають різні ділянки підготовки пропозиції. Шаблонна генерація тримає структуру й обов’язкові блоки, правила підбору рішень визначають склад, збирання тексту моделлю відповідає за формулювання під конкретного клієнта.
Що підійде у вашому випадку, залежить від кількості змінних в угоді та від того, наскільки строго потрібно контролювати текст.
| Режим | Коли підходить | Межі застосовності |
|---|---|---|
| Жорсткий шаблон | Короткий цикл, стандартна послуга, потік однотипних угод | Формулювання не змінюються під галузь і масштаб клієнта |
| Правила підбору рішень | Каталог послуг із явними умовами застосовності | Потрібен описаний каталог; правила супроводжують за кожної зміни складу |
| Збирання тексту моделлю | Потрібен розгорнутий текст під конкретного клієнта | Потрібні перевірка фактів і жорсткі обмеження за структурою |
| Генерація за даними угоди | В угоді накопичено історію, галузь, склад запиту, минулі домовленості | Якість падає там, де поля не заповнені або застаріли |
На практиці режими стикуються в один контур. Правила підбору рішень збирають склад із каталогу, модель розкриває кожен пункт під галузь і масштаб замовника, а шаблон задає незмінний каркас — блок умов, строків і відповідальності, який не переписується генерацією.
Кожен результат зберігається з версією та вихідними даними угоди, тому пропозицію можна відтворити, порівняти з попередньою редакцією або відкотити, якщо змінилися ввідні.
Етапи впровадження: від аудиту даних до приймання на угодах
Порядок етапів жорсткий: генерація починається не з тексту, а з даних, і перестрибнути аудит не вийде. Якщо джерело віддає застарілий прайс або порожнє поле, модель видасть правдоподібну, але хибну пропозицію — і помилка піде клієнту під нашим іменем.
- Аудит даних. Інвентаризуємо джерела: записи CRM, історію угод, прайси, каталог, складські залишки, шаблони договорів. Дивимося на повноту полів, дублі, розбіжності в одиницях і неактуальні позиції — тут видно, що взагалі допустимо подавати в генерацію.
- Схема потоків даних. Фіксуємо, яке поле звідки береться, де нормалізується і що не покидає контур замовника. Схема стає основою інтеграції та критерієм перевірки результату.
- Налаштування правил генерації. Задаємо допустимі діапазони знижок і обов’язкові блоки: термін дії, умови постачання та оплати. Формулювання модель варіює, комерційні умови — ні.
- Перевірка на історичних угодах. Прогонимо генерацію на закритих угодах і порівнюємо з версіями, які менеджери надсилали вручну. Кожна розбіжність указує на правило, якого ми не описали.
- Доступи та журнал. Розмежовуємо права на зміну правил і перегляд цін, вмикаємо журналювання: видно, хто, коли і на яких даних отримав пропозицію.
- Приймання на реальних угодах. Пілот на групі менеджерів з метриками: частка пропозицій, що пішли клієнту без правок, час підготовки, кількість помилок в умовах угоди. Далі передача — регламент оновлення правил і прайсів, навчання менеджерів, відповідальний за якість даних.
Що передаємо на руки: правила генерації, схеми, регламенти
Проєкт з AI-генерації комерційних пропозицій закрито не тоді, коли модель видала першу чернетку, а коли замовник може змінювати правила генерації сам, без нас.
Тому на виході залишається не набір налаштувань в особистому кабінеті, а комплект артефактів, який можна читати, версіонувати й передавати новим співробітникам.
- Бібліотека затверджених формулювань — текстові блоки за продуктами, галузями та етапами угоди з позначкою, де формулювання обов’язкове юридично, а де допустима варіативність; лист збирається тільки з цього набору.
- Схема інтеграцій — які системи віддають дані (облікова система, база клієнтів, каталог), у якому вигляді та як часто; окремо позначено точки відмови й поведінку за недоступності джерела.
- Політики доступу — хто бачить шаблони, хто править формулювання і хто випускає лист; розмежування за ролями та журнал дій.
- Регламент перевірки — порядок випуску: автоматична перевірка на заборонені твердження, гарантії та персональні дані, потім підтвердження відповідального, потім надсилання.
- Документація рішення — логіка збирання, словник полів, інструкція з додавання нового продукту або сегмента без правок коду.
- Набір еталонних прикладів — пари «вхідні дані → коректна пропозиція», за якими перевіряють якість після кожної правки шаблонів.
- Порядок передачі — робоча сесія з вашою командою, чек-лист приймання та період супроводу після запуску.
Кожен пункт проходить приймання: якщо регламент не можна виконати без нас, повертаємося й доопрацьовуємо.
Кейс: як прискорили підготовку пропозицій і прибрали помилки
Відділ продажів промислового постачальника: вісім менеджерів, 40–60 комерційних пропозицій на тиждень за каталогом із кількох сотень позицій. До автоматизації кожне КП збирали вручну — копіювали позиції з таблиць, перераховували знижку, узгоджували умови в листуванні.
На один документ ішло від двох до трьох годин, і приблизно кожна восьма пропозиція йшла з розбіжністю в ціні або комплектації.
Що перебудували в потоці даних
Каталог, правила знижок і типові умови винесли в єдине джерело, з якого генератор бере дані. Менеджер заповнює картку угоди — галузь, обсяг, строки, набір позицій, — а система збирає чернетку: підбирає формулювання під сегмент і рахує підсумок за актуальним прайсом.
Перед надсиланням документ проходить перевірки: ціна, наявність, термін постачання, збіг умов зі знижкою. Дані про угоди залишилися в Бітрікс24 — другого джерела заводити не довелося.
Що змінилося
Середній час підготовки пропозиції скоротився з двох-трьох годин до 15–20 хвилин: менеджер править готову чернетку, а не збирає документ.
Частка КП з розбіжностями в ціні та комплектації впала з 12% до менш ніж 1%, а кількість пропозицій на тиждень зросла приблизно на третину за того самого штату.
«Раніше ми звіряли кожен рядок вручну, і все одно щось проскакувало, — каже керівник відділу продажів. — Тепер спірні місця система підсвічує до надсилання».
«Ми нарешті бачимо, які формулювання та умови частіше приводять до угоди, і тиражуємо їх на інші сегменти», — додає комерційний директор.
Що робити, якщо каталог, ціни та угоди живуть у різних системах
Каталог лежить в обліковій системі, ціни — у прайсах постачальників, угоди та історія замовлень — у CRM, залишки — у складському контурі. Поки пропозицію збирає менеджер, розбіжності він править руками й дорогою помічає.
Щойно AI-генерація КП бере збирання на себе, будь-яка розбіжність іде в документ і далі до клієнта — тому питання не в моделі, а в тому, звідки вона бере дані.
Сталих способів роботи з розрізненими джерелами три, і вибирають між ними за частотою зміни цін і вимогами до свіжості.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Запит до джерел на льоту | Ціни змінюються щодня, каталог невеликий | Залежність від доступності всіх систем: збій однієї — КП не зібрати |
| Регламентне вивантаження в проміжний шар | Потрібна швидкість і стійкість до збоїв джерел | Дані відстають на цикл оновлення, потрібен контроль розсинхронізації |
| Єдиний довідник як майстер-система | Каталог і правила цін спільні для всіх каналів | Потрібен власник довідника й регламент внесення змін |
Від замовника в будь-якому варіанті потрібні доступи до джерел тільки на читання, відповідальний за зіставлення позицій і рішення, яка система головна за конфлікту цін.
Стелю всієї схеми задає якість вихідних даних. Якщо позиція трапляється в трьох написаннях, а ціна вказана без терміну дії та кратності, синхронізація каталогу пройде, але КП все одно піде з помилкою.
Нормалізація на вході — артикул, одиниця виміру, кратність, період дії ціни — потрібна до того, як генерація отримає доступ до даних.
Часті технічні сумніви та обмеження рішення
Сумніви тут технічні, і спливають вони до старту, а не після. Нижче — прямі відповіді: де генерація ламається, як улаштований контроль тексту, що відбувається з даними і хто відповідає за помилку в готовому документі.
Як обробляється нетипова номенклатура?
Генерація спирається на каталог: артикули, характеристики та правила сумісності. Позиції без картки не досочуються — вони йдуть у список винятків на ручне доопрацювання менеджеру.
Хто відповідає за якість і стиль тексту?
Перед надсиланням документ проходить перевірки: обов’язкові блоки, цифри та строки звіряються з джерелом, заборонені обіцянки відсікаються правилами. Останнє слово — за менеджером, він затверджує версію.
Де генерація наперед не спрацює?
Тендери з жорсткою формою, нестандартні схеми постачання, унікальні технічні вимоги. Там система збирає чернетку й підказує, яких даних бракує, а логіку дописує інженер.
Що з безпекою даних?
Розмежування доступу за ролями, журнал дій за кожним документом, шифрування під час передавання та зберігання. Дані замовника не використовуються для навчання сторонніх моделей.
Хто відповідає, якщо в документі помилка?
Зону відповідальності фіксуємо в регламенті: правила перевірок, шаблони та журнали — наша частина, фактичні умови угоди підтверджує замовник. Журнали дають змогу відновити, звідки взялося конкретне формулювання.
Обговоримо ваше завдання: що надіслати для оцінки та плану
Щоб повернутися з оцінкою проєкту, а не з абстрактною вилкою, нам потрібен мінімум ввідних. Без них склад робіт доводиться домислювати, і на старті проєкту оцінка розходиться з реальністю.
- 20–30 уже надісланих комерційних пропозицій: і ті, що клієнт підписав, і ті, що пішли без відповіді — за ними видно, які блоки обов’язкові, а які менеджери дописують руками.
- Джерела даних для персоналізації: вивантаження з CRM, каталог, історія угод, галузеві ознаки клієнтів. Підійде будь-яке вивантаження в таблицю, аби було видно поля.
- Опис сегментів і правил: чим пропозиція для великого замовника відрізняється від роздрібної, які умови підставляються автоматично, а які затверджує керівник.
- Шаблон і вимоги до оформлення: фірмові блоки, обов’язкові формулювання, обмеження за обсягом.
- Обмеження на генерацію: що не можна виводити без людини — ціни, строки, гарантії, персональні дані та комерційні умови клієнта.
- Сценарій запуску: хто формує пропозицію, з якої системи вона йде, чи потрібна вичитка перед надсиланням.
- Доступи для роботи: тестовий контур і знеособлена копія даних — на них перевіряємо якість тексту, не зачіпаючи робочу базу.
- Критерії приймання: чим ви будете міряти результат — часткою пропозицій без правок, часом на підготовку, кількістю полів, що заповнюються автоматично.
Якщо частина даних закрита, скажіть про це відразу: підберемо схему, за якої навчання йде на знеособлених прикладах, а робоча база залишається у вас.
Опишіть завдання у вільній формі — повернемося з оцінкою та планом впровадження за етапами, з явно вказаними припущеннями та тим, що потрібно уточнити до старту.
