Контроль качества звонков с ИИ: как построить критерии проверки менеджеров

Обычная проверка звонков строится неудобно: руководитель выбирает несколько записей, слушает их целиком и по памяти сравнивает с внутренним стандартом. Такой разбор занимает время, а результат зависит от того, какие разговоры попали в выборку и кто именно их оценивал. Автоматическая расшифровка и краткое резюме ускоряют просмотр, но сами по себе не превращают его в контроль качества.

Саммари отвечает на вопрос «о чём говорили». Для управления нужны другие ответы: уточнил ли менеджер обязательные сведения, зафиксировал ли договорённость, не пообещал ли то, чего компания не может выполнить, появился ли следующий шаг в CRM. И главное — на каком фрагменте разговора основан каждый вывод. Поэтому ИИ здесь полезен не как автор общего впечатления, а как предварительный проверяющий, работающий по утверждённым критериям.

Ниже — схема, по которой можно построить такую проверку без попытки назначить модели роль судьи. Она дополняет общий подход к анализу звонков и процессов поверх CRM (/blog/ii-poverh-crm-analiz-zvonkov-i-processov/), но сосредоточена именно на критериях качества, выборке, неопределённости и ручном разборе спорных случаев.

Начните с цели проверки, а не с оценки сотрудника

Формулировка «оценивать менеджеров с помощью ИИ» слишком широкая. Она почти неизбежно приводит к одному суммарному баллу, который выглядит точным, но смешивает соблюдение сценария, результат обращения, сложность запроса, качество записи и субъективное впечатление модели. Исправлять по такому числу нечего: оно не показывает причину.

Полезная цель описывает конкретный риск процесса. Например: обнаруживать звонки, после которых клиенту обещали перезвонить, но задача не появилась; проверять, были ли озвучены обязательные условия; находить обращения, где причина отказа не зафиксирована; выделять разговоры, требующие разбора наставником. Каждый риск превращается в отдельный критерий с понятным источником подтверждения.

До подключения модели стоит ответить на три вопроса:

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

Если у сигнала нет следующего действия, он быстро превращается в ещё один отчёт, который никто не использует.

Определите единицу анализа и необходимый контекст

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

Вместе со звонком системе передают только необходимый контекст: направление и время, номер компании, роль сотрудника, тип обращения, текущий этап и разрешённые данные из CRM. Не следует отправлять модели общую выгрузку клиентов на случай, если что-то пригодится. Доступ ограничивается до анализа, а не просьбой «не показывать лишнее» в инструкции.

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

Переведите стандарт разговора в наблюдаемые критерии

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

Критерий Что проверяется Источник подтверждения
———————— —————————————————— ——————————————
Идентификация запроса Понятно ли, зачем обратился клиент Фрагмент расшифровки
Обязательные сведения Уточнены ли поля, нужные для следующего этапа Расшифровка и карточка CRM
Условия Нет ли противоречия утверждённым правилам компании Разговор и актуальная версия регламента
Договорённость Названы ли действие, ответственный или срок Конец разговора и итоговая сводка
Фиксация результата Перенесены ли нужные данные и следующий шаг Журнал CRM и задачи
Риск эскалации Есть ли нерешённый спор, жалоба или повторный запрос Разговор и история обращений

У критерия должны быть исключения. Например, повторно спрашивать адрес не требуется, если клиент подтвердил уже названный адрес; обязательное предупреждение может зависеть от услуги. Исключения лучше задавать явно, иначе система начнёт наказывать нормальные отклонения от сценария.

Разделяйте факт, правило и интерпретацию

В отчёте три разных слоя не должны выглядеть одинаково. Факт извлекается из журнала или записи: звонок длился восемь минут, клиент назвал адрес, после разговора задача не создана. Правило задаёт компания: обещанный обратный звонок нужно оформить задачей с определённым сроком. Интерпретация модели описывает смысл естественной речи: менеджер, вероятно, пообещал уточнить наличие и связаться позже.

Слой Пример результата Как показывать
————— ———————————————— —————————————-
Факт В CRM нет задачи после звонка Ссылка на журнал и время проверки
Правило После обещания перезвонить задача обязательна Версия чек-листа или регламента
Интерпретация Фраза похожа на обещание обратного контакта Фрагмент диалога и уровень уверенности

Сроки, статусы и наличие действий лучше проверять обычной логикой автоматизации процессов (/avtomatizaciya-biznesa/). ИИ нужен там, где договорённость выражена десятками способов. Такое разделение делает систему дешевле, понятнее и позволяет объяснить каждое срабатывание.

Не превращайте confidence в декоративный процент

Уверенность модели полезна только вместе с правилами её применения. Показатель «87%» не объясняет, что именно вызывает сомнение: плохая запись, неразделённые реплики, двусмысленная фраза или недостаток контекста. Кроме того, числовая уверенность модели не всегда является откалиброванной вероятностью ошибки.

Практичнее назначать состояние каждому критерию: подтверждено, не подтверждено, не применимо, недостаточно данных, требуется проверка. Рядом сохраняются повлиявший фрагмент и технические признаки качества: пропуски распознавания, неизвестный говорящий, оборванная запись. Если используется числовой confidence, пороги нужно настраивать на собственной размеченной выборке, а не брать из демонстрационного примера.

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

Свяжите разговор с тем, что произошло в CRM

Качество разговора нельзя оценивать исключительно по словам. Менеджер может корректно принять заявку, но забыть сохранить адрес. Может обещать отправить документ и действительно отправить его через минуту. Может кратко говорить с постоянным клиентом, потому что необходимые данные уже есть. Контекст меняет оценку.

Для каждого критерия заранее определяют владельца данных. Телефония подтверждает факт и время звонка. Расшифровка — произнесённые фразы с учётом ошибок распознавания. CRM (/crm-erp/) показывает карточку, ответственного, статус и последующие действия. Документы и платежи подтверждают завершение соответствующего шага. Ни один источник не объявляется безусловно истинным для всего процесса.

Проверка должна выполняться в подходящий момент. Нельзя сразу после завершения разговора обвинять менеджера в отсутствии действия, если регламент даёт пятнадцать минут на оформление. Система либо ждёт контрольного срока, либо отмечает результат как предварительный и пересчитывает его после появления новых событий.

Соберите выборку, которая не искажает картину

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

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

Выборку стоит распределять по типам обращений, сотрудникам, времени и каналам, а не брать первые доступные записи. При изменении сценария, модели или распознавания контрольный набор прогоняется заново. Иначе улучшение одного критерия может незаметно ухудшить другой.

Измеряйте ложные срабатывания и пропуски отдельно

У контроля качества две разные ошибки. Ложное срабатывание отправляет нормальный звонок на разбор и создаёт недоверие к системе. Пропуск не замечает реальную проблему. Их цена различается: для сигнала о возможной грубости допустим обязательный просмотр человеком, а для автоматического изменения премии даже небольшая неопределённость неприемлема.

На размеченной выборке полезно считать точность по каждому критерию, а не только общий результат. Система может хорошо находить обещание перезвонить и плохо различать подтверждение адреса. Общая цифра скроет эту разницу. Отдельно фиксируют причины ошибок: качество аудио, распознавание, неверное разделение участников, устаревший регламент, недостаток данных CRM или неправильная интерпретация.

Исправления тоже размечаются. Если проверяющий изменил вывод, система должна сохранить первоначальный результат, корректировку и основание. Такой журнал помогает улучшать критерии, а не просто накапливать ручные правки.

Human review должен быть рабочим процессом

Фраза «спорные случаи проверит человек» ничего не решает, пока не определено, кто, когда и что увидит. Очередь проверки должна содержать критерий, короткий релевантный фрагмент, необходимый контекст CRM и причину неуверенности. Заставлять наставника снова слушать весь разговор — значит почти не сократить работу.

Проверяющему нужны действия: подтвердить вывод, отклонить, отметить неприменимость, исправить категорию или отправить на более высокий уровень разбора. Для чувствительных критериев можно использовать вторую независимую проверку. Сотрудник, работа которого оценивается, должен иметь понятный путь увидеть основание и сообщить об ошибке в данных или контексте.

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

Оценивайте процесс этично, а сотрудника — объяснимо

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

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

Записи и расшифровки могут содержать персональные данные клиентов и работников. До запуска проверяют основания и цели обработки, уведомления, доступ, сроки хранения, место размещения баз и участие внешних поставщиков. Для России отдельно учитываются 152-ФЗ и изменения правил локализации. Такая проверка проводится применительно к конкретной схеме и не заменяется общей фразой в политике.

Запускайте систему от одного чек-листа

Первый пилот лучше ограничить одним типом звонка и пятью–семью критериями. Сначала команда вручную размечает репрезентативный набор разговоров и договаривается о трактовках. Если два опытных проверяющих постоянно расходятся, модель тоже не сможет стабильно применять правило: необходимо уточнить сам чек-лист.

Согласованность проверяющих имеет смысл измерять до автоматизации. Несколько специалистов независимо оценивают одну и ту же часть выборки, после чего разбирают несовпадения. Часто выясняется, что один считает обязательным дословное произнесение фразы, а другой принимает равнозначную формулировку; один видит нарушение, а другой — предусмотренное исключение. Итогом такого разбора должна стать не попытка выбрать «правильного» проверяющего, а более точное описание критерия, допустимых подтверждений и случаев, которые всегда уходят наставнику.

1. Выбрать процесс и управленческий риск.
2. Утвердить наблюдаемые критерии, исключения и источники.
3. Разметить обычные, проблемные и пограничные звонки.
4. Запустить анализ только для чтения и скрыть результаты от кадровых решений.
5. Сравнить выводы с ручной разметкой по каждому критерию.
6. Настроить пороги, состояния неопределённости и очередь проверки.
7. Связать подтверждённые сигналы с безопасными действиями: обучением, исправлением формы или задачей руководителю.
8. Повторять контроль после изменения модели, телефонии, регламента или состава данных.

На пилоте важнее не количество обработанных звонков, а воспроизводимость. Один и тот же критерий должен одинаково пониматься командой, каждый вывод — вести к источнику, а ошибка — иметь понятный маршрут исправления.

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

Чек-лист готовности к рабочему использованию

— У каждого критерия есть цель, формулировка, исключения и владелец.
— Результат разделяет факт, правило и интерпретацию модели.
— Сохраняются ссылка на фрагмент, версия чек-листа и время анализа.
— Доступ к звонкам и CRM ограничивается до передачи контекста модели.
— Есть состояния «не применимо» и «недостаточно данных».
— Пороги проверены на собственной размеченной выборке.
— Ложные тревоги и пропуски считаются отдельно по каждому критерию.
— Спорные случаи попадают в очередь с владельцем и сроком.
— Исправления проверяющих сохраняются и используются для пересмотра правил.
— Непроверенные сигналы не превращаются автоматически в санкции или финансовые решения.
— Определены сроки хранения, порядок удаления и юридическая схема обработки данных.

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

Источники

— NIST: AI test, evaluation, validation and verification (https://www.nist.gov/ai-test-evaluation-validation-and-verification-tevv)
— NIST AI 600-1: Generative Artificial Intelligence Profile (https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence)
— OWASP LLM09:2025 — Misinformation (https://genai.owasp.org/llmrisk/llm092025-misinformation/)
— OWASP LLM02:2025 — Sensitive Information Disclosure (https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/)
— Федеральный закон № 152-ФЗ «О персональных данных» (https://www.kremlin.ru/acts/bank/24154/print)
— Федеральный закон № 23-ФЗ об изменениях в обработке персональных данных (https://www.kremlin.ru/acts/bank/51683/print)