bitrixИИ-скоринг лидов: кейс девелопера жилой недвижимости
Задача
ИИ-скоринг лидов — кейс девелопера жилой недвижимости, который тонул в потоке заявок с рекламы. Клиент — региональный девелопер с портфелем из 4 жилых комплексов комфорт- и бизнес-класса (около 2 800 квартир в активной продаже), отдел продаж — 18 менеджеров и 2 руководителя направлений. Рекламный бюджет — порядка 6 млн рублей в месяц на Яндекс Директ, VK Ads и агрегаторы недвижимости. Реклама давала около 3 000 лидов в месяц, и все они падали в Битрикс24 в одну общую очередь. Менеджеры обзванивали лиды подряд, сверху вниз, не понимая, кто из обратившихся реально готов покупать, а кто «просто смотрит». В результате горячий покупатель с одобренной ипотекой мог ждать звонка 4–6 часов, а за это время успевал поговорить с конкурентами. По внутренним замерам клиента, до 40% горячих лидов «сгорало» именно из-за поздней реакции. Вторая проблема — выгорание и текучка. Менеджер совершал 60–80 звонков в день, из которых лишь 5–7 были осмысленными разговорами с заинтересованными покупателями. За полгода уволились 7 из 18 менеджеров, а найм и обучение одного нового специалиста обходились примерно в 120 000 рублей. Руководители отдела продаж при этом не имели инструмента контроля: в CRM было видно факт звонка, но не его результативность, и понять, какие рекламные каналы приводят покупателей, а какие — пустой трафик, было невозможно. Конверсия из лида в сделку держалась на уровне 1,9%, и рост рекламного бюджета ситуацию не менял — он лишь увеличивал очередь. • 3 000 лидов в месяц без какой-либо приоритизации • 4–6 часов до первого звонка горячему покупателю • Текучка 7 из 18 менеджеров за полгода • Конверсия лид → сделка на уровне 1,9% Клиент поставил задачу: научить систему отличать перспективного покупателя от пустышки в момент поступления лида, мгновенно маршрутизировать горячие заявки лучшим менеджерам, а остальных не терять, а прогревать автоматически. Дополнительные ограничения: персональные данные не должны покидать контур клиента, а интерфейс работы менеджера — остаться привычным, без отдельных программ и вкладок. Требование — решение должно работать поверх действующего коробочного Битрикс24, без смены CRM и без остановки продаж на время внедрения. План предполагал три этапа: сбор и разметку исторических данных, обучение ML-модели и пилот на части трафика с A/B-замером результата. Отдельным пунктом клиент просил предусмотреть механизм контроля качества модели после запуска, чтобы скоринг не превратился в «чёрный ящик», которому отдел продаж перестанет доверять через пару месяцев.
Решение
Мы предложили ML-скоринг поверх коробочного Битрикс24: модель машинного обучения оценивает каждый новый лид по шкале 0–100, а CRM автоматически распределяет его по нужной ветке обработки. Сначала мы выгрузили из Битрикс24 историю за 14 месяцев: 31 000 лидов и 2 900 завершённых сделок. На этих данных обучили градиентный бустинг LightGBM. Целевая переменная — сделка в статусе «успех» в течение 90 дней после лида. Модель использует около 40 признаков: • источник и рекламная кампания (utm-метки, площадка, ключевая фраза) • параметры интереса: ЖК, тип квартиры, площадь, бюджет, этаж • способ покупки: ипотека (и одобрена ли), рассрочка, 100% оплата, trade-in • поведение на сайте: глубина просмотра, время на странице ЖК, скачивание презентации, повторные визиты • качество контакта: валидность телефона, наличие email, время заявки Точность модели на отложенной выборке — ROC AUC 0,87: топ-10% лидов по скору давали 44% всех сделок в исторических данных. Мы специально отказались от нейросетевых решений в пользу градиентного бустинга: модель интерпретируема, руководитель отдела продаж может увидеть, какие признаки повлияли на оценку конкретного лида, а переобучение на свежих данных занимает минуты на обычном сервере. Скоринг-сервис мы написали на Python 3.11 и FastAPI и развернули на сервере клиента рядом с коробкой Битрикс24. Интеграция построена на штатных механизмах CRM: на событие OnCrmLeadAdd повешен обработчик, который отправляет данные лида в скоринг-сервис, получает оценку и через REST API записывает её в пользовательское поле лида. Весь цикл занимает менее 3 секунд — менеджер видит скор ещё до того, как откроет карточку. Дальше срабатывает маршрутизация, настроенная бизнес-процессом в Битрикс24: • Скор ≥ 80 — горячий лид. Робот мгновенно ставит задачу топ-менеджеру, дублирует уведомление в чат отдела и запускает таймер: если за 5 минут лид не взят в работу, задача эскалируется руководителю. • Скор 40–79 — тёплый лид. Уходит дежурной смене, первый контакт в течение 2 часов. • Скор < 40 — холодный лид. Автоматически запускается цепочка автопрогрева: email-маркетинг, рассылки в мессенджеры и роботы с контентом о ЖК. Когда лид проявляет активность (переход по ссылке, повторная заявка), скор пересчитывается и лид может «всплыть» в горячую ветку. Внедрение шло поэтапно. Первые 3 недели занял сбор и чистка данных: мы привели к единому виду utm-метки, сматчили лиды со сделками и склеили дубликаты. Затем 2 недели — обучение и калибровка модели, ещё 3 недели — разработка сервиса и бизнес-процессов. Пилот запустили на 10% рекламного трафика: половина лидов пилота обрабатывалась по новой схеме, половина — по старой, чтобы честно измерить эффект A/B-тестом. Через 4 недели пилота разница в конверсии была статистически значимой, и скоринг раскатали на весь поток. Параллельно обучили отдел продаж: 2 сессии по 2 часа, регламент работы со скором и дашборд для руководителя.
Архитектура
Архитектура решения построена вокруг отдельного скоринг-сервиса, который работает рядом с коробочным Битрикс24 и не вмешивается в ядро CRM. Поток данных начинается с источников лидов: формы на сайте ЖК, коллтрекинг и рекламные кабинеты передают заявки в Битрикс24 штатными средствами — через входящие webhook и виджеты. На событие OnCrmLeadAdd установлен обработчик: при создании лида он отправляет его данные в скоринг-сервис по HTTP. Сервис на FastAPI принимает запрос, подтягивает недостающие признаки (поведение на сайте из PostgreSQL, историю касаний через REST API Битрикс24), прогоняет данные через модель LightGBM и возвращает скор 0–100. Ответ записывается в пользовательское поле лида через REST API, после чего бизнес-процесс Битрикс24 маршрутизирует лид по веткам. Чтобы пиковая нагрузка (до 150 лидов в час в рекламные часы) не блокировала создание лида, скоринг выполняется асинхронно: задачи ставятся в очередь Celery с брокером Redis, обработка занимает 2–3 секунды на лид. Признаки, которые не меняются часто (справочники ЖК, параметры кампаний), кешируются в Redis с TTL 1 час. Качество модели контролируется отдельным контуром: раз в неделю Celery-задача сверяет скоры с фактическим исходом сделок, считает AUC и долю сделок в топ-дециле. Метрики выводятся в Grafana; при дрейфе модели (падение AUC ниже порога 0,82) срабатывает алерт, и модель переобучается на свежих данных. Отказоустойчивость заложена на уровне интеграции: если скоринг-сервис недоступен или не отвечает за 5 секунд, обработчик отдаёт таймаут, поле скора остаётся пустым, и бизнес-процесс отправляет лид по fallback-ветке — стандартной очереди дежурной смены. Отдел продаж продолжает работать, ничего не замечая.
Стек
Битрикс24 Enterprise (коробка), Python 3.11, FastAPI, LightGBM, PostgreSQL 15, Redis, Celery, Grafana
Результат
Первые полные результаты сняли через 3 месяца после полного запуска, сравнивая с аналогичным периодом годом ранее и с контрольной группой пилота. Главный эффект — конверсия из лида в сделку выросла с 1,9% до 2,8%, то есть на 47%. При том же рекламном бюджете отдел стал закрывать на 25–27 сделок в месяц больше. Время первой реакции на горячий лид сократилось с 4–6 часов до 5 минут: робот ставит задачу мгновенно, а эскалация не даёт заявке зависнуть. Нагрузка на отдел продаж заметно снизилась. Менеджеры перестали тратить день на холодные обзвоны: около 35% входящего потока теперь обрабатывается автопрогревом без участия человека. Количество осмысленных разговоров на менеджера выросло с 5–7 до 12–14 в день. За полгода после запуска не уволился ни один менеджер — до этого отдел терял человека в среднем раз в 3–4 недели. • Конверсия лид → сделка: +47% (с 1,9% до 2,8%) • Реакция на горячий лид: 5 минут вместо 4–6 часов • Доля потока в автопрогреве: 35% без участия менеджера • Текучка менеджеров: 0 увольнений за 6 месяцев Стоимость привлечения сделки (CAC) снизилась на 31% — эффект дали и рост конверсии, и сокращение расходов на найм и обучение новичков. Дополнительно клиент получил прозрачность: по скорам рекламных кампаний стало видно, какие источники приводят покупателей, а какие — пустой трафик, и 18% бюджета перераспределили в эффективные каналы. Автопрогрев тоже окупился: около 9% сделок за период закрыли лиды, которые на входе получили скор ниже 40 и «дозрели» в рассылках. Окупаемость проекта — около 2,5 месяца после полного запуска. Модель продолжает работать и переобучается на свежих данных раз в месяц; точность скоринга за полгода эксплуатации не просела.
«Раньше менеджеры тонули в заявках и тупо обзванивали всех подряд — горячие клиенты уходили к конкурентам, пока ждали своей очереди. Теперь система сама показывает, кому звонить в первую минуту, и это изменило всё: конверсия выросла почти в полтора раза при том же рекламном бюджете. Отдельно радует, что за полгода не уволился ни один продавец — люди наконец продают, а не занимаются холодным обзвоном.»
Расскажите о задаче — предложим архитектурное решение
Бесплатный предварительный аудит за 3 рабочих дня: анализ задачи, вариант архитектуры, оценка сроков и бюджета. NDA при необходимости.
- Общение — с техническим архитектором, не с менеджером
- Фиксированная цена после технического аудита
- Гарантия на разработку по договору