О чём статья. Рабочий чек-лист KPI для первых двух недель запуска голосового робота на исходящем обзвоне. Разобрана по четырём контурам: техника и дозвон (Contact Rate, доля коротких диалогов, AHT), распознавание речи (intent accuracy, fallback, WER), логика сценария (прохождение воронки, зацикливание, эскалация, передача контекста при переводе) и бизнес-результат (конверсия, CSI).
Запуск голосового робота почти всегда проходит через одну и ту же фазу: первые два-три дня команда смотрит на дозваниваемость, видит «всё горит зелёным» — и успокаивается. А через неделю выясняется, что в большом куске диалогов робот путается на одном и том же вопросе клиента, перебивает его на уточнении и завершает звонок до целевого действия. Разберём метрики, по которым такие сбои ловятся на старте, а не месяцем позже из обзора конверсии.
Почему первые две недели нельзя оставлять без мониторинга
Боевая база всегда шире тестовой. На этапе интеграции скрипт обкатали на 50 номерах — всё работало. Но в проде появляются региональные акценты, непредвиденные формулировки, клиенты, которые перебивают робота на половине фразы. И сценарий, идеальный на тестах, начинает сыпаться на мелочах.
Итоговая конверсия как единственный KPI ловит эти сбои слишком поздно. Пока цифра просядет настолько, что станет заметной в отчёте, часть лидов уже раздражена, а часть номеров — выжжена. Мониторинг имеет смысл строить на опережение, по четырём контурам: техника, распознавание, логика, бизнес-результат. Каждый отвечает за свою зону отказа.
Контур 1. Техника и дозвон
Звонок до диалога ещё должен дойти. Если здесь что-то сломалось, остальной сценарий не включается в принципе.
Доля успешных дозвонов (Contact Rate). Отношение состоявшихся разговоров ко всем набранным номерам. Жёсткого универсального бенчмарка нет: Contact Rate на холодном B2B колеблется от 8 до 20% в зависимости от качества базы и числа попыток дозвона. Для тёплых и повторных обращений цифра выше. Правильный ориентир — результат вашей тестовой выборки на этапе интеграции. Падение на 10 пунктов относительно теста — сигнал проверить SIP-транк, автоответчики и чёрные списки.
Доля коротких диалогов (менее 10 секунд). Больше 15–20% — скорее всего, роботу не хватает первой реакции на «алло» или он начинает говорить до того, как собеседник взял трубку. Классическая причина — слишком короткая пауза в начале.
Средняя длительность разговора (AHT). Считайте медиану и 95-й перцентиль отдельно. Разрыв между ними больше чем в два раза — тревожный знак: часть диалогов зависает в бесконечных уточнениях или уходит в циклические ветки.
Контур 2. Распознавание речи
Прослойка между репликой клиента и логикой сценария. Если ASR (automatic speech recognition) ошибается, робот отвечает невпопад — даже когда сам сценарий написан правильно.
Точность распознавания намерений (Intent Recognition Accuracy). Процент реплик, где робот правильно классифицировал, чего хочет клиент. Отраслевой бенчмарк на хорошо очерченных сценариях (запись, подтверждение заказа, callback) — 90–97%. Это важнее fallback: он ловит явные провалы, а intent accuracy — скрытые ошибки, когда робот «понял» неправильно и уверенно пошёл не в ту ветку.
Доля fallback-ответов. Процент реплик, на которые робот отвечает «простите, не расслышал» или аналогом. Отраслевой ориентир — до 10% в зрелом деплое, до 20% на старте. Выше 20% на второй неделе — пора расширять словари интентов и слушать записи сложных мест.
WER (Word Error Rate). Общая ошибка распознавания слов. На чистом аудио норма — ниже 8%. Отдельно замеряйте accuracy на цифрах, адресах и именах: там WER обычно выше, и именно эти блоки чаще всего ломают сценарий, если клиент диктует данные.
Среднее число переспрашиваний на диалог. Больше двух — читается как «робот глухой», клиент бросает трубку.
Контур 3. Логика сценария
Здесь ловятся самые дорогие ошибки — те, что ломают не отдельную реплику, а весь путь клиента по дереву разговора.
Прохождение до целевого шага (Funnel completion). Какая доля разговоров доходит до ключевого узла — согласия, записи, подтверждения, перевода на оператора. Цифра строится как воронка по каждому шагу. По провалу между шагами видно, где именно диалог рушится.
Доля зацикливания. Процент диалогов, где робот больше одного раза возвращается в тот же узел. Любое повторное возвращение в один и тот же узел — повод открывать записи и смотреть, какая формулировка клиента «зацикливает» ветку.
Доля запрошенных переводов на оператора (Escalation Rate). Полезно разделять на плановую эскалацию (сценарий изначально ведёт к оператору) и форс-эскалацию (робот сломался посреди ветки). Отраслевой бенчмарк — плановая 30–40%, форсированная ниже 10%. Если клиенты просят оператора в 20% звонков, а в сценарии предусмотрена одна точка перевода — значит, роботу не хватает ответов на целый класс вопросов.
Качество передачи контекста при переводе (Transfer Success Rate). Доля переводов, при которых оператор получает краткое содержание диалога и клиенту не приходится повторяться. Бенчмарк — выше 90%. Низкий Transfer Success бьёт не по роботу, а по общему CSAT: клиент воспринимает это как «я трижды одно и то же рассказал».
Контур 4. Бизнес-результат
Финальный слой. По нему меряют успех проекта в целом, но для раннего мониторинга он работает как контрольная сверка: верхние контуры в норме, а эти проседают — значит, проблема в бизнес-логике, а не в технике.
Целевая конверсия звонка. Доля разговоров, закончившихся нужным действием: согласием на демо, подтверждением заявки, записью в календарь. Робот обычно даёт заметно меньшую конверсию с одного звонка, чем оператор, но компенсирует масштабом и ценой контакта. Правильное сравнение — не с оператором в абсолюте, а с юнит-экономикой лида: сколько стоит заявка через робота против заявки через КЦ.
Индекс удовлетворённости (CSI). В сервисных, подтверждающих и B2C-сценариях робот может завершать диалог короткой оценкой «вам было удобно общаться?» — её и фиксируем. В холодном B2B такая метрика обычно не собирается: клиент либо соглашается на следующий шаг, либо сбрасывает. Заменитель для B2B — регулярное выборочное прослушивание диалогов из жёлтой зоны других KPI.
Как построить мониторинг на опережение
Свести все метрики в один дашборд с автоматическими триггерами. Правило: у каждого KPI три границы — норма, жёлтая зона и красная. Красная зона отправляет уведомление ответственному в тот же день, жёлтая попадает в еженедельный обзор.
Частота проверок на первой-второй неделе запуска:
- технические KPI — каждые 2 часа в рабочее время;
- распознавание и логика — два раза в день с выборочным прослушиванием 20 записей на каждую проверку;
- бизнес-результат — ежедневно утром за прошедшие сутки.
Выборочное прослушивание критично именно на старте. Ни одна метрика не скажет вам, что робот говорит с неправильной интонацией или не делает паузу там, где клиент пытается возразить. Для этого диалоги нужно слушать. Но не все — а те, которые по метрикам попали в жёлтую или красную зону.
Готовая платформа вместо самодельного дашборда
Собрать такой контроль с нуля — это недели работы инженеров и аналитиков. На практике быстрее брать решение, где нужная телеметрия уже встроена.
Коротко — чек-лист для первой недели запуска
- настроить дашборд с Contact Rate, долей коротких диалогов и AHT;
- добавить intent accuracy, fallback-долю, долю переспрашиваний и WER;
- выстроить воронку по сценарию с метрикой зацикливания, плановой и форсированной эскалации;
- проверить, что при переводе на оператора передаётся контекст (Transfer Success);
- выделить человека, который каждый день слушает 20–30 диалогов из жёлтой зоны;
- через две недели ревью: что из KPI стабилизировалось, где нужно переделывать сценарий.
Голосовой робот — живой продукт, который дорабатывается первые полтора-два месяца. Чем раньше заметен сбой, тем дешевле его правка. Поэтому главный KPI запуска — не конверсия, а скорость, с которой команда ловит и чинит проблемы в диалоге.
