Метрики зелёные, а звонки плохие. Как их слушать правильно

Дашборд показывает containment 78%, среднюю длительность 1:40 и ноль технических ошибок. А руководитель отдела продаж говорит, что звонки плохие. Правы оба: метрики считают события, а качество разговора живёт в том, как агент до этих событий дошёл. Поэтому звонки надо слушать — вопрос только в том, какие и сколько.

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

Почему по дашборду не видно, что звонок был плохим

Метрики агрегируют факты: дозвонился, продержал разговор, закрыл без человека, записал заявку. Всё это бывает зелёным в разговоре, где агент трижды переспросил одно и то же, перебил клиента на середине фразы и записал «вторник» вместо «четверга».

Есть и техническая причина. Точность распознавания интента у зрелых систем — 90–97% (по оценке платформы Balto). То есть от трёх до десяти звонков из ста агент понимает не так, как задумано, и почти ни один из них не попадает в отчёт как ошибка: система уверена, что всё поняла. Отдельно проседает распознавание речи — на акцентах, шуме, узкополосной телефонии и на именах собственных. Телефония узкополосна по определению, а имена, адреса и марки — как раз то, что агент пишет в поля.

Парные метрики подсказывают, где копать: repeat contact rate за 72 часа выше 15%, forced escalation выше 10% или transfer success ниже 90% (ориентиры Balto и Famulor) означают дыру в сценарии. Но где именно — видно только ухом. Как собрать саму систему показателей, разобрано в статье о метриках голосового AI-агента.

Какие звонки слушать: три среза вместо случайной выборки

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

Самые короткие. Нижние 5–10% по длительности. Там почти всегда конкретная поломка: агент не услышал первую реплику, endpointing обрезал клиента, ветка сценария оказалась тупиковой, клиент положил трубку на приветствии. Один такой звонок обычно объясняет десятки одинаковых.

Эскалации и обрывы. Здесь важно разделить два случая: агент передал разговор сам, потому что не был уверен, — и клиент выбил перевод, попросив человека несколько раз. Второе — дефект сценария, а не признак хорошей эскалации.

Звонки с незаполненными полями. Пустое поле означает одно из трёх: агент не спросил, спросил и не понял ответ, спросил не вовремя. Три разные причины и три разных правки — различить их можно, только прослушав.

Автоматическая аналитика сужает выборку, но не отменяет ухо. Replica заявляет анализ 100% диалогов (по данным компании) — это помогает найти нужные звонки быстрее, но решение, дефект перед вами или норма, принимает человек.

Чек-лист ревью одного разговора

Отмечайте по каждому прослушанному звонку — две-три минуты на разговор.

1. Понял ли клиент, с кем говорит. Агент представился, назвал компанию и повод звонка.
2. Сколько раз агент переспросил одно и то же. Два раза подряд — уже дефект распознавания или формулировки вопроса.
3. Перебивания. Агент перебил клиента; или замолчал от постороннего шума и поддакивания.
4. Возражение. Отработал по существу или свернул обратно в скрипт, не ответив.
5. Просьба о человеке. Прозвучала ли и на какой по счёту раз агент её услышал.
6. Поля в карточке. Заполнены ли все обязательные.
7. Цифры и имена отдельно. Дата, время, сумма, адрес, ФИО — сверяем посимвольно с записью, а не «на слух похоже».
8. Итог. Клиент получил то, зачем звонил, или ушёл ни с чем при формально успешном статусе.

Точность полей: метрика, которую считают руками

Возьмите 30–50 звонков, откройте запись и карточку в CRM рядом. По каждому обязательному полю отметьте: совпадает с тем, что сказал клиент, или нет. Точность = верные поля / все проверенные поля. Дальше разложите по типам: имена, даты, суммы и адреса ошибаются по-разному, и общий процент это скрывает.

Ключевая ловушка: транскрипт и понимание — не одно и то же. Расшифровка может быть дословно верной — клиент сказал «во вторник, лучше после обеда», — а в поле записано «10:00». Или наоборот: смысл понят правильно, но фамилия «Скворцова» распознана как «Скворцов», и заявка ушла не на того человека. Автоматический отчёт эти случаи не различит: для машины оба выглядят как заполненное поле.

Ограничения: чего прослушка не даёт

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

«Мне не понравилось, как он это сказал» — не дефект. Если поле заполнено верно, клиент получил ответ и не просил человека, это вкусовая правка. Дефект формулируется проверяемо: «клиент сказал X, агент записал Y», «клиент дважды попросил оператора, перевода не было». Остальное — гипотеза для A/B-теста сценария, а не задача на исправление.

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

И главное. Распространённый миф: «вендор обещает 80–90% resolution, значит, столько и получу». Независимые оценки production-внедрений дают 40–70%, а формулировки вида «up to» обычно приводятся без определения того, что считается решённым обращением. Своя цифра узнаётся не из презентации, а из прослушанной выборки по своему определению успеха.

Вывод

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