Голосовой ИИ уже обслуживает заметную часть реального входящего потока. В июле 2026 года «Самолет Плюс» сообщил, что ассистент обрабатывает 65% звонков по объектам недвижимости. Компания также указала, что 87% клиентов положительно воспринимают такое общение. Это данные одного кейса, но они хорошо показывают сдвиг: контроль качества звонков теперь охватывает смешанную команду, где разговор начинает ИИ, продолжает менеджер, а результат фиксируется в одной CRM.
Старая таблица прослушки для такой схемы не подходит. Если поставить человеку и ИИ один общий балл, цифра скроет причину провала. Если построить две несвязанные системы, руководитель не увидит итог по воронке. Рабочая модель состоит из общего бизнес-блока, отдельных критериев исполнителя и критических нарушений.
Навигация по материалам M.I.L.O.: все статьи, глоссарий, главная.
Почему одного общего балла недостаточно?
Контроль качества звонков нельзя свести к одному общему баллу. Он отвечает на вопрос «звонок решил задачу?», но почти ничего не говорит о причине сбоя. Для управления нужен итоговый результат и отдельный профиль ошибок по каждому типу исполнителя, этапу и критическому нарушению.
Менеджер может верно понять потребность и забыть назначить следующий шаг. Голосовой ИИ может пройти сценарий до конца, но неверно распознать адрес или потерять контекст после перебивания. В обоих случаях итог один: клиент не получил ожидаемый результат. Исправления разные.
Google Quality AI объединяет оценку живых и виртуальных агентов в одном контуре. Документация описывает переход от ручной проверки небольшой выборки к автоматическому анализу всего массива разговоров. Amazon Connect также поддерживает формы оценки для людей, ботов и AI agents.
РОПу полезно видеть три числа:
- Общий бизнес-балл звонка.
- Ролевой балл исполнителя.
- Количество критических нарушений.
Первое число показывает состояние воронки. Второе направляет работу: обучение менеджера, правка сценария ИИ или исправление интеграции. Третье не даёт хорошей дикции или быстрому ответу скрыть опасную ошибку.
Что считать успешным звонком для человека и ИИ?
Успешный звонок заканчивается проверяемым результатом для клиента и бизнеса. Исполнитель может быть любым, но в системе должны остаться правильное намерение, выполненная задача, договорённость и запись в CRM. Эти признаки задают общий слой карты, по которому сравниваются менеджер и ИИ в одной воронке.
Контроль качества звонков начинается с результата процесса. Входящая квалификация может заканчиваться правильно определённым объектом и соединением с нужным специалистом. Продажа - подтверждённой потребностью и конкретным следующим шагом. Поддержка - решённым вопросом или передачей сотруднику вместе с контекстом.
Braintrust рекомендует измерять выполнение задачи, количество ходов до результата, частоту эскалации человеку и удовлетворённость клиента, когда её можно получить. Эти показатели полезнее, чем оценка «голос звучал естественно» без связи с исходом разговора.
Запишите одно предложение:
Звонок считается успешным, если клиент получил ___, система зафиксировала ___, а следующий участник процесса увидел ___.
Если команда заполняет пропуски по-разному, карта пока не готова. Сначала нужно договориться о результате, затем оценивать поведение.
Какие критерии должны быть общими?
Общая часть карты измеряет понимание задачи, точность информации, результат, следующий шаг и качество данных в системе. Она не зависит от того, кто говорил с клиентом. Каждый критерий формулируется через наблюдаемое действие и подкрепляется записью, транскриптом, событием CRM или журналом действий.
| Общий критерий | Проверяемый вопрос | Пример доказательства |
|---|---|---|
| Цель обращения | Исполнитель верно определил, зачем позвонил клиент? | намерение в транскрипте совпало с итоговой категорией |
| Результат | Целевая задача завершена или корректно передана? | запись создана, встреча назначена, вопрос закрыт |
| Точность | Клиент получил верную информацию? | ответ совпадает с базой знаний или условиями предложения |
| Следующий шаг | Клиент понимает, что произойдёт дальше и когда? | дата, канал и ответственный зафиксированы |
| Контекст | Следующий участник видит историю разговора? | резюме и ключевые данные попали в CRM |
| Обязательные правила | Выполнены требования сценария и обращения с данными? | обязательная фраза есть, запрещённого действия нет |
В контроле качества звонков каждый вопрос описывает наблюдаемое действие. Фраза «разговор прошёл профессионально» оставляет оценщику слишком много свободы. Более точный вариант звучит так: «исполнитель подтвердил задачу клиента до предложения решения».
Такой подход совпадает с рекомендациями Google по scorecard: вопросы должны быть ясными, конкретными, снабжёнными инструкцией и примерами. Неприменимый вопрос получает N/A и не участвует в расчёте.
Если текущая карта содержит общие слова без доказательства, начните с одного пилота. Бесплатный аудит до 60 минут звонков покажет, какие этапы вашего скрипта уже можно превратить в проверяемые вопросы.
Что отдельно проверять у менеджера?
У менеджера оцениваются решения внутри живого диалога: как он выясняет задачу, использует ответы клиента, работает с сомнением и фиксирует следующий шаг. Этот блок показывает навыки, которые можно разобрать на встрече, потренировать и повторно проверить на следующей серии реальных разговоров команды.
Ролевой контроль качества звонков менеджера обычно включает шесть этапов: приветствие, выявление потребности, презентацию, работу с возражениями, фиксацию следующего шага и завершение. Одного факта прохождения мало. Презентация могла прозвучать, но не опираться на слова клиента. Следующий шаг мог появиться в CRM без подтверждения в разговоре.
Ролевой блок менеджера можно собрать из пяти вопросов:
- Задал ли менеджер вопросы, достаточные для понимания задачи?
- Подтвердил ли он услышанное своими словами?
- Связал ли предложение с конкретной потребностью?
- Уточнил ли причину сомнения вместо ответа по шаблону?
- Согласовал ли конкретный следующий шаг?
Интонация и эмпатия остаются полезными сигналами, но их нельзя выводить только из транскрипта. Аудио нужно слушать отдельно. Документация Google прямо исключает акустические вопросы из оценки, основанной на тексте разговора.
Что отдельно проверять у голосового ИИ?
У голосового ИИ проверяются распознавание речи, понимание намерения, удержание контекста, задержка, перебивания, действия во внешних системах и передача человеку. Эти показатели собираются из аудио, транскрипта, телеметрии и журналов интеграций, потому что один текст разговора не раскрывает техническую причину сбоя в конкретном звонке.
Для контроля качества звонков голосового ИИ нужно видеть несколько слоёв. Распознавание переводит звук в текст. Модель определяет намерение и выбирает действие. Синтез возвращает ответ в аудио. Оркестратор удерживает контекст, вызывает CRM и решает, когда подключить человека. Ошибка любого слоя видна клиенту как один плохой разговор.
Минимальный ролевой блок ИИ:
| Критерий | Что измерять | Где искать причину |
|---|---|---|
| Распознавание | имена, адреса, числа и термины распознаны верно | аудио и STT-транскрипт |
| Намерение | запрос отнесён к правильному сценарию | классификатор и маршрут |
| Контекст | ИИ помнит уточнения и исправления клиента | история диалога |
| Задержка | ответ начинается без длинной паузы | p50, p95 и p99 по телеметрии |
| Перебивания | ИИ останавливается и продолжает с нужного места | аудио полного цикла |
| Действие | CRM, расписание или база знаний изменены верно | журнал вызовов инструментов |
| Передача | человек получает причину, резюме и собранные данные | карточка обращения |
Braintrust советует тестировать шум, акценты, быстрый темп, смену темы и противоречивые вводные. TestDevLab разделяет проверку распознавания, синтеза и полного голосового цикла. Транскрипта для этой работы мало.
Как собрать карту оценки с весами и auto-fail?
Начните со 100 баллов, отдайте 60 общему результату, 30 ролевым критериям и 10 операционной дисциплине. Критические нарушения вынесите за пределы суммы: они обнуляют звонок. Веса служат стартовой настройкой и меняются под задачу, тип разговора и конкретный уровень бизнес-риска компании на текущем этапе.
Стартовый шаблон выглядит так:
| Блок | Вес | Для менеджера | Для ИИ |
|---|---|---|---|
| Результат задачи | 20 | сделка продвинулась | задача выполнена или корректно передана |
| Понимание клиента | 10 | потребность подтверждена | намерение классифицировано верно |
| Точность информации | 10 | условия и факты верны | ответ совпал с источником данных |
| Следующий шаг | 10 | договорённость подтверждена | действие создано и озвучено |
| Контекст в CRM | 10 | комментарий отражает разговор | резюме и поля записаны без потерь |
| Ролевые критерии | 30 | слушание, презентация, возражения | STT, задержка, перебивания, handoff |
| Операционная дисциплина | 10 | регламент и обязательные фразы | сценарий, доступы и журнал действий |
Карта на 100 баллов нужна для сравнения динамики. Auto-fail защищает от ложного благополучия. Примеры критических нарушений:
- раскрытие чувствительных данных;
- неверная цена или условие;
- действие в CRM не соответствует договорённости;
- ИИ продолжил сценарий после явного запроса соединить с человеком;
- менеджер или ИИ пообещал то, чего компания не предоставляет;
- звонок завершился без сохранения критичного контекста.
AWS поддерживает секции, условные вопросы, веса и автоматическое заполнение вопросов по категориям, метрикам или генеративному анализу. Часть способов автоматизации имеет ограничения для self-service AI, поэтому возможности конкретной платформы нужно сверять отдельно. Google строит карту из вопроса, инструкции, типа ответа, вариантов и баллов. Принцип переносится на любую систему: вопрос должен иметь доказательство и однозначное правило оценки.
Как откалибровать карту до запуска на 100% звонков?
Сначала добейтесь согласия людей на одной выборке. Если РОП и ОКК по-разному оценивают один звонок, автоматизация лишь размножит это расхождение на весь массив. Спорные вопросы переписываются, получают примеры и повторно проверяются до устойчивого совпадения между всеми участниками процесса оценки команды.
Калибровка проходит в шесть шагов:
- Соберите реальные звонки с разными исходами, исполнителями и типами обращений.
- Дайте одну выборку независимо оценить РОПу, ОКК и владельцу процесса.
- Сведите вопросы, где ответы расходятся.
- Перепишите критерии через наблюдаемое действие и добавьте примеры.
- Зафиксируйте эталонный ответ и причину оценки.
- Запустите автоматическую оценку и регулярно проверяйте спорные случаи вручную.
Google рекомендует добавлять примеры реальных разговоров и следить за согласованностью аннотаторов. NIST AI Resource Center собирает материалы для тестирования, оценки, валидации и верификации AI. Новая ошибка в продакшене должна становиться новым тестовым случаем.
Как запустить контроль на реальных звонках?
Начинайте с одного типа звонка и одного результата. Широкая карта на все сценарии сразу почти неизбежно создаёт десятки неприменимых вопросов и спорные оценки. Пилот на реальном аудио показывает, какие критерии читаются однозначно по смыслу, а какие требуют другого источника данных.
Возьмите, например, входящую квалификацию. Опишите результат, выберите общие вопросы, добавьте ролевой блок и критические нарушения. Затем проверьте карту на реальном аудио. Контроль качества звонков лучше масштабировать после пилота, когда владельцы согласовали трактовку каждого вопроса.
Первый запуск даёт четыре набора находок:
- вопросы, которые нельзя оценить по транскрипту;
- условия, которые два оценщика понимают по-разному;
- ошибки интеграции, скрытые за нормальным разговором;
- новые сценарии клиента, которых нет в карте.
После пилота не меняйте сразу весь скрипт или всю модель. Сначала отделите частный случай от повторяющегося паттерна. Сбой у нескольких менеджеров требует коучинга или правки процесса. Поведение ИИ меняется через инструкцию, маршрут, базу знаний или интеграцию.
Что должен видеть РОП в отчёте?
Дашборд должен показывать не среднюю температуру, а провалы по этапам, исполнителям, типам звонков и бизнес-исходам. Каждый красный показатель должен открываться до конкретного разговора. Руководитель видит динамику, причину отклонения, запись и следующее управленческое действие без лишней ручной сводки данных по отделу.
Минимальный отчёт содержит:
- Долю успешных звонков по типу исполнителя.
- Средний общий и ролевой балл.
- Частоту auto-fail по категориям.
- Три самых частых провала за неделю.
- Связь оценки с результатом в CRM.
- Очередь звонков для ручного разбора.
Средний балл без расшифровки бесполезен. В контроле качества звонков рост с 72 до 78 выглядит хорошо, пока не выяснится, что увеличилась скорость ответа, но чаще теряется следующий шаг. Отчёт должен вести от цифры к этапу, затем к звонку и действию.
Что делать с низкими оценками?
Одна и та же оценка запускает разные действия. Менеджеру нужна обратная связь, ИИ - изменение сценария или интеграции, процессу - новый критерий и владелец. Без маршрута исправления полное покрытие звонков создаёт больше отчётов, но не меняет поведение команды или системы.
Разделите причины на четыре корзины:
| Причина | Действие |
|---|---|
| Навык менеджера | разбор звонка, тренировка формулировки, повторная проверка |
| Правило процесса | изменение скрипта, регламента или ответственности |
| Поведение ИИ | правка инструкции, примеров, маршрута или порога передачи |
| Технический сбой | исправление STT, телефонии, CRM или базы знаний |
Карта оценки становится полезной, когда каждый провал получает владельца и срок проверки. Иначе 100% охвата создают только больше красных строк.
С чего начать на своих данных?
Возьмите один сценарий и небольшой реальный массив звонков. Зафиксируйте результат, превратите этапы в наблюдаемые вопросы и найдите расхождения до масштабирования. Такой пилот даёт рабочий черновик карты и показывает, какие данные уже доступны, а какие ещё нужно собирать до полной автоматизации.
Контроль качества звонков можно начать с небольшого реального массива. M.I.L.O. проводит бесплатный аудит до 60 минут: мы собираем дерево оценки под ваш скрипт и показываем, какие этапы выполняются, где оценки расходятся и в какой части разговора теряется следующий шаг.
Посмотреть, как устроен аудит.
Источники: на чём основана карта?
Карта опирается на свежую документацию Google и AWS по оценке живых и виртуальных агентов, международный стандарт для контакт-центров, рекомендации NIST по проверке AI и практические материалы по голосовым агентам. Российский кейс используется только как сигнал массового внедрения и сравнения подходов.