Скоринг и проверка лидов с ИИ: что выбрать

2026-11-05 · Слаживание

Я советую начинать с валидации, если в CRM много ошибок, и со скоринга - если команда не успевает обрабатывать лиды. Если есть обе проблемы, сначала проверьте данные, затем расставляйте приоритеты.

Разница простая: скоринг отвечает «кого обработать первым?», а валидация - «можно ли действовать по этой записи?». _Балл 85 из 100 не означает вероятность покупки 85 %._ И высокий балл не отменяет проверку контактов, дублей и противоречий.

Краткое сравнение

Я бы начал с пилота на одном источнике: без автоматических действий, с ручным разбором спорных записей. Проверять стоит не рост баллов, а результат: качество данных, сроки обработки, продажи и прибыль после расходов на ИИ, подключения и работу сотрудников.

1. ИИ-скоринг лидов

Скоринг определяет, какие лиды обрабатывать первыми. Он не оценивает качество записи в CRM.

Решение и результат

Сначала выберите целевой результат и срок: создание сделки в CRM за 30 дней или продажа за 180 дней. Ранжирующий балл определяет очерёдность обработки: 85 из 100 не означает вероятность покупки 85 %. Калиброванная вероятность показывает ожидаемую долю конверсий в сопоставимой группе лидов за выбранный срок. [5][6]

Оценивайте отдельно соответствие целевому профилю клиента (ICP) и покупательское намерение. Отрасль и размер компании говорят о соответствии ICP, а запрос цены или демо - о намерении купить. Если лид не подходит целевому сегменту, его приоритет снижается даже при высокой активности. Давние действия должны терять вес, а повторяющиеся малоценные сигналы - не перевешивать явные ограничения. [5][7]

Точность скоринга зависит от качества истории CRM и правильной разметки исходов.

Требования к данным и надёжность

Для обучения нужны история этапов CRM, даты событий и исходы, включая проигранные и дисквалифицированные лиды. Модель должна использовать только данные, доступные до момента прогноза. Сведения из будущего не должны попадать в обучение. Если надёжной истории мало, лучше начать с прозрачных правил. [5]

Уверенность модели - отдельный показатель. Он зависит от полноты, актуальности и согласованности данных. Объяснение оценки само по себе не подтверждает калибровку вероятности, а один пропуск в данных не говорит о низком потенциале лида.

Проверяйте модель на выборке за более поздний период. Верхние 10 % рейтинга должны давать больше целевых переходов, чем средняя и нижняя группы. Калибровку вероятности проверяйте отдельно - по фактическим конверсиям. [5][6][9]

Влияние на процесс и результаты

После проверки данных направляйте лиды с высоким баллом и высокой уверенностью менеджеру в рамках установленного SLA, со средним баллом - в прогрев, а спорные - на ручную проверку. При распределении учитывайте стадию, регион и загрузку команды.

Измеряйте конверсию верхней группы, время первого контакта и долю лидов, принятых продажами. Сравнивайте эти показатели с прежним процессом или контрольной группой. Рост среднего балла сам по себе не означает роста продаж. [4][6][8]

Скоринг задаёт приоритет, но не принимает окончательное решение о продаже. Следующий слой процесса - валидация данных. Она проверяет качество записи и определяет, можно ли запускать автоматическое действие.

2. Проверка лидов с помощью ИИ

Скоринг определяет, каким лидом заняться первым. Валидация - можно ли вообще запускать действие по записи.

Решение и результат

Валидация проверяет, заполнены ли обязательные поля, подтверждены ли контакты, нет ли дублей и противоречий. По итогам запись получает статус: «одобрить», «проверить» или «исправить». Исходное значение и правку храните отдельно. [10]

Для каждого статуса нужны чёткие правила: когда система пропускает запись дальше, когда блокирует действие, а когда передаёт запись на проверку.

Требования к данным и надёжность

Обязательные поля - контактные данные, компания, источник, владелец в CRM и согласие на контакт. Для каждого этапа задайте требования, которые запись должна пройти до маршрутизации и коммуникации. Если поле пустое, не позволяйте ИИ заполнять его догадкой: ставьте «не указано» и запрашивайте данные. Без источника сложнее определить, откуда пришёл лид, а без согласия коммуникация может быть заблокирована. [11][12]

Уверенность в данных должна опираться на источник, его актуальность и результат проверки. Рядом с полем храните источник подтверждения, дату проверки и разрешённое действие. Если значения расходятся, сохраняйте оба и отправляйте конфликт на ручную проверку. [11][13]

Влияние на процесс и результаты

Валидация не ранжирует лиды - она не даёт ошибкам попасть в продажи. Проверяйте запись сразу после поступления, до назначения менеджера и запуска коммуникаций. Одобренные лиды направляйте по обычному маршруту, спорные - в очередь на проверку с конкретным вопросом и сроком, исправленные - на повторную проверку. Неподтверждённые данные, добавленные при обогащении, не должны запускать действия в продажах. [10]

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

Данные, методы и надёжность

Для каждого слоя нужны свои данные и способы проверки. Если данных не хватает, важно заранее определить, что система сделает вместо автоматического решения. Ошибки в данных ухудшают и скоринг, и валидацию. [14][15]

Для скоринга важна не только полнота признаков. Исходы тоже должны быть размечены правильно.

Какие сигналы и исходы CRM допустимы для обучения

Закрепите единые определения стадий. «Проигран», «заброшен» и «ещё открыт» - разные состояния: открытый лид нельзя автоматически считать отрицательным исходом. Задайте окно результата:

Переход в квалифицированную сделку в течение 60 дней.

Если этот срок ещё не прошёл, не размечайте запись как неуспех. Используйте только признаки, доступные на момент расчёта. Итог сделки, поздние заметки и последующие касания создают утечку целевой переменной: модель получает сведения, которых в момент оценки ещё не было. Обучайте её на более ранних записях, а проверяйте на более поздних. [14][16][17][18]

Правила, предиктивные модели и помощь LLM

Балл LLM не равен вероятности покупки. Требуйте ответ по заданной структуре: критерий, оценка, подтверждающий фрагмент текста. Сверяйте этот фрагмент с первоисточником, сохраняйте версии модели и инструкции, проверяйте результаты на размеченной выборке. Чтобы трактовать оценку как вероятность, нужна отдельная проверка калибровки. [4][15]

Даже точная модель даёт сбои на некачественных данных. Поэтому перед автоматическими действиями запись нужно проверить.

Проверки данных и поводы для ручного разбора

Правильный формат контакта ещё не означает, что по нему можно связаться. А заполненная карточка не подтверждает потребность. Проверяйте формат детерминированными правилами, а ИИ используйте для извлечения, нормализации, сопоставления и обогащения данных из разрешённых источников. Валидация определяет, допустимо ли действие, а не насколько приоритетен лид.

Единый процесс: от заявки до обратной связи продаж

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

При приёме сохраняйте идентификатор события, источник, время в формате ДД.ММ.ГГГГ ЧЧ:ММ и основание обработки. Для обогащённых данных фиксируйте исходное значение, источник и уверенность. Дубли искажают знаменатель конверсии, поэтому рассчитывайте её отдельно по заявкам и по уникальным возможностям продажи.

Правила одобрения, проверки и исправления

Валидация должна блокировать действия, для которых нет подтверждения. Если обязательное поле пустое, реквизиты противоречат друг другу или данные извлечены ненадёжно, направляйте запись сотруднику. Укажите причину проверки и допустимое действие.

Чувствительные сведения, к которым у ИИ нет доступа, проверяет уполномоченный сотрудник. Расширять доступ агента для этого не нужно. При исправлении или отказе фиксируйте конкретную причину, а не общий ярлык «низкое качество».

Повторный контакт и новый участник закупочной группы - разные случаи. Участников связывают с одной возможностью продажи, но сохраняют для каждого отдельный контакт и историю.

Маршрутизация по баллу, уверенности и стадии

После одобрения запись должна сразу попадать в нужную очередь. Храните балл, уверенность, стадию, статус проверки и причину дисквалификации в отдельных полях.

Высокий балл не отменяет проблем с данными: такую запись направляйте на проверку. Проверенный лид на активной стадии передавайте в продажи, а валидный лид с низким приоритетом - в прогрев. При распределении учитывайте загрузку менеджеров.

Для каждой очереди назначьте владельца, срок реакции и резервного ответственного. Определите порядок эскалации при просрочке. Сохраняйте исходное решение ИИ, правку сотрудника, её причину и время, а также результат продажи. Используйте правки для обучения только после проверки.

Подключения к CRM, доступ и внедрение

Когда правила и очереди готовы, свяжите их с CRM и смежными системами. CRM должна хранить решения и исходы, а 1С - предоставлять разрешённые сведения о клиентах, договорах и оплатах. Почта, диск и телефония должны давать доступ к переписке, документам и результатам звонков.

Для каждого подключения определите поля обмена, сроки хранения и действия при сбое. Настройте ролевой доступ и защищённый от изменений журнал действий. Отдельно проверьте соблюдение 152-ФЗ.[19][20][21]

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

Метрики для руководителя и компромиссы

Метрики помогают понять, что нужно исправить: скоринг, валидацию или их связку. Важно видеть не только результат, но и этап, на котором возникает проблема.

Качество данных и точность скоринга

Разделите дашборд на четыре блока: данные, модель, обработка и продажи. Для каждой метрики укажите знаменатель, исключения и окно наблюдения. Считайте конверсии только после закрытия окна исхода. Если исходов мало, показывайте неопределённость - не спешите объявлять победителя.

Согласие продаж не доказывает, что модель права. И отсутствие сделки ещё не означает, что лид плохой: его могли не обработать.

Чтобы оценить упущенные возможности, случайно отбирайте низкобалльные и отклонённые лиды по источникам. Проверяйте их пригодность и качество контакта. Доля перспективных лидов среди проверенных описывает только эту выборку - это не подтверждённая доля потерянных продаж.

Когда данные и модель под контролем, проверьте следующий узкий участок: скорость прохождения лида.

Скорость обработки, SLA и результаты продаж

Заранее закрепите рабочие часы, праздники, паузы и часовой пояс. Например:

09:00–18:00 МСК по рабочим дням.

Установите единые критерии SQL: подтверждённая потребность, соответствие ICP, контакт и согласованный следующий шаг. Воронку, выручку и валовую прибыль показывайте отдельно, но используйте одну модель атрибуции.

Сравнивайте эффект с прежним процессом или контрольной группой. Правила квалификации и сопровождения должны быть одинаковыми. Не приписывайте ИИ изменения, которые вызваны ценами, сезонностью, кампанией или новой командой.

В расходы включайте внедрение, интеграции, использование моделей, поддержку, обучение, контроль и ручную проверку. Стоимость ручной проверки считайте как часы сотрудников × полная часовая стоимость. Высвобождённое время учитывайте как эффект только тогда, когда оно сокращает расходы или позволяет перераспределить работу с пользой.

Скоринг и валидация: польза, ограничения и затраты

После качества, скорости и продаж проверьте экономику процесса. Объединяйте слои, только если дополнительная прибыль перекрывает дополнительные затраты за период.

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

Итог: выбирайте слой под узкое место

Начните с того, что мешает работе: ошибки в данных требуют валидации, сложности с приоритетами - скоринга.

Метрики помогут определить, где происходит сбой: в данных, приоритизации или маршрутизации. Выбирайте слой под конкретную проблему.

Проверьте выбранный слой в пилоте. До запуска убедитесь, что записи звонков прикрепляются к карточкам и доступны ИИ для анализа [1]. Исходящие сообщения сначала сохраняйте как черновики: отправляйте их только после подтверждения [2][3].

В пилоте оцените качество данных, соблюдение SLA и коммерческие результаты - эти показатели должны улучшиться. Отдельно проверьте, не стало ли больше пропущенных горячих лидов и не выросла ли полная стоимость привлечения с учётом ИИ, ручной проверки и накладных расходов [1][22]. Масштабируйте процесс только после этих проверок.

FAQs