Скоринг лидов: как перестать путать активность с готовностью купить

Один посетитель двадцать раз открыл кейс. Другой прислал короткое сообщение: «У нас десять филиалов, хотим обсудить внедрение в ноябре». Кто должен попасть к менеджеру первым?

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

Скоринг лидов начинается с двух разных вопросов

Первый: можем ли мы решить задачу этой компании? Второй: что говорит о намерении обсуждать покупку сейчас? В документации HubSpot это разделено на fit и engagement: свойства контакта или компании и действия взаимодействия.

В обучающих материалах Salesforce о квалификации лидов также рассматриваются разные подходы к оценке интереса и соответствия. Но названия инструментов не задают универсальную шкалу для вашего бизнеса. Критерии приходится привязывать к продукту и реальным продажам.

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

Сначала определите, кому продукт подходит

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

Для простоты введём категории. A — соответствие подтверждено по выбранным критериям. B — часть информации ещё неизвестна. C — обнаружено конкретное ограничение, которое продукт сейчас не снимает.

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

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

Учебная шкала намерения: пять событий вместо сотни кликов

Ниже — пример ручной балльной модели. Значения придуманы для объяснения подхода, не обучены на продажах и не являются готовыми нормативами.

Таблицу можно прокрутить вбок →

Повтор одного события не должен бесконечно накапливать баллы. Двадцать просмотров того же кейса в этой модели дают те же 10 баллов, а не 200. Верхняя сумма шкалы — 100. Правила дедупликации и срок действия сигналов нужно записать отдельно.

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

Как читать результат: четыре разных маршрута

Таблицу можно прокрутить вбок →

У обращения A/85 есть понятные признаки приоритета, но это не «85% вероятности сделки». У B/40 может оказаться отличный потенциал после уточнения. В этом и польза двух осей: неизвестное не маскируется числом.

Скоринг не отменяет быстрый ответ на заявку. Нельзя оставлять остальные обращения без базового ответа, пока система выбирает «самые ценные». Даже при низком соответствии человеку нужна понятная и корректная коммуникация.

Как проверить, что баллы действительно помогают

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

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

Начните с небольшой пилотной области: одного продукта и одной команды. Зафиксируйте версию правил, собирайте причины изменения приоритета и обратную связь менеджеров. Если обращений мало, не делайте выводов по нескольким удачным сделкам. Сначала накопите сопоставимую историю.

Почему скоринг ломается после запуска

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

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

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

Как внедрить скоринг лидов в CRM без чёрного ящика

Начните с отдельных полей: соответствие A/B/C, балл намерения, время последнего подтверждённого сигнала и версия правил. Не храните всё в одном поле «горячий»: менеджер должен понимать, почему обращение попало в очередь и чего ещё не знает команда.

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

Отдельно настройте маршрут, а не только цвет карточки. В нашем примере B/40 сначала требует уточнения условий, A/85 — предметного разговора, C/15 — честного объяснения ограничения. Порог передачи и срок ответа согласуйте с реальной загрузкой команды; базовый ответ не должен исчезать у низкого приоритета.

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

Паспорт простой модели скоринга

Продукт и сценарий:
Критерии соответствия A / B / C:
Как обозначаем неизвестные данные:
События намерения и их баллы:
Защита от повторного начисления:
Когда сигналы устаревают:
Маршрут для каждой комбинации:
Как менеджер может уточнить оценку:
Показатель проверки, период и версия правил:

Нужен ли ИИ для скоринга лидов?

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

Скоринг заменяет разговор с клиентом?

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

Следующий шаг

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