ML-скоринг лидов: оценка и приоритизация с SHAP-объяснениями

Почему lead scoring не приживается: данные и недоверие к оценке

Скоринг лидов ломается не на этапе обучения модели, а на данных, на которых её учат. Историческая разметка отражает не качество сделок, а поведение отдела продаж: менеджеры обрабатывали то, что оказалось сверху списка, а остальные заявки просто не доходили до звонка. Модель честно воспроизводит эту обратную связь — смещение выборки закрепляется как «закономерность» и усиливается при каждом переобучении.

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

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

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

Что даёт приоритизация обращений по вероятности сделки

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

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

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

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

Подходы к приоритизации обращений: правила и модели

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

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

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

Как мы внедряем приоритизацию: от аудита данных до запуска

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

Порядок работ и точки контроля

1. Аудит данных. Разбираем источники: сделки и этапы, история касаний, активность на сайте, переписка и звонки. Смотрим полноту, дубли, задержки записи событий и то, как фиксируется факт сделки. На выходе — карта источников и перечень полей, которым можно доверять.
2. Целевая метка. Договариваемся, что считаем квалифицированным лидом, и задаём горизонт наблюдения — сколько времени ждём исход, чтобы метка успела стать известной. Определение согласуем с отделом продаж, иначе модель начнёт оптимизировать не тот результат.
3. Схема признаков. Группируем поведение на сайте, историю касаний, профиль компании и качество контакта. Для каждого признака — окно агрегации и правило обработки пропусков. Отсекаем всё, что становится известно только после сделки.
4. Обучение и калибровка. Сравниваем результат с текущим правилом приоритизации и подбираем порог отсечения под реальную пропускную способность отдела продаж, а не под «максимальную точность».
5. Проверка на отложенном периоде. Обучение — на более раннем срезе, проверка — на позднем. Смотрим не только качество в целом, но и устойчивость по каналам, сегментам и типам клиентов.
6. Передача в эксплуатацию. Настраиваем доступы и мониторинг качества входящих данных, фиксируем регламент переобучения и ответственного за признаки. Менеджеры получают приоритет в привычной CRM и объяснения SHAP по каждому лиду — видно, какие признаки подняли его в списке.

Артефакты и регламенты: конфигурации, схемы, документация

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

• Схема признаков. Перечень полей с источниками, типами, допустимыми значениями и правилами обработки пропусков; отдельно отмечено, какие признаки критичны, а что делать при отвале источника.
• Конфигурация скоринга. Гиперпараметры модели, пороги разбиения на приоритеты и веса каналов вынесены в конфигурацию, а не в код — правку вносит аналитик без пересборки.
• Документация модели. Какие признаки и в какую сторону влияют, как интерпретировать объяснения по конкретному лиду и где границы применимости — на каких сегментах модель не обучена.
• Регламент приоритизации. Как разбирается очередь, срок реакции на верхний приоритет, кто владелец решения при конфликте и как лид понижается вручную.
• Правила переобучения. Триггеры — падение метрики, сдвиг распределения входных данных, смена источника или бизнес-правил; периодичность, порядок запуска и проверка на отложенной выборке.
• Мониторинг качества. Набор метрик и пороги оповещений, что считается инцидентом, кому уходит сигнал и как быстро ожидается реакция.
• Инструкции и журнал. Действия оператора при спорном лиде, порядок пересчёта, история версий модели с возможностью отката на предыдущую.

Кейс: перестройка приоритизации обращений, метрики до и после

Что было до

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

Что изменили

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

Что стало

Точность верхнего сегмента выросла с 41% до 68% — две из трёх сделок в приоритете действительно закрываются. Скорость реакции на приоритетные обращения сократилась с 9 часов до 40 минут, а доля обработанных обращений — с 62% до 91% при том же составе отдела. Отдельно ушёл класс потерь, когда обращение с явным спросом остывало в общей очереди и уходило к конкуренту.

Чем lead scoring с объяснениями отличается от ручных правил

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

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

SHAP-объяснения закрывают именно этот разрыв. Для каждого лида показывается вклад отдельного признака в итоговый балл — со знаком и величиной. Менеджер видит, что высокий балл дал размер компании и совпадение отрасли, а не случайный клик по рассылке, и звонит первым по тем, кого сам считает перспективными.

Объяснения нужны не всегда. Там, где сегмент узкий и логика отбора очевидна — повторная заявка от действующего клиента, продление по истечении срока, — прозрачных правил достаточно, и модель только добавит лишний слой согласований.

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

Частые технические сомнения по приоритизации обращений

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

Что будет при смене каналов привлечения?

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

Как проверяете качество разметки?

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

Кто отвечает за правила и модель?

Жёсткие правила (VIP, повторное обращение, стоп-лист) остаются выше модели — она упорядочивает остаток потока. Журнал решений, метрики на отложенной выборке и регламент дообучения передаём вашей команде при нашей поддержке.

Обсудим вашу задачу: данные, метрики, план внедрения

Чтобы вернуться с оценкой и планом, а не с общими словами, на старте разбираем данные и постановку. Ниже — что уточняем с вашей стороны и что проверяем сами, прежде чем строить скоринг лидов на вашей истории.

• Аудит данных: какие источники есть — CRM, веб-аналитика, история звонков и переписок, — как давно они собираются, насколько полно заполнены поля, есть ли разметка «сделка / отказ» и где расходятся системы между собой.
• Целевая метрика: что считаем успехом — долю сделок в топ-20% приоритета или сокращение времени до первого касания. Фиксируем до старта, иначе результат нечем мерить.
• Пилот на исторических данных: прогоняем модель на прошлых сделках и сравниваем с тем, как лиды распределялись у вас раньше, — это даёт проверяемую цифру до изменений в работе отдела.
• Объяснения балла: как менеджер увидит, почему лид поднялся, — вклады признаков в интерфейсе, чтобы скоринг не спорил с опытом отдела продаж.
• Интеграции и доступы: куда отдаём балл — в CRM или в отчёты, кто владелец системы, нужен ли доступ к внешним сервисам и в каком контуре всё работает.
• План внедрения и оценка сроков: подготовка данных, обучение и валидация, пилот, вывод в рабочий контур — по каждому этапу называем длительность и точки вашей проверки.

Опишите задачу — сколько истории есть, какие поля заполняются и как приоритизация устроена сейчас. Вернёмся с оценкой сроков и планом работ.