В отдел продаж за неделю приходит 180 заявок. Менеджеров четверо, рабочих часов у каждого около сорока. Даже если тратить на первый контакт десять минут, руки дойдут в лучшем случае до сотни обращений. Остальные восемьдесят полежат в CRM, потом их закроют пачкой через групповые действия с причиной «не дозвонились». Среди этих восьмидесяти почти наверняка были два-три клиента с бюджетом, который окупил бы весь месяц работы отдела.
Дело здесь не в лени менеджеров и не в нехватке людей. Список лидов отсортирован по дате создания, то есть по случайному признаку. Скоринг лидов меняет порядок этой очереди: сверху оказываются те, кто с большей вероятностью доведёт дело до оплаты.
Что такое скоринг лидов простыми словами
Скоринг — это числовая оценка лида по заранее оговорённым признакам. Каждому признаку присваивается вес в баллах, баллы складываются, итог записывается в карточку. Дальше по этому числу можно фильтровать список, распределять ответственных, запускать роботов и строить отчёты.
Сразу оговорюсь про важное. В базовой CRM Битрикс24 нет отдельной кнопки «включить скоринг», которая сама начнёт раздавать лидам оценки. Есть набор инструментов, из которых модель собирается за пару часов: пользовательские поля, роботы, триггеры и фильтры. В Маркете лежат готовые приложения от сторонних разработчиков с похожей логикой «из коробки», но собственная модель обычно точнее, потому что построена на данных вашей воронки.
Скоринг не заменяет менеджера и не запрещает ему звонить кому угодно. Он делает приоритизацию заявок объяснимой. Когда руководитель спрашивает, почему лид висит третий день, ответ звучит так: у него 12 баллов из 100 при пороге в 40. Это уже разговор про модель, а не про добросовестность сотрудника.
Из чего складывается оценка
Прежде чем открывать настройки CRM, нужно договориться о критериях. Разговор этот скорее про продажи, чем про технологии: как в вашей компании выглядит хороший клиент. Обычно критерии делятся на две группы.
Первая группа описывает профиль клиента: отрасль, регион, размер компании, должность обратившегося, наличие в заявке юрлица. Эти данные почти не меняются во времени и часто известны уже в момент создания лида.
Вторая группа описывает поведение. Скачал прайс, открыл письмо, перезвонил сам, оставил заявку второй раз за месяц, спросил про сроки поставки. Поведение говорит о готовности покупать честнее, чем заполненная анкета.
Дальше каждому признаку назначается вес. Первую версию весов вы придумываете из здравого смысла и опыта РОПа, а через пару месяцев корректируете по фактическим конверсиям. Вот как может выглядеть таблица оптовой компании, которая продаёт оборудование:
- заявка с формы «рассчитать стоимость проекта»: 25 баллов;
- заявка с формы «подписаться на новости»: 3 балла;
- указано юрлицо: 15 баллов;
- регион присутствия наших складов: 10 баллов;
- клиент уже покупал: 20 баллов;
- входящий звонок от клиента после отправки коммерческого предложения: 20 баллов;
- почта на бесплатном домене без названия компании: минус 5 баллов;
- заявка вне рабочего региона: минус 15 баллов.
Порог отсечения задаётся по той же логике. Если из ста лидов вы физически успеваете качественно обработать сорок, порог «горячего» ставится там, где в эти сорок попадает максимум будущих сделок. Первую границу берут примерно, потом сдвигают. Так и должно быть.
Откуда брать данные для баллов
Формула работает только на заполненных карточках. Если половина лидов приходит без региона и без названия компании, результат получится средним по больнице. Поэтому перед настройкой стоит пройтись по источникам заявок и посмотреть, что каждый из них реально передаёт в CRM.
Заявки с сайта дают больше всего управляемых данных: состав полей формы вы задаёте сами. Если в форме нет вопроса про объём закупки, а для скоринга он критичен, дешевле добавить одно поле в форму, чем потом вытягивать эту информацию из менеджеров. Обращения из мессенджеров и соцсетей приходят через открытые линии и почти всегда беднее по данным, поэтому вес там смещается на поведение и на историю прошлых обращений.
Звонки долгое время были слепой зоной: содержание разговора оставалось в голове менеджера и в лучшем случае попадало в комментарий. Сейчас эта дыра закрывается встроенной обработкой звонка. Расшифровка и автозаполнение полей превращают разговор в данные, пригодные для формулы.
Ещё одна категория, про которую часто забывают, это клиенты, уже присутствующие в базе. Повторное обращение почти всегда ценнее нового контакта, и нужные данные у вас уже лежат в CRM. Их остаётся научиться замечать автоматически.
Шаг первый: поле для балла
Оценке нужно место, где она будет храниться. В CRM Битрикс24 для этого создаётся пользовательское поле типа «Число». В справке оно описано как «любое число, например вес товара или средний чек», для нашей задачи подходит.
Создать поле можно двумя путями. Быстрый: открыть карточку лида и нажать «Создать поле» прямо в ней. Системный: пройти по пути CRM → Ещё → Настройки → Настройки CRM → Настройки форм и отчётов → Пользовательские поля. Второй вариант удобнее, когда полей несколько и нужно сразу навести порядок в их названиях.
Помимо числового балла обычно заводят второе поле типа «Список» с человекочитаемым классом: «горячий», «тёплый», «холодный». Менеджеру проще ориентироваться по слову, чем по числу 62. Ограничение по количеству полей вас почти наверняка не побеспокоит, справка называет предел в 1016 полей на каждый тип элемента CRM.
Шаг второй: роботы, которые считают баллы
Начисление баллов делают роботы. Робот срабатывает, когда элемент попадает на определённую стадию, и выполняет заданное действие. Для скоринга нужен робот «Изменить элемент» из группы «Управление элементом»: он меняет информацию в полях элемента, причём новое значение можно собрать из значений других полей карточки.
Практическая схема выглядит так. На первой стадии лида, обычно это «Не обработан», выстраивается цепочка роботов «Изменить элемент», каждый со своим условием: такой-то источник прибавляет столько-то баллов, такой-то регион добавляет ещё столько-то. Условия задаются в настройках самого робота, поэтому лишние срабатывания отсекаются на входе.
Настраиваются роботы в разделе CRM: выбираете нужный элемент (лиды или сделки) и открываете вкладку «Роботы». Там же живут вспомогательные вещи, без которых сложная модель быстро превращается в кашу. Переменные и константы хранят значения, которые не хочется дублировать по всем роботам. Отладчик роботов позволяет пошагово отследить все действия и найти ошибку, и пользоваться им стоит сразу, а не когда менеджеры придут с вопросом, почему у половины лидов балл нулевой.
Если условий становится слишком много и они начинают ветвиться, вкладка «Роботы» перестаёт быть удобной. На этот случай есть дизайнер бизнес-процессов: он добавляет расширенные действия, недоступные в базовом интерфейсе, включая циклы для повторяющихся операций. Переносить туда всю модель ради красоты не нужно, но сложную ветку логики держать удобнее именно там.
Шаг третий: триггеры для поведения
Профильные признаки известны сразу, поведенческие появляются позже. За них отвечают триггеры. Триггер отслеживает действия клиента и изменения в CRM: переход по ссылке из письма, входящий звонок, оплату счёта, заполнение формы. Когда указанное действие происходит, триггер перемещает элемент на другую стадию.
Отсюда вытекает рабочая связка. Триггер ловит событие и переносит лид на служебную стадию, а на этой стадии уже висит робот, который прибавляет баллы и возвращает элемент обратно. Возврат делает робот «Сменить стадию»; после переноса роботы новой стадии остаются активными, так что цепочка не обрывается.
С повторными обращениями всё ещё проще. В справке есть пример ровно про этот случай: если в CRM появляется сделка от существующего клиента, робот сразу переносит её на стадию «Повторная сделка». Тот же приём работает и для скоринга, потому что постоянный клиент почти всегда должен получать высокий балл автоматически, без участия менеджера.
Есть и триггеры, которые срабатывают при изменении значений полей в карточке. Это удобно для ручной обратной связи: менеджер проставил отметку «бюджет подтверждён», и лид сам поднялся в приоритете.
Шаг четвёртый: приоритет должен дойти до менеджера
Число в карточке само по себе ничего не меняет. Балл должен влиять на то, что менеджер видит утром и в каком порядке берёт заявки в работу. Здесь понадобятся три настройки.
Сортировка и фильтр. Список лидов настраивается так, чтобы колонка с баллом была видна, а сохранённый фильтр «балл выше порога» открывался одним кликом. Это самое дешёвое изменение из всех и одновременно самое заметное для отдела.
Распределение. Робот «Изменить ответственного» назначает другого сотрудника ответственным за элемент в зависимости от условий, в справке приводится пример с суммой сделки. Для скоринга логика такая же: лиды выше определённого балла уходят опытным менеджерам, остальные распределяются обычным порядком. Если заявки приходят из открытых линий, работает ещё и очередь распределения лидов и контактов, которая настраивается в контакт-центре. Там задаётся список сотрудников и способ раздачи: равномерно между всеми либо строго по очереди, с переходом к следующему, если первый не ответил.
Задачи и уведомления. Роботы умеют ставить задачи и отправлять сообщения в чат, так что горячий лид можно сопроводить задачей с жёстким сроком, а руководителю отправить уведомление, если такая заявка провисела без звонка дольше получаса.
Что делать с холодными лидами
Самая частая ошибка после внедрения скоринга: считать, что всё ниже порога можно выбросить. Холодный лид редко означает «не купит никогда». Обычно он означает «не купит сейчас».
Для этой части базы разумнее собрать отдельную ветку автоматизации: письмо с полезным материалом, повторное касание через месяц, приглашение на вебинар. Робот отправляет письмо, триггер ловит переход по ссылке и поднимает лида обратно в работу. Так база не сгорает и не требует ручного внимания, пока клиент сам не подаст сигнал.
Заодно стоит присмотреться к качеству данных. Чем полнее заполнены карточки, тем точнее любая оценка, хоть человеческая, хоть автоматическая. Здесь помогает обработка звонков через встроенный AI: она состоит из трёх действий, это расшифровка диалога, подготовка резюме звонка и заполнение полей карточки на основе разговора. Менеджеру достаточно нажать кнопку и идти к следующему клиенту, а поля, от которых зависит скоринг, заполнятся из содержания диалога.
Как понять, что модель работает
Через месяц после запуска нужно проверить главное предположение: действительно ли высокобалльные лиды чаще доходят до оплаты. Без такой проверки модель превращается в украшение карточки.
Базовые ответы даёт CRM-аналитика. В ней есть раздел анализа лидов с отчётом «Общий анализ», который оценивает движение лидов по стадиям и работу менеджеров, и раздел продаж с отчётами «Воронка продаж», «Динамика продаж» и «Сравнение периодов». Все отчёты фильтруются по любым полям, включая пользовательские, а значит, и по вашему полю с баллом. Сравнение конверсии в двух срезах, «балл выше порога» и «балл ниже порога», показывает состоятельность модели за пять минут.
Если нужен постоянный дашборд, задача решается через BI-конструктор. Он работает с наборами данных о сделках, звонках и других элементах Битрикс24. Там же доступны наборы с оценками разговоров: crm_ai_quality_assessment содержит оценки звонков менеджеров по скриптам продаж вместе с идентификаторами звонков и информацией о сотрудниках, а crm_copilot_call_assessment хранит сами скрипты, их тексты, статус и пороговые значения оценок. Связка «балл лида плюс качество разговора» показывает руководителю, где именно теряются хорошие заявки: на входе или уже в работе менеджера.
Пересматривать веса стоит раз в квартал. Рынок меняется, каналы трафика меняются вместе с ним, и признак, который год назад приносил сделки, может перестать работать.
Пример: как это выглядит на практике
Сценарий ниже иллюстративный, собранный из типичных ситуаций, чтобы удобнее было примерить логику на себя.
Компания продаёт промышленное оборудование по Казахстану. Заявок в месяц около трёхсот, менеджеров пять, средний чек высокий, цикл сделки от двух недель. До скоринга менеджеры разбирали список сверху вниз, и крупные клиенты регулярно попадали в обработку на второй или третий день.
Модель собрали из восьми признаков, максимум 100 баллов, порог «горячего» на отметке 45. Технически это три пользовательских поля (балл, класс, дата последнего пересчёта), одиннадцать роботов на стадии «Не обработан» и четыре триггера на поведенческие события. Настройка заняла примерно рабочий день, ещё неделя ушла на наблюдение и правку весов.
Дальше поменялся сам ритм работы отдела. Утренний список открывается сохранённым фильтром: сначала «горячие», потом остальные. Лиды с баллом выше 70 автоматически уходят двум сильным менеджерам. По каждому такому лиду ставится задача со сроком в один час, а если задача просрочена, руководитель получает уведомление в чат.
Заметный эффект тут даже не в конверсии. Руководитель перестаёт узнавать о потерянной крупной заявке через месяц и видит перекос в нагрузке в тот же день.
Типичные ошибки
Слишком сложная модель на старте. Двадцать признаков с дробными весами невозможно объяснить менеджерам и потом невозможно отладить. Пять или восемь признаков в первой версии, этого достаточно.
Скоринг без изменения процесса. Балл посчитан, но список по-прежнему открывается по дате, а распределение осталось прежним. Тогда поле никак не влияет на выручку.
Отсутствие отрицательных баллов. Модель, которая умеет только прибавлять, со временем красит в горячий цвет половину базы. Штрафы за нецелевые признаки нужны так же, как бонусы за целевые.
Баллы, о которых менеджеры узнали последними. Если отдел продаж не понимает, откуда берётся число в карточке, он перестаёт ему доверять и работает по-старому. Полчаса на планёрке с разбором конкретных примеров стоят дешевле, чем месяц саботажа. Заодно менеджеры почти всегда подсказывают признаки, которых не было в первой версии модели: они видят закономерности, не заметные в отчётах.
Модель, построенная на догадках. Веса, придуманные на совещании, остаются гипотезой, пока их не проверили на фактах. Выгрузите выигранные и проигранные сделки за прошлый квартал, прогоните по ним свою формулу вручную и посмотрите, попали ли реально выигранные в верхнюю часть списка. Такая сверка занимает час и экономит месяцы работы с моделью, которая гладко выглядит на бумаге и ничего не предсказывает.
Никто не отвечает за модель. У скоринга должен быть владелец, обычно РОП, который раз в квартал смотрит отчёты и правит веса. Без этого модель тихо устаревает.
Если настраивать своими силами не хочется или в CRM уже накопилась логика, которую страшно трогать, эту работу можно передать на сторону. Мы занимаемся такими задачами постоянно: внедрение и настройка Битрикс24 включает и разбор текущей воронки, и сборку модели оценки, и обучение отдела продаж работе с новым порядком.
Частые вопросы
Нужны ли программисты, чтобы настроить скоринг лидов в Битрикс24?
Для базовой модели не нужны. Пользовательские поля, роботы и триггеры настраиваются через интерфейс без кода. Программист может понадобиться, если баллы должны подтягиваться из внешней системы, например из 1С или с сайта через API.
Где хранится оценка лида?
В пользовательском поле карточки. Обычно заводят числовое поле для самого балла и поле-список для класса лида, чтобы менеджеру было понятно без расшифровки чисел.
Можно ли пересчитывать балл автоматически при изменении данных?
Да. Триггеры реагируют на изменение значений полей и на действия клиента, а роботы после этого пересчитывают и записывают новое значение. Схема с промежуточной служебной стадией позволяет делать это сколько угодно раз за жизнь лида.
Чем скоринг отличается от простого деления лидов на источники?
Источник даёт один признак. Скоринг складывает несколько признаков, включая поведение клиента, и выдаёт одно число, по которому можно сортировать и принимать решения. При этом источник обычно остаётся самым весомым слагаемым.
Как проверить, что модель приносит пользу?
Через CRM-аналитику: сравните конверсию в оплату у лидов выше и ниже порога за один и тот же период. Если разница небольшая, веса подобраны неудачно и признаки нужно пересмотреть.
