Відділ IT-підтримки обробляє 200 звернень на день через три канали: електронна пошта, формуляр і чат. Половина надходить між 16:00 і 9:00 ранку, коли команда неповна. Аналіз історичних даних за 3 місяці показує, що 12 справ, позначених як «стандартні», протягом 48 годин ескалували до серйозних інцидентів. Кожна ескалація коштувала від 4 до 8 додаткових годин роботи. Класифікатор AI, впроваджений після 6-8 тижнів пілотування, може скоротити такі затримки на 60-75%, якщо він добре відкалібрований під асиметрію вартості помилок.
Що класифікує AI і які сигнали аналізує
#Добре спроєктований класифікатор звернень аналізує одночасно кілька вимірів.
Тематична категорія – найпростіший вимір. Модель навчається розрізняти білінг від технічних проблем, комерційні запити від рекламацій, онбординг від питань щодо регламенту. Тренувальні дані – історичні звернення з мітками, доданими командою. При 500+ прикладах на категорію модель досягає точності 85-92% на власному тесті. Якщо прикладів менше 200, слід використовувати few-shot промптинг із базовою моделлю замість fine-tuningu.
Терміновість – складніший вимір, оскільки він асиметричний. Хибна ескалація коштує хвилин роботи координатора. Пропущене термінове звернення – втрата клієнта або інцидент SLA. Тому класифікатор терміновості має бути окремою моделлю (або окремою класифікаційною голівкою) з явно вищою чутливістю до класів «висока» та «критична». Сигнали: кризові ключові слова (аварія, відсутність доступу, неможливо, негайно, втрата), кількість попередніх звернень від цього клієнта за 7 днів, рівень клієнта з CRM, час надходження відносно вікна SLA.
Мова та сентимент доповнюють картину. Багатомовній компанії потрібна автодетекція мови перед класифікацією, щоб не передавати польськомовне звернення до англомовної черги. Негативний сентимент сам по собі не змінює пріоритет, але є сигналом ескалації: клієнт, який у чотирьох реченнях двічі використав слово «скандал» і написав з окличними знаками, потребує іншого тону автовідповіді та швидшого контакту з людиною.
Канал і формат також впливають на маршрутизацію. Звернення через чат має нижчий очікуваний час відповіді, ніж електронний лист. PDF із додатками, що потребує OCR, потрапляє до іншої черги, ніж текстове запитання. Формуляр із полем «пріоритет», заповненим клієнтом, є сильним сигналом, який модель може пропустити в самому тексті.
Архітектура: від сигналу до черги
Шаблон, який добре працює при 100-500 зверненнях на день, – це конвеєр структурованого виводу з багатошаровим фолбеком.
Крок 1: нормалізація вхідних даних. Звернення з кожного каналу зводиться до спільної структури: тема + текст + метадані (канал, час, ID клієнта). Додатки обробляються окремо за допомогою OCR або екстрактора PDF перед передачею класифікатору.
Крок 2: класифікація. Модель (або промпт LLM з few-shot прикладами) повертає JSON зі структурою: { "category": "...", "urgency": "high|standard|low", "language": "pl|en|de", "sentiment": "negative|neutral|positive", "keywords": [...] }. Structured output з валідацією схеми усуває галюциновані поля. Якщо модель повертає urgency: null або низький confidence score, звернення потрапляє до черги ручної класифікації, а не до авто-маршрутизації.
Крок 3: маршрутизація. На основі перетину категорії та терміновості правила направляють до черги. Критична терміновість завжди потрапляє до спеціальної черги чергування, незалежно від категорії. Висока терміновість поза робочим часом надсилає пуш-повідомлення або SMS черговому. Стандартні звернення з низьким сентиментом можуть отримати автовідповідь із RAG на базі бази знань.
Крок 4: human-handoff. Агент не завершує роботу на маршрутизації. Передає контекст: чому потрапило до цієї черги, які сигнали вирішили, історія клієнта за останні 30 днів, схожі вирішені справи. Консультант бачить готовий бриф замість сирого звернення.
Таблиця: сигнал vs рішення маршрутизації vs фолбек
#| Вхідний сигнал | Рішення маршрутизації | Фолбек при низькому confidence |
|---|---|---|
| Кризові слова (аварія, відсутність доступу, втрата) | Черга критичних + сповіщення чергового | Черга термінових з прапорцем для перевірки |
| Рівень клієнта: enterprise + висока терміновість | Призначений менеджер клієнта, max 15 хв SLA | Старший супровід, max 30 хв SLA |
| Дуже негативний сентимент + категорія рекламація | Черга утримання, пріоритет високий | Загальна черга підтримки з нотаткою про сентимент |
| Мова, що не підтримується | Автодетекція + маршрутизація до носія мови або MT з прапорцем | Загальна черга з позначкою мови |
| Категорія білінг + час поза офісом | Автовідповідь RAG + тикет на наступний день | Черга білінгу з нотаткою про час |
| Низький confidence класифікатора (< 0,6) | Черга ручної класифікації, не авто-маршрутизація | Завжди: людина класифікує вручну |
| Повторний клієнт з 3+ зверненнями за тиждень | Ескалація до account-менеджера з історією | Черга старшої підтримки з історією |
Коли автовідповідь, коли людина
Автовідповідь через RAG добре працює у вузькому діапазоні: запитання про статус замовлення, години роботи, процедури повернення, стандартні інструкції з налаштування з документації. Умова: відповідь має бути верифікованою системою (наприклад, статус із бази даних) або буквально взятою з затвердженого документа. Галюцинована або неточна автовідповідь коштує більше довіри, ніж її відсутність.
Людина втручається в кожному з цих сценаріїв: критична або висока терміновість, ескалація утримання, юридичні або регуляторні звернення (RODO, фінансові рекламації), тема, невідома моделі (новий продукт, інцидент без прецедентів у тренувальних даних), дуже негативний сентимент із сигналами відтоку. Хороше правило: якщо консультант мав би виправляти автовідповідь у понад 15% випадків певної категорії, ця категорія випадає з авто-маршрутизації та повертається до людської черги.
Шаблон пілотування: протягом перших 4-6 тижнів класифікатор працює в режимі shadow. Класифікує, але остаточну маршрутизацію робить людина. Порівняння рішень AI та консультанта будує ground truth для оцінки моделі та виявляє категорії, де модель помиляється систематично.
Як вимірювати точність маршрутизації
Observability для системи маршрутизації базується на кількох метриках, які збираються з першого дня.
Precision і recall для кожної черги. Precision: скільки звернень потрапило до черги обґрунтовано. Recall: скільки звернень, які мали потрапити до черги, фактично туди потрапили. Особливо важливий recall для черги критичних: пропуск термінової справи – це інцидент.
Escalation rate. Частка звернень, перенесених консультантом до вищої черги після маршрутизації. Високий escalation rate (понад 10-15%) сигналізує, що класифікатор занижує терміновість. Це головний показник помилкової деприоритизації.
Re-classification rate. Частка звернень, де консультант змінив категорію, визначену моделлю. Понад 20% для певної категорії – сигнал до додаткового тренування або перегляду тренувальних міток.
Time-to-first-response для кожної черги vs SLA. Чи дійсно маршрутизація прискорює обслуговування? Вимірюється час від надходження звернення до першої відповіді консультанта, порівняно з SLA для даного пріоритету.
Розподіл confidence score. Моніторинг розподілу впевненості моделі за категоріями. Якщо категорія «білінг» регулярно повертає confidence 0,55-0,65, модель не впевнена і потребує більше тренувальних прикладів або переформулювання промпту.
Спробуй наживо
FAQ
#Скільки часу займає впровадження класифікатора звернень на базі AI?
#Пілотний режим shadow mode з класифікатором на основі few-shot промптингу можна запустити за 2-4 тижні, якщо є історичні дані звернень з мітками. Повне впровадження з інтеграцією до helpdesk, метриками та процедурами ескалації займає 6-12 тижнів. Більшість часу йде на збір і перевірку тренувальних даних та калібрування порогів терміновості, а не на саме програмування.
Чи може AI повністю замінити людину при класифікації звернень?
#Для тематичної категорії та простих випадків терміновості AI досягає точності 85-92% на добре підготовлених даних. Однак автоматична маршрутизація без нагляду людини має сенс лише для класів низького ризику (стандартні запитання, низький сентимент, відома категорія). Критичні, юридичні та пов'язані з утриманням звернення потребують людської перевірки. Мета – не нуль консультантів, а звільнення 60-70% їхнього часу від рутинної класифікації.
Що робити, якщо класифікатор систематично помиляється з однією категорією?
Зберіть звернення з цієї категорії за останні 30-60 днів, перегляньте їх із консультантом і перевірте, чи були мітки узгодженими. Найчастіші причини: занадто вузьке або занадто широке визначення категорії, категорії, що перетинаються (наприклад, «білінг» vs «повернення»), мала кількість тренувальних прикладів (менше 200). Рішення: уточнення визначення, об'єднання або розділення категорій, додавання додаткових прикладів, можливо, додавання негативних прикладів (що НЕ є цією категорією).
Як обробляти багатомовні звернення в одній системі?
Автодетекція мови працює на рівні 98%+ для мов із достатньою кількістю даних. Класифікація категорії та терміновості працює незалежно від мови, якщо базова модель багатомовна (наприклад, BGE-M3 для ембедінгів). Маршрутизація до мовної черги – це просте правило на виході з класифікатора. Проблема виникає при змішаній мові в одному зверненні або при діалектах. Рішення: позначка для ручної перевірки при confidence мови нижче 0,85.
Які дані потрібні для тренування класифікатора і як їх захищати?
Для тренування потрібні історичні звернення з мітками: мінімум 200-500 прикладів на категорію, мінімум 100-200 на клас терміновості. Дані звернень часто містять PII (ім'я, електронна пошта, номер рахунку). Перед тренуванням: анонімізація або псевдонімізація даних, видалення персональних даних із тренувальних прикладів або їх маскування. Якщо звернення містять конфіденційні фінансові або медичні дані, розгляньте self-hosting моделі та проведіть DPIA перед впровадженням.
Пов'язані статті: AI у call-центрі, Автоматизація обслуговування клієнтів за допомогою AI, Багатокрокове планування агента AI, AI для модерації контенту. Також перегляньте інструмент blueprint агента для проєктування архітектури вашої системи маршрутизації.