Прайс за 2 минуты: как машинное обучение ускорило ответ лиду

К нам обратилась компания с большим потоком лидов и широким каталогом предложений. Каждый клиент искал свой продукт: с определёнными характеристиками, ценой и условиями. Менеджеру приходилось разбирать запрос, просматривать варианты и решать, какой прайс отправить. Ответ занимал до трёх часов.

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

Время ответа лиду

3 часа → 2 минуты

Рост конверсии

В 3 раза

Экономия времени команды

120 часов в месяц

Задача: подобрать прайс под запрос лида

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

При большом потоке обращений этот подбор становился узким местом. Много времени уходило на просмотр каталога, а часть подходящих вариантов могла остаться незамеченной. Клиент ждал, хотя нужная информация уже находилась внутри компании.

Мы сформулировали задачу для алгоритма: оценивать совместимость каждого предложения с запросом лида и помогать менеджеру собирать подходящий прайс. Цены и условия берутся из каталога компании. Машинное обучение отвечает за выбор его позиций.

Как устроен алгоритм

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

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

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

Какие данные нужны модели

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

Для публикации обобщим названия полей. Модели нужны три группы сведений:

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

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

Подготовка данных: чему можно доверять в CRM

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

Числовые поля приводят к единому формату и проверяют на ошибки. Пропуск в цене нельзя молча превращать в бесплатный продукт. Категории приводят к согласованным значениям; отсутствие значения обозначают отдельно. Для стартовой модели в плане подготовки предусмотрены масштабирование чисел и one-hot encoding — отдельные индикаторы категорий.

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

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

Для повторения такого подхода данные следует разделять до обучения преобразований, а правила заполнения пропусков и кодирования — определять только по обучающей части. Иначе в модель попадает информация из контрольной выборки и оценка становится завышенной. Этот риск называется утечкой данных; его подробно разбирает документация scikit-learn.

От логистической регрессии к CatBoost

Первой точкой сравнения стала логистическая регрессия. Затем в экспериментах использовали CatBoostClassifier и подбор его параметров. В журнале ранних версий зафиксированы следующие значения при 12 признаках:

Для последнего эксперимента также записаны Precision = 0,44 и F1 = 0,44. Это результаты ранней разработки. Журнал не содержит полного протокола измерения, выбранного порога и способа усреднения метрик, поэтому эти числа не описывают качество финальной системы на всех новых лидах.

CatBoost использует градиентный бустинг над деревьями решений: последовательность деревьев учится исправлять ошибки предыдущих. Такой подход позволяет учитывать сочетания признаков — например, вид деятельности клиента вместе с ценой и размером продукта. Метод описан в официальной документации CatBoost.

Библиотека поддерживает категориальные признаки. При работе с ней способ кодирования нужно выбирать с учётом её встроенных механизмов: подготовка данных для логистической регрессии и CatBoost может различаться. Подробнее — в документации по категориям.

Подбор гиперпараметров означает сравнение настроек обучения на валидационных данных. В журнале проекта указан grid search — перебор заданных сочетаний. Конкретные итоговые значения настроек в материалах не приведены.

Почему важен recall

Для фильтра есть два вида ошибок. Он может оставить лишний вариант, который менеджер затем уберёт. Или исключить предложение, которое действительно подошло бы клиенту. Вторую ошибку легко не заметить: менеджер уже не увидит этот вариант в подборке.

Если положительным классом считать подходящее предложение, recall показывает, какую долю всех подходящих вариантов удалось сохранить. Формула: TP / (TP + FN), где TP — сохранённые подходящие варианты, FN — ошибочно исключённые. Определение приведено в документации scikit-learn.

Учебный пример: из 15 подходящих предложений система сохранила 12 и убрала 3. Recall равен 12 / 15 = 80%. В проектном плане такой уровень потерь был предложен как критерий пилота. Это целевой критерий экспертной проверки, а опубликованные выше 0,44 — запись из раннего эксперимента; сравнивать их напрямую без протокола нельзя.

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

ROC AUC характеризует разделение классов по оценкам модели при разных порогах. Значение 0,86 нельзя читать как «86% прайсов подобраны верно»: метрика не описывает точность готовой подборки при выбранном пороге. См. определение ROC AUC.

Как проверять подбор до запуска

Для пилота в документации предусмотрено разделение данных на 75% для обучения с пятикратной кросс-валидацией и 25% для теста. Отдельно запланирована проверка на новых лидах: эксперт смотрит, какие подходящие предложения модель ошибочно убрала.

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

Экспертная проверка отвечает на практические вопросы:

• Сохраняет ли подборка варианты в нужном диапазоне характеристик и цены?
• Учитывает ли несколько допустимых категорий и местоположений?
• Не повторяет ли модель случайные или ошибочные решения из истории?
• Что происходит с новым продуктом, неизвестной категорией или неполной карточкой?
• Сколько времени менеджер тратит на проверку и исправления?

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

Как связать алгоритм с CRM

Проектная архитектура описывает взаимодействие «запрос — ответ». CRM передаёт признаки клиента и идентификатор менеджера. ML-сервис сопоставляет запрос с продуктами и возвращает пары «идентификатор продукта — класс». На стороне CRM этот ответ используется для фильтрации предложений.

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

В материалах раннего этапа описаны эксперименты в Jupyter и проверочный интерфейс Streamlit. Для сервиса указан Flask; контейнеризация обсуждается как вариант. Это описание проектной схемы, по нему нельзя восстановить полный состав финальной инфраструктуры.

Требование к ответу ML-сервиса составляло до 10 секунд, с желаемым ориентиром 2–3 секунды. Две минуты в результате кейса — время ответа лиду в целом. В него входит работа процесса вокруг модели. Эти два интервала измеряют разные вещи.

Что изменилось для бизнеса

По итогам внедрения получили три результата: время ответа сократилось с трёх часов до двух минут, конверсия выросла в три раза, а экономия рабочего времени составила 120 часов в месяц.

Сокращение ожидания и экономия труда — отдельные показатели. Три часа до ответа могут включать очередь и переключение между задачами. Поэтому разницу между тремя часами и двумя минутами нельзя просто умножить на число лидов и назвать экономией труда. 120 часов в месяц — отдельный итог проекта.

Денежный эквивалент высвобождённого времени можно оценить по формуле 120 часов × полная стоимость часа сотрудника. Ставку клиента мы не публикуем, поэтому сумму в рублях не приводим. Эти часы можно направить на переговоры и сложные обращения; сами по себе они не означают сокращения фонда оплаты труда.

Рост конверсии в три раза — относительный результат. Без исходного процента нельзя вычислить прибавку в процентных пунктах. В этом кейсе не публикуются период сравнения, размеры выборок и протокол эксперимента, поэтому результат описывает внедрение целиком и не позволяет выделить вклад одной модели.

Когда такой подход полезен

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

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

Для подготовки своей задачи используйте разбор первого AI-проекта и калькулятор времени автоматизации. А краткие результаты этого внедрения собраны в кейсе на главной.