bitrixРечевая аналитика звонков в Битрикс24: кейс оптового дистрибьютора
Задача
К нам обратился федеральный оптовый дистрибьютор строительных материалов с отделом продаж в 40 менеджеров и оборотом около 2 млрд ₽ в год. Запрос звучал так: «речевая аналитика звонков, кейс нужен как у нас — качество переговоров неконтролируемо вообще». Компания работала на коробочном Битрикс24 с подключённой телефонией: записи звонков формально сохранялись и даже прикреплялись к сделкам, но их не слушал никто — архив из десятков тысяч аудиофайлов просто занимал место на диске. Контекст боли. 40 менеджеров в трёх региональных офисах делали порядка 3 000 звонков в неделю: исходящий обзвон строительных компаний и розничных точек, входящие запросы по счетам и отгрузкам. Руководитель отдела продаж физически мог прослушать 20–30 записей в неделю — менее 1% трафика, и это при полной загрузке. Обучение новичков строилось по принципу «посиди рядом с опытным», а контроль скрипта — на самоотчётах менеджеров на еженедельных планёрках. CRM заполнялась небрежно: типовой комментарий к сделке — «созвонились, думают», хотя на самом деле клиент мог отказывать из-за цены, просить отсрочку платежа на 60 дней или согласовывать условия крупного контракта на квартал. Симптомы, с которыми пришёл клиент: • Средний чек по новым клиентам падал третий квартал подряд, причины были неизвестны — версии на планёрках расходились от «рынок просел» до «менеджеры разленились». • Контролёр качества (1 человек на 40 менеджеров) выборочно слушал звонки и регулярно находил грубые нарушения скрипта — от пропущенного выявления потребности до споров с клиентом, — но системно влиять на отдел не мог. • Потерянные сделки не разбирались вовсе: этап «Проиграно» ставился без обязательной причины, половина причин — «не отвечает», хотя по записям клиент часто озвучивал конкретное возражение или уходил к конкуренту по названию. • Наставники тратили по 6 часов в неделю на прослушку записей новичков, и этого всё равно не хватало: адаптация менеджера до плановых показателей занимала 4 месяца. Дополнительное требование службы безопасности: записи и тексты разговоров — коммерческая тайна, передача их внешним облачным сервисам исключена. Это сразу отсекло готовые SaaS-решения речевой аналитики. Что было запланировано. Автоматическая транскрибация 100% звонков внутри контура клиента, оценка каждого разговора по чек-листу скрипта с помощью LLM, поиск сигналов в диалогах (упоминание конкурента, возражение по цене, запрос на скидку или отсрочку, интерес к новой категории товара), автозадачи руководителю на разбор проблемных звонков, регулярный пересмотр «проигранных» сделок по текстам разговоров и обновление карточки сделки по факту звонка — без участия менеджера.
Решение
Мы спроектировали решение на базе коробочного Битрикс24 клиента (портал уже был развёрнут в собственном контуре, что совпало с требованием безопасности) и отдельного микросервиса речевой аналитики, который развернули на сервере клиента. Архитектура. Телефония клиента (Mango Office) писала все разговоры. По событию завершения звонка Битрикс24 через исходящий вебхук передавал нашему сервису ID записи и привязку к сущности CRM (лид, сделка, контакт, компания). Сервис забирал аудиофайл по API телефонии, ставил задачу в очередь и отправлял запись на транскрибацию в локально развёрнутый Whisper — данные не покидали контур. На выходе получался текст с диаризацией по ролям «менеджер/клиент» и таймкодами реплик. Далее транскрипт попадал в LLM-модуль с тремя независимыми задачами: • Оценка по чек-листу скрипта: 12 пунктов (приветствие и представление, выявление потребности, презентация по выгодам, отработка возражений, предложение следующего шага, фиксация договорённостей и т.д.). Каждый звонок получал балл 0–100 и разбор нарушений с таймкодами конкретных реплик. • Извлечение сигналов: упоминание конкурентов по справочнику из 30 названий, возражение по цене, запрос отсрочки, интерес к категории товара, договорённости вида «перезвоню в четверг» — с датой, нормализованной из разговора. • Резюме разговора в 3–5 предложениях: о чём договорились, что смущает клиента, какой следующий шаг. Результаты возвращались в Битрикс24 через REST API: резюме и балл — в таймлайн сделки, сигналы — в пользовательские поля сделки, распознанные договорённости — в дело «Запланированный звонок» с датой из разговора. Менеджер не заполнял ничего вручную. Автоматизация. Бизнес-процесс на сделке: если балл звонка ниже 60 — автозадача руководителю «Разбор звонка» со ссылкой на таймкоды нарушений. Если LLM нашёл сигнал «упомянут конкурент» или «возражение по цене» в сделке суммой свыше 500 тыс. ₽ — задача РОПу с высоким приоритетом и сроком 2 часа. Если по активной сделке 10 дней нет звонков и дел — робот напоминает менеджеру и копирует РОПа. На этапе «Проиграно» бизнес-процесс стал требовать причину из справочника — поле «не отвечает» без комментария больше не сохранялось. Отдельно построили воронку «потерянных сделок»: раз в неделю ночное задание пересматривало транскрипты всех сделок в статусе «Проиграно» за последние 60 дней и искало диалоги, где клиент фактически не отказал («думаю», «дорого, но интересно», «вернёмся после сезона»). Такие сделки автоматически возвращались в активную воронку на ответственного менеджера с комментарием из разговора и задачей «Перезвонить по итогам аналитики». Калибровка. Первые три недели мы прогоняли исторические записи (4 800 звонков за 3 месяца), вместе с РОПом корректировали чек-лист и веса пунктов: начальная версия завышала оценки за «вежливость» и занижала за выявление потребности. После двух итераций расхождение оценки системы с оценкой РОПа на контрольной выборке из 100 звонков сократилось до 8 баллов. Отчётность. Для РОПа и коммерческого директора собрали дашборд в Power BI клиента (данные через REST API): средний балл по менеджеру и по офису, динамика по неделям, топ-5 нарушений скрипта, карта возражений по сегментам, доля сделок с запланированным следующим шагом. Сроки: 3 месяца от старта до промышленной эксплуатации, включая калибровку и обучение руководителей работе с дашбордом.
Архитектура
Поток данных начинается с телефонии: Mango Office записывает все разговоры менеджеров. Битрикс24 по событию завершения звонка через исходящий вебхук передаёт в интеграционный сервис (FastAPI на сервере клиента) идентификатор записи и связанную сущность CRM. Сервис забирает аудио по API телефонии и ставит задачу в очередь Redis: транскрибация выполняется локальным Whisper в on-premise-контуре, аудио и текст не покидают периметр. Далее транскрипт с диаризацией по ролям поступает в LLM-модуль: три независимых промпта (оценка по чек-листу, извлечение сигналов, резюме) выполняются параллельно, результаты валидируются по JSON-схеме и сохраняются в PostgreSQL. Обратная запись в Битрикс24 идёт через REST API: резюме и балл — в таймлайн сделки, сигналы — в пользовательские поля, договорённости — в запланированные дела. Неудачные вызовы API попадают в очередь повторов с экспоненциальной задержкой; после 5 неудач — алерт дежурному инженеру. Бизнес-процессы на стороне Битрикс24 реагируют на обновлённые поля: низкий балл или критичный сигнал в крупной сделке порождают задачи руководителю, «проигранные» сделки раз в неделю перепроверяются отдельным ночным заданием. Отказоустойчивость: очередь выдерживает остановку LLM-контура до 24 часов без потери звонков, все промежуточные результаты персистентны, сервис транскрибации горизонтально масштабируется добавлением воркеров. Мониторинг — Grafana + Prometheus: длина очереди, время обработки звонка, доля ошибок транскрибации, доступность REST API портала. Среднее время от завершения звонка до результата в CRM — 4 минуты.
Стек
Битрикс24 Корпоративный портал, Mango Office, Whisper (on-premise), LLM API, REST API Битрикс24, Python 3.11, FastAPI, PostgreSQL 15, Redis, Power BI
Результат
Эффект проявился уже через 6 недель после запуска, полная картина — по итогам первого квартала. Контроль качества. Доля звонков, проходящих проверку, выросла с менее 1% до 100% — каждый из ~12 000 разговоров в месяц оценивается по единому чек-листу. Средний балл скрипта по отделу вырос с 54 до 78 за первые два месяца: менеджеры знают, что каждый звонок проверяется, и видят разбор своих нарушений с таймкодами. Срок адаптации новичка до плановых показателей сократился с 4 месяцев до 2,5 — наставники работают по конкретным пунктам чек-листа, а не по общим впечатлениям. Потерянные сделки. Еженедельный пересмотр «проигранных» за первый квартал вернул в работу 46 сделок, 19 из них закрыты на сумму 11,4 млн ₽. Это прямая выручка, которую компания раньше просто не видела: клиенты не отказывали — их никто не перезванивал. Экономия времени. Наставники перестали слушать записи целиком: вместо 6 часов в неделю на менеджера — 40 минут разбора по таймкодам, которые подсвечивает система. РОП получил автозадачи вместо случайных проверок: около 90 точечных задач на разбор в месяц, две трети закрываются в день постановки. Контролёра качества перевели на обучение отдела — штат не вырос. Заполнение CRM. Резюме и договорённости попадают в сделку автоматически: доля сделок с пустым таймлайном упала с 31% до 4%, следующий шаг запланирован в 92% активных сделок (было 47%). Причины проигрыша стали достоверными — доля «не отвечает» снизилась с 50% до 12%. Деньги. Конверсия из звонка во встречу или КП выросла с 18% до 24%, средний чек новых клиентов стабилизировался и прибавил 9% за квартал — в разборах стало видно, где менеджеры необоснованно дают скидки. Совокупный эффект (возврат сделок плюс рост конверсии) клиент оценил в 3,2 млн ₽ дополнительной маржи в месяц; затраты на проект и инфраструктуру окупились за 5 недель. Требование безопасности выполнено полностью: записи и транскрипты обрабатываются в контуре клиента, внешним сервисам передаётся только обезличенная аналитика дашбордов.
«Раньше я управлял отделом вслепую: слушал двадцать звонков в неделю и надеялся, что остальные похожи. Теперь система сама ставит мне задачи на разбор именно тех разговоров, где мы теряем деньги, — с таймкодами и причиной. А возврат «проигранных» сделок окупил проект ещё до конца первого квартала.»
Расскажите о задаче — предложим архитектурное решение
Бесплатный предварительный аудит за 3 рабочих дня: анализ задачи, вариант архитектуры, оценка сроков и бюджета. NDA при необходимости.
- Общение — с техническим архитектором, не с менеджером
- Фиксированная цена после технического аудита
- Гарантия на разработку по договору