ШІ для класифікації і маршрутизації звернень у Jira та Zendesk

Коротка відповідь: ШІ-класифікація звернень корисна, коли категорії чітко визначені, а якість перевіряється окремо для кожного класу, а не однією загальною точністю. Тема, мова, пріоритет і емоційність звернення є різними полями. Емоційний лист не обов'язково є критичним інцидентом, а спокійний опис може виявитися аварією.

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

Які рішення автоматизуємо

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

• Тема. Про що звернення: оплата, доступ, технічний збій, повернення. Від теми залежить, яка команда має знання для відповіді.
• Черга або виконавець. Куди потрапить звернення. Тема впливає на чергу, але не визначає її повністю: тут діють також мова, регіон, тип клієнта, навантаження команд.
• Мова. Для багатомовної підтримки мова визначає, хто зможе відповісти.
• Пріоритет. Наскільки терміново потрібно реагувати. Він залежить від впливу на клієнта і бізнес, умов обслуговування та правил сервісу.
• Тональність. Наскільки клієнт роздратований. Це сигнал для уважнішої комунікації, але не пріоритет сам по собі.

Найпоширеніша помилка: змішати тональність і пріоритет. Фраза «Терміново, де мій рахунок?!» звучить як аварія, але це питання оплати зі звичайним пріоритетом. А лист «Добрий день, з ранку жоден співробітник не може увійти в систему» написаний спокійно, але описує інцидент, що зачіпає всю компанію клієнта. Якщо пріоритет виставляється за емоціями, перший лист обганяє другий.

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

Підготовка категорій

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

Що потрібно для робочої таксономії:

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

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

Вбудовані функції і власний класифікатор

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

Zendesk. Має функцію intelligent triage, яка класифікує нові звернення за темою (раніше в інтерфейсі поле називалося «намір»), тональністю, мовою і сутностями, наприклад назвами продуктів, і показує рівень впевненості класифікації. За документацією Zendesk, станом на жовтень 2026 року класифікації доступні на планах Suite і Support Professional та вищих, а використання їх у тригерах та інших робочих процесах потребує доповнення Copilot. Початкова класифікація спирається на тему звернення і перший публічний коментар. Якщо у вашому обліковому записі ввімкнено динамічну класифікацію, тему й тональність можуть переоцінювати після наступних відповідей клієнта; мова при цьому не оновлюється з кожною відповіддю. Zendesk також радить для кожної теми окремо визначити, який рівень впевненості потрібен перед автоматичною дією.

Jira Service Management. Atlassian пропонує ШІ-сортування для черги: агент вибирає кілька звернень, отримує пропозиції нових типів запитів і заповнення полів, переглядає їх і застосовує вибрані. Тобто людина підтверджує зміни перед застосуванням. Є обмеження: тип запиту, обов'язкові поля якого ШІ не може заповнити, недоступний для вибору; функція потребує увімкнених ШІ-можливостей і недоступна в окремих середовищах.

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

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

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

Критичні помилки

Не всі помилки класифікації однакові. Варто окремо розглядати дві групи.

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

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

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

Практичні запобіжники:

• Ключові ознаки критичного інциденту (масова недоступність, безпека, втрата даних) перевіряються окремим правилом, а не лише загальним класифікатором.
• Звернення з низькою впевненістю класифікації йдуть на ручний розбір.
• Будь-яке звернення від клієнтів з особливими умовами обслуговування проходить додаткову перевірку пріоритету.
• Кожен випадок, коли критичне звернення виявили із запізненням, розбирається окремо: що було в тексті, як його класифікувала модель і яке правило мало б його зловити. Такі звернення одразу додаються в контрольну вибірку.

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

Вимірювання

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

Навчальний приклад: як загальна точність приховує пропущені інциденти

Розмічена вибірка: 200 звернень. З них 196 звичайних (оплата, доступ, технічний збій, повернення) і 4 критичні інциденти.

Класифікатор правильно визначив 188 з 196 звичайних звернень і лише 1 з 4 критичних.

• Загальна точність: (188 + 1) / 200 = 189 / 200 = 94,5%.
• Повнота (recall) для класу «критичний інцидент»: 1 / 4 = 25%. Тобто три з чотирьох аварій потрапили не туди.

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

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

Навчальна таблиця перевірки окремих звернень

Які метрики варто рахувати:

• Точність (precision) за класами: з усіх звернень, які модель віднесла до класу, яка частка справді до нього належить.
• Повнота (recall) за класами: з усіх звернень класу, яку частку модель знайшла. Для критичних класів це головна метрика.
• Матриця помилок: таблиця, що показує, з якими класами модель плутає кожен клас. Вона підказує, які визначення треба уточнити.
• Ручні перепризначення: як часто агенти переносять звернення в іншу чергу після автоматичної маршрутизації.
• Час до першої відповіді і до вирішення за чергами до і після запуску, з урахуванням сезонності.

Запуск і оновлення

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

1. Тіньовий режим. Модель класифікує звернення, але результат лише записується в поле і не впливає на маршрутизацію. Команда працює як раніше, а ви порівнюєте прогнози з фактичними рішеннями агентів.
2. Обмежена черга. Автоматична маршрутизація вмикається для однієї-двох категорій з найкращими метриками і низькою ціною помилки. Критичні класи на цьому етапі залишаються під ручним контролем або окремими правилами.
3. Розширення. Нові категорії підключаються лише після того, як їхні precision і recall на свіжій розміченій вибірці досягають рівня, погодженого керівником підтримки.
4. Регулярний перегляд. Звернення змінюються: новий продукт, нова проблема, сезон. Метрики перераховуються регулярно, а таксономія і приклади оновлюються, коли зростає частка ручних перепризначень або звернень у категорії «невідоме».

Висновок

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

Що можна зробити на своєму процесі:

1. Розділіть рішення: тема, черга, мова, пріоритет, тональність. Визначте, які з них ухвалює модель, а які правила.
2. Опишіть неперетинні категорії з прикладами і категорією «невідоме». Перевірте узгодженість розмітки двома людьми.
3. Перевірте, які функції класифікації і маршрутизації доступні саме у вашому тарифі Jira або Zendesk.
4. Зберіть розмічену вибірку з окремою групою критичних звернень і рахуйте precision і recall за класами, а не лише загальну точність.
5. Запустіть класифікацію в тіньовому режимі, потім для обмеженої черги з низькою ціною помилки.
6. Призначте відповідального за регулярний перегляд метрик, таксономії і правил пріоритету.

Якщо ви хочете зменшити ручне сортування звернень, команда BotLabs може розібрати вашу чергу на 15-хвилинній консультації. Обговоримо категорії, правила пріоритету і критичні звернення, які не можна пропускати, а також що з потрібного вже є у вашій системі підтримки. Наступним кроком визначимо, з якої черги і якої вибірки почати тіньовий режим.

Часті запитання