ServiceNow AI Agents: где ломается служба поддержки
В большинстве ИТ-подразделений обращение попадает в работу не сразу. Сначала оператор первой линии читает тему и текст, вручную определяет категорию, приоритет и исполнителя, и только потом заявка уходит в нужную очередь. Ручная маршрутизация ест часы на каждой сотне обращений, а без ключевого слова в теме заявка приходит не тому — например, во вторую линию, которая возвращает её назад.
Второй источник потерь — однотипные обращения. Сброс пароля, выдача доступа, продление лицензии, вопрос о статусе своей же заявки: это больше половины входящего потока, но каждый раз оператор разбирает такое обращение заново и отвечает вручную. Очередь растёт в пиковые часы, ночная смена остаётся без подстраховки, а вторая линия тратит время на то, что решается по инструкции.
Третий сбой — потерянные заявки на стыке смен. Дежурство передают без контекста, заявка висит в промежуточном состоянии, пользователь пишет повторно и создаёт дубль. История размывается по нескольким записям, эскалация срабатывает позже срока, а отчётность показывает закрытые обращения, не отражая задачи, которые просто истекли по времени.
Все три узкие места поддержки упираются в одно: у службы нет автоматического слоя между поступлением обращения и исполнителем. Именно здесь работают ServiceNow AI Agents — разбираем, как это закрывается и что остаётся за человеком.
Что меняется после запуска виртуальных ассистентов
Эффект виртуальных ассистентов видно только в сравнении, поэтому до запуска фиксируем базовый срез: медиану времени реакции на обращение, долю обращений, дошедших до второй линии, распределение по категориям и число ручных переназначений группы. Те же метрики снимаем через месяц и через квартал — иначе цифры «до» и «после» несопоставимы.
Первым меняется время реакции: ассистент отвечает за секунды, а не в очереди на исполнителя, уточняет запрос и подтягивает данные о пользователе и оборудовании из учётных систем. Дальше — разгрузка первой линии за счёт повторяющихся операций: сброс пароля, разблокировка учётной записи, выдача типового доступа, статус заявки, пошаговая инструкция. Человеку остаются обращения с нестандартным контекстом.
Доля обращений, закрытых без участия человека, растёт ступенями. Сначала ассистент разбирает сценарии с однозначным ответом, затем — многошаговые, с проверкой условий и обращением к каталогу услуг. Ошибки маршрутизации при этом падают: категория, приоритет и группа определяются по тексту обращения и правилам каталога, а не по выбору пользователя в свободном поле.
Считаем и цену ошибки: сколько обращений закрыто неверно и сколько вернулось от пользователя. История по каждому обращению в ServiceNow показывает, какой сценарий сработал и где ассистент передал диалог оператору.
Сценарий допускаем в работу, когда на размеченной выборке он даёт стабильный результат; до этого он работает в режиме подсказки. Выход на плато занимает несколько недель: настраиваем пороги и правила, пока метрики не перестанут меняться.
Режимы работы AI-агентов: сравнение подходов
Прежде чем запускать ServiceNow AI Agents в промышленном режиме, выбирают схему подключения: от неё зависит, сколько данных нужно подготовить, кто отвечает за качество ответа и как агент ведёт себя на границах своих знаний. Ниже — четыре варианта, которые мы разворачиваем на проектах, с их ограничениями.
Сравнение вариантов
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Готовые агенты из коробки | Быстрый старт на типовых сценариях: классификация обращений, маршрутизация, подсказки оператору | Работают только в предустановленных сценариях, локальные регламенты и нестандартные процессы не учитывают |
| Обучение на своей базе знаний | Накоплены статьи, решённые инциденты и запросы — нужны ответы в терминах компании | Требует чистки и разметки источников; на замусоренных данных качество ответов падает |
| Внешняя языковая модель | Нужны свободные формулировки, краткое изложение длинных переписок, неструктурированный текст | Ответы менее предсказуемы, нужен контур согласования и контроль чувствительных данных |
| Гибридная схема с правилами | Критичные действия идут по регламенту, а диалог остаётся естественным | Сложнее в поддержке: правила эскалации, пороги уверенности и роли ведут как отдельный артефакт |
Ключевая развилка — правила эскалации: агент закрывает типовые случаи сам, а при низкой уверенности или отклонении от сценария передаёт диалог оператору вместе с собранным контекстом. Мы фиксируем эти правила до запуска: что агент делает автономно, что подтверждает человек, что уходит сразу на вторую линию.
Как проходит внедрение: этапы инженерной работы
Аудит процессов поддержки — первая и самая объёмная часть проекта. Мы смотрим, какие обращения реально приходят в систему, какая доля закрывается по типовому сценарию и где обязательна эскалация на вторую линию, проверяем базу знаний, каталог услуг и историю закрытых заявок. От этого зависят границы полномочий агента: что он закрывает сам, а что только предлагает оператору.
- Аудит процессов поддержки и источников данных. Размечаем обращения по темам и причинам, проверяем актуальность статей базы знаний. На выходе — перечень сценариев с прогнозом доли автоматизации по каждому.
- Схема взаимодействия систем. Определяем, как агенты связаны с очередями заявок, каталогом услуг и внешними системами: что читается, что записывается обратно, где нужны права на изменение записи. Схему согласуем до настройки.
- Настройка сценариев. Собираем агентов ServiceNow AI Agents под конкретные темы: подсказка оператору, самопомощь на портале, классификация и маршрутизация обращений. Задаём правила эскалации и точки, где агент обязан передать диалог человеку.
- Проверка качества ответов. Прогоняем сценарии на реальных обращениях из архива и на тестовом потоке: считаем точность классификации, долю принятых ответов и число переоткрытых заявок. Правим логику, а не формулировки.
- Передача в эксплуатацию. Обучаем первую и вторую линии, фиксируем регламент правок сценариев и панель метрик. Дальше команда ведёт агентов сама, мы подключаемся на изменения и развитие.
Пакет передачи: конфигурации, база знаний, регламенты
Внедрение считается завершённым не в момент, когда агент отвечает на тестовый запрос, а когда заказчик может менять его поведение без нас. Поэтому передача конфигураций идёт не архивом, а разбором по слоям: что настроено, где лежит и по какому правилу меняется.
- Настроенные конфигурации — сценарии обработки обращений, ветки диалога, привязка к категориям и приоритетам, условия автоответа и передачи оператору.
- Структура базы знаний — дерево статей, привязка к темам обращений, разметка источников: какие статьи агент читает, какие закрыты для использования.
- Схемы интеграций — карта связей с учётными системами, каталогом услуг, почтой и мессенджерами: направление потока данных и точки отказа.
- Политики доступа — роли и права, разграничение по группам и регионам, правила работы с персональными данными, кто и на каком уровне правит сценарии.
- Регламент эскалации — условия передачи обращения человеку, уровни и сроки, кому уходит заявка при срабатывании.
- Инструкции для операторов — как принять диалог, что видно в интерфейсе, как пометить ошибку агента, чтобы она попала в дообучение.
- Журнал изменений — какие правки вносились, кем и зачем, чтобы поведение агента оставалось объяснимым.
Приёмка идёт на реальных сценариях: прогоняем типовые обращения и смотрим, какую долю агент закрывает сам, а где уходит на эскалацию. После этого ServiceNow AI Agents остаётся управляемым инструментом внутри вашей команды, а не чёрным ящиком подрядчика.
Кейс: убрали ручную маршрутизацию обращений
У заказчика — внутренняя служба поддержки с несколькими тысячами обращений в месяц. Маршрутизацию вёл диспетчер вручную: читал текст заявки, определял категорию, группу и приоритет. На пике смена не успевала, часть обращений уходила не в ту команду, и около четверти заявок приходилось переклассифицировать повторно — с потерей времени и повторным уведомлением пользователя.
Что изменили
Поверх существующей инсталляции развернули ServiceNow AI Agents — ServiceNow осталась системой учёта, а агенты взяли на себя разбор текста обращения, историю по объекту и данные конфигурационной базы. Агент выдаёт категорию, группу и приоритет, а решение по неоднозначным случаям остаётся за человеком. Первые недели слой работал в режиме рекомендаций: диспетчер подтверждал или отклонял каждый выбор, и по этим отклонениям правила уточнялись точечно, а не переписывались целиком.
Что стало через два месяца
Время первой реакции сократилось с сорока минут до шести: обращение попадает в нужную очередь сразу, а не ждёт разбора. Доля заявок, закрытых без оператора, вышла на 38% — это типовые запросы на доступы, продление и стандартные изменения, где агент выполняет проверку и подставляет готовый ответ. Ошибочная маршрутизация упала с 24% до 4%, а пиковая нагрузка на смену перестала требовать дополнительного дежурного: работа сместилась с ручного распределения на проверку исключений.
Что делать, если процессы поддержки уже выстроены
Агенты ServiceNow встраиваются не вместо регламентов, а поверх них — как исполнительный слой между обращением и оператором. Учёт остаётся в единой системе: агент пишет в те же поля карточки, что и человек, поэтому очереди и историю не приходится вести в двух местах. Маршрутизация, сроки реакции и правила эскалации сохраняются — меняется исполнитель на части шагов.
Начинаем с одной категории обращений, где сценарий предсказуем: сброс доступа, типовые запросы по оборудованию, статусы заявок. Первый этап — режим подсказок: агент готовит ответ, оператор подтверждает отправку. Сроки реакции при этом не сдвигаются ни на день, зато накапливается статистика по качеству формулировок.
Роли и права разводятся заранее. Агент получает отдельную учётную запись с ограниченным набором действий и не может выйти за её пределы. Каждый шаг фиксируется в истории обращения, владельцем записи остаётся человек, а сложный случай возвращается на линию с готовым контекстом.
Дальше включаем автозакрытие для узкого набора сценариев и следим за тремя числами: доля обращений, закрытых без человека, время первого ответа и доля возвратов на доработку. Если возвраты растут, агент отключается по категории — регламент продолжает работать, очередь не встаёт.
На старте разбираем карту текущих регламентов, выбираем сценарии для первой волны и критерии, по которым считаем встраивание удавшимся.
Технические вопросы перед началом работ
Перед стартом инженерного этапа снимаем сомнения, которые обычно и определяют, дойдёт ли внедрение ServiceNow AI Agents до продуктивной эксплуатации. Ниже — короткие ответы по доступам, эскалации, качеству и базе знаний; развёрнутые схемы разбираем уже на этапе проектирования.
Как агент получает доступ к системам и данным?
Отдельная сервисная учётная запись с минимально необходимыми правами: чтение там, где достаточно чтения, запись — только в разрешённых полях заявки. Секреты хранятся в защищённом хранилище, а не в конфигурации, каждый вызов фиксируется в журнале с указанием инициатора и результата. Так остаётся понятный ответ на вопрос, кто и на каком основании изменил запись.
Как устроена передача оператору?
Передача идёт по порогу уверенности и по прямому запросу пользователя. Оператор получает диалог целиком: историю обращений, действия агента, приложенные данные и уже собранный контекст — переспрашивать клиента заново не приходится. Обратная передача агенту тоже предусмотрена, если вопрос сводится к типовому сценарию.
Как проверяется качество ответов?
До вывода в продуктив прогоняем набор контрольных диалогов и сверяем решения с эталонными. Дальше следим за долей верных решений, долей эскалаций и числом повторных обращений по той же теме — разбор ошибок идёт по конкретным случаям, а не по общей оценке.
Какие требования к базе знаний?
Одна статья — одна тема, у каждой записи есть владелец и дата проверки, устаревшее архивируется, а не остаётся в подборке. Структурированные поля и однозначные формулировки важнее объёма: слабая статья приводит к уверенному, но неверному ответу.
Где границы применимости?
Агенту отдаём сценарии с повторяемым решением и понятными данными для проверки. Уникальные разбирательства, спорные условия и всё, что требует ответственности за решение, остаются за человеком — это фиксируем на старте, а не по факту ошибок.
Обсудим задачу и вернёмся с оценкой и планом
Начинаем с разбора задачи, а не с шаблонного предложения: нам важно увидеть ваш процесс изнутри. На старте от заказчика нужны перечень типовых обращений и их доля в общем потоке, схема маршрутизации и правила эскалации, доступы к тестовому контуру, справочники и выгрузка истории заявок за прошлые периоды, а также человек с правом менять регламент и принимать результат.
- Проводим разбор процессов и фиксируем, какие шаги агент закрывает сам, а где обязательно остаётся согласование сотрудника.
- Составляем план работ по этапам с точками приёмки — от настройки диалоговых сценариев и правил маршрутизации до аккуратного вывода в рабочий контур.
- Собираем исходные данные для старта: доступы, структуру каталога услуг, разграничение прав по ролям, тестовый набор обращений для проверки.
- Определяем состав команды — выделенный инженер по ServiceNow AI Agents, аналитик процессов, инженер по связке с внешними системами и тестировщик.
- Проговариваем порядок оценки: объём сценариев, число точек связи с учётными системами, требования к журналированию и контролю действий агента.
- На выходе первого разговора вы получаете карту сценариев автоматизации, схему решения, границы ответственности и риски, которые видим заранее.
Опишите задачу в удобном формате — вернёмся с оценкой и планом, где по каждому этапу будут сроки, требования к вашему участию и критерии приёмки.
