Контроль качества звонков: как выстроить ОКК и автоматизировать оценку под вашу нишу

Что такое контроль качества звонков и где его границы

Контроль качества звонков — это процесс, в котором каждый разговор менеджера с клиентом оценивается по фиксированному чек-листу и превращается в обратную связь для сотрудника и в управленческий сигнал для РОПа. До прихода ИИ в этот процесс компания держала отдел контроля качества, в котором один человек прослушивал 5–10% звонков, ставил оценки по таблице и писал комментарии в Excel. Сейчас задача та же, но методика изменилась: 100% покрытия, единые критерии и фидбек менеджеру в течение нескольких минут после разговора.

Важно сразу развести три понятия, которые в статьях часто склеивают в одно. Коллтрекинг отвечает на вопрос «откуда пришёл звонок» — рекламный канал, ключевое слово, посадочная. Запись разговоров отвечает на вопрос «что было сказано» — это просто хранилище аудио в карточке сделки. Контроль качества отвечает на вопрос «как менеджер вёл разговор и что с этим делать» — это оценка по критериям, тренды и решения.

Речевая аналитика — это технологический слой под контролем качества: ASR-движок переводит речь в текст, диаризация разделяет реплики менеджера и клиента, LLM проходит по чек-листу и ставит баллы. Сама по себе речевая аналитика — не цель, а инструмент. Цель — управленческий процесс «оценил → дал фидбек → менеджер исправил → выросла конверсия».

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

5 признаков, что вам нужен отдельный ОКК

Не каждой компании нужен отдельный отдел контроля качества — иногда достаточно того, что РОП слушает выборку звонков сам. Но в какой-то момент масштаб ломает эту схему, и возникают вполне измеримые сигналы. Если хотя бы три из пяти ниже — пора запускать ОКК или автоматизированный контроль через ИИ.

Первый признак — РОП тратит на прослушку больше 2 часов в день и всё равно охватывает меньше 10% потока. На отделе из 10 менеджеров это типично уже при 200 звонках в день, и ни о каком развитии команды речь не идёт — РОП превращается в модератора. Второй признак — менеджеры регулярно спорят с оценками, потому что критерии «дружелюбный», «вёл клиента» субъективны и каждый проверяющий понимает их по-своему.

Третий — конверсия в сделку проседает, но непонятно, на каком этапе. Это значит, что выборка из 5–10% звонков не репрезентативна, и системные ошибки скрипта вы просто не видите. Четвёртый — приходят жалобы, которые вы не можете заранее отловить: клиент уходит к конкуренту с формулировкой «мне обещали», а вы не знаете, что именно ему обещали и кто.

Пятый признак — поток новых менеджеров. Каждый новичок проходит через 2–3 месяца «адаптации», в которые вы платите ему зарплату и сжигаете тёплые лиды на учебных разговорах. Без системного контроля и быстрой обратной связи онбординг растягивается, а часть менеджеров отваливается, не дойдя до плана.

Сигналы запуска ОКК

• РОП слушает 2+ часов в день, но охватывает меньше 10% звонков
• Менеджеры регулярно спорят с оценками — критерии плывут
• Конверсия проседает, но этап провала не виден
• Жалобы клиентов из-за обещаний, которые никто не контролировал
• 3+ новых менеджера за квартал и медленная адаптация

Как устроен отдел контроля качества

ОКК — это не один человек с наушниками, а распределение ролей. На небольшом отделе до 10 менеджеров ОКК часто совмещается с РОПом или тренером, но как только поток переваливает за 200 звонков в день, нужен отдельный аналитик качества. Один аналитик вручную закрывает 25–30 звонков в день при средней длине 5–7 минут, то есть 500–600 в месяц — этого хватает на статистическую выборку, но не на 100% покрытие.

Ключевые роли в зрелом ОКК — аналитик, тренер, супервайзер и РОП. Аналитик слушает звонки или валидирует AI-оценки, ставит баллы и фиксирует расхождения. Тренер берёт звонки с низкой оценкой и проводит разборы — индивидуально или на общем стендапе. Супервайзер калибрует оценщиков между собой и следит, чтобы критерии не расходились. РОП работает с агрегатами: видит динамику по менеджерам, отделам и продуктам и принимает решения о коучинге или замене.

В гибридной схеме с ИИ роли смещаются. Аналитик не слушает каждый звонок, а валидирует выборку и работает с расхождениями между AI-оценкой и эталоном. Тренер получает не «список плохих звонков», а ранжированный шорт-лист с конкретными ошибками — система сама подсвечивает, у кого просел блок выявления потребностей или кто пропустил отработку возражения. Это переводит ОКК из режима «найти виноватого» в режим точечного развития команды.

Подчинение — отдельный вопрос. Если ОКК подчиняется РОПу, есть конфликт интересов: РОП заинтересован в высоких оценках своей команды. Если ОКК подчиняется коммерческому директору или собственнику, оценки честнее, но падает оперативность. Рабочий компромисс — функциональное двойное подчинение: процесс и стандарты задаёт коммерческий директор, оперативное взаимодействие — с РОПом.

Чек-лист и веса критериев: как сделать так, чтобы он работал

Универсальный чек-лист не работает. У застройщика звонок строится вокруг ЖК, сроков сдачи, ипотечных программ — здесь критерий «знание продукта» весит больше, чем «эмпатия». В B2B-услугах с длинным циклом сделки важнее выявление лица, принимающего решение, и фиксация следующего шага. В медицине — соблюдение compliance-формулировок и согласия на обработку данных. Поэтому чек-лист собирается под нишу и под конкретный скрипт, а не скачивается из интернета.

Базовая структура — 10–15 критериев, разделённых на блоки: открытие звонка, выявление потребности, презентация, отработка возражений, договорённости и закрытие, ведение CRM. Каждому критерию назначается вес от 1 до 5 в зависимости от того, насколько он влияет на сделку. Сумма весов даёт максимум — например, 100. Порог прохождения мы обычно ставим на 70–80%: ниже этого балла звонок попадает в очередь на разбор.

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

Чек-лист обязательно версионируется. Когда вы меняете скрипт или добавляете новый продукт, чек-лист тоже меняется — иначе старые критерии будут штрафовать менеджера за то, что вы сами и попросили делать иначе. У нас в проектах чек-лист пересматривается каждые 4–6 недель в первые полгода после внедрения, потом — раз в квартал. Версия фиксируется в карточке оценки, чтобы было понятно, по каким правилам звонок оценивался.

Типовые блоки чек-листа

• Открытие: представление, цель звонка, согласие на запись
• Выявление потребности: открытые вопросы, ЛПР, бюджет, сроки
• Презентация: связь с потребностью клиента, факты вместо «у нас круто»
• Возражения: отработка по технике, без давления и спора
• Договорённости: следующий шаг с датой и ответственным
• CRM: заполнены поля сделки, поставлена задача

Как калибровать оценки и убрать споры

Главная боль ручного контроля качества — субъективность. Двое аналитиков ставят одному звонку 7 и 9 баллов, и менеджер справедливо спрашивает: «А по чему вы вообще оцениваете?» Чтобы ОКК перестал быть спором мнений, его нужно калибровать — у этого процесса есть методика, и она простая.

Раз в неделю аналитики и тренер берут 5–10 одних и тех же звонков и оценивают их независимо. Потом сравнивают результаты по каждому критерию. Если расхождение по критерию больше 1 балла из 5, садятся и проговаривают: что именно понимается под «выявил потребность», на каком таймкоде это считается выполненным, что считается отработкой возражения, а что — спором с клиентом. Решение фиксируется в комментарии к чек-листу с примером.

При гибридной схеме калибровка идёт в две стороны. AI-модель проходит выборку звонков, аналитик параллельно оценивает их вручную, и расхождения идут в обе стороны: где AI ошибается — корректируется промпт; где ошибается человек — он смотрит на «второе мнение» AI. На наших проектах первые 2–3 недели уходят именно на это — после стабилизации расхождения в 80–85% случаев на стороне промпта, и они уходят за месяц.

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

Ручной контроль, AI и гибрид: что выбрать

Выбор модели зависит от трёх вещей: объёма звонков, среднего чека и зрелости отдела. Ниже — как мы расписываем это клиентам на первом созвоне, без маркетинговой шелухи. Маленькая команда из 1–3 менеджеров со скриптом «здравствуйте, у вас заявка» обычно не требует ни ОКК, ни AI — РОП и так слышит всё сам. На таких объёмах автоматизация не окупается.

Команда 5–20 менеджеров с потоком 200–500 звонков в день — пограничная зона. Можно нанять одного-двух аналитиков, и они закроют 30–50% звонков выборочно. Можно подключить готовый сервис речевой аналитики из коробки — он даст 100% покрытия, но оценки будут шумными, потому что чек-лист общий. Можно сделать гибрид: коробка плюс один аналитик, который валидирует и калибрует. Окупаемость зависит от чека: при чеке от 100 тысяч и среднем потоке гибрид окупается за 1–2 месяца.

Команда от 20 менеджеров и поток от 500 звонков в день — это территория серьёзного гибрида с кастомным AI. Здесь ручной ОКК физически не успевает: для 100% покрытия нужно 12–13 контролёров с фондом 700 тысяч в месяц. AI закрывает 100% за абонплату от 30–50 тысяч плюс 1–2 аналитика на валидацию. Главное — чтобы чек-лист был именно ваш, а не из шаблона: иначе вы платите за шум.

Встроенная в ВАТС оценка (Mango, UIS, Sipuni и тарифы Битрикс24) — отдельный класс. Она дешёвая и работает «из коробки», но её чек-листы общего назначения, точность распознавания на шумных мобильных звонках падает, а интеграция с CRM ограничена тем, что предусмотрено в самой ВАТС. Хорошо для старта или для маленьких отделов. Плохо как единственный инструмент в нише с длинным чеком и сложным скриптом.

Что технически делает AI-модуль контроля качества

Технологически контроль качества с AI собирается из четырёх слоёв. Первый — ASR, движок распознавания речи. На чистых записях офисной телефонии точность достигает 96–98%, на шумных мобильных и в кол-центре — 90–94%. Это сильно зависит от условий: акцент, фоновый шум, перебивания. Поэтому одну модель универсально на всё не натянешь, и в проектах мы подбираем ASR под реальные записи клиента.

Второй слой — диаризация. Она разделяет аудио на реплики менеджера и клиента. Без неё LLM смешивает фразы и оценивает звонок как монолог, что особенно критично в чек-листе по критерию «не перебивает клиента». Качество диаризации напрямую влияет на качество всего скоринга — это часто упускают в обзорах.

Третий слой — LLM-анализ по чек-листу. На вход подаётся транскрипт и промпт с критериями, на выходе — оценка по каждому критерию, общий балл, риски (например, «менеджер пообещал срок, который мы не можем гарантировать») и краткое саммари разговора. Промпт пишется под нишу клиента и под конкретный скрипт — это не «общая модель», а кастомная сборка. Иногда мы добавляем второй контрольный AI-оценщик: он проходит тот же звонок другим промптом, и расхождения отлавливаются автоматически.

Четвёртый слой — интеграция. Оценка и саммари записываются в карточку сделки в amoCRM или Битрикс24, риски ставятся как метки или цвет карточки, а РОП получает сводку рисковых звонков в Telegram-канал отдела. Раз в неделю — отчёт с динамикой по менеджерам и трендами. Это и превращает технологию в управленческий процесс. Без этого слоя AI работает в вакууме.

Контроль качества с человеком за чек-листом — это слепое пятно: ОКК слышит максимум 30% звонков и фидбек приходит через неделю. ИИ закрывает 100% потока за 5-10 минут, и впервые становится видно не «кто плохой менеджер», а «где ломается скрипт».

— Артём Костецкий, основатель MBK-Agent

Каким должен быть отчёт ОКК и что видит руководитель

Отчёт ОКК — это не папка с PDF за месяц. Это работающий рабочий инструмент, который РОП открывает каждый день вместо прослушки. Базовая структура — три уровня: карточка звонка, дашборд менеджера, сводный дашборд команды.

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

Дашборд менеджера показывает динамику: средний балл за неделю и месяц, проседающие критерии, сравнение с командой. Здесь важнее не сама оценка, а тренд — менеджер с 8/10 в среднем, у которого падает блок «закрытие сделки» три недели подряд, важнее, чем менеджер с 6/10, у которого стабильно. Тренд подсвечивается цветом и попадает в шорт-лист тренеру.

Сводный дашборд РОПа — главный инструмент управления. На одном экране: 5–7 рисковых звонков за день (где сорвалась сделка или были обещания), топ-3 проседающих критерия по команде, динамика по менеджерам и продуктам. Сюда же подключаются алерты — если в звонке сработал блокирующий критерий, РОП получает уведомление в течение 5–10 минут после завершения разговора. Это и есть то самое «action layer», когда аналитика не лежит в отчёте, а превращается в решение.

Как запустить пилот за 2–4 недели

Внедрение мы разбиваем на 7 этапов и укладываем в 3–4 недели. Первый этап — диагностика: 1 день на демо, разбор воронки, изучение текущего скрипта и того, как сейчас устроен контроль. Здесь важно понять, есть ли вообще запись звонков, в какой телефонии, как она связана с CRM, и где живут оценки сейчас — в Excel, в Google Sheets или вообще нигде.

Второй этап — аудит существующих звонков и сборка чек-листа. Мы берём 200–500 реальных записей, слушаем выборку с РОПом и тренером, формулируем критерии и веса, отдельно выписываем блокирующие. Это 3–5 дней совместной работы. Без этого этапа любой коробочный сервис даёт шумные оценки — потому что критерии «общие», а ниша «своя».

Третий-четвёртый этап — КП с детальным скоупом и договор с соглашениями по 152-ФЗ. Дальше идёт интеграция: подключение к телефонии, выгрузка записей, настройка ASR, написание промптов LLM под чек-лист, передача оценок и саммари в карточку сделки CRM. Параллельно настраиваются дашборды и каналы алертов. Это 5–10 дней технических работ.

Шестой этап — пилот на 30–50% потока с калибровкой. AI-оценки и оценки аналитика сравниваются 5–7 дней, расхождения фиксируются, промпт корректируется. На седьмом этапе включается полный охват и еженедельный мониторинг с докруткой чек-листа. К концу первого месяца у клиента уже есть цифры — насколько изменилась средняя оценка, сколько рисковых звонков отловлено, какие критерии стабильно проседают.

Что нужно от клиента до старта

• Доступ к записям звонков (телефония или CRM)
• Текущий скрипт и регламент звонка
• Контакт РОПа и тренера для калибровки
• Доступ к CRM с правами на запись в карточку сделки
• 200–500 типовых записей для аудита

Кейс: застройщик, контроль качества как часть AI-отдела продаж

Один из наших клиентов — застройщик с офисами в Санкт-Петербурге и Москве. Контроль качества был частью комплексного внедрения AI-отдела продаж, но сам по себе модуль ОКК давал измеримый эффект уже в первый месяц. До нас ОКК-сотрудник прослушивал около 25% звонков, оценки лежали в Google-таблице, обратная связь приходила менеджеру через 5–7 дней. Главная боль — менеджеры обещали клиентам сроки и условия, которые не были закреплены в карточке сделки, а потом сделки разваливались на этапе договора.

Чек-лист собирали 4 дня вместе с РОПом и тренером. В нём оказалось 13 критериев, из них 3 блокирующих: обещание срока сдачи без сверки с базой ЖК, обещание скидки сверх регламента, обещание ипотечной ставки конкретного банка. AI-модуль помечал такие звонки красным флагом, и в Telegram-канале РОПа появлялась карточка в течение 5–10 минут после разговора.

За 2 месяца количество просроченных обещаний клиентам упало в 4 раза. Покрытие выросло с 25% до 100%, скорость фидбека — с 5–7 дней до 5–10 минут. Аналитик качества переключился с прослушки на калибровку и работу с проседающими менеджерами. Параллельно тренер начал собирать «банк сильных приёмов» — фразы успешных менеджеров, которые подсвечивал AI, переходили в скрипт и онбординг.

Второй проект — застройщик в Казани, NDA. Здесь AI-контроль качества за первый месяц выявил 6 системных ошибок в скрипте: формулировки, после которых клиенты регулярно «уходили подумать» и не возвращались. Скрипт переписали, конверсия в сделку выросла. Главная сложность была не техническая, а методическая: РОП изначально хотел использовать AI как инструмент наказания, а в итоге получил инструмент развития команды и доработки продукта. Это типичный сдвиг — мы видим его почти на каждом внедрении.

152-ФЗ, хранение записей и on-prem

Звонок клиента — это персональные данные. По 152-ФЗ компания обязана получить согласие на запись и обработку, обеспечить безопасность хранения и иметь правовые основания для передачи данных третьим лицам, в том числе подрядчику аналитики. На практике это значит: предупреждение о записи в IVR или в начале разговора, политика обработки персональных данных, договор с подрядчиком с приложением о персональных данных и описание мер защиты.

Где хранятся записи и транскрипты — отдельный вопрос. В коробочных сервисах данные обычно лежат в облаке вендора, и контролировать срок хранения и удаление сложнее. В кастомных проектах мы предлагаем три варианта: облако в российском дата-центре с разграничением доступа, гибрид (хранение записей у клиента, обработка через API) или полный on-prem с развёртыванием на серверах клиента.

On-prem чаще всего нужен в банках, страховых, медицине и при работе с гостайной или коммерческой тайной по контракту. Это дороже на старте — нужны мощности под ASR и LLM, нужна команда DevOps, — но снимает все вопросы с регуляторами и службой безопасности. Облачный вариант проще и быстрее, и для большинства B2B-компаний с обычным средним чеком его достаточно.

Срок хранения записей и транскриптов прописывается в политике обработки. Типовая практика — 6–12 месяцев для записей и до 24 месяцев для транскриптов и оценок. После этого данные удаляются или анонимизируются. На наших проектах это всегда обсуждается с юристом клиента до запуска пилота, и в договоре фиксируется конкретный срок и процедура удаления.

Частые вопросы: шум, акцент, точность, ниша

«А справится ли распознавание с нашим колл-центром, где шум и перебивания?» В чистых условиях точность ASR держится на уровне 96–98%, в шумных мобильных — 90–94%. Это нормальные цифры для большинства задач: для оценки чек-листа важно не дословное совпадение, а смысловое — отработал ли менеджер блок выявления потребности, а не каким именно словом. Если у вас сильный фоновый шум, мы обычно делаем шумоподавление на уровне предобработки и подбираем ASR-движок под реальные записи на этапе аудита.

«У нас узкая ниша и жаргон, готовый сервис нас не понимает». Это правда — поэтому в кастомных проектах мы пишем промпт LLM под вашу терминологию и обучаем модель распознавать ваши продуктовые термины. У застройщика это «литер», «ДДУ», «эскроу», «литерное расположение». У IT-аутсорса — «спринт», «MVP», «ретро». Это не общая модель, а сборка под нишу, и поэтому она работает там, где коробка фейлит.

«Окупится ли это при нашем объёме?» Простая формула: считаем стоимость ручной прослушки (ставка ОКК × часы × месяцы) и сравниваем со стоимостью внедрения и абонплаты. При потоке от 100 звонков в неделю и среднем чеке от 100 тысяч окупаемость обычно укладывается в 1–3 месяца. При меньших объёмах или среднем чеке до 30 тысяч лучше начать с коробочного решения или вообще обойтись внутренним ОКК.

«AI — это чёрный ящик, я не доверяю оценке, которую дала машина». Это нормальное возражение, и оно правильно решается калибровкой. Каждая оценка LLM сопровождается обоснованием: на каком таймкоде сработал критерий, какая фраза послужила триггером. РОП может пересмотреть звонок и оспорить — после первых 2–3 недель калибровки точность стабилизируется, и доверие к системе возникает само. AI — не финальный судья, а первый фильтр, экономящий часы.

Что именно делает MBK-Agent под ключ

Мы не продаём подписку на коробочный сервис. Мы внедряем контроль качества звонков как кастомный модуль под ваш скрипт, CRM и регламент. Это значит, что каждый проект — это аудит реальных звонков, сборка чек-листа с РОПом и тренером, написание промптов под нишу, интеграция с вашей телефонией и CRM, развёртывание в облаке или on-prem и пилот с калибровкой.

После запуска мы остаёмся на еженедельной поддержке: следим за расхождениями оценок, докручиваем чек-лист при изменении скрипта, обновляем промпты, мониторим точность ASR. Это не «поставили и ушли», а постоянное сопровождение, потому что отдел продаж живой — у вас меняется продукт, меняется скрипт, приходят новые менеджеры, и контроль качества должен меняться вместе.

Контроль качества у нас часто идёт частью большого AI-модуля для отдела продаж: квалификация лидов, автозаполнение CRM, дашборд РОПа, контроль звонков, отчёты в Telegram. Но и отдельно как самостоятельный продукт он работает — у нас есть проекты, где компания подключила только ОКК, и через 2 месяца расширилась до квалификации и автозадач. Подход модульный.

Внедрение занимает 3–4 недели от первого созвона до полного запуска. Цена начинается от 100 тысяч за интеграцию и от 30 тысяч в месяц абонплаты — конкретная цифра зависит от телефонии, объёма звонков, количества кастомных критериев и формата развёртывания. Облако дешевле, on-prem дороже на старте. На пилоте за 2 недели можно увидеть первые цифры до/после на реальных звонках.

Что заказчики обычно не ожидают увидеть

Большинство клиентов заходит в проект с мыслью «сейчас найдём слабых менеджеров и наведём порядок». А получают три неожиданных результата, которые в итоге дают больше эффекта, чем сама дисциплина.

Первое — система так же чётко находит сильных менеджеров. Это не очевидно, но в среднем 1–2 из 10 регулярно показывают приёмы, которых нет в скрипте: их формулировки, способ задавать уточняющие вопросы, их тон в работе с возражениями. AI подсвечивает эти звонки как «успешные», тренер слушает, выписывает приёмы и переносит в скрипт и в онбординг новых. По нашим внедрениям это даёт +15–25% к скорости адаптации новичка.

Второе — становится видно, что скрипт нуждается в правках. Когда вы видите, что 60% менеджеров «спотыкаются» на одной и той же формулировке и клиенты после неё «уходят подумать», вопрос не в менеджерах. Вопрос в скрипте. У застройщика в Казани мы так нашли 6 проблемных формулировок за месяц, переписали — конверсия выросла. Это ROI не от контроля качества как такового, а от того, что AI работает ещё и как инструмент диагностики продукта.

Третье — тренды важнее разовых оценок. Менеджер с 8/10 в среднем, у которого три недели подряд проседает блок закрытия, важнее, чем менеджер с 6/10 со стабильным средним. Без AI этот тренд не виден — РОП смотрит на «среднюю по больнице» и не понимает, кому нужен персональный коучинг. С AI видно сразу, и коучинг становится точечным, а не «общая планёрка по работе с возражениями для всех».