Контроль качества звонков можно вести по записям с помощью ИИ: расшифровать разговор, отметить пункты чек-листа и передать спорные оценки руководителю. Такой подход полезен при большой очереди звонков, когда ручная выборка пропускает повторяющиеся ошибки. Оценка нужна для обучения, поэтому сотрудник должен видеть основание каждого замечания.
Цель оценки
Для одного звонка нужны запись, сверенный транскрипт, чек-лист и карточка замечаний с цитатами.
Сначала решите, что именно команда хочет улучшить. Оценка приветствия полезна лишь тогда, когда клиент действительно слышит начало разговора. Для продаж может быть важнее уточнение запроса, фиксация следующего шага и корректная работа с возражением. Для поддержки — точность ответа и подтверждение решения. Необязательные пункты в одном общем балле делают итог непонятным для менеджера.
Разделите критерии на наблюдаемые действия и качество результата. «Назвал срок поставки» можно проверить по записи. «Проявил заинтересованность» остаётся субъективным, до того, как команда задаст слышимые признаки: уточняющий вопрос, перефразирование потребности, подтверждение договорённости. Возьмите разговоры разной сложности и согласуйте оценки между руководителями до подключения модели. Расхождения людей укажут, где рубрике требуется уточнение.
- Оцените отдельно точность условий сделки и ход беседы.
- Назначьте статус «неприменимо» для отсутствующего этапа.
- Покажите сотруднику цитату и путь оспаривания.
Материал про ИИ для звонков охватывает также распознавание и голосового бота. Здесь речь только об оценке уже завершённого разговора. Бот участвует в беседе, а контроль качества помогает человеку понять, какой приём сработал и где произошёл сбой. Отдельная рубрика для каждого типа звонка избавит от ложных замечаний по сценариям, которые в разговоре вообще отсутствовали.
Зафиксируйте цель каждого пункта рубрики. Если менеджер задаёт вопрос о сроке, важно понять, какой риск сделки этот вопрос снимает. Тогда руководитель сможет обсуждать смысл действия, а модель получит ясную проверку. Пустая формальная отметка «скрипт соблюдён» обучению помогает слабо.
Транскрипт под проверкой
Запись сначала получает расшифровку и разделение реплик по участникам. Ошибка распознавания имени, числа или отрицания может перевернуть смысл оценки. Поэтому в карточке замечания нужна ссылка на отрезок аудио, вместе с цитатой из текста. Для пунктов о сроке, цене и обещаниях клиенту прослушивание фрагмента обязательно.
Сервис распознавания выбирайте по качеству речи вашей команды, шуму и доле разговоров с двумя говорящими. Сравнение способов расшифровки звонков поможет выбрать вход для этого процесса. Сам транскрипт мало говорит о качестве работы менеджера: правила оценки задаются отдельно и проверяются на реальных записях. Пробуйте записи с плохим звуком, паузами и перебиваниями, включая записи вдали от образцовых условий.
- Отберите записи и отметьте тип разговора.
- Получите транскрипт с разделением говорящих.
- Проверьте ключевые фрагменты аудио.
- Сохраните цитаты и временные метки возле критериев.
Если клиент и сотрудник говорят одновременно, модель может приписать ответ другому человеку. В таком месте карточка должна содержать отметку «требует прослушивания». Запретите автоматический штраф по фрагменту с сомнительной расшифровкой. Такая пометка честнее уверенного балла и быстрее ведёт руководителя к полезному эпизоду. Отмечайте качество входного звука отдельно от качества работы сотрудника.
При плохой связи отделяйте восстановленные слова от дословной расшифровки. Некоторые фразы выглядят гладко на экране, хотя в аудио слышен обрыв. Карточка качества должна показывать уровень надёжности самого источника. Руководителю полезнее прослушать сомнительный участок, чем спорить с уверенным текстом модели.
Рубрика без произвола
Один пункт рубрики формулируйте как проверяемый вопрос. Например: «Сотрудник повторил согласованный следующий шаг и срок?» Рядом задайте исходы: выполнено, частично, пропущено, неприменимо, запись спорная. У каждого исхода есть пример цитаты и правило для руководителя. Так модель выдаёт объяснимое наблюдение вместо характерологического отзыва о человеке.
Для оценки можно передать сверенный транскрипт в GigaChat или YandexGPT и попросить вернуть структурированную карточку. В промпте задайте роль, рубрику и правило цитирования. Пункт без свидетельства получает статус «данных мало». Модели нельзя додумывать намерение клиента по тону одной реплики. Полезно указывать временную метку к каждой цитате: руководитель быстро откроет соответствующий звук.
Покажите сотруднику, откуда взялся балл и как оспорить запись. Если руководитель исправил оценку, сохраните причину: ошибка распознавания, неподходящий критерий либо неверное толкование диалога. Эти причины пригодятся для пересмотра рубрики. Дисциплинарные решения по одному машинному баллу создают конфликт вокруг инструмента. Обсуждайте конкретные действия и следующий приём, который сотрудник сможет испытать в разговоре.
Сделайте несколько эталонных карточек с разными исходами по одному критерию. На них видно, чем «выполнено» отличается от «частично» и «неприменимо». Попросите руководителей оценить те же разговоры до показа образца. Если разногласия часты, меняйте формулировку критерия вместо усложнения промпта.
Разбор с менеджером
Руководитель выбирает один конкретный эпизод и начинает встречу с вопроса о намерении менеджера. Затем вместе слушают фрагмент и сравнивают его с критерием. Если сотрудник выбрал удачный путь за пределами чек-листа, обновите рубрику. Контроль качества нужен для улучшения разговора, поэтому число замечаний без последующей тренировки мало что меняет.
Отделяйте тип звонка: входящий вопрос о наличии товара и сложные переговоры требуют разного поведения. Периодически добавляйте случайную выборку помимо записей, помеченных моделью как проблемные. Иначе команда увидит лишь одну сторону работы. Сравните разборы до и после тренировки на том же типе разговора, сохраняя контекст сделки. При изменении скрипта сообщите об этом сотрудникам до следующей оценки.
Какие ошибки в разговорах вашей команды повторяются чаще всего?
Если замечания повторяются по одному пункту, следующим действием станет короткая репетиция фразы или вопроса. Руководителю важно понять, какую сцену дать сотруднику на тренировке. Для такого перехода полезен промпт оценки по записи, но окончательную формулировку обратной связи определяет наставник. Этот разбор подсказывает тему следующего занятия команды.
После обсуждения запишите один конкретный приём для следующего звонка. Например, менеджер повторяет словами клиента согласованный срок и просит подтверждения. На следующей встрече слушайте именно этот момент. Такой цикл обратной связи понятнее сотруднику, чем абстрактное требование «повысить качество общения».
Выборка и запуск
Запустите оценку на типах разговоров, где качество реально влияет на следующий шаг клиента. Составьте эталонную выборку, которую руководители уже оценили независимо. Разногласия между людьми покажут слабые места чек-листа раньше, чем спор с ИИ. После согласования сравните карточки модели с эталоном по каждому пункту, вместе с общим баллом.
Проверяйте, насколько часто модель пропускает важное обещание, путает говорящих или уверенно оценивает испорченный звук. Для таких случаев нужны маршруты ручного прослушивания. Доступ к записям и транскриптам ограничьте ролями; срок хранения согласуйте с принятой политикой обработки данных. В отчёте руководителю обычно хватает агрегированных причин замечаний. Сотруднику оставьте доступ к своим эпизодам и способу исправить спорную карточку.
Цена проекта зависит от объёма записей, состояния телефонии, требований к доступу и числа разных рубрик. При обсуждении сметы просите показать, где проверяется транскрипт, как хранится ссылка на аудио и как сотрудник оспаривает оценку. Пакет красивых графиков без доступа к исходному разговору почти бесполезен для обучения. Обучение сотрудников работе с ИИ поможет закрепить единую практику разбора замечаний.
Если телефония и CRM хранят разные идентификаторы разговора, проверьте связку до массовой оценки. Ошибка привязки отправит замечание другому сотруднику или сделке. В журнале держите идентификатор записи и источник метаданных. Это техническая деталь, от которой зависит доверие команды ко всему процессу.