# 08. Алерты и автодействия: отчёт, который сам приходит вовремя

| | |
|---|---|
| **Статус** | v1.2 (Q3 2027) |
| **Тариф** | «Корпоративный» и выше |
| **Зависимости** | [02-architecture.md](../02-architecture.md) §2 (поток live), [08-api.md](../08-api.md) (вебхуки) |

## Проблема

Аналитика сегодня приходит через сутки — когда клиент уже ушёл, а менеджер забыл, что обещал.
Отчёт «в марте было 42 конфликта» не помогает в момент конфликта. Ценность разговора
заканчивается вместе с разговором, а вся речевая аналитика построена на разборе post factum.

## Решение

**Правила реального времени + действия, а не только письмо с алертом.**

Конвейер live (см. [02-architecture.md](../02-architecture.md) §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 алертов |

## Этапы

1. **v1.2:** вебхуки по правилам, лента событий, дедупликация, коннектор Битрикс24.
2. **v1.3:** конструктор «событие → действие» без разработчика, шаблоны отраслей, amoCRM/Telegram.
3. **2028:** обратные действия — например, автоматическая передача звонка на повторный контакт
   при выявленном риске оттока.

## Монетизация

Входит в «Корпоративный» и выше — это главный аргумент перехода с «Бизнес» (разница
90 000 ₽/мес) для контакт-центров, где важна скорость реакции. В продажах фича закрывает
возражение «у нас уже есть отчёты»: отчёт — это про прошлое, алерт — про деньги сейчас.

## Почему этого нет у других

- **SaaS для продаж** дают готовые отчёты и чек-листы post factum; реакция в реальном времени
  остаётся ручной.
- **Модули телефонии** умеют уведомлять о событиях телефонии (пропущенный звонок), но не о
  содержании разговора.
- **API-конструкторы** — только вебхуки по готовому результату: логику реакции клиент пишет сам.
- **Enterprise-вендоры** умеют правила и триггеры, но это часть дорогого проекта.
- **Наша основа** — live-обработка на локальной LLM: классификация на арендованном GPU
  позволяет гонять правила по каждому звонку, а не по выборке.