Implementation scenario / 02 / Revenue control
Контроль пропущенных лидов и SLA
CRM хранит лид, но не сообщает вовремя, что нет ответа, ответственного или следующего действия.
Событийный слой отслеживает SLA, контекст обращения и бездействие, затем возвращает риск менеджеру и руководителю. Финальное решение и работа с исключениями остаются у ответственного: Руководитель определяет SLA и разбирает исключения; система отвечает за обнаружение, а не за дисциплинарные решения.
Проверить применимость сценария →
Problem / buying moment
Почему этот процесс становится задачей для руководителя.
Обычно к сценарию «Контроль пропущенных лидов и SLA» приходит коммерческий директор, руководитель продаж или собственник, когда воронка формально заполнена, но выручка всё ещё зависит от личного контроля руководителя. В этот момент локальная ручная проверка уже не масштабируется, но покупка отдельного AI-инструмента ещё не гарантирует изменения процесса.
В продажах ценность создаёт не ещё один отчёт, а своевременное действие: назначить ответственного, вернуть лид, зафиксировать следующий шаг или остановить ошибочное обещание.
ПОЗИЦИЯ IT WHITEРезультат этого сценария — не «внедрённый AI», а управляемое изменение показателей: лиды без реакции, медиана первого ответа, возврат лидов в работу. Система должна обнаруживать событие, объяснять контекст и доводить его до ответственного действия.
Target operating model
Что именно меняется после внедрения.
Как разобрать именно этот сценарий.
У этого сценария есть понятный момент, когда ручной процесс перестаёт выдерживать нагрузку. Исходная ситуация формулируется так: CRM хранит лид, но не сообщает вовремя, что нет ответа, ответственного или следующего действия. Для коммерческий директор, руководитель продаж или собственник это уже не локальное неудобство сотрудника, потому что сбой отражается на показателе «лиды без реакции» и со временем становится нормой, которую команда перестаёт замечать. До проектирования мы берём несколько реальных событий, восстанавливаем последовательность действий и отделяем причину от симптома.
Контур данных начинается не с единого хранилища, а с минимального набора доказательств. Bitrix24 или amoCRM фиксирует первичное событие; Telegram даёт контекст или состояние работы; источники лидов подтверждает следующий шаг и результат. Для каждого поля определяется источник, допустимая задержка и правило отсутствующего значения. Если событие нельзя восстановить, его нельзя безопасно использовать для автоматического решения.
Рабочая логика сценария выглядит конкретно: Событийный слой отслеживает SLA, контекст обращения и бездействие, затем возвращает риск менеджеру и руководителю. При этом система не подменяет владельца процесса. Руководитель определяет SLA и разбирает исключения; система отвечает за обнаружение, а не за дисциплинарные решения. Такое разделение нужно зафиксировать в интерфейсе, правах доступа и журнале действий, иначе формальный human-in-the-loop останется надписью в презентации, а человек будет подтверждать решение без достаточного контекста.
Главный негативный сценарий тоже проектируется заранее: Избыточные уведомления быстро превращают контроль в шум, поэтому нужна приоритизация событий. Поэтому у пилота должны быть порог уверенности, маршрут исключения, возможность открыть первичные данные и понятный способ отменить действие. Ошибку нельзя прятать в среднем показателе: команда отдельно разбирает ложные срабатывания, пропущенные события и ситуации, где правило сработало правильно, но не привело к действию.
Руководитель принимает решение о масштабировании по трём наблюдаемым изменениям: «лиды без реакции», «медиана первого ответа» и «возврат лидов в работу». Сначала фиксируется базовая линия, затем одна зона работает в режиме пилота, а сравнение проводится на сопоставимом потоке. Целевой бизнес-результат: лиды без реакции, медиана первого ответа, возврат лидов в работу. Если изменение держится только благодаря ручному контролю разработчика, система ещё не готова к эксплуатации.
Architecture
AI не получает власть над процессом. Он получает ограниченную роль.
- Bitrix24 или amoCRM
- Telegram
- источники лидов
Руководитель определяет SLA и разбирает исключения; система отвечает за обнаружение, а не за дисциплинарные решения.
Избыточные уведомления быстро превращают контроль в шум, поэтому нужна приоритизация событий.
Каждый вывод хранит исходное событие, версию правила или модели и действие ответственного. Если контекста недостаточно, система не угадывает, а переводит событие на ручную проверку.
Business case / no invented ROI
Экономика начинается с потери, которую можно пересчитать.
До сметы мы не обещаем проценты эффективности. Сначала измеряем частоту события, стоимость ручной работы и ошибки, нагрузку на проверяющего и цену эксплуатации контура.
объём событий, в которых возникает проблема «CRM хранит лид, но не сообщает вовремя, что нет ответа, ответственного или следующего действия.»
стоимость ручного действия, задержки или ошибки по показателю «лиды без реакции»
доля исключений, которые после запуска всё равно должен проверять человек
стоимость интеграции и сопровождения систем: Bitrix24 или amoCRM, Telegram, источники лидов
Если измеримый эффект не покрывает стоимость контура и риск, задачу не нужно превращать в отдельный продукт.
Measurement
Как понять, что внедрение работает.
Источник: Bitrix24 или amoCRM. Базовая линия: 2–4 недели до пилота.
Источник: Telegram. Базовая линия: 2–4 недели до пилота.
Источник: источники лидов. Базовая линия: 2–4 недели до пилота.
Сначала проверяем процесс, качество данных и владельца решения.
Избыточные уведомления быстро превращают контроль в шум, поэтому нужна приоритизация событий.
Readiness check
Когда этот сценарий имеет смысл.
Автоматизация оправдана, когда проблема повторяется, влияет на управляемый показатель и у процесса есть владелец. Для сценария «Контроль пропущенных лидов и SLA» сначала проверяем не модель, а фактический маршрут работы.
- 01Повторяемость
Событие повторяется достаточно часто, чтобы измерять «лиды без реакции».
- 02Доступность данных
Первичные данные доступны в системах: Bitrix24 или amoCRM, Telegram, источники лидов.
- 03Владелец решения
Владелец процесса готов отвечать за исключения и финальное решение.
- 04Ограниченный риск
Риск «Избыточные уведомления быстро превращают контроль в шум, поэтому нужна приоритизация событий.» можно ограничить правилами, журналом и ручной проверкой.
Questions before code
Что нужно выяснить до выбора технологии.
Ответы отделяют реальную задачу от красивой демонстрации. Они же задают границы пилота и критерии остановки.
- Q1
Сколько раз за неделю возникает ситуация: CRM хранит лид, но не сообщает вовремя, что нет ответа, ответственного или следующего действия.
- Q2
Где сегодня фиксируется лиды без реакции и можно ли восстановить исходное событие?
- Q3
Кто принимает решение после сигнала и за какое время он должен отреагировать?
- Q4
Какие ошибки системы недопустимы и когда решение обязательно передавать человеку?
Pilot / 4–8 weeks
Как запускать без большой ставки вслепую.
Зафиксировать текущий маршрут
Интервью с владельцем процесса, карта событий, исключения, права доступа и исходные значения KPI. На этом этапе может выясниться, что проблему надёжнее решает обычная логика, а не AI.
Собрать минимальный контекст
Подключаем только необходимые источники: Bitrix24 или amoCRM, Telegram, источники лидов. Не строим озеро данных до появления первого работающего сценария.
Запустить на ограниченной зоне
Событийный слой отслеживает SLA, контекст обращения и бездействие, затем возвращает риск менеджеру и руководителю. Первые решения логируются, а низкая уверенность и исключения уходят человеку.
Сравнить с базовой линией
Смотрим на лиды без реакции, медиана первого ответа, возврат лидов в работу. Если процесс не изменился, не масштабируем интерфейс только ради уже написанного кода.
Пилот принимается по изменению лиды без реакции, медиана первого ответа, возврат лидов в работу, а не по количеству экранов и промптов.
Останавливаем масштабирование, если данные нестабильны, ответственный не использует сигнал или сохраняется риск: Избыточные уведомления быстро превращают контроль в шум, поэтому нужна приоритизация событий.
How IT WHITE enters the project
Не продаём всю систему до проверки процесса.
100–180 тыс. ₽
Карта процесса, данные, потери, владелец решения, варианты архитектуры и предварительная экономика.
от 450 тыс. ₽
Одна ключевая задача, необходимые интеграции, роли, журнал решений, запуск и критерии результата.
от 100 тыс. ₽/мес.
Мониторинг, исправления, качество решений, новые правила, развитие интеграций и отчёт по работе системы.
Decision FAQ
Три вопроса, которые защищают проект от лишней сложности.
Здесь точно нужен AI?
Не обязательно. Если событие определяется стабильными правилами, обычная логика будет дешевле, быстрее и надёжнее. AI нужен там, где решение зависит от неструктурированного контекста.
Что подготовить к первичному разбору?
Один реальный пример сбоя, список систем (Bitrix24 или amoCRM, Telegram, источники лидов), пример исходных данных и человека, который сегодня принимает финальное решение.
Что происходит при ошибке?
Система сохраняет исходные данные и причину вывода, не выполняет критическое действие без разрешения и передаёт исключение человеку. Главный риск сценария: Избыточные уведомления быстро превращают контроль в шум, поэтому нужна приоритизация событий.
Evidence base
На каких рыночных сигналах основан сценарий.
Материал синтезирует публичные исследования и практики. Мы не переносим чужие кейсы на себя и не обещаем чужие показатели. Экономика рассчитывается только после анализа вашего процесса.
Related scenarios / Продажи и CRM
Следующие процессы в том же контуре.
Fit check / 20–30 min
Проверим сценарий «Контроль пропущенных лидов и SLA» на вашем процессе.
За 20–30 минут определим разрыв, доступные данные, владельца решения и разумный первый контур. Это бесплатная проверка соответствия задачи, не платная диагностика.