Скоринг лидов в CRM: как разделить интерес и соответствие клиента
Частые визиты на сайт не всегда означают готовность к покупке. Разбираем, как построить объяснимую очередь лидов и проверить, кому менеджеры действительно должны отвечать раньше.
Один контакт прочитал десять статей и открыл несколько писем. Другой сразу запросил интеграцию с конкретной системой, но почти не взаимодействовал с рассылкой. Если приоритет определяется суммой действий на сайте, первый легко окажется выше второго. Для отдела продаж такой порядок может быть неудобен.
Скоринг лидов — способ упорядочить обращения по заданным признакам. Разберём предлагаемую схему для компании, которая продаёт сложные B2B-услуги: отдельно оцениваются соответствие клиента и проявленный интерес, а неизвестные сведения остаются видимыми. Примеры баллов и выборок ниже учебные. Это не готовая универсальная формула вероятности покупки.
Соответствие показывает, может ли компания решить задачу клиента: подходящая услуга, доступная география, нужная система, допустимый масштаб работ. Интерес отражает действия: конкретный запрос, ответ на письмо, согласованную встречу. Хорошее соответствие без текущей потребности и высокая активность по неподходящей задаче требуют разных следующих шагов.
В документации HubSpot по скорингу отдельно описаны fit и engagement scores — оценки соответствия и вовлечённости. Это полезное различие для проектирования собственной очереди. Доступность готовых инструментов зависит от подписки и объекта CRM; описанная ниже матрица не предполагает наличия одной и той же функции во всех системах.
Соответствие
Интерес
Следующее действие в предлагаемой схеме
Высокое
Конкретный запрос
Быстрый предметный разбор менеджером
Высокое
Только чтение материалов
Полезная информация по задаче при допустимом канале связи
Низкое
Много действий
Проверка, подходит ли услуга вообще
Неизвестно
Любой уровень
Короткое уточнение недостающих данных
Такой вид очереди проще обсуждать на реальных обращениях. Если менеджер не согласен с приоритетом, можно увидеть причину: неверно указанная система, устаревшая потребность или чрезмерный вес посещений. Один непрозрачный итоговый балл скрывает это различие.
Для каждого признака нужны значение, источник и дата. Название CRM клиент может указать в форме или подтвердить в разговоре. Предположение из текста письма лучше хранить как неподтверждённое значение. Отсутствие бюджета не равно нулевому бюджету, а неизвестная должность — отсутствию влияния на выбор подрядчика.
В учебном варианте соответствие получает до 50 баллов, интерес — до 50. Прямой запрос на подходящую услугу может добавить 20 баллов интереса, а изучение материалов — не более 5 за выбранный период. Числа служат начальной гипотезой. Выбрать реальные веса можно только после разбора того, какие обращения и решения они поднимают в вашей очереди.
Сведения, которые однозначно исключают услугу, удобнее показывать отдельной причиной. Большой объём чтения не должен арифметически отменять несовместимость задачи. Исключения при этом требуют проверки: клиент мог ошибиться в названии системы, а компания — расширить перечень работ.
События нуждаются в собственных идентификаторах, времени и связи с контактом. Повторная доставка уведомления не является новым действием пользователя. Отдельно определите, считается ли серия просмотров одной страницы новым интересом. Иначе рейтинг растёт от технических повторов и обновления вкладки.
Задайте окно актуальности и верхнюю границу для группы событий. Например, в учебной модели посещения учитываются за последние 30 дней и дают суммарно не более 5 баллов. Ответ на конкретное предложение хранится отдельно. При пересчёте значения сохраняют дату и версию правил, чтобы изменение приоритета можно было объяснить.
Не стоит делать любой цифровой след сигналом намерения. Открытие письма, посещение страницы и запрос расчёта различаются по смыслу и надёжности измерения. Начните с событий, у которых есть понятное деловое значение, и проверяйте, улучшают ли дополнительные признаки очередь.
Модель можно использовать для извлечения признаков из свободного текста: интересующая услуга, используемая система и сформулированный срок. Каждый результат сопровождается исходной фразой. Если сведений нет, возвращается «не указано». Вычисление баллов затем выполняют по обычным правилам, которые руководитель может прочитать и изменить.
Прогнозная модель покупки — другая задача. Ей нужна история с достоверным результатом, достаточным числом наблюдений и понятным горизонтом прогноза. При малой или несопоставимой базе простые правила часто проще проверить. Называть балл от языковой модели вероятностью сделки без калибровки нельзя: число 85 не становится вероятностью 85% из-за формата ответа.
Сохраните данные, которые были доступны на момент обращения. Статус «успешная сделка», итоговая сумма и проведённая позже встреча не должны попадать в признаки при проверке раннего приоритета. Иначе система фактически увидит ответ, который её просят предсказать.
Для первичной проверки можно применить правила к прошлым обращениям, восстановив доступный тогда снимок. Затем проверить их на более позднем периоде. У исходов должен быть одинаковый срок наблюдения: лид с одним днём истории ещё нельзя сопоставлять по продажам с лидом, который ведут два месяца. Отдельно отмечают незавершённые сделки.
Учебный пример: в первых 20 позициях старой очереди оказалось 5 подходящих обращений, в новой — 8. Доля подходящих в выбранной верхней части выросла с 25% до 40%. Это результат ранжирования на этой выборке, а не доказанный рост выручки. Если контакты уже обслуживались по другой очереди, их дальнейшие исходы зависят и от прежней скорости ответа.
Не превращайте низкий балл в автоматический отказ #
На пилоте новые оценки можно показывать рядом с обычным порядком обработки. Менеджер исправляет признаки и указывает причину. Для низкого приоритета задают предельное время ожидания, а для неизвестных данных — отдельную очередь уточнения. Так эксперимент не лишает потенциальных клиентов ответа.
Проверьте, не ухудшилось ли обслуживание новых сегментов. Исторические данные отражают прошлую работу команды: если небольшой бизнес раньше редко обрабатывали, это ещё не означает, что он заведомо не подходит. Разбор ручных исправлений помогает отличить слабую формулу от устаревшего представления о клиенте.
Если все новые обращения быстро получает подходящий менеджер, сложная оценка может не дать заметной пользы. Достаточно явных категорий: предмет запроса, срочность и нужный специалист. Баллы полезны, когда очередь действительно требует выбора, а команда может объяснить, какие признаки помогают сделать его лучше.
NetLabCS поможет связать признаки из писем и обращений с карточками в рамках интеграции ИИ с Битрикс24 , настроить объяснимую очередь и проверку ручных исправлений. Опишите, какие лиды сейчас ждут слишком долго : откуда они приходят, что известно на входе и по каким признакам менеджер решает, кому ответить первым.
