AI-квалификация не должна автоматически объявлять заявку «хорошей» или «плохой». Её задача — до первого контакта собрать контекст, проверить обязательные признаки, отделить явный спам, определить срочность и направить обращение тому менеджеру, который способен продолжить разговор без повторного опроса клиента.
Надёжная система сочетает детерминированные правила и модель. Правила отвечают за жёсткие ограничения — географию, тип клиента, запрещённые категории, существующий договор.
AI извлекает смысл из свободного текста, нормализует потребность и предлагает категорию. Итоговое решение остаётся объяснимым: менеджер видит факторы оценки, исходные данные и причину маршрута.
Где менеджер теряет время
Заявки приходят из формы, почты, чата, телефонии и мессенджеров. На входе система связывает их с компанией или контактом, удаляет технические дубли и проверяет согласие на обработку данных. Затем извлекает продукт, задачу, сроки, масштаб и следующий ожидаемый шаг.
Рабочий кейс · K33. У K33 первичная квалификация начинается с web-анкеты: workflow оценивает ответы, может автоматически назначить встречу или отправить отказ, а допущенный лид перед формальным onboarding проходит подтверждение менеджером через Slack. Дальше данные уходят в AML-систему уже в контролируемом статусе. Что я бы забрала в работу: это хороший пример того, что квалификация — не один score модели, а последовательность проверяемых условий, статусов и ручных gates для спорных или рискованных случаев. Источник: n8n ↗
Что я проверю в воронке до запуска
Словарь признаков согласуется с продажами до разработки. Для каждого поля укажите источник, допустимую свежесть и влияние на решение.
Например, отрасль может приходить из формы, CRM или внешнего справочника. Эти значения не всегда совпадают. Система должна сохранять происхождение и не заменять подтверждённое значение догадкой из текста.
Порог приоритета выбирают не по красивой точности модели, а по пропускной способности команды и цене пропуска. Если high-priority очередь больше, чем менеджеры способны обработать в SLA, дополнительный recall не приносит пользы.
Нужен совместный расчёт: сколько заявок можно принять, сколько уточнить автоматически и сколько безопасно оставить в обычной очереди.
Объяснение оценки должно помогать следующему действию. Формулировка «скор 82» бесполезна без факторов: запрос на конкретный продукт, указанный срок, действующий клиент, не заполнен бюджет. Хорошее резюме отделяет факты клиента от вывода AI и предлагает вопросы, которые снимут неопределённость на первом разговоре.
Контур обратной связи защищают от самоусиления. Если менеджеры чаще берут уже высоко оценённые лиды, у них появляется больше положительных исходов, и система ошибочно подтверждает собственный выбор.
Поэтому анализируют также выборку лидов с низким приоритетом и причины закрытия, а изменения правил выпускают через контрольную проверку.
Что я бы упростила до запуска
- Сначала контракт заявки. Определите обязательные поля и допустимое отсутствие данных; AI не должен додумывать ИНН, бюджет или должность.
- Scoring отдельно от grading. Поведенческий интерес и соответствие целевому профилю измеряются раздельно.
- Причина решения. В CRM сохраняются факторы, источник данных и версия правил, а не только итоговый балл.
- Очередь уточнения. Неполная, но потенциально ценная заявка получает короткий уточняющий сценарий вместо автоматического отказа.
- Обратная связь продаж. Изменение статуса и результат встречи возвращаются в контур качества, но не обучают систему автоматически без проверки.
Как я связываю событие со следующим шагом
Интеграционный слой принимает события каналов и приводит их к общей схеме. Сервис идентификации ищет существующий контакт и компанию. Далее оркестратор вызывает извлечение признаков, бизнес-правила и оценку, после чего пишет в CRM не только лид, но и протокол квалификации.
Маршрутизация должна учитывать территорию, продукт, загрузку и SLA. Если модель не уверена, признаки противоречат друг другу или найдено несколько компаний, заявка направляется в очередь разбора. Менеджер получает исходный текст, структурированное резюме и перечень вопросов, которые ещё нужно задать.
Что чаще всего ломает процесс
Риск нужно связывать с наблюдаемым сигналом и заранее определённым действием. Я бы здесь упростила правило: наблюдаемый сигнал заранее связываем с действием, чтобы после инцидента команда не угадывала причину вручную.
| Риск | Как проявляется | Контроль |
|---|---|---|
| Ложный низкий приоритет | Короткая заявка важного клиента выглядит «пустой» | Проверка CRM-контекста и запрет автоотказа по одному скору |
| Скрытая дискриминация | Прокси-признаки влияют на оценку без бизнес-основания | Ревизия признаков, сегментный анализ ошибок и ручное решение |
| Дубли | Один лид приходит из нескольких каналов | Идентификация контакта и окно дедупликации до создания сущности |
| Устаревшие правила | Изменился продукт, регион или ICP | Версионирование, дата действия и владелец каждого правила |
| Спам и prompt injection | В свободном тексте есть вредоносные инструкции | Разделение данных и инструкций, фильтры, отсутствие прямых привилегированных действий |
Как понять, что продажи реально ускорились
Сначала я бы сняла baseline воронки. Я бы здесь упростила правило: считаем метрики по завершённому бизнес-результату и отдельно по сценарию, версии и причине исключения. Одно среднее скрывает деградацию.
| Метрика | Что показывает | Как разрезать |
|---|---|---|
| Время до принятия заявки | от входа до назначения ответственного | по каналу и приоритету |
| Доля верной маршрутизации | не потребовалась переадресация | по командам и продуктам |
| Precision приоритета | сколько high-priority лидов подтвердили ценность | с задержкой до результата продажи |
| Recall значимых лидов | сколько реальных возможностей не были занижены | обязательный контроль цены ошибки |
| Доля ручного уточнения | сколько заявок не хватает данных | по отсутствующим полям |
Первые изменения в реальной воронке
- 01
Определить стадии лида и единый словарь результата квалификации.
- 02
Собрать выборку заявок с подтверждёнными исходами и разобрать причины ошибок вручную.
- 03
Зафиксировать обязательные признаки, правила, очереди уточнения и запрещённые автоотказы.
- 04
Реализовать протокол объяснения решения и запись версии в CRM.
- 05
Запустить shadow-режим: AI предлагает оценку, но не меняет маршрут.
- 06
После сравнения с baseline включать автоматическую маршрутизацию по безопасным сегментам.
Короткая проверка перед реальными лидами
Перед включением реального потока команда проходит короткий операционный чек-лист. Я бы здесь упростила правило: считаем пункт закрытым только когда есть проверяемый артефакт: настройка, тест, журнал или назначенный ответственный.
- Каждый фактор имеет источник и дату актуальности
- Fit и intent сохраняются отдельно
- Низкий score не вызывает необратимый автоотказ
- Менеджер видит исходный текст и причины маршрута
- Дубли объединяются до создания новой сущности CRM
- Ошибки анализируются по сегментам, а не только в среднем
Где команда чаще всего сомневается
Может ли AI сам отклонять лиды?
Для необратимого отказа нужен очень узкий, проверяемый набор правил. В остальных случаях безопаснее понижать приоритет или отправлять на уточнение.
Нужна ли историческая CRM?
Она полезна, но только если статусы и причины исходов заполнены последовательно. Плохая история закрепляет ошибки отдела продаж.
Что важнее — скорость или точность?
Это разные SLA. Срочную заявку надо быстро назначить, а окончательную квалификацию можно дополнить после первого контакта.
Первое изменение без большой перестройки
Я бы начала диагностику с трения в процессе, данных, цены ошибки и маленького пилота.
Источники и рабочие ограничения
- Einstein Lead ScoringSalesforce
- Create a lead qualification modelSalesforce Trailhead
- Support a lead qualification model with Account EngagementSalesforce Trailhead
- Salesforce Lead Management Implementation GuideSalesforce
- AI Risk Management Framework: CoreNIST
- Best practices for deploying language modelsOpenAI
- Evals drive the next chapter of AI for businessesOpenAI
- Building an evalOpenAI
Источники и методическая база
- Einstein Lead ScoringSalesforce
- Create a lead qualification modelSalesforce Trailhead
- Support a lead qualification model with Account EngagementSalesforce Trailhead
- Salesforce Lead Management Implementation GuideSalesforce
- AI Risk Management Framework: CoreNIST
- Best practices for deploying language modelsOpenAI
- Evals drive the next chapter of AI for businessesOpenAI
- Building an evalOpenAI
- K33 uses n8n to automate compliance and anti-money laundering workflowsn8n
