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, аналітик процесів, інженер зі зв'язку із зовнішніми системами та тестувальник.
- Промовляємо порядок оцінки: обсяг сценаріїв, кількість точок зв'язку з обліковими системами, вимоги до журналювання й контролю дій агента.
- На виході першої розмови ви отримуєте карту сценаріїв автоматизації, схему рішення, межі відповідальності та ризики, які бачимо заздалегідь.
Опишіть задачу в зручному форматі — повернемося з оцінкою та планом, де за кожним етапом будуть строки, вимоги до вашої участі та критерії приймання.
