ИИ-контроль качества звонков и чатов: что проверить в пилоте
Оценка разговора полезна бизнесу, только если понятно, что именно проверял ИИ и на какие реплики он опирался. Свежий разбор DiDi и AWS показывает один из подходов к такой проверке. Рассмотрим, какие вопросы стоит поставить перед собственным пилотом.
Что описали DiDi и AWS
8 сентября 2026 года AWS опубликовала материал о системе контроля качества контакт-центра DiDi на Amazon Bedrock. В ней выделены три направления: проверка причины обращения, оценка соблюдения правил обслуживания и поиск повторяющихся проблем клиентов. Чаты и расшифровки звонков предварительно приводятся к общему формату.
Важная деталь: вычислимые показатели, например время ожидания ответа, рассчитываются программно. Проверки с однозначными правилами дополнительно сверяются с исходным разговором. Такая схема сочетает расчёт метрик с проверкой контекста и позволяет разбирать спорные оценки по конкретным репликам.
С чего начать проверку на своих данных
Если в компании уже сохраняются разговоры, переписка и записи CRM, на этих данных можно построить пилот контроля качества. Его задача — проверить выбранные критерии на реальных обращениях и оценить, сколько времени команда тратит на разбор результатов.
Начните с одного отдела и одного понятного вопроса. Например: фиксирует ли менеджер согласованный следующий шаг после входящего обращения? До подключения модели руководителю полезно самому разобрать несколько типичных и спорных разговоров. Если сотрудники по-разному понимают критерий, автоматизация лишь сделает это расхождение заметнее.
Для каждого критерия подготовьте короткую карточку: что считается выполнением, какие исключения допустимы и когда следует ответить «недостаточно данных». Отдельно опишите ситуации с плохой записью, обрывом разговора и переносом обсуждения в другой канал. Отсутствие информации нельзя автоматически приравнивать к ошибке менеджера.
| Проверка | Подтверждение | Результат для руководителя |
|---|---|---|
| Назван следующий шаг | Реплика клиента или менеджера с отметкой времени | Выполнено / не найдено / недостаточно данных |
| Договорённость внесена в CRM | Конкретная задача, ответственный и срок | Совпадение или расхождение с разговором |
| Есть спорная ситуация | Фрагмент, который требует контекста или экспертизы | Передача человеку без автоматического взыскания |
Почему одного отчёта недостаточно
Salesforce Engineering предлагает оценивать агентов по действиям и итоговому состоянию системы, а не по убедительности ответа. Важно также проверять, не изменены ли посторонние записи и не использованы ли запрещённые операции. Это помогает выявлять ошибки, которые не видны в самом ответе помощника.
Для рассматриваемого пилота отсюда следует практический тест: если помощник написал «задача создана», откройте CRM и проверьте саму задачу. Совпадают ли клиент, ответственный и срок? Нет ли дубликата? Повторите проверку после повторной обработки того же обращения.
На первом этапе можно вообще не разрешать агенту изменять CRM. Пусть он готовит отчёт и черновик действий, а сотрудник подтверждает запись. Права на автоматическое изменение конкретных полей обсуждаются после проверки качества. Не следует одновременно давать доступ ко всем сделкам, контактам и настройкам системы.
Какие результаты измерять
- Ошибочные замечания. Как часто система находит нарушение там, где проверяющий его не подтверждает?
- Пропущенные нарушения. Какие существенные ситуации она не заметила?
- Проверяемость. Можно ли быстро найти реплику или запись CRM, на которой основан вывод?
- Трудозатраты. Сколько времени занимает проверка отчёта по сравнению с текущим способом работы?
- Стоимость обработки. Учитываются ли расшифровка, модель, хранение, интеграции и ручная проверка?
Границы приемлемого качества согласуйте до испытания. Не ограничивайтесь средней оценкой по всем разговорам: отдельно разберите жалобы, сложные запросы и записи низкого качества. Такой разбор помогает выбрать следующий шаг — уточнить критерии, улучшить данные или расширить пилот.
Риски пилота и условия масштабирования
Качество данных и специфика процесса. Отраслевая терминология, шум в записях, разные регламенты и пропуски в CRM могут приводить к неверным оценкам. Для пилота стоит собрать выборку типичных и сложных обращений, проверить качество расшифровки и согласовать критерии с руководителем отдела. Результаты на этой выборке помогут определить, какие проверки готовы к работе, а какие требуют настройки.
Обработка данных и доступы. Состав передаваемых данных, сроки хранения и круг сотрудников с доступом определяют до подключения реальных разговоров. Выбор облачного или локального размещения зависит от требований компании: отдельно проверяют, где выполняются расшифровка и анализ и какие внешние сервисы участвуют в обработке. Это позволяет заранее согласовать архитектуру с ответственными за ИТ и информационную безопасность.
Проверка спорных выводов. Ошибочная оценка может повлиять на обратную связь сотруднику и управленческие решения. Поэтому замечания сопровождают фрагментами разговора, спорные случаи передают ответственному руководителю, а кадровые решения оставляют за человеком. Исправленные оценки используют для уточнения критериев и повторной проверки системы.
Готовность к расширению. Перед подключением новых отделов и каналов оценивают долю ошибок, время ручной проверки и стоимость обработки. Если согласованные критерии выполняются на разных типах обращений, пилот можно расширять поэтапно, сохраняя контроль качества на каждом шаге.
