Когда команда внедряет ИИ-агентов в поддержку, первым делом обычно смотрят на долю автоматически закрытых обращений. Цифра удобна для отчёта: «45% диалогов завершены без инженера». Но она почти ничего не говорит о том, стало ли клиентам лучше. Агент может быстро закрыть простое обращение, передать сложное человеку, собрав контекст, или уверенно дать неверный ответ и поставить статус «решено». Поэтому в кейсе с цифровыми сотрудниками команда решила копнуть глубже — и получила медиану времени до фактического решения 22 минуты против 21 часа 52 минут до запуска. Цифра впечатляет, но именно из-за её красоты к ней стоит относиться осторожно.

Что на самом деле измерять

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

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

Почему процент автоматизации обманчив

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

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

Конкретные шаги для проверки эффекта

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

  • Определите целевые метрики заранее. Не ограничивайтесь процентом автоматизации. Включите время до первого содержательного ответа, время до фактического решения, долю повторных обращений, долю эскалаций и удовлетворённость.
  • Сравнивайте сопоставимые периоды. Берите одинаковые по длине отрезки до и после запуска, исключайте дни с аномалиями и переходные режимы.
  • Анализируйте полную историю обращения. Смотрите, когда клиент получил полезный ответ, сколько времени заявка была без движения, что происходило после передачи инженеру.
  • Проверяйте качество закрытых обращений. Выборочно просматривайте диалоги, которые агент закрыл сам. Ищите случаи, где ответ был формально верным, но не решал проблему.
  • Следите за повторными обращениями. Если клиент возвращается с той же проблемой в течение нескольких дней, это сигнал, что решение было неполным.
  • Собирайте обратную связь от инженеров. Они видят, какие случаи агент передаёт и с каким контекстом. Это помогает настроить передачу и избежать потери информации.

Эти шаги не требуют сложных инструментов. Достаточно выгрузки из системы тикетов и небольшой дисциплины в анализе. Главное — не подменять качество скоростью.

Типичные ошибки и примеры

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

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

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

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

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

Внедрение ИИ-агентов в поддержку — это не гонка за процентами. Это баланс между скоростью и качеством. И если медиана времени до решения упала в 59 раз, это повод не праздновать, а проверить, не потерялось ли что-то важное по пути.