Поговори
со мной!
со мной!
Когда «зелёный» дашборд вводит в заблуждение: как правильно оценивать эффективность ИИ в клиентском сервисе
Содержание статьи
Почему «успешный» AHT не гарантирует качества
В большинстве проектов задача по внедрению ИИ формулируется так: необходимо снизить нагрузку на первую линию и сократить расходы контакт-центра без ухудшения качества сервиса.
Для оценки эффекта от автоматизации традиционно используют привычные метрики:
- AHT (average handling time) — среднее время обработки обращения;
- % эскалаций — доля передач на вторую линию или живому оператору;
- % автоматизации — доля обращений, обработанных системой.
Изначально они разработаны для оценки работы оператора, например: в стандартных случаях AHT показывает, как быстро человек решил задачу ту или иную задачу клиента. Но когда аналогичную задачу решает робот или агент - есть подвох. Звонок может закончиться быстрее: но точно ли потому, что клиент получил решение проблемы?
«В проектах обычно смотрят на операторский AHT. Если после внедрения ИИ звонков к операторам стало меньше и они стали короче, это воспринимается как признак успешной автоматизации.
Но здесь кроется методологическая ошибка. При внедрении агентов «простые» темы начинает закрывать ИИ, а к операторам уходят более сложные кейсы. В результате структура потока меняется: коротких звонков становится меньше, доля сложных растёт, и операторский AHT может увеличиться.
Поэтому динамика AHT после внедрения не всегда отражает реальную эффективность — она часто показывает перераспределение сложности, а не качество работы системы.»
Но здесь кроется методологическая ошибка. При внедрении агентов «простые» темы начинает закрывать ИИ, а к операторам уходят более сложные кейсы. В результате структура потока меняется: коротких звонков становится меньше, доля сложных растёт, и операторский AHT может увеличиться.
Поэтому динамика AHT после внедрения не всегда отражает реальную эффективность — она часто показывает перераспределение сложности, а не качество работы системы.»
Елена Ефремова
Руководитель LLM-инженеров targetai
Недавний разбор команды Coval показал показательный пример: при «зелёном» дашборде 6 из 10 разговоров по факту оказались провальными — пользователи получали неточную или противоречивую информацию. Формально диалог был завершён, но задача клиента — не решена.
И если компания строит стратегию масштабирования ИИ, опираясь только на AHT и процент эскалаций, она рискует оптимизировать не то, что действительно важно.
В чём источник проблемы: перенос человеческих метрик успеха на ИИ
Контакт-центр десятилетиями жил в парадигме управления людьми. Отсюда логика измерений:
- Сколько длится разговор;
- Передали ли оператору;
- Сколько звонков обработано;
- Сколько стоил контакт.
Для человека эта модель логична: оператор ограничен временем на линии, нормами нагрузки и стоимостью рабочего часа. Чем быстрее он закрывает обращение, тем ниже себестоимость контакта.
AI Агент работает иначе:
- говорит устно и письменно;
- работает 24/7;
- параллельно обрабатывает тысячи диалогов;
- не устаёт.
Поэтому метрики скорости и «удержания на линии» перестают быть показателями качества. Более того, иногда они маскируют проблему.
Когда AHT маскирует провал
Снижение AHT может означать:
- более точные ответы;
- или преждевременное завершение диалога.
Высокий containment rate может означать:
- грамотную автоматизацию;
- или то, что клиент просто не понял, как попасть к оператору.
Containment rate — это доля обращений, завершённых без передачи оператору, и её часто используют как показатель автономности ИИ.
Но без контекста CJM эта метрика может вводить в заблуждение. Перевод на оператора не всегда означает провал — в сложных или чувствительных сценариях это корректная маршрутизация.
Поэтому важно оценивать не сам факт эскалации, а была ли она обоснованной и решена ли задача клиента в итоге. В отчётах это выглядит как рост эффективности, но в реальности, как перенос нагрузки в повторные обращения.
Какие метрики нужно измерять на самом деле
Если генеративный ИИ становится частью инфраструктуры клиентского сервиса, его нужно оценивать как автономную систему принятия решений, работающую в рамках бизнес-правил, регламентов и требований, с учётом обратной связи от клиентов.
Именно степень корректной автономности, а не просто скорость ответа, определяет реальную эффективность системы.
Это означает переход от абстрактных формулировок к измеряемым показателям, которые можно проверить.
Ниже — примеры метрик результата и способы их фиксации.
1. Доля фактически решённых обращений (Success Rate)
Что измеряем:
Процент диалогов, в которых задача клиента действительно закрыта.
Процент диалогов, в которых задача клиента действительно закрыта.
Как измерять:
Важно отличать «диалог завершён» от «задача решена».
- сопоставление завершённого диалога с событием в CRM (создано обращение, оформлено продление, отправлена карточка статуса);
- отсутствие повторного обращения по той же теме в течение X дней;
- выборочный аудит диалогов с ручной разметкой «решено / не решено».
Важно отличать «диалог завершён» от «задача решена».
2. Точность предоставленной информации (Answer Accuracy)
Что измеряем:
Долю ответов агента, в которых данные и рекомендации корректны: соответствуют CRM, базе знаний и правилам компании.
Долю ответов агента, в которых данные и рекомендации корректны: соответствуют CRM, базе знаний и правилам компании.
Как измерять:
1) Автопроверка по данным (там, где это возможно)
2) Симуляции диалогов (тестовые прогоны)
3) Оценка «судьями"
1) Автопроверка по данным (там, где это возможно)
- сопоставление ключевых фактов из ответа с CRM/БЗ (статус, сумма, срок, условия);
- проверка, что агент использовал нужные источники (например, запросил статус, а не "угадал").
2) Симуляции диалогов (тестовые прогоны)
- собирается набор типовых сценариев по тематикам (20−50 кейсов из реальных обращений и ошибок);
- агент прогоняется по ним в одинаковых условиях;
- фиксируется не только ответ, но и итог: что должно было произойти в системе (создано обращение, отправлен статус, выбрана правильная ветка).
3) Оценка «судьями"
- часть диалогов проверяется по чек-листу:
○ корректность фактов,
○ отсутствие противоречий,
○ соблюдение регламентов,
○ понятность объяснения;
○ отсутствие противоречий,
○ соблюдение регламентов,
○ понятность объяснения;
- периодически эта оценка калибруется человеком, чтобы шкала не "уплывала".
4) Аудит транскриптов, а не только финальных ответов
- выборочно читаются полные диалоги, чтобы понимать причину ошибок:
Принцип
Точность — это не только «как звучит ответ». Это проверяемая связка: что агент сказал, на каких данных он основывался и к какому результату привёл диалог.
3. Обоснованность эскалации (Valid Escalation Rate)
Что измеряем:
Долю передач оператору, которые действительно требовали участия человека.
Долю передач оператору, которые действительно требовали участия человека.
Как измерять:
Важно рассматривать эту метрику в связке с containment rate и долей автоматизации: высокий containment без анализа обоснованности эскалаций может скрывать недомаршрутизацию, а низкий — наоборот, избыточные передачи.
- классификация эскалаций по типам (сложный кейс / техническая ошибка / некорректный сценарий);
- анализ «возвратов» после передачи (если оператор повторяет тот же ответ — эскалация была избыточной);
- выборочная оценка диалогов перед переводом.
Важно рассматривать эту метрику в связке с containment rate и долей автоматизации: высокий containment без анализа обоснованности эскалаций может скрывать недомаршрутизацию, а низкий — наоборот, избыточные передачи.
Только баланс автономности и корректной передачи на оператора показывает реальное качество маршрутизации, а не просто уровень автоматизации.
4. Индикаторы фрустрации (Friction Signals)
Что измеряем:
Сигналы раздражения, снижения доверия и потери вовлеченности в диалоге.
Сигналы раздражения, снижения доверия и потери вовлеченности в диалоге.
Как измерять:
Это ранний индикатор скрытых провалов, которые не отражаются в AHT, но напрямую влияют на CSI, контактность и NPS.
- повтор одного и того же вопроса;
- рост длительности без продвижения к решению;
- резкий запрос оператора;
Это ранний индикатор скрытых провалов, которые не отражаются в AHT, но напрямую влияют на CSI, контактность и NPS.
5 Достижение целевого действия (Goal Completion)
Что измеряем:
Долю обращений, по которым агент привёл к фактическому достижению цели клиента.
Не «диалог завершён» и не «клиент доволен», а произошло ли целевое действие в системе.
Долю обращений, по которым агент привёл к фактическому достижению цели клиента.
Не «диалог завершён» и не «клиент доволен», а произошло ли целевое действие в системе.
Как измерять:
Метрика фиксируется через объективное событие в бизнес-системах:
Подтверждением служит не финальная фраза агента, а изменение состояния системы.
Если агент сказал «возврат оформлен», но запись в системе не создана — Goal Completion не достигнут.
Почему это критично для ИИ-агента
В проектах автоматизации часто путают:
Но отсутствие повторного обращения ещё не означает, что задача решена. Клиент мог отказаться от попытки, уйти в офлайн или просто потерять время.
Goal Completion убирает эту иллюзию. Он связывает работу агента напрямую с бизнес-результатом.
Отличие от Task Resolution
Task Resolution — задача логически закрыта в диалоге.
Goal Completion — цель клиента достигнута на уровне системы.
Для автономного агента это ключевой показатель эффективности.
Все остальные метрики — производные.
Метрика фиксируется через объективное событие в бизнес-системах:
- оформлено продление;
- проведена транзакция;
- создан и корректно классифицирован тикет;
- изменён статус заявки в CRM;
- отправлен документ или подтверждение;
- выполнено действие в биллинге.
Подтверждением служит не финальная фраза агента, а изменение состояния системы.
Если агент сказал «возврат оформлен», но запись в системе не создана — Goal Completion не достигнут.
Почему это критично для ИИ-агента
В проектах автоматизации часто путают:
- диалог завершён;
- оператор не подключался;
- клиент не перезвонил;
- метрика выглядит «зелёной».
Но отсутствие повторного обращения ещё не означает, что задача решена. Клиент мог отказаться от попытки, уйти в офлайн или просто потерять время.
Goal Completion убирает эту иллюзию. Он связывает работу агента напрямую с бизнес-результатом.
Отличие от Task Resolution
Task Resolution — задача логически закрыта в диалоге.
Goal Completion — цель клиента достигнута на уровне системы.
Для автономного агента это ключевой показатель эффективности.
Все остальные метрики — производные.
Ключевой принцип
Каждая метрика результата должна быть связана с проверяемым источником данных: CRM-событие, лог диалога, повторное обращение, ручной аудит или аналитика базы знаний.
Если способ проверки не определён, метрика остаётся декларацией.
И именно эти показатели позволяют понять, усиливает ли решение на базе ИИ клиентский сервис — или просто сокращает длительность звонков.
Как это сработало на примере кейсов targetai
1 Кейс «Ренессанс Страхование»: рост автоматизации — это не только доля звонков
Ренессанс Страхование обрабатывает около 90 000 звонков в месяц. Изначальная задача была типовой: снизить нагрузку на операторов и автоматизировать первую линию.
Какие метрики дополнительно отслеживались
1. Доля фактически решённых обращений (Task Resolution Rate)
Измерялась через:
Рост автоматизации сопровождался ростом именно фактически закрытых задач, а не просто завершённых диалогов.
Измерялась через:
- отсутствие повторного обращения по той же теме в течение контрольного периода;
- сопоставление диалога с действием в системе (создание обращения, отправка карточки, регистрация случая).
Рост автоматизации сопровождался ростом именно фактически закрытых задач, а не просто завершённых диалогов.
2. Обоснованность эскалаций
Часть обращений передавалась оператору. Важно было понять, оправдана ли передача.
Это позволило сократить избыточные эскалации и не перегружать операторов искусственно.
Часть обращений передавалась оператору. Важно было понять, оправдана ли передача.
Это позволило сократить избыточные эскалации и не перегружать операторов искусственно.
3. Индикаторы фрустрации
На старте до 60% клиентов отказывались от диалога с агентом. После корректировки формулировок показатель снизился до 30%.
Если бы ориентировались только на AHT и процент автоматизации, этот риск остался бы незаметным. Но именно снижение фрустрации стало фактором устойчивого роста автоматизации.
Формально:
По сути:
При росте доли обращений через агента с 5% до 100% в потоке, доля фактически закрытых задач увеличивалась пропорционально, без роста повторных обращений.
На старте до 60% клиентов отказывались от диалога с агентом. После корректировки формулировок показатель снизился до 30%.
Если бы ориентировались только на AHT и процент автоматизации, этот риск остался бы незаметным. Но именно снижение фрустрации стало фактором устойчивого роста автоматизации.
Формально:
- AHT мог оставаться стабильным,
- доля автоматизации росла.
По сути:
- росла доля фактически решённых задач,
- снижались повторные обращения,
- улучшалась корректность маршрутизации.
При росте доли обращений через агента с 5% до 100% в потоке, доля фактически закрытых задач увеличивалась пропорционально, без роста повторных обращений.
2 Кейс «Банки.ру»: работа 24/7 как фактор устойчивости
Контакт-центр получал около 5000 звонков в месяц. Задача — обеспечить поддержку 24/7 без расширения штата.
Классические показатели:
Но если смотреть через метрики результата, важнее следующее.
Классические показатели:
- 55% обращений агент закрывает полностью;
- 75% клиентов продолжают диалог без запроса оператора.
Но если смотреть через метрики результата, важнее следующее.
Что дополнительно измерялось
1. Goal Completion
Закрытие обращения сопоставлялось с действием:
Закрытие обращения сопоставлялось с действием:
- оформлена консультация,
- переданы корректные данные,
- создано обращение по мошенничеству.
2. Повторные обращения по ночным кейсам
Анализировали:
Анализировали:
- сколько клиентов, обратившихся ночью, перезванивают днём;
- были ли их задачи решены с первого контакта.
3. Отдельная эскалация VIP-клиентов
Для сегментов по значимости настраивалась особая маршрутизация, где измерялось, были ли передачи оператору обоснованными или вызваны недоработкой сценария.
Управленческий эффект:
Для сегментов по значимости настраивалась особая маршрутизация, где измерялось, были ли передачи оператору обоснованными или вызваны недоработкой сценария.
Управленческий эффект:
- ночью агент берёт на себя большую часть потока;
- нагрузка распределяется равномернее;
- снижается зависимость от смен и текучести персонала;
- уменьшается риск провалов доступности.
Это уже не оптимизация AHT. Это снижение операционного риска и повышение устойчивости сервиса.
Типовые управленческие ошибки при внедрении ИИ в клиентский сервис
1. Ожидание мгновенной «идеальной» автоматизации.
Без калибровки на реальных звонках точность всегда ниже ожиданий. Внедрение должно быть поэтапным — с проработкой отдельных этапов CJM и оценкой влияния на ключевые метрики. Иначе автоматизация масштабируется быстрее, чем подтверждается её качество.
Без калибровки на реальных звонках точность всегда ниже ожиданий. Внедрение должно быть поэтапным — с проработкой отдельных этапов CJM и оценкой влияния на ключевые метрики. Иначе автоматизация масштабируется быстрее, чем подтверждается её качество.
2. Отсутствие интеграции с внутренними системами.
Без доступа к актуальным данным ИИ не может обеспечивать корректность ответов.
Без доступа к актуальным данным ИИ не может обеспечивать корректность ответов.
3. Управление результатами по одной метрике.
Снижение AHT или рост FCR не гарантируют качества. Отсутствие повторного обращения не равно решённой проблеме — без проверки точности и результата это может быть лишь иллюзией эффективности.
Снижение AHT или рост FCR не гарантируют качества. Отсутствие повторного обращения не равно решённой проблеме — без проверки точности и результата это может быть лишь иллюзией эффективности.
4. Отсутствие системного мониторинга в первые недели.
GenAI-агент, как и сотрудник, может ошибаться. Разница в масштабе: при объёме 90 000 минут в месяц даже небольшая неточность быстро становится системной.
Так же как работа оператора регулярно проверяется, работа агента требует постоянного контроля, аудита диалогов и корректировки сценариев в первые недели после запуска.
Без этого единичная ошибка масштабируется быстрее, чем успевает быть замеченной.
GenAI-агент, как и сотрудник, может ошибаться. Разница в масштабе: при объёме 90 000 минут в месяц даже небольшая неточность быстро становится системной.
Так же как работа оператора регулярно проверяется, работа агента требует постоянного контроля, аудита диалогов и корректировки сценариев в первые недели после запуска.
Без этого единичная ошибка масштабируется быстрее, чем успевает быть замеченной.
Как избежать ошибок
1. Стройте систему метрик, а не одну цифру
Разделите показатели на три уровня:
Только связка этих уровней даёт реальную картину эффективности.
- Операционные — нагрузка, длительность, объём.
- Качественные — точность ответа, корректность маршрутизации.
- Результативные — достижение цели клиента, выполнение действия в системе.
Только связка этих уровней даёт реальную картину эффективности.
2. Масштабируйте поэтапно
Выводите агента в промышленную эксплуатацию постепенно:
10% → 30% → 50% → 100% потока.
На каждом этапе оценивайте влияние на ключевые показатели CJM, а не только рост доли автоматизации.
10% → 30% → 50% → 100% потока.
На каждом этапе оценивайте влияние на ключевые показатели CJM, а не только рост доли автоматизации.
3. Контролируйте скрытые риски
Отслеживайте:
Закладывайте 1–1,5 месяца на ежедневную калибровку.
По нашим данным, именно первые недели формируют до 70 % итогового качества автоматизации.
- повторные обращения по одной теме;
- причины эскалаций (обоснованные, технические, вызванные фрустрацией);
- динамику точности и достижения цели.
Закладывайте 1–1,5 месяца на ежедневную калибровку.
По нашим данным, именно первые недели формируют до 70 % итогового качества автоматизации.
4. Главное отличие: агент ≠ сценарный робот
Этот подход применим к автономному агенту.
Сценарный робот оценивается по выполнению скрипта. Автономный агент — по результату принятого решения. В этом его ключевое преимущество и сила с точки зрения реальной автоматизации сервиса.
Именно поэтому нужна комплексная система показателей — интегральный agent success score, отражающий:
Когда компания начинает измерять не «процент автоматизации», а реальный результат, кейсы перестают быть витриной технологии и становятся инструментом управляемости сервиса.
Сценарный робот оценивается по выполнению скрипта. Автономный агент — по результату принятого решения. В этом его ключевое преимущество и сила с точки зрения реальной автоматизации сервиса.
Именно поэтому нужна комплексная система показателей — интегральный agent success score, отражающий:
- уровень автономности,
- корректность решений,
- бизнес-эффект.
Когда компания начинает измерять не «процент автоматизации», а реальный результат, кейсы перестают быть витриной технологии и становятся инструментом управляемости сервиса.
Куда смещается фокус метрик
1. Стройте систему метрик, а не одну цифру
В обозримом горизонте нескольких лет кейсы будут оцениваться не по «проценту автоматизации», а по:
- устойчивости сервиса при росте нагрузки,
- снижению операционных рисков,
- точности ответов,
- влиянию на повторные обращения,
- влиянию на фактическое решение задач клиентов.
AHT останется вспомогательной метрикой.
Но он перестанет быть главным аргументом.
Но он перестанет быть главным аргументом.
Потому что главный вопрос уже не «сколько длился звонок», а «получил ли клиент правильный результат».
И именно через эту призму стоит пересобирать не только аналитику, но и сам формат кейсов, чтобы они отражали бизнес-эффект, а не только улучшение операционных показателей.
И именно через эту призму стоит пересобирать не только аналитику, но и сам формат кейсов, чтобы они отражали бизнес-эффект, а не только улучшение операционных показателей.