08. Алерты и автодействия: отчёт, который сам приходит вовремя
| Статус | v1.2 (Q3 2027) |
| Тариф | «Корпоративный» и выше |
| Зависимости | Архитектура: пайплайн, стек, безопасность §2 (поток live), Спецификация API v1: загрузка и вебхуки (вебхуки) |
Проблема
Аналитика сегодня приходит через сутки — когда клиент уже ушёл, а менеджер забыл, что обещал. Отчёт «в марте было 42 конфликта» не помогает в момент конфликта. Ценность разговора заканчивается вместе с разговором, а вся речевая аналитика построена на разборе post factum.
Решение
Правила реального времени + действия, а не только письмо с алертом.
Конвейер live (см. Архитектура: пайплайн, стек, безопасность §2) уже даёт результат за минуты. На этот поток накладываются правила:
| Правило (настраивается клиентом) | Типовое действие |
|---|---|
| Конфликт / оскорбление / угроза расторжения | Задача руководителю группы + карточка звонка, SLA реакции 15 минут |
| Упоминание конкурента | Тег в CRM + в отчёт маркетинга |
| Клиент назвал крупную сумму или объём | Пуш аккаунт-менеджеру |
| Оператор не выполнил обязательную фразу (критичную) | Уведомление ОКК и запись в лист развития |
| Низкая уверенность классификации | Очередь ручного контроля |
Куда доставляем: вебхук в систему заказчика, задача в CRM (шаблонные коннекторы: Битрикс24, amoCRM), Telegram/почта для дежурных, а также внутри продукта — в ленте событий.
Анти-спам как обязательная часть. Дедупликация по звонку и правилу, группировка («12 конфликтов за час по одной кампании» — одно уведомление, а не двенадцать), эскалация по необработанным алертам, «тихие часы». Правило без настроенной реакции не публикуется — иначе аналитика превращается в шум, который все отключают.
Как это выглядит
- Экран «Правила и действия»: конструктор «событие → условие → действие» с тестом на
историческом звонке.
- Лента событий с фильтром по статусу: новое / принято / закрыто, время реакции.
- Отчёт «Что дали алерты»: сколько событий, сколько обработано, среднее время реакции,
сколько денег вернули (если есть связь с CRM).
- API:
POST /v1/rules,GET /v1/events, вебхукevent.triggeredс тем же HMAC-подписыванием.
Метрики успеха
| Метрика | Цель |
|---|---|
| Задержка от окончания звонка до алерта | ≤ 30 минут (p95) |
| Доля ложных срабатываний | ≤ 10 % после двух недель настройки |
| Доля алертов с зафиксированной реакцией | ≥ 70 % |
| Эффект (по данным CRM клиента) | возврат ≥ 1 клиента на 100 алертов |
Этапы
- v1.2: вебхуки по правилам, лента событий, дедупликация, коннектор Битрикс24.
- v1.3: конструктор «событие → действие» без разработчика, шаблоны отраслей, amoCRM/Telegram.
- 2028: обратные действия — например, автоматическая передача звонка на повторный контакт
при выявленном риске оттока.
Монетизация
Входит в «Корпоративный» и выше — это главный аргумент перехода с «Бизнес» (разница 90 000 ₽/мес) для контакт-центров, где важна скорость реакции. В продажах фича закрывает возражение «у нас уже есть отчёты»: отчёт — это про прошлое, алерт — про деньги сейчас.
Почему этого нет у других
- SaaS для продаж дают готовые отчёты и чек-листы post factum; реакция в реальном времени
остаётся ручной.
- Модули телефонии умеют уведомлять о событиях телефонии (пропущенный звонок), но не о
содержании разговора.
- API-конструкторы — только вебхуки по готовому результату: логику реакции клиент пишет сам.
- Enterprise-вендоры умеют правила и триггеры, но это часть дорогого проекта.
- Наша основа — live-обработка на локальной LLM: классификация на арендованном GPU
позволяет гонять правила по каждому звонку, а не по выборке.
Исходный markdown