Скоринг лидов в CRM: как проверить, кого ошибочно ставят первым
Как задать баллы по наблюдаемым признакам и испытать скоринг на старых сделках. Пример ошибок оценки, выбора порога и очереди менеджера.
Спасибо! Заявка принята.
Не удалось отправить заявку. Попробуйте позже.
Оглавление статьи · 6 разделов
У менеджера восемь новых заявок и время только на три подробных разговора до обеда. Скоринг лидов в CRM помогает выбрать порядок обработки. Но если система даёт много баллов за любое скачивание каталога, студент с активным интересом окажется выше закупщика с конкретной спецификацией. Проверьте шкалу на прошлых сделках, прежде чем она начнёт определять, кому действительно позвонят первому.
Сформулируйте задачу шкалы
Установите цель: предсказать подтверждённый запрос расчёта, состоявшуюся встречу или оплаченный заказ. Для разных событий полезны разные признаки. Если сделки длятся полгода, только что поступившие заявки нельзя честно оценивать как проигранные. Выберите старую группу с достаточным временем до исхода и отдельно оставьте более свежую группу для контрольной проверки.
Отделите право обслуживать заявку от её приоритета. Запрос на продукцию, которую компания не поставляет, требует маршрута в другую очередь независимо от баллов. Крупный заказ из обслуживаемого региона и небольшой заказ из того же региона могут оба подходить бизнесу, но по-разному распределяться между специалистами. Установите, какую организационную задачу решит сортировка и кто увидит её результат.
Выберите признаки, известные до первого звонка
Придумайте небольшую прозрачную шкалу. В учебном варианте подходящее назначение оборудования даёт три балла, приложенная спецификация — два, указанный объём — два, посещение страницы условий — один при допустимом и надёжном учёте этого просмотра. Веса здесь иллюстративны. У каждого поля должен быть проверяемый источник. Ответ «объём не указан» означает отсутствие сведений и не равен заявленному слишком маленькому объёму.
Исключите признаки, возникшие после того события, которое пытаетесь предсказать. Поле «дата коммерческого предложения» бесполезно для сортировки только что поступивших обращений: на старой выборке оно может прекрасно отличать успешные сделки просто потому, что заполнено уже после разговора. Восстановите, что было известно именно на момент очереди. Если старые значения в CRM перезаписаны, пометьте такое поле непригодным для ретроспективной проверки.
Разберите ошибки на небольшом примере
Предположим, в старой группе 40 обращений, двенадцать дошли до предметного расчёта. При пороге от пяти баллов в приоритет попали десять человек, из них семь дошли до расчёта. Трое заняли очередь напрасно относительно выбранной цели. Ещё пять перспективных оказались ниже порога. Вместо красивой цифры «семь успешных» рассмотрите обе ошибки: бесполезное ускорение и пропущенная возможность.
Откройте карточки пяти пропущенных. Например, у двух не было спецификации, но клиент описал задачу в свободном тексте; у трёх источник не передал поле количества. В первом случае стоит проверить, можно ли выделить понятный признак и кто будет его вносить. Во втором — исправить передачу поля и проверить старые записи отдельно. Повышение веса количества при сломанной передаче лишь усилит ошибку.
Свяжите порог с реальной вместимостью очереди
Если отдел способен быстро обработать восемь заявок в день, а порог ежедневно выделяет двадцать, слово «приоритет» перестаёт помогать. Проверьте распределение по дням и сменам, включая сезонные всплески. При одинаковых баллах можно учитывать время поступления или согласованный срок ответа. Зафиксируйте, когда менеджер имеет право отступить от очереди и как оставить причину такого решения.
Порог лучше проверять на отложенной группе, которую не использовали при выборе весов. Сравните долю перспективных обращений среди первых и число потенциально ценных ниже порога. Посмотрите отдельно на новые компании, повторные обращения и источники с неполной передачей сведений. Если группа маленькая, сохраняйте исходные числа. Изменение одной сделки может сильно сдвинуть проценты, хотя о качестве шкалы известно всё ещё мало.
Введите оценку сначала как подсказку
Покажите балл и его составляющие рядом с прежней очередью. Попросите менеджеров отмечать очевидные ошибки и фактический следующий шаг. Не закрывайте заявки автоматически только из-за низкой суммы. Иначе вы лишитесь наблюдений о том, могли ли они стать сделками, и отчёт начнёт подтверждать собственную сортировку. По части обращений ниже порога нужен обычный контроль качества обработки.
Сохраните версию правил и дату перехода. При новой шкале сравнивайте обращения, которые могли быть оценены обеими версиями на одинаковых данных. Для более широкого разбора потерь пригодится статья «Почему заявки из рекламы не превращаются в продажи». Ценность скоринга видна по тому, кого команда успевает обслужить и какие реальные исходы получает, а не по сложности формулы в CRM. Для сверки результата проследите путь клиента от рекламы до покупки по данным конкретного заказа.
Свобода от рекламной зависимости – за 1 день
ЛидБлог за 1 день превращает сайт в канал привлечения новых клиентов из Яндекс, Google и поиска в нейросетях. Работает без вашего участия
.PDF ФАЙЛ
Выберите способ связи и укажите номер, чтобы получить персональный план привлечения клиентов с помощью нового канала «ЛидБлог» и узнать стоимость внедрения
Вопросы и ответы
Можно ли присвоить ноль всем неизвестным признакам?
Технически можно, но сохраните отдельную отметку об отсутствии сведений. Иначе потерю поля при передаче вы примете за отсутствие интереса у клиента.
Какой порог ставить для приоритетной очереди?
Испытайте несколько порогов на исторической и отдельной контрольной группе. Сравните пропущенные перспективные обращения с возможностями менеджеров по обработке.
Почему нельзя закрыть все заявки с низким баллом?
Пока шкала не проверена, среди них могут быть подходящие клиенты. Без обычной обработки хотя бы части таких заявок вы не увидите настоящую частоту ошибок.