Ежемесячный отчёт: почему сделки выигрываются или сливаются
Что делает
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 не сможет компенсировать это полностью — он восстановит часть из переписки и звонков, но точность упадёт. Перед запуском проводится audit полноты данных и устраняются критичные пробелы.
Что нужно
Внедрение опирается на доступ к данным 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.
Что делать со сделками с очень коротким циклом?
Сделки с циклом меньше двух недель агрегируются отдельной секцией без глубокого разбора каждой. Для них акцент идёт на агрегатных паттернах: источники лидов, типичные возражения на первом контакте, конверсия по сегментам. Глубокий разбор остаётся для сделок с длинным циклом, где данных по переписке, звонкам и стадиям больше и есть что анализировать.
Хотите такую автоматизацию в своём бизнесе?
Запишем на бесплатный аудит — покажем, как это будет работать именно у вас.