AI-автоматизація генерації комерційних пропозицій: під ключ

Автоматизація комерційних пропозицій: де ламається процес

Менеджер збирає комерційну пропозицію вручну: номенклатуру виписує з каталогу, ціни — з прайс-таблиці, умови — з листування за схожою угодою. На один документ витрачається кілька годин, а сама заявка весь цей час живе в пошті й ніде не зафіксована як завдання зі строком.

Погодження цін і знижок відбувається там же, у листах: керівник отримує цифру без історії розрахунку й уточнює її назад, менеджер чекає на відповідь.

Швидкість відповіді клієнту падає до доби й більше — за цей час він встигає зібрати пропозиції від конкурентів і порівняти умови, а початкова ціна та знижка підтверджуються вже неактуальними.

Окрема проблема — різні версії документа. Правки вносять у копію файлу, підсумок у таблиці перераховують вручну, і ніхто не може впевнено сказати, яка версія пішла клієнту.

Якщо після відправлення змінюється обсяг або знижка, розрахунок роблять заново, і частина заявок губиться на етапі розрахунку — їх просто не дораховують.

Ціна такого процесу — не лише години менеджера, а й угоди, які йдуть мовчки, без зрозумілої причини відмови. Нижче розбираємо, як це закривається: на якому кроці втрачається час і що потрібно змінити в ланцюжку.

Що дає автоматизація: ефект у строках і якості

Підготовка комерційної пропозиції — це збірка з різних джерел: ціни в одному файлі, умови в іншому, знижка погоджується в листуванні. Автоматизація змінює сам принцип: менеджер вибирає клієнта та позиції, система підставляє актуальні ціни, умови й шаблон. Цикл підготовки стискається з годин до хвилин, а правка вноситься до відправлення, а не після.

Єдине джерело цін — не спільна папка, а довідник із правами доступу, історією змін і прив’язкою до груп клієнтів. Ціна правиться в одному місці й одразу потрапляє в усі пропозиції; документ, надісланий місяць тому, не розійдеться із сьогоднішнім. Це ж знімає вічне питання, чия версія цін правильна.

Розрахунок — найчастіше джерело розбіжностей: відсотки від бази, знижки, податки й округлення на довгій специфікації. За галузевими оцінками Deloitte, помітна частка помилок у комерційних документах виникає саме під час ручного перенесення даних.

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

Окремо закриваються повторні запити клієнта: схожа комплектація збирається з історії угод за пару кроків. Як наслідок, зникає цілий клас відмов — пропозиція більше не йде із застарілою ціною, чужими умовами або арифметичною помилкою в підсумковій сумі.

Варіанти збірки документів: порівняння підходів

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

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

Щойно з’являються нестандартні умови угоди — розстрочка, прив’язка платежів до етапів, гарантійні застереження — складач формує чернетку й віддає її менеджеру на підтвердження, а не надсилає клієнту напряму.

Практичний висновок: гібридний режим закриває більшість сценаріїв — генерація за даними угоди плюс обов’язкове підтвердження на позиціях із нестандартними умовами.

Так типові пропозиції йдуть за хвилини, а ризик надіслати клієнту неправильні умови залишається на менеджері, а не на автоматиці.

Етапи впровадження: від розбору процесів до передачі

Порядок етапів тут не формальність. Якщо почати з генерації тексту, отримаємо охайні документи з неправильними цифрами, а розбиратися доведеться вже на живих клієнтах. Спочатку фіксуємо, як продаж насправді влаштований, і лише потім переносимо цю логіку в систему.

1. Аудит процесу продажів. Розбираємо, хто і на якому кроці готує документ, які погодження проходить знижка і де пропозиція затримується найдовше.
2. Схема джерел даних. Фіксуємо, звідки беруться ціни, залишки, умови клієнта та історія угод, і яке правило діє при розбіжності між системами.
3. Правила розрахунку та знижок. Переносимо у явну логіку те, що раніше трималося на досвіді менеджера: межі знижок за категоріями, вартість опцій, умови відстрочки. Винятки залишаються, але з зрозумілим порогом погодження.
4. Пілот на одному типі документів. Запускаємо генерацію на одному шаблоні й одній товарній групі — розбіжності видно на живих угодах, поки контур вузький і правки дешеві.
5. Перевірка на історичних угодах. Проганяємо закриті угоди через нові правила й звіряємо результат із фактичними документами. Частка збігів — об’єктивний критерій готовності, а розбіжності показують, яке правило описано неповно.
6. Передача в контур замовника. Віддаємо регламенти, доступи й інструкції для менеджерів, налаштовуємо оповіщення про помилки. Система залишається всередині ваших процесів, а не на нашому стенді.

Що залишається у замовника: конфігурації та регламенти

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

• Опис правил генерації — які блоки обов’язкові, які залежать від сегмента, суми й умов оплати, а які підставляються з картки угоди. Правила зберігаються окремим набором, а не в коді, тому формулювання змінює власник процесу.
• Налаштовані сценарії збірки — по одному на кожен тип пропозиції: первинна, повторна, тендерна, партнерська. У сценарії закріплені джерела даних, умови спрацювання та порядок блоків.
• Шаблони й бібліотека формулювань — фірмове оформлення з підстановкою полів і готові варіанти тексту під сегменти; правляться без перезбирання рішення.
• Розмежування доступу — ролі менеджера, керівника й редактора правил: хто запускає збірку, хто змінює правила та шаблони, хто бачить історію. Права видаються за роллю, а не вручну кожному.
• Регламент роботи з документами — версіонування, точки погодження, строки зберігання, порядок заміни або відкликання документа. Окремо описані ручні кроки, якщо вони залишаються.
• Інструкція для відділу продажів — як запустити збірку, що перевірити перед відправленням, як передати на доопрацювання й куди дивитися при розбіжності даних.
• Журнал змін — хто і коли правив правила, шаблони й доступи; у спірній ситуації видно причину розбіжності.

Кейс: тендерні пакети замість ручної збірки

Перші тендерні пакети відділ продажів збирав вручну: реквізити — з картки угоди, описи — зі старих листів, додатки — з папки на спільному диску.

На один пакет витрачалося 6–8 годин, і кожен третій повертався на доопрацювання через чужий шаблон, застарілу редакцію або пропущений додаток. За потоку в десяток запитів на місяць частина тендерів не доходила до відправлення — просто не встигали зібрати.

Метрики до і після

Механіка змінилася не в обсязі тексту, а в точці докладання зусиль.

Дані угоди тягнуться з Битрикс24 — реквізити, склад поставки, умови; формулювання беруться з бібліотеки готових блоків із версіонуванням, тому повторне використання не перетворюється на копіювання застарілих редакцій.

Система збирає чернетку й залишає незаповнені поля видимими — їх знаходять на перевірці, а не на підписі.

Перевірка документа людиною залишається обов’язковим кроком: менеджер звіряє склад, умови та додатки, після чого пакет фіксується як фінальна редакція. Автовідправлення немає — рішення завжди за відповідальним.

«Раніше про проблему в пакеті я дізнавався від клієнта. Тепер менеджер приносить готовий документ, і мій розбір займає десять хвилин замість години», — керівник відділу продажів.

Чим відрізняється підстановка в шаблон від генерації за змістом?

Підстановка змінних — детермінована операція: є заготовка, є довідник значень, на виході той самий документ за однакових даних.

Вона передбачувана й легко перевіряється построковим порівнянням версій, але структура та логіка тексту задані заздалегідь і під склад конкретної угоди не підлаштовуються.

Генерація за змістом угоди йде від структурованого опису: склад позицій, галузь замовника, етап переговорів, обмеження та типові заперечення. Формулювання збираються під цей контекст, а не вибираються розгалуженням умов.

Блок про строки й порядок робіт у дистриб’ютора та у виробничого холдингу відрізняється за змістом, а не за підставленою назвою.

Обидва підходи ламаються на типових помилках у документах. Підстановка дає залишкові фрагменти чужого шаблону, розсинхрон одиниць і строків між розділами, різні написання однієї організації, неузгоджені припущення.

Генерація додає свій клас ризиків — варіативність там, де потрібна буквальна точність: реквізити, дати, умови оплати, гарантійні формулювання.

Тому в робочій схемі незмінні поля беремо підстановкою з довідника, а змістові блоки — обґрунтування вибору, опис ефекту, відповіді на заперечення — генеруємо.

Зверху ставиться валідація: перевірка обов’язкових полів, звірка версій документа, контрольний список перед відправленням.

Орієнтир для вибору простий. Якщо більша частина тексту повторюється від угоди до угоди — достатньо підстановки. Якщо змінюється склад аргументації — потрібна генерація за змістом із жорсткими обмеженнями на незмінні поля.

За розборами типових помилок у комерційній документації більшість дефектів — не про стиль, а про неузгодженість даних між розділами: якість формулювань починається з того, що всі числа та строки мають одне джерело.

Що уточнюють перед стартом: обмеження та ризики

Перед стартом ми розбираємо технічні сумніви, які найчастіше спливають на другій-третій зустрічі: як рішення поведеться на вашій обліковій базі, хто відповідає за неправильно порахований рядок у документі й що вважається результатом першого етапу.

Нижче — п’ять питань, які ми ставимо самі, щоб не переносити їх у середину робіт. За кожним заздалегідь домовляємося про критерій приймання.

Що робити з нестандартними умовами та ручними застереженнями?

Типові позиції йдуть у правила, нетипові — у редагований блок із явною позначкою, що розрахунок за ними потребує участі менеджера. Так автоматизація не підмінює експертизу, але перестає гальмувати на кожній угоді.

Як перевіряються розрахунки?

Рахуємо контрольні приклади на історичних угодах і звіряємо підсумок із тим, що виставлялося вручну. Розбіжність — не привід «поправити на око», а сигнал знайти правило, яке її породило.

Хто відповідає за помилку в готовій пропозиції?

Відповідальність розподіляємо за етапами: збій збору даних, логіка розрахунку й фінальне відправлення — різні зони. Договір фіксує, які класи помилок закриває система і де обов’язкова перевірка людиною.

Яким буде перший етап?

Перший етап — обмежений контур: один продуктовий потік або тип угоди, із заміром часу підготовки та частки документів без ручних правок. Далі розширюємо за результатами, а не за планом.

Обговоримо завдання: що підготувати до розмови

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

Вхідні дані для оцінки:

• 5-10 комерційних пропозицій, які вважаєте вдалими, і 2-3 слабкі — за ними видно цільовий стиль, структуру та межі допустимого;
• джерела даних: каталог, прайс-листи, умови знижок і строків, звідки система має брати позиції;
• шаблон і вимоги до оформлення: обов’язкові блоки, юридичні формулювання, брендові елементи;
• правила погодження: хто і на якому етапі перевіряє пропозицію перед відправленням клієнту;
• обмеження: недопустимі формулювання, конфіденційні дані, вимоги до того, де зберігаються матеріали;
• обсяг роботи: скільки пропозицій готуєте на місяць і в який строк потрібна відповідь замовнику;
• доступи: тестовий контур облікової системи або знеособлене вивантаження, щоб перевірити рішення на ваших даних.

Порядок етапів впровадження розбираємо на першій зустрічі: поточний процес, прототип на ваших матеріалах, погодження правил перевірки, запуск у робочий контур і навчання співробітників.

Після розбору повернемося з оцінкою та планом робіт — зі строками, складом команди й точками контролю.

Готові обговорити завдання у зручному форматі: опишіть її у вільній формі — цього достатньо, щоб почати.