Разработка AI-агента для автоматизации техподдержки L1/L2

Почему AI-агент техподдержки тонет в однотипных обращениях

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

Очередь заявок при этом растёт нелинейно. Пока оператор занят повтором, новые обращения копятся, и время первого ответа уезжает с минут на часы — именно там, где клиент ещё готов ждать. Пиковые окна и ночные смены рвут график, а приоритетные задачи второй линии стоят в общей очереди наравне с «как поменять пароль».

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

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

Что меняется в работе поддержки после внедрения

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

Доля обращений, закрытых без оператора

Разделяем трафик по темам: типовые запросы — доступы, статусы заказа, настройки, инструкции — уходят агенту, всё остальное сохраняет маршрут на человека. На внедрениях доля самостоятельных решений по L1 обычно держится в диапазоне 55–70%, и она не размазана по всем темам, а сконцентрирована в 10–15 сценариях. Остальные обращения агент не «дожимает», а передаёт оператору с выжимкой: что спросил клиент, что уже проверено, какой ответ не подошёл.

Время первого ответа и полного решения

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

Круглосуточная линия без ночных дежурств

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

Повторные обращения и разгрузка операторов

Повторные обращения мы считаем по той же теме в течение нескольких дней — это индикатор того, что ответ был формальным. Агент проверяет, решилась ли задача: если клиент возвращается, диалог поднимается в приоритете вместе с историей. Освободившееся время операторов уходит на L2 и разборы, которые нельзя закрыть сценарием, — работа поверх текущей системы, будь то Zendesk, Freshdesk или внутренний портал, без переноса данных и переобучения команды.

Способы подключения: готовый сценарий или своя логика

Выбор варианта подключения определяет не модель, а то, где проходит граница автоматизации: агент закрывает обращение сам или передаёт контекст оператору. От этого зависят требования к доступам, объём работ по интеграции и скорость вывода в работу.

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

Ограничения подхода

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

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

Как проходит внедрение: этапы инженерной работы

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

1. Аудит обращений. Выгружаем архив за последние 12 месяцев, размечаем по темам и повторяемости. На выходе — карта: какая доля запросов закрывается типовым ответом, где нужны данные из учётной системы, а где обязателен человек.
2. Проектирование маршрутов. Определяем, что агент берёт на себя, что уходит оператору и по каким признакам срабатывает эскалация: низкая уверенность, конфликтный тон, запрос на изменение данных.
3. Настройка базы знаний. Регламенты, переписки и решения операторов сводим в статьи с указанием источника. Отвечает агент только по ним: на пробел в знаниях — «не знаю» и передача диалога человеку.
4. Связка с учётной системой. Агент читает историю и статусы обращений, создаёт и обновляет заявки, подтягивает данные клиента — с разграничением прав, ровно то, что нужно для ответа.
5. Проверка на закрытом контуре. Прогон на реальном архиве, где ответы известны, и сравнение с работой операторов: доля верных ответов, лишние эскалации, время до первого ответа. Ошибки разбираем, правим базу и маршруты.
6. Передача в эксплуатацию. Фиксируем регламент: кто дополняет базу, какие случаи разбираются вручную, как откатывается неудачное изменение. Первые недели снимаем показатели вместе с вашей командой.

Состав поставки: сценарии, база знаний, регламенты

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

• Карта сценариев. Типовые обращения разложены по темам, для каждой помечено: агент закрывает сам или передаёт оператору, какие данные собирает перед ответом.
• Схема маршрутизации. Признаки, по которым обращение уходит в ту или иную ветку: тема, тон, найден ли ответ в базе, сколько попыток решения уже сделано.
• База знаний и регламенты. Статьи привязаны к темам обращений, у каждой — владелец из вашей команды и порядок обновления; черновики не попадают в ответы до проверки.
• Правила эскалации. Условия передачи на вторую линию и то, что агент успевает собрать до неё: переписка, результаты диагностики, уже предложенные клиенту варианты.
• Журнал диалогов. Записи переписок со ссылками на применённые статьи и причиной передачи — основа для разбора ошибок и пополнения базы.
• Инструкции для операторов. Как принимать передачу, что проверять в подсказках агента, какие темы помечать как непокрытые.
• Регламент сопровождения. Периодичность пересборки базы по новым обращениям, ответственные, метрики качества и порядок отката.

Кейс: разгрузка техподдержки в сервисной службе

Сервисная служба по обслуживанию оборудования принимала около 400 обращений в сутки — типовые вопросы по подключению, статусам заявок и настройкам. Смена из шести инженеров L1/L2 не успевала: среднее время первого ответа держалось на 22 минутах, ночью линия не работала вовсе, и заявки копились до утра. История переписки не сохранялась, каждый инженер отвечал по-своему, поэтому клиенты возвращались с теми же вопросами.

Что сделали

Развернули AI-агента техподдержки на рабочей платформе Zendesk, подключив его к базе знаний, биллингу и очереди заявок. Сначала навели порядок в знаниях: 340 разрозненных инструкций свели к 90 актуальным статьям с явными условиями применимости — без этого агент уверенно отвечал неверно. Затем описали правила эскалации: спорные, гарантийные и эмоциональные обращения сразу уходят инженеру вместе с контекстом диалога.

Метрики до и после

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

Чем отличается сценарий на правилах от решения на языковой модели?

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

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

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

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

Частые технические сомнения перед стартом

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

Ниже — короткие ответы по каждому пункту.

Что происходит, когда обращение нерешается?

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

Как агент работает с внутренними данными?

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

Можно ли дообучить агента на своих примерах?

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

Как проверяется качество ответов?

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

Обсудим задачу: с чего начинается работа

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

Порядок сотрудничества выглядит так:

• Разбор обращений. Раскладываем накопленный поток по темам и типам, считаем долю типовых и повторяющихся — это верхняя граница того, что вообще можно автоматизировать.
• Согласование границ пилотного запуска. Фиксируем, какие темы агент берёт на себя, какие уходят людям, и на какой выборке считаем результат.
• Сборка и обучение на ваших данных. Агент отвечает по вашей базе знаний и регламентам, а не по общей памяти — ответ всегда можно показать инженеру вместе с источником.
• Ограниченный запуск на живом потоке. Один-два канала, часть обращений, обязательная передача сложного на вторую линию.
• Критерии успеха. Доля обращений, закрытых без участия человека, точность ответов на размеченной выборке, доля корректных эскалаций, время первого ответа и число возвратов клиента с тем же вопросом.
• Передача и развитие. Регламенты, инструкции для линии поддержки и понятный список тем, которые добавляем следующими.

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