Скоринг лидов для малого бизнеса: когда достаточно простой модели
Скоринг лидов упорядочивает обращения по согласованным признакам и помогает выбрать следующий контакт. Простой балл удобен, если менеджер понимает его состав и может проверить решение. Он не становится вероятностью продажи только потому, что выражен числом от нуля до ста.
До скоринга нужно определить пригодность обращения. Реальный запрос на неподдерживаемую услугу не превращается в приоритетный из-за большого числа посещений сайта. Квалификация и порядок работы решают разные задачи.
Когда баллы вообще нужны
Модель полезна, если подходящих обращений больше, чем команда успевает обработать, либо разные сотрудники выбирают приоритет без общего правила. При нескольких запросах в неделю быстрее может оказаться обычный регламент с ответственным и сроком ответа.
Первые признаки выбирают из реального процесса. Это могут быть подтверждённое соответствие услуги, согласованная дата следующего шага и вовлечённость нужного участника. События вроде открытия письма требуют осторожности: техническая фиксация не гарантирует намерение купить.
В документации HubSpot о lead scoring признаки соответствия и взаимодействия рассматриваются отдельно. Это полезная граница и для ручной таблицы, хотя возможности конкретной CRM и тарифа отличаются.
Как задать понятные правила
Начать можно с небольшой учебной модели. Веса ниже условные и не основаны на статистике вашей компании.
| Признак | Учебный вес | Что сохранить |
|---|---|---|
| Задача соответствует услуге | 3 | Основание квалификации |
| Подтверждён следующий разговор | 2 | Дату и канал |
| Уточнены обязательные условия | 2 | Какие именно условия |
| Сведения устарели | Проверка вручную | Причину пересмотра |
Важен порядок объяснения: балл получается из наблюдений, а не заменяет их. Если поля неизвестны, это отражается отдельно. Молчание клиента не означает автоматического отрицательного ответа на каждый вопрос.
Как проверить модель на истории
Сохраняют список обращений с признаками на момент оценки и позднейшим известным исходом. Нельзя подставлять сведения, которые стали доступны только после продажи: такая проверка будет знать будущее.
Затем смотрят, какие реальные ситуации модель поднимает и опускает. Если важные клиенты постоянно получают низкий балл из-за специфического пути покупки, правило пересматривают. Для небольшой истории результат остаётся наблюдением, без выдуманной точности и уверенности.
Нужна и рабочая инструкция: кто реагирует на приоритет, в какой срок, что делает с обращением без балла. Само появление числа в карточке не организует продажи.
Черновик модели для команды
Конструктор помогает записать назначение, признаки и действие после оценки. Он не подключается к CRM и не обучает статистическую модель.
При изменении весов сохраняют версию. Иначе баллы разных месяцев будут выглядеть сопоставимыми, хотя означают разное. Автоматическую оценку стоит вводить после того, как команда может объяснить ручное решение на конкретной карточке.
Базовый процесс описан в регламенте обработки заявок. Обсудить модель приоритета и CRM.