Автоматизація обробки заявок: ШІ-маршрутизація для підтримки

AI маршрутизація заявок: де ламається ручне сортування

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

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

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

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

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

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

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

Що дає перехід на автоматичну обробку звернень

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

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

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

Після донавчання на накопиченій розмітці показник сягає 75–85%, і впирається він не в модель, а в якість рубрикатора — черг, за якими звернення дійсно розходяться.

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

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

У зв'язці з Jira Service Management видно й підставу рішення: за якою ознакою заявка потрапила до виконавця і де правило спрацювало не так.

Способи маршрутизації: правила, модель, гібридна схема

Маршрутизація — це шар, який вирішує, кому піде звернення і з яким пріоритетом.

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

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

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

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

Порядок впровадження: від розбору потоку до передачі в підтримку

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

1. Аудит потоку звернень — розбираємо, звідки надходять заявки, скільки їх за типами і як вони розподіляються зараз; фіксуємо, де накопичується черга і які звернення йдуть не туди.
2. Проєктування схеми маршрутизації — описуємо категорії, правила ескалації та поріг впевненості, нижче якого заявку обов'язково дивиться людина.
3. Розмітка історичних даних — на вибірці минулих звернень проставляємо еталонні категорії та пріоритети. Це база, на якій схему можна виміряти, а не показати на демонстраційних прикладах.
4. Налаштування та перевірка на історії — проганяємо маршрутизацію за розміченим набором і дивимося матрицю помилок: де плутаються сусідні категорії, правимо ознаки та пороги до прийнятної точності.
5. Дослідна експлуатація — вмикаємо режим, де система пропонує маршрут, а рішення ухвалює оператор; розходження розбираємо щодня і повертаємо в донавчання.
6. Передача в підтримку — віддаємо регламент категорій, порядок розбору спірних заявок, навчаємо команду і залишаємося на супроводі після запуску.

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

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

Схема розподілу заявок не повинна залишатися «чорною скринькою» на стороні підрядника.

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

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

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

Кейс: розподіл заявок без ручного сортування

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

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

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

Що змінили

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

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

Метрики до та після

• Частка авторозподілу: від нуля до 87% звернень, ручна розмітка залишилася лише на спірних випадках.
• Час до першої відповіді: з кількох годин у піку до 30-40 хвилин, включно з нічними змінами.
• Повторні звернення: мінус третина — клієнт рідше писав повторно в інший канал.
• Навантаження на операторів першої лінії: сортування перестало бути основним завданням, вивільнений час пішов на складні звернення.

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

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

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

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

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

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

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

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

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

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

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

Технічні сумніви перед стартом роботи

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

Чи можна змінювати правила на ходу?

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

Скільки потрібно історичних даних?

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

Як перевіряється якість маршрутизації?

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

Як відкочуються зміни?

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

Обговоримо задачу та повернемося з планом робіт

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

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

На виході повертаємося не із загальними словами, а з планом впровадження: етапи, строки кожного, зона відповідальності вашої команди та нашої.

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

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