AI-квалификация и маршрутизация лидов

Начинать нужно с наблюдаемого сбоя, а не с выбора модели. Исходная ситуация формулируется так: Менеджеры вручную читают обращения, поздно отделяют целевой спрос от шума и по-разному назначают ответственных. Для коммерческий директор, руководитель продаж или собственник это уже не локальное неудобство сотрудника, потому что сбой отражается на показателе «время до назначения» и со временем становится нормой, которую команда перестаёт замечать. До проектирования мы берём несколько реальных событий, восстанавливаем последовательность действий и отделяем причину от симптома.

Контур данных начинается не с единого хранилища, а с минимального набора доказательств. CRM фиксирует первичное событие; формы и мессенджеры даёт контекст или состояние работы; телефония подтверждает следующий шаг и результат. Для каждого поля определяется источник, допустимая задержка и правило отсутствующего значения. Если событие нельзя восстановить, его нельзя безопасно использовать для автоматического решения.

Рабочая логика сценария выглядит конкретно: Модель извлекает намерение, продукт, бюджет и срочность, после чего правила CRM назначают очередь, SLA и следующий шаг. При этом система не подменяет владельца процесса. Сотрудник подтверждает неоднозначные лиды и меняет критерии квалификации; AI не закрывает сделку самостоятельно. Такое разделение нужно зафиксировать в интерфейсе, правах доступа и журнале действий, иначе формальный human-in-the-loop останется надписью в презентации, а человек будет подтверждать решение без достаточного контекста.

Главный негативный сценарий тоже проектируется заранее: Нельзя обучать приоритет на исторических данных, если в них закреплена плохая сегментация или дискриминация. Поэтому у пилота должны быть порог уверенности, маршрут исключения, возможность открыть первичные данные и понятный способ отменить действие. Ошибку нельзя прятать в среднем показателе: команда отдельно разбирает ложные срабатывания, пропущенные события и ситуации, где правило сработало правильно, но не привело к действию.

Руководитель принимает решение о масштабировании по трём наблюдаемым изменениям: «время до назначения», «доля лидов с полными данными» и «конверсия квалифицированных лидов». Сначала фиксируется базовая линия, затем одна зона работает в режиме пилота, а сравнение проводится на сопоставимом потоке. Целевой бизнес-результат: время до назначения, доля лидов с полными данными, конверсия квалифицированных лидов. Если изменение держится только благодаря ручному контролю разработчика, система ещё не готова к эксплуатации.