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

Автоматизация решает три связанные проблемы отдела продаж: нечестный прогноз, потерянные лиды и забытые 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 с корректно настроенными этапами воронки. Не пять штук на глаз — реальные стадии, через которые проходят сделки. 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; этот — только про раннее предупреждение.