Автоматизація класифікації заявок: де ламається ручне сортування
Потік звернень майже ніколи не буває рівним: ранок понеділка, планові роботи, збій у великого клієнта — і за годину до підтримки надходить стільки заявок, скільки зазвичай набирається за добу.
Вузьке місце виникає на вході потоку: хтось має прочитати кожне звернення, зрозуміти тему, пріоритет і адресата, поставити мітку й передати в потрібну лінію. Поки це робить людина, черга підтримки зростає швидше, ніж вона встигає її розбирати.
Ціна ручного сортування звернень видна у двох метриках. Час першої відповіді зростає разом із чергою: клієнт чекає, поки диспетчер дійде до його заявки, і повертається з уточненням.
Друга метрика — помилкова маршрутизація: під час поспіху звернення потрапляє в лінію, яка цим питанням не займається, заявка проходить кілька переадресацій, перш ніж її візьме профільний інженер.
Правила й фільтри за ключовими словами проблему не закривають. Один і той самий збій описують як «не працює», «висить», «не завантажує сторінку» — словник клієнта не збігається зі структурою ліній і переліком послуг.
Нові типи звернень з’являються швидше, ніж оновлюється регламент сортування, а в пік часу на ручний розбір немає взагалі.
Розбираємо, як закривається ця ділянка: з чого починається автоматизація класифікації заявок, за якими ознаками звернення отримує лінію та пріоритет і що відбувається із заявками, де впевненість моделі низька — такі випадки не повинні губитися в потоці.
Що дає автосортування звернень у службі підтримки
Автоматична маршрутизація замінює ручний розбір черги: класифікатор читає тему, текст і вкладення звернення та одразу призначає групу. Оператор першої лінії перестає бути диспетчером — він підтверджує або виправляє мітку, а не пересилає заявку вручну.
Що змінюється у вимірюваних величинах
Модель навчається на історії закритих заявок і працює в зв’язці з правилами: жорсткі умови закривають однозначні випадки (аварійний шаблон, пріоритетний клієнт), класифікатор — решту.
Нижче порога впевненості звернення потрапляє до загальної черги з позначкою «не визначено», тому частка помилкових переспрямувань падає, а не зростає.
Час обробки звернення скорочується тому, що заявка не гуляє між групами: на типовому потоці частка помилкових переспрямувань знижується з 15–20% до одиниць відсотків. Навантаження на операторів вирівнюється — друга лінія отримує відфільтроване, а не все вхідне.
Стійкість на піках і зворотний зв’язок
Сплески розбираються за тими самими правилами: тема й терміновість оцінюються незалежно, тому зростання потоку втричі не ламає сортування, а лише ділить чергу на групи.
Мітки та впевненість записуються в поля тікета — у Jira Service Management це окремі атрибути, за якими будуються черги та звіти.
Кожне виправлення оператора стає навчальним прикладом: змінив групу — сигнал пішов у розмітку. Якість контролюємо за класами, а не за загальною точністю: критичні категорії не повинні губитися, а рідкісні — звалюватися в «не визначено».
Підходи до класифікації заявок: правила, модель, гібрид
Універсально найкращого способу немає: вибір визначається тим, наскільки однорідний потік звернень і чи є у вас історія з уже проставленими категоріями. Нижче — три варіанти, які ми збираємо на практиці, та обмеження, об які найчастіше спотикаються під час впровадження.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Правила та ключові слова | Усталені формулювання, стабільний набір категорій, потрібен передбачуваний розбір з першого дня | Ламається на одруках, змішуванні мов і нових формулюваннях; звід правил розростається й починає конфліктувати сам із собою |
| Навчання на історичних даних | Є вивантаження заявок за кілька місяців із коректно проставленими категоріями | Потребує розмітки вибірки та повторного навчання при зміні продуктів; рідкісні типи звернень отримують упевнену, але неправильну відповідь |
| Гібридна схема | Потік неоднорідний: масові типові звернення плюс рідкісні, що потребують розбору | Складніше в експлуатації — стежити потрібно і за зводом правил, і за якістю навченого сортування |
Практичний орієнтир: спочатку рахуємо, яка частка заявок припадає на п’ять найчастіших категорій і як часто оператори змінюють автоматично проставлену.
Якщо історія чиста й категорій небагато, навчання на історичних даних дає помітний виграш; якщо розмітки немає або потік змінюється щомісяця, починають із правил.
Гібрид беруть там, де правила закривають типову масу, а модель — хвіст рідкісних звернень, і знімають з операторів ручне сортування.
Впровадження крок за кроком: від розбору потоку до передачі
Класифікація заявок ламається не на моделі, а на спробі включити її одразу в робочий потік: категорії придумані у відриві від реальних звернень, оператори не розуміють логіку маршрутизації, а якість ніхто не вимірював. Тому ми ведемо проєкт послідовно — кожен етап закінчується артефактом, який можна перевірити.
- Аудит потоку звернень. Вивантажуємо історію заявок, дивимося розподіл за каналами, частку дублів, листи без тексту, вкладення та автогенеровані повідомлення. Рахуємо, яка частина потоку взагалі піддається розмітці. На виході — карта потоку та перелік вузьких місць.
- Проєктування категорій. Узгоджуємо дерево тем і правила маршрутизації з власниками процесів. Категорій рівно стільки, скільки служба підтримки готова обслуговувати: надмірна деталізація дає шум і плутанину на першій лінії.
- Підготовка еталонного набору. Розмічаємо історичні заявки, окремо фіксуємо пограничні випадки та правило для них. Цей набір далі слугує лінійкою якості, а не разовою вправою.
- Налаштування та навчання. Модель збирається під ваш словник і номенклатуру, регулярні випадки закриваються правилами. Задається поріг впевненості: нижче нього заявка йде людині, а не в неправильну чергу.
- Перевірка на живому потоці. Запускаємо в тіньовому режимі — система розмічає, маршрутизує, як і раніше, оператор. Порівнюємо з еталоном, рахуємо частку помилок за кожною категорією та правимо спірні.
- Передача в експлуатацію. Віддаємо опис категорій, інструкцію для операторів, порядок донавчання на нових прикладах і регламент перегляду дерева тем при зміні процесів.
Комплект постачання: правила, схеми, регламенти, розмітка
Після впровадження в команди замовника залишаються не лише працюючі правила, а й усе, чим їх можна змінювати й перевіряти власними силами — без звернення до нас.
Комплект збирається так, щоб новий співробітник розібрався в логіці за тиждень, а зміни не ламали вже досягнуту точність.
- Схема категорій і підкатегорій — дерево з визначенням кожної гілки та еталонними прикладами. За нею перевіряють, куди потрапляє заявка і в якому місці розмивається межа між схожими типами.
- Набір правил і порогів — порядок застосування правил, поріг впевненості, нижче якого заявка йде оператору, а не в автоматичну чергу, і список винятків.
- Журнал розмітки — накопичені спірні заявки з вердиктом людини. Він слугує джерелом для донавчання та розбором причин: видно, яких формулювань бракує в правилах.
- Регламент оновлення — хто вносить правки, як часто, на якій вибірці перевіряють перед увімкненням і який приріст точності вважається достатнім для випуску.
- Інструкції операторів — як розбирати заявки нижче порога, як позначати помилку класифікації, щоб вона гарантовано потрапила до журналу розмітки, і чого робити не потрібно.
- Політики доступу — ролі адміністратора й оператора, права на тексти заявок, журнал розмітки та вивантаження, строки зберігання й порядок видачі даних на запит.
- Порядок відкату — як повернути попередню версію правил однією операцією і що перевірити після повернення, щоб не втратити накопичену розмітку.
З цим комплектом підтримка й розвиток залишаються всередині команди замовника. Якщо потрібно буде розширити схему категорій або перезібрати правила під новий потік заявок — опишіть задачу, повернемося з оцінкою та планом.
Кейс: як зросла частка автоматичних рішень
До впровадження весь потік звернень розбирався вручну: оператор першої лінії читав заявку, вибирав тему з каталогу на кілька десятків категорій і призначав виконавця.
За кількох тисяч звернень на місяць медіанний час обробки тримався близько шести хвилин, а помилкова маршрутизація сягала дев’яти відсотків — найбільше промахів давали нічні зміни та пікові дні. Частка автоматичних рішень була нульовою.
Що змінили
Зібрали навчальну вибірку з накопиченої історії звернень і навчили класифікатор тем із імовірнісною оцінкою; поверх нього додали правила на часті шаблони — номер замовлення, тип збою, ознаку блокування.
Потім виставили поріг впевненості: вище порога заявка йде виконавцю сама, нижче — оператору, але з підказкою трьох найімовірніших тем, і він підтверджує або виправляє її одним кліком.
Зв’язок зробили двостороннім через Zendesk: результат класифікації повертається в картку заявки, а кожне виправлення оператора зберігається як розмічений приклад.
Що стало
| Метрика | До | Після |
|---|---|---|
| Частка автоматичних рішень | 0% | 71% |
| Точність класифікації | не вимірювалася | 93% |
| Час обробки (медіана) | ~6 хвилин | 40 секунд |
| Помилкова маршрутизація | 9% | 2% |
Контур донавчання працює на правках операторів: раз на квартал класифікатор перенавчають, тому поява нової категорії звернень не знижує точність. Час першої лінії, що вивільнився, пішов на складні випадки, де справді потрібна людина.
Порівняння до й після — за одним потоком звернень; дані замовника не розкриваємо, наводимо лише відносні метрики.
Що робити, якщо звернення вже розподіляються за старими правилами
Старі правила нікуди не зникають — модель вбудовується поруч із ними. Перший крок — тіньовий режим: модель розмічає вхідний потік і пише передбачення в окреме поле, а маршрут, як і раніше, визначають фільтри за полями форми, ключовими словами та ознакою клієнта.
Далі розмежовуємо зони відповідальності. Детерміновані випадки — відомі форми, звернення за конкретним договором, теми з юридичними наслідками — залишаються на правилах: там важлива передбачуваність, а не частка вгаданих. Вільний текст без явних ознак віддаємо моделі, і жорстке правило завжди перекриває її висновок.
Спірні випадки закриваються порогом впевненості. Поки модель не впевнена, заявка йде звичним маршрутом, а розбіжність із правилом потрапляє до журналу — цей журнал стає розміткою для донавчання, і якість зростає без ручного перегляду всього потоку. На кожен тип звернення закріплюємо власника, який вирішує, що вважати помилкою.
Перехід без зупинки підтримки робимо поетапно: спочатку один канал або частка потоку, потім розширення, повернення — перемикачем конфігурації за секунди, без випуску нової версії.
У Zendesk та аналогічних системах це робиться правилами маршрутизації та викликом сервісу сортування за подією, у самописній — проміжною ланкою перед чергою. Розкажіть про свій контур — повернемося з планом міграції та оцінкою.
Часті технічні сумніви та обмеження
Питання про брак даних і контроль якості виникають на оцінці майже завжди, і в них є інженерні відповіді, а не загальні обіцянки. Нижче — як закриваються брак розмічених заявок, поява нових рубрик, нетипові звернення та перевірка точності сортування.
У нас мало розмічених заявок — моделі вистачить?
Для старту достатньо кількох сотень історичних звернень: навчання йде на них, а не на всьому архіві. Решту добираємо правилами за ключовими сутностями й уточнюємо розмітку там, де класифікатор сумнівається — точність зростає в міру накопичення даних.
Що буде із заявками нових категорій?
Сортування спирається на сенс тексту, а не на жорсткий перелік рубрик, тому близькі за сенсом звернення потрапляють до найближчої відповідної категорії.
Коли новий тип заявок стає стійким, достатньо додати приклади й налаштувати поріг впевненості — перезбирати схему розподілу повністю не потрібно.
Як обробляються нетипові та змішані звернення?
Заявка з упевненістю нижче порога не йде навмання: вона позначається й передається оператору на ручний розбір. Рідкісні та пограничні випадки не псують статистику автоматизації, а їхня розмітка пізніше повертається до навчального набору.
Хто і як контролює якість сортування?
Якість вимірюється не на око: ведемо частку автоматично розібраних заявок, точність за кожною категорією та частку переведень на оператора.
Вибірку регулярно звіряємо з ручною розміткою й розбираємо розбіжності — при просіданні за категорією правимо приклади або правило точково, без зупинки потоку звернень.
Обговоримо ваш потік звернень і повернемося з оцінкою
Щоб повернутися з оцінкою та планом робіт, а не із загальними обіцянками, нам потрібні параметри потоку: скільки звернень надходить за добу, якими каналами, як влаштовані поточні правила маршрутизації та яку частку заявок оператори перекласифікують вручну.
Ці ввідні визначають і обсяг розмітки, і сам підхід — від набору правил і пошуку за схожими зверненнями до навчаної моделі на історичних даних.
- Обговоримо задачу та цільові метрики: яку частку звернень має розбирати автомат, яка точність за кожною чергою достатня і що вважаємо критичною помилкою — пропущений інцидент чи зайва переадресація.
- Зафіксуємо план робіт із проміжними точками: розбір потоку → підготовка даних → базова модель із правилами → пілотний потік → виведення в промислову експлуатацію.
- Позначимо доступ до даних: вивантаження закритих звернень за кілька місяців, склад полів, наявність підсумкової категорії та пріоритету, порядок знеособлення персональних даних до передачі.
- Виберемо пілотний потік: одна черга або канал, де помилки класифікації найпомітніші, а ефект вимірюється за пару тижнів без змін в інших напрямках.
- Розділимо зону відповідальності: з вашого боку — доступ до системи, експерт для перевірки розмітки та приймання; з нашого — модель, вбудовування в приймальну лінію, метрики якості та документація.
- Узгодимо поведінку при низькій впевненості та критерії приймання: частка автоматично розібраних звернень, точність за чергами, час відповіді на класифікацію та процедура повернення до ручного режиму.
