AI-ассистент для отдела продаж: разбор кейса — контроль качества 12 000 звонков в месяц с 2% до 100%
Что это за кейс и на что стоит обратить внимание перед чтением
Запрос «ai ассистент для отдела продаж» люди вкладывают в разные вещи: одни имеют в виду бота, который общается с клиентом, другие помощника для менеджера, третьи инструмент для руководителя отдела. В этой статье разбирается один конкретный реальный проект, который ближе всего к последнему варианту. Отделу продаж внедрили систему речевой аналитики: все записанные звонки автоматически расшифровываются, оцениваются по скрипту и размечаются тегами, а руководитель отдела продаж (РОП) смотрит дашборды вместо выборочной прослушки.
Главная подтверждённая цифра проекта: покрытие звонков автоматическим контролем качества выросло с 2% до 100% на объёме 12 000 звонков в месяц. Срок внедрения составил 4-6 недель. Клиент работает по договору с NDA, поэтому название компании и остальные детали мы не раскрываем, а цифры приводим только те, которые подтверждены. Мы не приводим показатели, которых в проекте не измеряли: роста конверсии, выручки или скорости обработки заявок в данных кейса нет, и выдумывать их мы не будем.
Статья для владельцев бизнеса, коммерческих директоров и РОПов, которые решают, стоит ли внедрять AI в отдел продаж, и хотят увидеть на реальном примере, что именно делается, сколько это занимает и где границы возможностей. Если вам нужен общий обзор двух форматов (речевая аналитика и ИИ-слой в CRM), он есть в отдельной статье блога «AI-аналитика отдела продаж: кейсы с цифрами». Здесь мы идём глубже в один проект.
Проблема клиента: 12 000 звонков в месяц и 2% контроля
Отдел продаж клиента обрабатывал 12 000 звонков в месяц. Контроль качества звонков (ОКК) делался вручную: сотрудник включает запись, слушает, заполняет оценочный лист. Физически он успевал прослушать только 2% звонков.
Простая арифметика показывает масштаб. 2% от 12 000 — это примерно 240 звонков в месяц, то есть около 11 760 разговоров в месяц не слышал никто, кроме менеджера и клиента. Для наглядности условный пример (допущение автора, не данные кейса): если средний звонок длится 5 минут, то прослушать все 12 000 звонков — это около 1 000 часов работы в месяц. Один сотрудник на полной ставке такой объём не вытянет, а для команды ОКК это отдельная и дорогая штатная единица.
Чем опасна выборка в 2%
Выборка из 2% звонков может быть случайной, а может быть вынужденной: слушают те звонки, на которые пожаловался клиент, или те, что попались первыми. В обоих случаях картина по отделу складывается из малой доли разговоров, и общую динамику она отражает слабо. Если менеджер систематически не называет цену, не отрабатывает возражение или не фиксирует следующий шаг, в выборку из 240 звонков он может попасть случайно или не попасть вовсе.
Чего не хватало руководителю отдела
РОПу нужна была не просто расшифровка, а ответы на управленческие вопросы: кто из менеджеров не следует скрипту, какие возражения встречаются чаще всего, как часто клиенты называют конкурентов, на каких этапах разговор заканчивается отказом. Эти вопросы требуют анализа всего массива, а не горстки звонков.
Почему не решали вручную
Первая мысль в такой ситуации: нанять ещё сотрудников в ОКК. Здесь она упирается в экономику и в природу задачи. Объём звонков растёт вместе с отделом продаж, и штат ОКК пришлось бы увеличивать пропорционально. Прослушка звонков при этом остаётся монотонной работой, где качество оценки может снижаться к концу смены, а оценки разных людей могут расходиться.
Вторая мысль: ужесточить выборку (слушать только проблемные звонки). Но чтобы понять, какие звонки проблемные, нужно хотя бы поверхностно знать содержание всех. Без автоматической разметки этого знания нет. Третья: отдать оценку самим менеджерам. Самооценка не заменяет независимый контроль, особенно там, где от оценки зависит премия.
Поэтому задача ставилась по-другому: не усилить ручную прослушку, а убрать её физический потолок. Машина прослушивает всё и сообщает человеку, на что стоит потратить внимание. Решение о том, правильно ли менеджер отработал звонок, остаётся за человеком, но он принимает его по размеченному, а не по случайному материалу.
Решение: какой стек и из чего оно состоит
Внедрили систему речевой аналитики на базе ASR (автоматического распознавания речи, Whisper или Vosk) и LLM (большой языковой модели). Мы перечисляем только то, что реально вошло в проект.
Транскрибация звонков
Записи звонков автоматически превращаются в текст. Для распознавания использовали ASR-модели Whisper или Vosk: выбор между ними делается под требования к языку и приватности. Это первый слой: без качественной расшифровки всё дальнейшее строится на неверных данных.
Диаризация спикеров
Система разделяет реплики менеджера и клиента. Без этого нельзя оценить, что именно сказал менеджер: нужны отдельные ответы на вопросы «задал ли он нужный вопрос» и «как отреагировал клиент».
Скоринг по скрипту
LLM оценивает звонок по реальному скрипту продаж клиента, а не по общему шаблону для всех отраслей. Критерии оценки задаются заранее вместе с клиентом: что считается выполнением этапа, что нарушением, что допустимым отклонением. От качества этих критериев зависит качество оценки, поэтому их описание — одна из главных частей проекта.
Автотегирование
Звонки автоматически размечаются тегами: возражения, упоминания конкурентов, отказы. По тегам РОП быстро находит нужные разговоры, например, все звонки, где клиент назвал конкурента, или все отказы за неделю.
Дашборды для РОПа
На выходе руководитель получает дашборды по качеству звонков команды, а не сырые расшифровки. Расшифровка сама по себе не помогает: 12 000 текстов в месяц так же невозможно прочитать, как прослушать. Ценность появляется на уровне агрегатов и выборок по тегам.
Чего в этом проекте не было: RAG, агентов и голоса в реальном времени
Чтобы не создавать ложных ожиданий, прямо перечислим, что в проект не входило. RAG (поиск ответа по базе документов) здесь не использовался: система анализирует разговоры, которые отдел уже сам генерирует, и не ищет ответы во внешней базе знаний. RAG-ассистент для сотрудников — отдельный формат с другими задачами. Автономного AI-агента, который сам принимает решения, тоже нет: система оценивает и размечает, а решения принимают люди. Разговорного бота, который общается с клиентом по телефону, нет: анализ происходит после разговора.
Архитектура и этапы внедрения
Работа заняла 4-6 недель. Типовая последовательность этапов нашей услуги анализа звонков выглядит так, как приведено ниже; это общая схема процесса, а не детальный журнал конкретного проекта под NDA.
Этап 1. Подключение источника звонков (около 1 недели)
Записи берутся оттуда, где они уже хранятся: из телефонии, Zoom или записей в CRM. Менять систему связи не нужно. На этом этапе проверяется, в каком формате и качестве приходят записи, раздельные ли каналы у менеджера и клиента, как организован доступ.
Этап 2. Настройка ASR и диаризации (1-2 недели)
Настраивается распознавание речи и разделение реплик. Модель проверяется на реальных записях клиента, потому что качество зависит от шума, телефонного канала, акцентов и профессиональной лексики.
Этап 3. Настройка LLM-скоринга и автотегирования (1-2 недели)
Формализуется скрипт продаж: из него выделяются проверяемые критерии. По ним настраивается оценка и набор тегов. На этом этапе чаще всего выясняется, что скрипт в голове у РОПа и скрипт на бумаге — не одно и то же, и его нужно уточнять.
Этап 4. Дашборды и тестирование на реальных звонках (около 1 недели)
Перед полным запуском оценка системы сверяется с оценкой людей на реальных звонках, спорные случаи разбираются, критерии уточняются. Затем РОП получает дашборд, с которым работает в обычном режиме.
Результат в цифрах: что подтверждено
Подтверждены две цифры. Первая: покрытие звонков автоматическим контролем качества выросло с 2% до 100%. Вторая: объём, на котором это достигнуто, — 12 000 звонков в месяц. Срок внедрения — 4-6 недель.
Важно понимать, что именно означает «100%». Это охват: каждый звонок проходит транскрибацию, скоринг и разметку. Это не означает, что оценка в каждом звонке верна на 100%, и не означает, что продажи выросли на какой-то процент. Нам не известны (и мы не публикуем) данные о влиянии на конверсию, выручку или скорость обработки заявок: в данных кейса такого замера нет.
Оговорка про NDA и применимость. Клиент проекта закрыт договором, поэтому детали его бизнеса мы не раскрываем. Результат другого бизнеса может отличаться: он зависит от объёма звонков, качества записей, зрелости скрипта продаж, готовности РОПа работать с дашбордами и от того, что компания делает с найденными проблемами. Эффект на деньгах возникает не от самой системы, а от управленческих решений на её основе.
Соседний кейс: что дало встраивание ИИ в CRM
Для полноты картины упомянем отдельный реальный проект другого отдела продаж на amoCRM. Менеджеры тратили 8-10 минут после каждого звонка на ручное заполнение карточки сделки. Встроили ИИ-слой: LLM-саммари звонка формируется автоматически и попадает в карточку сделки через API и вебхуки, без ручного ввода. Время на заполнение карточки после звонка сократилось с 8-10 минут до нуля; срок внедрения — 3-5 недель, CRM не менялась. Подробнее о формате — на странице ИИ-автоматизация CRM для amoCRM и Bitrix24.
Эти два проекта решают разные задачи. Речевая аналитика даёт руководителю картину качества всего массива звонков, ИИ-слой в CRM снимает рутину с менеджера. Их можно внедрять по отдельности или вместе. Это два независимых результата двух разных клиентов, складывать цифры нельзя.
Ограничения и риски: что стоит знать до запуска
Любая система на ASR и LLM ошибается, и честный проект с ИИ начинается с признания этого. Ниже риски, которые мы закладываем в план.
Ошибки распознавания речи и «выдуманные» фразы
Whisper обучен на 680 000 часов многоязычных данных со слабой разметкой, и его авторы пишут, что модели приближаются к человеческой точности и устойчивости при проверке без дообучения под конкретный набор данных (ICML 2023). Но это общий результат на открытых тестах, а не гарантия для телефонных записей конкретной компании на русском языке. Исследование Koenecke и соавторов «Careless Whisper» (ACM FAccT 2024) показало, что примерно 1% расшифровок Whisper содержал целые выдуманные фразы, которых в аудио не было. Это измерено на англоязычных записях речи людей с афазией и контрольной группы (корпус AphasiaBank), а не на русскоязычных телефонных звонках, и относится к версии 2023 года. В повторном прогоне части выборки в декабре 2023 года авторы отметили тенденцию к улучшению, но подчеркнули, что модель всё ещё воспроизводимо выдумывает фразы. Вывод для проекта: транскрипт нельзя считать истиной в последней инстанции, а спорные оценки нужно проверять по самой записи.
Оценка по скрипту — это не приговор менеджеру
LLM-скоринг даёт приоритизацию, а не вердикт. Если оценка влияет на премию или увольнение, решение должен принимать человек, прослушавший звонок. Мы рекомендуем использовать систему как фильтр и инструмент обучения, а не как автоматическую систему штрафов.
Персональные данные и запись разговоров
Запись разговора с клиентом и её расшифровка — это обработка персональных данных, и, как правило, на неё распространяется закон 152-ФЗ. Статья 5 (ч. 5) закона требует, чтобы содержание и объём обрабатываемых данных соответствовали заявленным целям и не были избыточными. На практике это значит: определить, зачем хранятся записи и транскрипты, сколько времени, кто имеет доступ, и корректно уведомлять клиента о записи. Мы не юристы и точные формулировки уведомлений не диктуем: вопросы о согласиях и сроках хранения согласуйте с юристом вашей компании. Если данные нельзя передавать за пределы вашей инфраструктуры, это отдельное требование, которое влияет на выбор ASR-модели и способ развёртывания.
Качество входных данных и скрипта
Если записи звонков шумные, склеены в один канал или хранятся не полностью, качество диаризации и оценки падает. Если скрипт продаж существует только на словах, автоматизировать оценку по нему нельзя: сначала его нужно формализовать. Это не недостаток системы, а условие её применимости.
Как оценить такой проект у себя: сроки, стоимость, аудит
Начинать стоит с цифр, а не с технологии. Выпишите объём звонков в месяц, долю, которую прослушивает ОКК, и вопросы, на которые вы сейчас не можете ответить, потому что не слышите разговоры. Если звонков 50 в месяц, ручная прослушка ещё реалистична, и внедрение может не окупиться. Если их тысячи и покрытие измеряется единицами процентов, как в кейсе, смысл появляется.
Срок. Реальный проект речевой аналитики занял 4-6 недель, ИИ-слой в CRM — 3-5 недель. Это сроки уже понятных задач, а не оценка для любой компании: у вас они могут отличаться в зависимости от источника записей и сложности скрипта.
Стоимость. Для анализа звонков цена зависит от объёма звонков в месяц и сложности скрипта оценки, поэтому называется после аудита; цены «по запросу» мы не заменяем придуманными. Для ориентира по смежному формату: пилотная интеграция LLM в продукт или процесс (один сценарий, один канал) стоит от 250 000 ₽ при сроке 4-6 недель, а токены LLM-провайдера оплачиваются отдельно напрямую провайдеру. Это цена другой услуги, и мы приводим её лишь как порядок величины для пилота, а не как стоимость анализа ваших звонков.
Если неясно, с чего начинать, есть формат аудита: разбор данных, процессов и готовности к ИИ занимает 1-2 недели по фиксированной цене, на выходе план со сценариями, сроками и бюджетом. Подробности — на странице внедрение ИИ в бизнес. Если вам нужен именно анализ звонков, смотрите страницу анализ звонков отдела продаж с помощью ИИ.
Чек-лист: готов ли ваш отдел продаж к речевой аналитике
Пройдите по пунктам. Если на большинство вы отвечаете «да», разговор о пилоте будет предметным.
1. Звонки записываются, и записи можно выгрузить (из телефонии, Zoom или CRM) в нормальном качестве.
2. Известен объём звонков в месяц и доля, которую реально прослушивают сейчас.
3. Есть скрипт продаж, по которому можно проверять звонок: этапы, обязательные вопросы, запрещённые формулировки.
4. Есть человек (РОП или руководитель ОКК), который будет работать с дашбордами и принимать решения по результатам.
5. Сформулирована метрика, по которой вы поймёте, что проект сработал: охват контроля, число найденных нарушений, время на разбор, а не абстрактное «станет лучше».
6. Понятно, что делать с результатом: обучение менеджеров, правка скрипта, работа с возражениями. Без этого дашборд останется красивым экраном.
7. С юристом согласованы цели и сроки хранения записей и транскриптов, а клиенты уведомляются о записи.
8. Вы готовы к тому, что система ошибается, и выбрали процесс проверки спорных оценок по самой записи.
9. Команда понимает, что это инструмент контроля и обучения, а не способ поймать и наказать: иначе менеджеры будут сопротивляться.
10. Вы не ждёте от проекта голосового бота, который заменит менеджеров на линии: анализ идёт по записанным разговорам.
С чего начать
Практичный первый шаг — небольшой пилот на выгрузке реальных записей: проверить качество расшифровки, оценить, насколько критерии скрипта поддаются автоматической проверке, и посмотреть, какие вопросы РОП сможет закрыть дашбордом. Точный объём и стоимость называются после аудита ваших данных. Общий формат работ по встраиванию LLM в процессы описан на странице ai интеграция для бизнеса.
Источники
Radford A., Kim J.W., Xu T., Brockman G., McLeavey C., Sutskever I. — «Robust Speech Recognition via Large-Scale Weak Supervision» (Whisper), ICML 2023, PMLR 202; arXiv:2212.04356: обучение на 680 000 часов многоязычных и мультизадачных данных; модели хорошо работают на стандартных бенчмарках без дообучения под конкретный набор данных, приближаются к человеческой точности и устойчивости. https://proceedings.mlr.press/v202/radford23a.html
Koenecke A. и др. — «Careless Whisper: Speech-to-Text Hallucination Harms», ACM FAccT 2024; arXiv:2402.08021: около 1% расшифровок Whisper содержали целые выдуманные фразы или предложения, которых нет в аудио; измерено на англоязычных записях корпуса AphasiaBank (речь людей с афазией и контрольной группы), версия модели 2023 года; в повторном прогоне 250 сегментов (декабрь 2023) авторы отметили улучшение, но не исчезновение проблемы. https://arxiv.org/html/2402.08021v2
Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных», статья 5 «Принципы обработки персональных данных»: содержание и объём обрабатываемых персональных данных должны соответствовать заявленным целям обработки и не должны быть избыточными по отношению к ним. https://rulaws.ru/laws/Federalnyy-zakon-ot-27.07.2006-N-152-FZ/Statya-5/
Примеры проектов
Частые вопросы
Вернуться в блог.