16 июля 2026 года цифровой сотрудник, ИИ-агент клиентской поддержки, начал массово работать с обращениями в компании, которая разрабатывает, внедряет и сопровождает ПО для автоматизации дистрибуции. За следующий месяц медианное время до фактического решения упало с 21 часа 52 минут до 22 минут, примерно в 59 раз. Эти цифры приводит автор разбора в материале на Habr.
Цифра впечатляет и одновременно обманывает. 22 минуты измеряют скорость ответа, а не его правильность. Агент может уверенно выдать неверное решение и всё равно поставить статус «решено». Обратная ситуация тоже бывает: содержательный ответ ушёл клиенту, а карточка висела открытой ещё двое суток. Автор кейса прямо говорит, что внедрение не завершено, и причин три: формальные атрибуты CRM, неоднородность выборок и тем, отсутствие постоянной поддержки агента после запуска.
Дальше разбор методики, ограничений сравнения и практических выводов. Они переносятся на другие команды с поправкой на домен и объём потока.
Что показал кейс: 22 часа против 22 минут
До запуска агента поддержка жила в обычном режиме: обращение попадало к инженеру, тот разбирался, отвечал, закрывал карточку. После 16 июля часть клиентских обращений стала уходить цифровому сотруднику. Медиана времени до фактического решения сместилась на два порядка: с почти суток до получаса с небольшим.
За этой цифрой стоит конкретная последовательность шагов внутри компании. Сначала в поддержке появился помощник инженера, потом агентам начали передавать часть клиентских обращений. То есть к моменту выхода в клиентский поток у команды уже был опыт работы с моделью на внутренних задачах и понимание, где она ошибается.
Почему 59-кратное ускорение - не финальная точка
Метрика «время до фактического решения» отвечает на вопрос «как быстро», но молчит про «насколько верно». Агент, который за минуту выдал правдоподобную чушь и закрыл тикет, улучшает отчётность и ухудшает жизнь клиента. Обратный перекос: решение найдено и отправлено, а формальное закрытие задержалось на двое суток из-за регламента или забывчивости, и метрика показывает плохой результат там, где всё уже работало.
Ранее автор кейса сообщала, что около 45% переданных диалогов завершались без участия инженера. Цифра удобная для слайда, но её тоже нужно читать с оговорками: «переданных» и «завершённых без инженера» можно посчитать несколькими способами, а быстрый неверный ответ формально попадает в те же 45%. Именно поэтому анализ расширили с финального действия агента на полную историю обращений: когда пользователь получил содержательное решение, сколько времени обращение лежало без движения, что происходило после передачи инженеру и не породило ли ускорение новых ошибок.
Как считали: методика сравнения «до/после»
Сравнение построено на двух одинаковых по длине периодах. До запуска: с 16 июня по 15 июля. После запуска: с 17 июля по 15 августа. В выборку попали только закрытые обращения без дублей. Объём до запуска подтверждён в источнике: 1 876 обращений. Вторая цифра, 3 078 обращений после запуска, фигурирует в описании кейса, но в опубликованном фрагменте текста не подтверждена, это стоит держать в голове при чтении таблицы.
| Показатель | До запуска (16.06-15.07) | После запуска (17.07-15.08) |
|---|---|---|
| Медианное время до фактического решения | 21 ч 52 мин | 22 мин |
| 90-й процентиль времени до решения (по описанию кейса) | 211 ч | 76 ч |
| Закрытых обращений без дублей | 1 876 | 3 078 (по описанию кейса) |
Разница в объёмах сама по себе не отменяет сравнение: медиана и процентили устойчивы к размеру выборки, если распределение не меняется. Но при росте потока на две трети меняется многое другое: состав тем, доля типовых вопросов, сезонность, поведение клиентов. Выборки разного размера требуют более аккуратной интерпретации, а не механического деления одного числа на другое.
Почему день запуска исключили
16 июля в одном временном окне смешались два режима: часть обращений ещё шла по старой схеме, часть уже попала к агенту. Такой день не относится ни к группе «до», ни к группе «после», поэтому его вырезали из сравнения. Приём простой и его стоит взять на вооружение: фиксируйте дату и точное время переключения, а переходное окно вырезайте из сравнительных отчётов, иначе размытое значение будет тянуть метрику в случайную сторону.
Что не учтено в сравнении: состав тем и массовые инциденты
Состав обращений до и после мог измениться. Если в первый месяц работы агента пришлась волна однотипных сбоев после обновления продукта, медиана падает не из-за интеллекта модели, а из-за тиражирования одного согласованного ответа на сотни одинаковых карточек. Один массовый инцидент способен сдвинуть метрики целого периода и создать иллюзию прорыва.
Практический вывод: массовые инциденты считают отдельной строкой в отчётности. Их длительность полезна как инженерная метрика (как быстро команда распознала проблему и выпустила единый ответ), но в общую медиану по поддержке их подмешивать не стоит, иначе вы измеряете скорость рассылки одного текста, а не качество агента.
Почему процент автоматически закрытых обращений обманывает
Процент автоматизации удобен для презентации, но сам по себе мало говорит о качестве поддержки. В кейсе разобраны три сценария, и все три увеличивают долю закрытых агентом тикетов, означая при этом совершенно разное.
- Агент быстро закрывает простое обращение. Это честный выигрыш: клиент получил ответ, инженер не потратил время.
- Агент передаёт сложное обращение человеку, предварительно собрав данные. Метрика автоматизации растёт не полностью, зато инженер входит в задачу с готовым контекстом, и суммарное время решения падает.
- Агент уверенно даёт неправильный ответ и ставит статус «решено». Формально это лучший результат по отчётности и худший по факту.
Три сценария неразличимы, если смотреть только на долю автоматических закрытий. Различить их можно лишь выборочной проверкой закрытых агентом обращений и метрикой повторных обращений по той же теме.
Статус «решено» в CRM: когда он врёт
Статус в CRM это формальный атрибут карточки, а не подтверждение того, что клиент получил рабочее решение. Искажения идут в обе стороны. Вверх: агент ставит «решено» при неверном ответе, и метрика качества завышается. Вниз: карточка остаётся открытой ещё двое суток после содержательного ответа, и метрика скорости занижается. В обоих случаях цифра врёт, только в разные стороны.
Отсюда два изменения в учёте. Считать время до содержательного ответа, а не до смены статуса. И выборочно проверять закрытые агентом обращения на корректность, иначе доля ошибок останется невидимой.
Какие метрики смотреть вместо одной цифры
Набор, который можно защитить перед руководством, выглядит так:
- медианное время до фактического решения;
- 90-й процентиль времени до решения, потому что медиана скрывает хвост долгих обращений (в кейсе он сократился с 211 до 76 часов по описанию кейса);
- доля повторных обращений по той же теме в течение недели и месяца;
- доля эскалаций на инженера и что происходит после передачи;
- доля обращений, закрытых агентом и затем переоткрытых;
- отдельная строка по массовым инцидентам.
90-й процентиль здесь не украшение. Именно в хвосте живут самые дорогие для бизнеса случаи: клиент ждёт трое суток, звонит, пишет снова и в итоге обсуждает расторжение. Медиана по такой истории ничего не покажет.
Где агент ломается: пример регрессии с кодами объектов
Отдельная часть кейса посвящена регрессии, которая появилась после, казалось бы, полезного улучшения. Правила точного поиска кодов объектов ужесточили: агент должен был искать только точное совпадение кода в справочнике. Ответы стали быстрее и точнее на чистых данных. Одновременно сломалась обработка опечаток вида 0/O/О, где ноль, латинская O и кириллическая О визуально почти неразличимы, а в коде объекта означают разные вещи.
Сам по себе сбой выглядит мелочью. На практике клиент, скопировавший код из письма или набравший его в спешке, получал отказ вместо товара, а поддержка получала поток обращений, которые агент не мог обработать. Скорость выросла, покрытие упало.
Почему «ужесточить правила» - не бесплатное улучшение
Любое ужесточение инструкций или правил поиска перераспределяет ошибки, а не устраняет их. Формулировка «искать только точное совпадение» уменьшает число ложных срабатываний, но увеличивает число нераспознанных обращений с опечатками, смешанной раскладкой и разными написаниями кодов. Это не баг конкретной модели, это свойство любой системы, где точность и устойчивость тянут в разные стороны.
Практика простая и скучная: после каждого изменения правил прогонять набор старых обращений, включая «грязные» случаи. Опечатки, латиница вместо кириллицы, лишние пробелы, коды из разных версий справочника. Без такого прогона улучшение видно только на тех данных, на которых его придумывали.
Ограниченная коррекция с проверкой на единственное совпадение
Чинили регрессию не «умным» автокорректором, а ограниченной коррекцией: символ исправляется только тогда, когда альтернатива ровно одна и она однозначно ведёт к существующему коду. Если кандидатов несколько, агент не угадывает, а эскалирует обращение или просит уточнение.
Такой подход безопаснее подстановки «наиболее вероятного» варианта: агент не подменяет код наугад и не создаёт ситуацию, когда клиенту отправляют данные по чужому товару. Ограничение очевидно: при неоднозначности приём не спасает, обращение уходит человеку. Это осознанный выбор в пользу предсказуемости, и его стоит проговаривать заранее, чтобы рост доли эскалаций не выглядел провалом.
Почему качество агента деградирует без поддержки
Цифровой сотрудник не артефакт, который сделали и забыли. Он зависит от инструкций, базы знаний и потока обращений, а все три меняются: выходят версии продукта, появляются новые типовые проблемы, клиенты приносят новые формулировки. Инструкции, написанные под июльский набор тем, к осени устаревают частично, а иногда и вредят: агент уверенно применяет правило, которое больше не соответствует продукту.
Деградация обычно незаметна в моменте. Метрика автоматизации держится, медиана держится, а доля повторных обращений медленно растёт. Заметить это можно только по связанным метрикам и по выборочной проверке ответов.
Версионирование инструкций и знаний
Версионировать нужно системные инструкции агента, правила поиска, базу знаний и набор примеров ответов. Каждое изменение фиксируется с датой и привязывается к метрикам периода, в котором оно действовало. Тогда просадка качества связывается с конкретным релизом инструкций, а не ищется вслепую по всему стеку.
Побочная выгода: становится видно, какие правки вообще ничего не изменили. Часть «улучшений» на проверке оказывается нейтральной, и это повод не тащить их дальше в прод.
Регрессионный набор из старых обращений
Набор собирается из реальных прошлых обращений с известными правильными ответами. В него обязательно входят сложные и грязные случаи: опечатки, смешанные раскладки, коды объектов из разных справочников. Прогон выполняется перед каждым изменением инструкций или знаний, а не после жалобы клиента.
Отдельным блоком держат кейсы массовых инцидентов: они проверяют не интеллект агента, а корректность тиражирования одного согласованного ответа на сотни карточек. Как устроена оценка качества агентских ответов на длинных и неоднозначных данных, включая калибровку оценщика, разобрано в материале про LLM-as-judge и трейсинг в LangSmith.
Что делать, если вы только начинаете: практический чек-лист
- Начинайте с помощника инженера. В кейсе агент сначала работал на внутренние задачи поддержки и только потом получил часть клиентского потока. Почему такой режим «спроси про систему» часто полезнее полной автоматизации, разобрано в кейсе про ИИ-агента, ставшего помощником аналитиков.
- Определите метрики до запуска: время до содержательного ответа, 90-й процентиль, повторные обращения, доля эскалаций, переоткрытые тикеты.
- Зафиксируйте дату и время переключения и вырезайте переходное окно из сравнений «до/после».
- Ведите раздельный учёт массовых инцидентов, не растворяйте их в общей выборке.
- Версионируйте инструкции, правила поиска и базу знаний, привязывайте версии к метрикам периодов.
- Держите регрессионный набор старых обращений и прогоняйте его перед каждым изменением.
- Выборочно проверяйте закрытые агентом обращения на корректность, а не только на скорость.
Ограничения кейса стоит назвать прямо. Это одна компания, один продукт (ПО для автоматизации дистрибуции) и один двухмесячный период сравнения. Цифры 3 078 обращений после запуска и значения 90-го процентиля (211 и 76 часов) приведены по описанию кейса и в опубликованном фрагменте источника не подтверждены. Переносить 59-кратное ускорение на другой домен без собственного замера нельзя: в одних темах агент закроет половину потока, в других упрётся в справочники и регламенты.
Главное: одна цифра автоматизации не заменяет качество
22 минуты вместо 22 часов, это реальный и полезный результат. Он измеряет скорость, а не корректность, и потому не может быть единственным доказательством успеха. Устойчивый цифровой сотрудник в поддержке получается не разовым проектом, а процессом: версии инструкций и знаний, регрессия на старых обращениях, отдельный учёт массовых инцидентов, метрики повторных обращений и выборочная проверка закрытых агентом тикетов.
Без этого агент деградирует тихо, а отчётность начинает льстить. Если вы готовите разговор с руководством о запуске или развитии ИИ-агента, приходите не с процентом автоматизации, а с набором метрик и планом проверок. Как выстроить границы применимости и не потерять устойчивость процесса, разобрано в материале про чек-лист устойчивости AI-first процессов.