Моніторинг воронки

Автоматизація вирішує три пов'язані проблеми відділу продажів: нечесний прогноз, втрачені ліди та забуті follow-ups. Агент працює у фоні, без запиту — перевіряє воронку із заданою частотою (зазвичай раз на день вранці) і сигналізує лише тоді, коли бачить ризик. Керівник не відкриває CRM вручну: потрібні угоди надходять до нього з контекстом.

Що конкретно робить агент

1. Читає воронку з CRM. Підключається до HubSpot, Pipedrive, Salesforce, Close, Zoho або іншого джерела через API або конектор оркестратора.
2. Рахує вік угод за етапами. Якщо угода стоїть на етапі «Demo scheduled» 14 днів при середньому терміні 3 дні — це сигнал. Норми часу налаштовуються один раз за історичними даними.
3. Знаходить забуті follow-ups. Шукає угоди з активністю більше N днів тому, але в активному статусі або з високою ймовірністю.
4. Порівнює з історичним патерном. Відхилення від типової швидкості воронки підсвічується окремо — наприклад, якщо менеджер зазвичай проводить demo за 2 дні, а тут 10.
5. Формує зведення. Список угод, сума ризику, рекомендація щодо кожної: нагадати менеджеру, переглянути ймовірність, закрити як lost, запросити апдейт у клієнта.
6. Надсилає алерт. Коротке повідомлення з прямими посиланнями на картки угод у Slack, Telegram або e-mail. Одне повідомлення на день, не потік сповіщень.

Звіт короткий — 5–15 угод, не вся воронка. Керівник відкриває повідомлення вранці, витрачає кілька хвилин, делегує менеджерам або переглядає прогноз на тиждень.

Що агент не робить

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

Типові варіанти налаштування

Solo / команда 1–5

Один-два менеджери або founder-led продажі. Агент підключається до однієї CRM (часто HubSpot Free або Pipedrive), перевіряє одну воронку, надсилає алерт у Telegram або на особисту пошту. Логіка проста: угоди на етапі довше X днів, follow-up не зроблено більше Y днів. Без рольового доступу — один одержувач. Збірка за 1–2 дні, обслуговування майже нульове. Економить години на тиждень, які йшли на ручний перегляд карток, і ловить угоди, які інакше б «провалилися» через край воронки. Виправданий, коли засновник сам відповідає за продажі та веде помітну кількість угод.

SMB / 6–30 осіб

Відділ продажів із 3–8 менеджерами та керівником. Агент читає угоди за власниками, формує два різних звіти: один керівнику (ризикуючі угоди по всьому відділу), інший кожному менеджеру (його власні завислі). Додаються пороги за сумою — алерт лише для угод вище певного ARR. Канал — Slack з окремим приватним каналом для sales lead. Збірка за вихідні, потребує налаштування етапів воронки з коректними нормами часу. Починає окупатися з другого місяця: менше втрачених угод у середині воронки плюс чесніший прогноз на квартал.

Enterprise / 30+

Кілька команд (inbound, outbound, account managers), сегментація за регіонами або продуктами, інтеграція з BI-системою. Агент працює багатоканально: Slack для оперативних алертів, щотижневий зведений звіт для VP Sales у PDF, дані записуються до data warehouse для аналітики. Додаються правила за сегментами — enterprise-угоди та SMB-угоди мають різні норми часу. Підключається до Salesforce з рольовою моделлю: менеджер бачить лише свої угоди, team lead — свою команду, директор — агрегат. Збірка складніша: 2–4 тижні за участі sales ops та data-team. Виправданий, коли воронка містить сотні угод і ручний контроль неможливий.

Архітектура

Автоматизація збирається на no-code стеку: оркестратор (workflow-рушій, Make, Zapier), CRM як джерело даних, LLM для аналізу динаміки та генерації тексту алерта, канал доставки повідомлень. AI-агент на базі AI-моделі або аналогічної моделі відповідає за «наратив» — перетворює таблицю з 15 угод на читабельне повідомлення, де сказано не лише «що зависло», а й «чому це важливо саме сьогодні».

Поверх цього працює шар правил (CRM API + оркестратор) і шар інтерпретації (LLM + системний промпт з нормами команди). Розподіл важливий: правила ловлять кандидатів, LLM прибирає шум. Без LLM-шару виходить звичайний cron-алерт, без шару правил — токени витрачаються на кожну угоду і вартість володіння зростає без користі.

Потік даних за кроками

1. Тригер за розкладом.Cron в оркестраторі запускає workflow раз на день вранці, зазвичай о 8:00 за часом команди. Частоту налаштовують під ритм продажів — щодня для коротких циклів, 2–3 рази на тиждень для довгих.
2. Вивантаження угод. Запит до CRM: всі відкриті угоди на визначених етапах за останні 60–90 днів із полями власника, суми, дати останньої зміни, дати останньої активності, нотаток менеджера.
3. Нормалізація даних. Дані приводяться до єдиної структури: стадія → норма часу на стадії → фактичний час на стадії → флаг ризику → контекст активності.
4. Правило детекції. Застосовуються пороги: час на стадії > норма × 2, днів з останньої активності > N, висока ймовірність у CRM за відсутності дій менеджера, велика сума без руху.
5. LLM-шар. AI-агент отримує список кандидатів із флагами та контекст (історія команди, типова динаміка, розмір угоди, tone of voice керівника) і формує коротке повідомлення з пріоритизацією. На цьому кроці відсіюються шумні випадки.
6. Доставка. Зведення надсилається у потрібний канал: Slack channel #sales-alerts, Telegram чат керівника, e-mail digest. Угоди йдуть прямими посиланнями на картки у CRM.
7. Логування. Кожна відправка записується — хто отримав, які угоди були підсвічені, чи була реакція (чи відкрили картку, чи змінився статус). На цих логах потім коригуються пороги.

Чому AI-шар, а не чисте правило

CRM вміє сама надсилати alerts за правилами, але лише буквальні: «угода старша за 14 днів». Завдання тут інше — відрізнити угоду, яка зависла через клієнта (важливо), від угоди, яка зависла, бо менеджер у відпустці (не важливо сьогодні). LLM читає нотатки, останню активність і контекст, залишає у зведенні лише те, що справді вимагає реакції. Це знижує alert fatigue — найшвидший спосіб знищити будь-яку систему моніторингу.

Плюс LLM генерує читабельний текст: не «Deal #12345 overdue», а «Контракт з Acme завис на етапі demo три тижні, в останньому листуванні клієнт просив комерційну пропозицію — схоже, забули надіслати». Різниця у формулюванні визначає, чи відкриватиме керівник повідомлення через місяць після запуску.

Альтернативні підходи

Вибір залежить від стадії: при невеликій кількості угод на місяць ручний контроль працює. При зростанні воронки починають губитися ліди, і вбудовані алерти допомагають частково. Коли одночасно активних угод більше півсотні — без AI-шару або шум, або пропуски. Проміжний варіант — використовувати і CRM-алерти, і агента: алерти CRM для жорстких SLA (наприклад, відповідь клієнту за 24 години), агент для якісного контексту та пріоритизації.

Безпека та compliance

AI-агент працює з даними про угоди та клієнтів, тому базові вимоги: API-ключ CRM зберігається в secret manager оркестратора, не у відкритому workflow; LLM-провайдер не використовує дані для навчання (enterprise-режим або data-processing addendum у Anthropic, OpenAI, Mistral); логи очищаються від PII або зберігаються не довше 30 днів. У Slack/Telegram надходять лише короткі summary — повні дані угоди залишаються у CRM. Якщо компанія підпадає під GDPR або аналогічні режими, потрібно переконатися, що регіон обробки даних збігається з вимогами і що DPA підписано з постачальником LLM. Для внутрішніх команд достатньо базової рольової моделі на стороні CRM — агент успадковує її обмеження.

Що має бути готово до старту

1. CRM з коректно налаштованими етапами воронки. Не п'ять штук на oko — реальні стадії, через які проходять угоди. HubSpot, Pipedrive, Salesforce, Close, Zoho — будь-яка, де є API та стабільні поля.
2. Історія угод хоча б за 3 місяці. Агент використовує її, щоб порахувати норми часу на кожну стадію. Без історії алерти будуть або надто часті, або надто рідкі — нема на чому калібрувати.
3. Канал для сповіщень. Slack workspace або Telegram bot з доступом для керівника. E-mail працює, але гірше — легко загубиться в потоці, відкриваність нижча.
4. Один відповідальний отримувач. Людина, яка буде читати ранковий алерт і реагувати. Без цього автоматизація перетворюється на ще один мовчазний канал і тихо вмирає.
5. No-code оркестратор.low-code платформа self-hosted, Make або Zapier. Вибір залежить від бюджету, вимог до хостингу даних і стеку команди.
6. Дисципліна введення даних у CRM. Менеджери мають закривати активності, рухати угоди по стадіях, ставити коректні ймовірності. Без цього сигнал буде зашумлений і агент скаржитиметься на угоди, які насправді в порядку.
7. Згода на обробку даних LLM-провайдером. Короткий документ від юриста або позначка в договорі, що дані про угоди надходять у хмару постачальника моделі.

Чого НЕ потрібно

• Окремої data-team або аналітика на full-time.
• Власного BI-стеку (Tableau, Power BI, Looker).
• Кастомної ML-моделі — LLM загального призначення справляється.
• Переходу на нову CRM — агент працює з поточною, якою б вона не була.
• Зміни процесів продажів — агент вбудовується в існуючий workflow, не нав'язує новий.

Можливі підводні камені

• Погана гігієна CRM. Якщо половина угод висить на етапі «New» місяцями, бо ніхто не чистить воронку, агент кричатиме про них щодня. Перший тиждень після запуску — чистка, потім тонке налаштування порогів.
• Надто чутливі пороги. Починаєте з time-on-stage × 1.5 — отримуєте десятки алертів на день, керівник вимикає канал. Стартуйте з × 2–3, звужуйте поступово в міру зростання довіри до сигналу.
• Немає власника процесу. Якщо алерт іде «у відділ», а не конкретній людині, реакції не буде. Один отримувач, один відповідальний — інакше система тихо вмирає через місяць.
• LLM без контексту команди. Якщо агенту не передати середню довжину угоди, типовий розмір ARR і tone of voice команди, він буде підсвічувати все однаково і писати загальними фразами. Короткий системний промпт з нормами — обов'язковий.
• Змішування ролей в одному workflow. Якщо агент одночасно алертить, пише листи клієнтам і рухає угоди — це вже не моніторинг. Розділіть функції по окремих workflow; цей — лише про раннє попередження.