Розробка AI-системи прогнозування угод у воронці продажів

Чому прогнозування угод розходиться з фактом

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

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

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

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

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

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

Що змінюється після впровадження моделі у воронку

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

Частка правильних прогнозів за етапами зростає з 55 до 78%, а розбіжність між очікуваним і фактичним виторгом видно за 3-4 тижні до кінця періоду, а не у звітний день.

Точність за етапами воронки

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

Калібрування перераховується на закритих угодах: ймовірність 70% означає, що закривається приблизно 7 угод із 10, і на це можна спиратися в плануванні.

Менше ручної роботи керівника

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

Підготовка прогнозу займає 20-30 хвилин замість кількох годин на тиждень — час іде на розбір відхилень, а не на арифметику.

Прозорість воронки дає раннє попередження про ризики: угода з падаючою активністю або зсунутим терміном позначається за 2-3 тижні до того, як це помітить менеджер.

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

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

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

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

Коли історії мало, а прогноз потрібен

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

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

Етапи впровадження: від аудиту даних до передачі

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

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

Аудит вивантажень і цільова метрика

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

Перевірка на історичних періодах

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

Артефакти впровадження: схема, модель, регламент

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

Схема даних і ознаки

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

Регламент перенавчання та моніторингу

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

Кейс: прогнозування угод стало точнішим

Відділ продажів із 20 менеджерів прогнозував місяць за вагою етапу у воронці Бітрікс24: угода на етапі узгодження договору вважалася закритою з імовірністю 70%.

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

Вихідна точка та обмеження

Перший замір на трьох місяцях історії дав 54% влучань, а за великими угодами помилка сягала 38% від суми.

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

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

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

Результат у цифрах

Через сім тижнів від старту, з яких два пішли на узгодження ознак із відділом, модель видавала прогноз за кожною угодою та за місяцем загалом.

Точність на горизонті місяць зросла з 54% до 87%, середня помилка за сумою угоди — з 38% до 11%, розбіжність плану та факту скоротилася з 2,3 до 1,1 раза.

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

Чим модель відрізняється від звіту за воронкою?

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

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

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

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

Модель проти правил

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

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

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

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

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

У нас коротка історія угод — даних вистачить?

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

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

Що буде, якщо ми змінимо етапи воронки?

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

Хто відповідає за модель після запуску?

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

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

Обговоримо задачу та повернемося з планом впровадження

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

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

Вимоги до даних ми формулюємо самі й надсилаємо списком полів із типами та очікуваною повнотою.

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

Що знадобиться для старту проєкту:

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

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