Розробка ШІ-системи автоматичного створення тікета після звернення

Автоматичне створення тикета: де ламається обробка звернень

Звернення надходить на пошту, у месенджер і форму на сайті — і вже на вході в першу лінію підтримки починається ручний розбір. Оператор читає текст, визначає тему, вручну створює тикет і переносить у нього контакти з описом.

Тут же частина контексту губиться: вкладення не додаються, суть звернення переказується своїми словами, а клієнт залишається без номера заявки й без розуміння, хто її веде.

Наступний збій — дублі тикетів. Один клієнт пише в чат, дублює листом і телефонує: у системі з’являються три незалежні заявки, за якими працюють різні виконавці. Клієнт отримує суперечливі відповіді, а команда витрачає час на узгодження версій замість розв’язання задачі.

Далі потерпає черга звернень у підтримці: тикет без явного маршруту залишається в загальній вхідній черзі першої лінії. Відповідальний за нього розмитий, строки відповіді не рахуються, пріоритет визначає той, хто гучніше нагадав про себе.

Загублені звернення — прямий наслідок такого устрою: лист, що надійшов у неробочий час або осів у особистій папці оператора, не перетворюється на тикет і спливає лише після скарги клієнта.

Частина запитів так і не доходить до виконавця, і дізнаємося ми про це від замовника, а не зі звіту.

Корінь усіх цих збоїв один: розбір, класифікація й маршрутизація тримаються на людині, а не на правилах. Нижче розбираємо, як це закривається на рівні системи.

Що змінюється після впровадження: швидкість і повнота розбору

Ефект впровадження вимірюється не «стало зручніше», а числами, які знімаються з панелі звітності підтримки. Ми фіксуємо їх до запуску й приймаємо систему за цим списком — кожен рядок береться зі штатного вивантаження за період.

• [ ] Частка звернень, розібраних без людини. Модель читає текст звернення, витягує сутності й сама закриває типові сценарії — у масових темах це 60–75% вхідного потоку.
• [ ] Час до призначення виконавця. Звернення більше не чекає ручного сортування в черзі: строк скорочується з десятків хвилин до секунд, а перша відповідь надходить у ту саму сесію.
• [ ] Частка повернень на уточнення. Якщо в тикеті немає продукту, версії або кроків відтворення, виконавець повертає його авторові — ціль за цим показником однозначні відсотки від загальної кількості.
• [ ] Зниклий клас відмов маршрутизації. Помилкові призначення між чергами (запит щодо оплати потрапляє в техпідтримку) перестають бути системною проблемою: черга обирається за змістом, а не за формою заявки.
• [ ] Навантаження на підтримку. Звільнені години йдуть на складні кейси, а не на механічне сортування й переписування полів.
• [ ] Повнота тикета. Обов’язкові атрибути заповнюються на вході з даних звернення, а не з пам’яті автора чи оператора.

Інтеграцію з обліковою системою — у нас це Jira Service Management і рівнозначні платформи — налаштовуємо так, щоб кожна метрика рахувалася штатними звітами, без ручних зведень.

Способи приймання звернень: правила, класифікатор, мовна модель

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

Вибір між правилами, класифікатором і мовною моделлю — це вибір між передбачуваністю результату й гнучкістю до формулювань.

Під час вибору дивляться на три речі: однорідність формулювань, обсяг накопиченої історії з проставленими категоріями й вимоги до пояснюваності рішення. Правила дають детермінований результат і повний контроль, але потребують ручної правки за кожного нового формулювання. Модель переносить вільний текст, але потребує валідації полів і обробки невпевнених випадків.

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

Етапи впровадження: від аудиту звернень до перших тикетів

Автоматичне створення тикета — це не модель сама по собі, а конвеєр: приймання звернення, розбір змісту, визначення черги й пріоритету, запис у систему обліку.

Помилка на будь-якому кроці коштує дорожче за ручний розбір: неправильний тикет іде не тому виконавцю й повертається до автора. Тому роботи йдуть від аудиту потоку до пілоту на історичних даних — кожен наступний етап спирається на виміряний попередній.

1. Аудит потоку звернень. Рахуємо канали, типи запитів та їхні частки, повторюваність формулювань. На виході — карта категорій і чернеткові правила маршрутизації.
2. Схема розбору. Домовляємося, які поля тикета заповнюються автоматично (тема, категорія, пріоритет, виконавець), а які залишаються на людині, і в якому вигляді система віддає результат.
3. Налаштування інтеграцій. Підключаємо джерела звернень і систему обліку: пошта, чат, форма на сайті, внутрішній портал. Окремо перевіряємо, що повторна доставка листа не породжує другий тикет.
4. Поріг упевненості. Кожен розбір отримує оцінку достовірності. Вище порога тикет створюється одразу, нижче — йде оператору із попередньо заповненими полями, щоб рішення залишалося за людиною.
5. Пілот на історичних даних. Проганяємо закриті звернення й звіряємо категорію, пріоритет і виконавця з тим, що вирішили вручну. За розбіжностями правимо правила й формулювання підказок.
6. Приймання якості розбору. Фіксуємо цільову точність за категоріями й частку звернень, прийнятих без правок, розбираємо найчастіші класи помилок.
7. Передавання в експлуатацію. Налаштовуємо моніторинг частки автозаповнення, регламент розбору спірних випадків і порядок зміни порогів без зупинки приймання звернень.

Що передаємо на руки: схеми, правила маршрутизації, регламенти

Комплект постачання — не папка з описами, а робоча частина контуру. За цими документами ваша служба супроводу сама змінює правила маршрутизації, додає категорії й розбирає інциденти, не чекаючи на нас. Нижче — що входить у передавання й навіщо потрібен кожен елемент.

• Схема інтеграцій — канали приймання звернень, облікова система заявок, база знань: напрямок обміну, формат даних, поведінка за недоступності зовнішньої системи.
• Правила маршрутизації — відповідність «тема → черга → виконавець → пріоритет» і порядок дій, коли класифікація дає дві рівнозначні категорії.
• Регламент ескалації — пороги впевненості моделі, строки реакції за пріоритетами й ланцюжок передавання звернення, якщо автоматичний розбір не дав результату.
• Політики доступу до даних звернень — хто зі співробітників і сервісів бачить тексти, де зберігаються копії, як маскуються персональні дані й як ведеться журнал доступу.
• Документація з розмітки — таксономія категорій і пріоритетів, приклади пограничних випадків, правила розбору; за нею новий співробітник виходить на узгоджену якість.
• Перелік облікових записів і прав — які сервісні облікові записи потрібні, які права видано й де діють обмеження за частотою запитів.
• Регламент супроводу моделі — метрики якості, періодичність перевірок на свіжих даних, порядок донавчання й умови відкату на попередню версію.

Кейс: розбір звернень у підтримці до й після впровадження

Підтримка сходилася в одну чергу: листи, форми на сайті й повідомлення з месенджерів потрапляли в Zendesk без розбору. Оператор вручну визначав тему, обирав чергу й заповнював картку — категорію, пріоритет, дані клієнта. На це йшло 15–20 хвилин, і помітна частина заявок від’їжджала не в ту групу.

Перед проєктом ми зняли базові метрики на потоці в кілька тисяч звернень на місяць — без них ефект впровадження нема чим вимірювати. Нижче порівняння до й після запуску автоматичного створення тикета.

Технічно це три кроки: класифікація тексту й вкладень за темами, вилучення полів для картки, правило маршрутизації, яке обирає чергу й виконавця.

Ключова деталь — поріг упевненості: якщо модель сумнівається, тикет не створюється автоматично, а йде оператору чернеткою з уже заповненими полями.

Повторні звернення впали не через швидкість, а через повноту картки: клієнту відповідали з першого разу, бо в тикеті одразу були замовлення, регіон та історія.

Далі модель донавчається на виправленнях операторів — кожне перепризначення стає прикладом, тому частка помилкових призначень знижується без ручної правки правил.

Чим відрізняється автоматична класифікація від правил маршрутизації?

Правила маршрутизації — це детерміновані умови: канал, обрана категорія, тип акаунта, збіг за словником. Класифікація звернень моделлю — ймовірнісна оцінка за текстом загалом.

Звідси різниця в природі помилок: правила пояснюються одним рядком і дають однакову відповідь на однаковому вході, модель узагальнює на перефразування, але не гарантує результат.

Правила передбачуваніші там, де сигнал формальний: звернення з форми «оплата», лист на відому адресу, тема з номером замовлення. Рідкісні теми — теж територія правил: десятків прикладів мало для стійкого класу, надійніше завести явну умову й окрему чергу.

У логіці ITIL це категоризація за заздалегідь описаним довідником — передбачувана, але потребує підтримки словника.

Модель виграє на вільному тексті: опис симптому своїми словами, вкладені умови, змішані мови. Але без порога впевненості вона впевнено помиляється на рідкісних темах, тому відповіді нижче порога не маршрутизуються, а йдуть у ручний розбір.

Гібридний підхід на одному потоці виглядає так: правила першим шаром забирають формальні звернення, залишок іде в модель, низька впевненість — оператору, його рішення повертаються в розмітку.

Схему розбору обирають за заміром: проганяємо історію звернень через правила й дивимося, яка частка закривається без моделі. Частка автоматично створених тикетів зростає, а помилкові маршрутизації залишаються видимими у звіті.

Часті технічні сумніви перед запуском

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

А якщо тема рідкісна й схожих прикладів майже не було?

Таке звернення не отримує випадкову категорію: низька впевненість розбору переводить його в загальну чергу з поміткою. Оператор бачить чернетку тикета з уже виділеними сутностями й править її, а не заповнює з нуля.

Як зберігається історія листування й вкладення?

Історія розмічається за повідомленнями: канал, автор, вкладення — усе прив’язано до тикета, а не залишається в пошті чи месенджері. За повторного звернення контекст минулих тикетів підтягується, і клієнту не потрібно заново описувати проблему.

Чи залишається людина в ланцюжку й як контролюється якість розбору?

Поріг упевненості налаштовується під ваш процес: вище — більше йде оператору, нижче — більше бере на себе автоматика. Після будь-якої зміни правил або прикладів прогін за еталонними зверненнями повторюється, тому видно, на якій частці розбір залишився правильним.

Обговоримо задачу: чого не вистачає для точної оцінки

Щоб порахувати, як система розбиратиме звернення й створюватиме тикети, потрібен не переказ болю, а дані: живий потік звернень і правила, за якими він обробляється сьогодні.

За ними ми перевіряємо гіпотезу на реальних прикладах, а не на показових сценаріях, і називаємо строки та склад робіт без «уточнимо в процесі».

• Постановка задачі: який результат вважаємо успішним — частка звернень, розібраних без оператора, точність визначення теми й пріоритету, час від повідомлення до готового тикета.
• Вивантаження звернень: 2-3 місяці листування в текстовому вигляді без персональних даних, обов’язково включно з випадками, які оператори закривали довше за звичайне, — на них видно межі моделі.
• Канали приймання: пошта, чат на сайті, месенджери, розшифрування дзвінків — скільки їх, який обсяг і в якому вигляді надходить текст.
• Системи обліку: де створюються тикети, які поля обов’язкові, як влаштовані довідники проєктів, черг і виконавців.
• Правила ескалації: за якими ознаками звернення йде на людину, кому й у який строк, що вважається критичним і потребує негайної реакції.
• Обмеження щодо даних: вимоги до зберігання й знеособлення, заборона на передавання назовні, чи потрібне ізольоване середовище.
• План впровадження: які системи й доступи зачіпаємо, хто приймає результат на боці замовника, у які вікна викочуємо зміни.

Опишіть задачу й додайте те, що є зі списку, — повернемося з оцінкою, планом і переліком ризиків.