Щомісячний звіт: чому угоди виграються або зливаються
Що робить
AI-агент Grow2.ai розбирає кожну закриту угоду з CRM і формує щомісячний звіт про причини перемог і програшів. Знання про те, чому угоду виграно або провалено, перестають існувати лише в головах продавців і потрапляють у документ, який читає вся команда — від комерційного директора до продактів і маркетингу. Замість ручного збору даних із різних джерел перед кожним ретро відділ отримує структурований наратив із готовими сегментами і цитатами.
Ось що робить агент у рамках одного циклу:
- Отримує список угод, закритих за звітний період (won і lost), з фільтрацією за pipeline і командою.
- Підтягує по кожній угоді історію листування, транскрипти дзвінків, нотатки продавців, поля кваліфікації, тривалість стадій і власника угоди.
- З'єднує дані з поведінковими метриками з data warehouse: відвідування сайту, продуктові події, активність у тріалі.
- Класифікує причини програшу і фактори виграшу за узгодженою з командою таксономією — ціна, тайминг, конкурент, фіт продукту, якість процесу продажу, внутрішні політичні фактори у клієнта.
- Вилучає повторювані заперечення, сигнали ризику і формулювання клієнтів у вигляді цитат із зазначенням угоди і стадії, де вони прозвучали.
- Сегментує результати за типом клієнта, джерелом ліда, продуктом, продавцем і тривалістю циклу.
- Зводить усе в structured markdown-звіт: TL;DR на одну сторінку, ключові інсайти, розбір окремих угод і додатки з raw-даними.
Чого автоматизація не робить
- Не проводить win/loss-інтерв'ю з клієнтом. Якісна розмова з втраченим клієнтом як і раніше потребує живої людини і навичок інтерв'юера.
- Не замінює sales-аналітика і не приймає рішень. Стратегічні висновки щодо ICP, цін або продуктових пріоритетів залишаються за командою.
- Не прогнозує майбутнє. Звіт описує що сталося і чому, але не прогнозує результат відкритих угод і не видає scoring поточного пайплайна.
Документ читають комерційний директор, head of sales, продакт-менеджери і маркетинг. Sales-команда отримує зворотний зв'язок без ручного перелопачування CRM перед кожним ретро. Продакт бачить сигнали з реальних розмов із втраченими клієнтами. Маркетинг розуміє, які сегменти виграються легше і де провисає messaging або таргетинг.
Як працює
AI-агент Grow2.ai працює за розкладом (раз на місяць або за тригером закриття угод) і проходить чотири етапи: збір даних, нормалізація, аналіз через LLM, формування звіту. Реалізація — кастомний код на Python або TypeScript з оркестрацією через workflow-рушій або скрипт за cron, без візуальних no-code конструкторів через складність промптів і обсяг даних.
Технічний потік
- Збір даних. Скрипт звертається до CRM (HubSpot, Salesforce, Pipedrive) через REST API і забирає всі угоди зі статусом closed_won або closed_lost за період. Для кожної угоди підтягуються пов'язані сутності: контакти, нотатки, активності, email-треди.
- Збагачення з data warehouse. До угоди приєднуються поведінкові дані: сторінки сайту, продуктові події, статус тріалу. Джерело — Snowflake, BigQuery, Postgres-репліка або BI-вітрина.
- Транскрипти дзвінків. Якщо у команди підключені Gong, Fireflies, tldv або Otter — агент підтягує транскрипти і нотатки по угодах через їхній API.
- Нормалізація і chunking. Сирі дані приводяться до єдиного JSON-об'єкта на угоду і розрізаються на смислові блоки для LLM.
- Аналіз через AI-модель. Кожна угода проходить через кілька промптів: класифікація за таксономією, витяг цитат і заперечень, оцінка факторів виграшу або програшу. Результати складаються у структурований JSON.
- Агрегація. Результати по всіх угодах зводяться у сегменти, рахуються патерни, виявляються повторювані теми і сигнали.
- Генерація звіту. Фінальний промпт перетворює структуровані дані на наратив на 5-10 сторінок з TL;DR, інсайтами, розбором ключових угод і додатками.
- Доставка. Готовий звіт публікується в Notion, Confluence або відправляється у Slack-канал команди продажів.
Кроки впровадження
- Погодити таксономію причин програшу і факторів виграшу з head of sales (1-2 зустрічі).
- Отримати read-only доступ до CRM, data warehouse і системи запису дзвінків.
- Зібрати датасет із 30-50 закритих угод за минулий період для калібрування промптів.
- Написати пайплайн збору і нормалізації даних.
- Налаштувати промпти під мовну модель і валідувати якість класифікації на розміченій вибірці.
- Запустити перший звіт вручну, обговорити з командою, скоригувати таксономію і промпти.
- Поставити пайплайн за розкладом і налаштувати алерти на збої.
Компоненти
Компонент | Призначення | Типовий вибір |
|---|---|---|
CRM-конектор | Джерело угод і активностей | HubSpot, Salesforce, Pipedrive API |
Data warehouse | Поведінкові метрики | Snowflake, BigQuery, Postgres |
LLM | Аналіз, класифікація, наратив | LLM |
Оркестрація | Розклад і pipeline | оркестратор або Python-скрипт + cron |
Зберігання результатів | Архів звітів | Notion, Confluence, S3 |
Якість звіту залежить від двох речей: чистоти даних у CRM (заповненість полів, причин програшу, нотаток дзвінків) і узгодженості таксономії. Якщо 40% угод мають поле причини програшу порожнім, LLM не зможе компенсувати це повністю — він відновить частину з листування і дзвінків, але точність впаде. Перед запуском проводиться аудит повноти даних і усуваються критичні прогалини.
Що потрібно
Впровадження спирається на доступ до даних CRM, data warehouse і базову готовність команди до розбору win/loss. Чим чистіші й повніші дані на вході, тим сильніший звіт на виході.
Доступ і дані
- CRM з історією угод. Мінімум 6 місяців із заповненими базовими полями (стадія, дата закриття, власник, причина втрати). HubSpot, Salesforce, Pipedrive підключаються через стандартні API.
- Data warehouse або BI-вітрина. Snowflake, BigQuery, Postgres-репліка або еквівалент із продуктовими та поведінковими даними. Опціонально, але підвищує якість аналізу.
- Транскрипти дзвінків. Gong, Fireflies, tldv, Otter або внутрішня система. Без транскриптів звіт будується на переписці та нотатках, але втрачає нюанси.
- Узгоджена таксономія. Список причин втрати та факторів виграшу від head of sales — 8-15 категорій для кожної сторони.
- Сервісний акаунт з read-only правами в CRM, data warehouse і системі запису дзвінків.
- Майданчик для публікації звіту — Notion, Confluence або Slack-канал команди продажів.
Готовність команди
- Head of sales або RevOps як owner проекту, готовий брати участь у калібруванні таксономії та валідації перших звітів.
- Один технічний співробітник або підрядник для інтеграцій і підтримки пайплайну.
- Sales-команда, готова отримувати й обговорювати висновки — без культури розбору win/loss звіт перетворюється на файл, який ніхто не відкриває.
Терміни
2-4 тижні від kickoff до першого автоматичного звіту. Перший тиждень — узгодження таксономії та аудит даних, другий — розробка пайплайну і калібрування промптів, третій і четвертий — пілотний запуск, обговорення з командою і постановка на розклад.
Болі
- Не бачимо сигналів відходу клієнтів
- Час на ручні звіти
- Знання в головах, не в документах
FAQ
За скільки можна запустити рішення?
Стандартний строк — 2-4 тижні від kickoff до першого автоматичного звіту. Перший тиждень іде на погодження таксономії причин програшу та аудит даних у CRM. Другий — на розробку пайплайна збору та калібрування промптів під AI-модель. Третій і четвертий — пілотний звіт, обговорення з командою та постановка на розклад. Якщо в CRM є серйозні прогалини за полями нотаток і причин програшу, додасться 1-2 тижні на очищення даних.
Що робити, якщо в CRM не заповнюються причини програшу?
Це типова ситуація і вона вирішується частково. AI-агент відновить частину причин із листування, нотаток і транскриптів дзвінків — там клієнти часто проговорюють те, чого немає в полях. Але якщо 40% угод мають порожні поля і немає записів дзвінків, точність класифікації впаде. У таких випадках паралельно з автоматизацією вводиться дисципліна заповнення полів при закритті угоди — інакше будь-який інструмент дасть слабкий результат.
Які основні ризики і де автоматизація ламається?
Три основних ризики. Перший — сміття на вході: порожні поля, відсутність нотаток і дзвінків дають слабкий звіт. Другий — неузгоджена таксономія: якщо команда розуміє категорії «ціна» і «конкурент» по-різному, висновки виходять розмитими. Третій — відсутність культури розбору win/loss: навіть технічно ідеальний звіт без обговорення на ретро перетворюється на файл, який ніхто не відкриває. Всі три ризики знімаються на етапі підготовки, а не пайплайна.
Чи підходить рішення для нашої індустрії?
Рішення є універсальним для B2B-відділів продажів з циклом угоди від місяця. Найкраще працює в SaaS і Tech, де є продуктові дані та записи дзвінків з покупцями. В індустріях з дуже коротким циклом — e-commerce, ритейл — цінність нижча, тому що фокус зміщується на конверсію воронки та аналітику когорт, а не на розбір окремих угод. Для B2B-послуг, агентств і enterprise-софта формат підходить без змін.
Чи можна отримувати звіт частіше, ніж раз на місяць?
Так, частоту налаштовує команда. Раз на тиждень працює в командах із великим обсягом угод — від 50 закриттів на тиждень. При менших обсягах тижневий звіт дає слабку статистичну базу: краще накопичувати за місяць або квартал. Додатково можна налаштувати алерти на окремі угоди з нестандартними паттернами — наприклад, програш великому клієнту з високим lead score.
Що робити з угодами з дуже коротким циклом?
Угоди з циклом менше двох тижнів агрегуються окремою секцією без глибокого розбору кожної. Для них акцент іде на агрегатних паттернах: джерела лідів, типові заперечення на першому контакті, конверсія за сегментами. Глибокий розбір залишається для угод із довгим циклом, де даних за листуванням, дзвінками та стадіями більше і є що аналізувати.
Хочете таку автоматизацію в своєму бізнесі?
Запишемо безкоштовний аудит — покажемо, як це працюватиме саме для вас.