Порог скоринга и загрузка продаж: как выбрать отсечку

Отсечка 80 баллов может дать аккуратную очередь и пропустить половину подходящих покупателей. Отсечка 40 — собрать почти всех, но перегрузить менеджеров. Выбор зависит от цены обеих ошибок и доступных часов. Само по себе круглое число в CRM ничего не обосновывает.

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

Из каких записей считать качество

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

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

В документации scikit-learn прогноз оценки и выбор действия по порогу разделены; там же предупреждают о настройке порога на данных обучения. Для ручного скоринга CRM я использую ту же дисциплину: разработка правил, выбор отсечки и окончательная проверка не должны незаметно стать одной выборкой.

Три порога на одной условной тысяче лидов

Условный пример. Есть 1 000 полностью размеченных лидов, из них 200 подходящих. Каждый переданный лид требует в среднем 20 минут. У продаж есть 100 часов на этот поток. Баллы здесь — условная шкала, а не вероятность покупки.

Precision — доля подходящих среди переданных: для порога 60 это 150 / 300 = 50%. Recall — доля найденных среди всех подходящих: 150 / 200 = 75%. Определения метрик приведены в справочнике scikit-learn. Нагрузка равна числу переданных × 20 / 60. Округление часов в таблице не меняет исходный расчёт.

В средней строке 150 истинно положительных, 150 ложноположительных, 50 ложноотрицательных и 650 истинно отрицательных. Сумма четырёх ячеек равна 1 000. Эта проверка быстро выявляет потерянные записи и смешанные знаменатели.

Как принять решение о передаче

При лимите 100 часов порог 40 не помещается. Порог 60 заполняет ресурс полностью, поэтому не оставляет запаса на сложные обращения. Порог 80 освобождает время, но дополнительно пропускает 30 подходящих относительно порога 60. Данных о марже и вероятности сделки здесь нет: объявлять одну строку экономически лучшей было бы преждевременно.

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

В карточке решения запишите выбранный порог, доступные часы, допустимые пропуски, резерв и маршрут остальных лидов. Низкий балл может означать отложенную обработку или уточнение профиля. Он не должен автоматически превращаться в окончательный отказ. Термины передачи полезно закрепить через различие MQL и SQL.

Проверка на следующем потоке

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

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