Чому класифікація звернень клієнтів ламається на обсязі
На потоці в сотні звернень на день класифікація тримається на людях: оператор першої лінії читає заявку, вручну визначає тему та перекладає її в потрібну чергу. Поки запитів небагато, схема працює — тематик десяток, і людина утримує їх у голові цілком, без довідника.
Вузьке місце обробки звернень проявляється, коли потік зростає, а теми починають перетинатися. Той самий запит містить питання щодо оплати, претензію до доставки та прохання закрити доступ — ручне сортування звернень вимагає вибрати одну категорію, і вибір щоразу робиться заново.
Рішення ухвалюється послідовно, по одному зверненню, тому пропускна здатність першої лінії не зростає разом із навантаженням.
Далі вмикається накопичення: черга першої лінії зростає швидше за вхідний потік, частина заявок чекає на розбір довше, ніж триває сама відповідь.
На піках помилкова маршрутизація відправляє запит не у той відділ — клієнт отримує відповідь на чуже питання, пише повторно, а початкове звернення осідає в історії листування без власника. Метрика часу першої відповіді ще тримається, а час повного вирішення розходиться з нею в рази.
Розбираємо, як це закривається: від розмітки корпусу та правил розбиття пересічних тем до автоматичної класифікації, яка проставляє тематику й пріоритет у момент надходження та залишає людині тільки спірні випадки.
Що дає автоматична маршрутизація звернень
Класифікатор розбирає звернення на вході: визначає тематику, мову, ознаки терміновості та віддає його в потрібну чергу разом із чернеткою відповіді.
Частка авторозпізнавання на закритому наборі тем тримається в діапазоні 0,75–0,9 — залишок не «докидається» навмання, а потрапляє в загальну чергу з позначкою для оператора.
Поріг упевненості — головний параметр налаштування. Нижче нього система чесно повідомляє «не знаю» і передає звернення людині: хибна маршрутизація дорожча за ручну розмітку, бо клієнт отримує відповідь не від того, хто вирішує питання.
Поріг підбираємо на відкладеній вибірці реальних звернень, а не на показових прикладах, і переглядаємо в міру появи нових тем.
Час первинної відповіді скорочується завдяки автоматичному підтвердженню: клієнт одразу бачить номер звернення, визначену тему та очікуваний час реакції.
Оператори перестають витрачати першу лінію на сортування — навантаження вирівнюється між групами, а пікові години більше не впираються в одного чергового.
Окремий ефект — зникає клас втрачених звернень: без власника, прийнятих поза годинами роботи, повторно надісланих після збою приймання. У кожного звернення з'являється маршрут і строк, а відхилення від нього видно у звіті.
Стикуємо це з тією системою обліку, що вже працює у вас, — від Zendesk до саморобної на пошті та в месенджерах.
Підходи до розмітки: правила, словники, навчання на історії
Розмітка потоку звернень — це не вибір «правила чи навчання на даних», а рішення про те, де закінчується зона відповідальності словників і починається статистика.
Нижче — три схеми, між якими реально вибирають на старті, та обмеження кожної: вони проявляються не на демо, а на другий-третій місяць експлуатації, коли потік змінюється.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Правила та словники | 5–15 стійких тематик, є характерна лексика: артикули, назви послуг, типові формулювання | Ламається на перефразуваннях і одруківках; словник зростає швидше за потік; конфлікт правил розводять пріоритетами вручну |
| Навчання на історичних даних | Накопичено історію звернень із проставленими тематиками, формулювання клієнтів різноманітні | Потрібна вивірена розмітка вибірки; за появи нової тематики потрібне донавчання; на рідкісних класах якість падає |
| Гібридна схема розмітки | Правила закривають явні випадки, навчання — решту, спірні йдуть на ручний розбір | Потрібні узгоджені пороги впевненості та зворотний зв'язок: розбір помилок повертається в розмітку вибірки |
Гібридна схема дає кращий баланс: словники знімають передбачувану частину потоку, навчання на історії — перефразовані звернення, а поріг упевненості вирішує, що йде оператору.
Контур виходить зрозумілим на кожному кроці: видно, яке правило чи який приклад з історії дав тематику, — і це ж спрощує розширення набору класів без повного перезбирання.
Як відбувається впровадження: етапи робіт від аудиту до передачі
Класифікація звернень не зводиться до встановлення готової моделі: склад тем, пороги впевненості та правила маршрутизації залежать від вашого потоку. Тому йдемо етапами, і кожен закривається результатом, який можна перевірити на ваших же даних.
- Аудит потоку звернень — вивантажуємо історію з усіх каналів, рахуємо обсяг, частку дублів, коротких і змішаних запитів.
- Перелік тем — робоча таксономія на 15–40 тем першого та другого рівня, клас «інше» і правило для запитів, що потрапляють одразу в дві теми.
- Інструкція та розмітка — фіксуємо правила розмітки й розбір спірних випадків, щоб розмітники не розходилися між собою.
- Налаштування та навчання — базовий варіант моделі, пороги впевненості за кожною темою, окрема обробка коротких звернень і вкладень.
- Пілот на зрізі даних — прогін на відкладеному зрізі, який модель не бачила, і звірка з ручною розміткою за кожною темою.
- Приймання за метриками — точність і повнота за темами, частка «інше», частка впевнено віднесених; поріг, нижче якого рішення не виходить у роботу, узгоджуємо заздалегідь.
- Передача в підтримку — документація з таксономії, регламент донавчання й перерозмітки, моніторинг потоку та порядок дій у разі падіння метрик.
Що відбувається після приймання
Таксономія продовжує жити: з'являються нові продукти, змінюється сезонність, розподіл запитів відходить від навчальної вибірки. Раз на квартал переглядаємо пороги й донавчаємо модель на нових розмічених зверненнях — частка автоматичної маршрутизації тримається, а не сповзає.
Артефакти проєкту: правила, схеми, регламенти перегляду
Після здачі проєкту в команди замовника не залишається «чорного ящика»: усе, що визначає поведінку класифікатора, лежить у його репозиторії та версіонується разом із кодом. Без цих артефактів проєкту перша ж нова тематика звернень вимагатиме нас — і підтримка стане на паузу.
- Схема інтеграції: звідки звернення потрапляють у класифікатор (CRM, канал підтримки, черга), де точки відмови та як налаштовані повтори в разі збою.
- Матриця доступу: хто бачить розмітку, хто править тематики, хто змінює поріг упевненості — права розведені за ролями, а не «в адміна все».
- Регламент перегляду тем: періодичність (за розкладом або за часткою некласифікованих), порядок додавання теми та перевірка на перетин із уже наявними.
- Інструкція для операторів: що робити із сумнівним зверненням, як його позначити, куди воно йде і як швидко розмітка потрапляє в донавчання.
- Конфігурація класифікатора: поріг упевненості, словники-винятки, правила маршрутизації спірних звернень на ручну перевірку.
- Каталог тематик зі словником синонімів: як називаються теми, що в них входить, якими формулюваннями клієнти їх позначають.
- Контрольна вибірка звернень з очікуваними тематиками — проганяється після кожної правки, щоб бачити, чи не зламали старе.
- Журнал змін: що, коли й за чиєю заявкою змінювалося в правилах — без нього спірне рішення не відкотити.
Документи живуть поруч із моделлю та оновлюються тим самим порядком, що й код: правка — перевірка на контрольній вибірці — запис у журнал. Систему можна розвивати своєю командою, а нам віддавати лише спірні ділянки.
Кейс: частка автоматичної маршрутизації зросла до 92%
До впровадження маршрутизація трималася на правилах за ключовими словами та ручному розборі. Автоматично розходилося близько 40% звернень, решту оператори першої лінії розкидали за групами вручну й на піках не встигали: нічна черга відставала на 6–8 годин.
Кожен п'ятий переклад виявлявся помилковим — звернення кочувало між групами, поки клієнт чекав на відповідь.
Від розмітки до маршрутизації
Спершу ми розмітили історичний масив звернень за єдиною таксономією. Спірні випадки закривали не голосуванням розмітників, а за Регламентом розмітки звернень: правило фіксували один раз і далі застосовували до всього потоку.
Це підняло узгодженість міток із 78% до 96% — модель перестала вчитися на суперечливих прикладах, де те саме формулювання позначене різними темами.
Що стало з метриками
У роботу схема пішла з порогом упевненості: вище порога звернення йде в групу автоматично, нижче — у чергу ручного розбору з підказкою щодо ймовірних тем.
Частка автоматичної маршрутизації зросла до 92%, помилкові переклади впали з 17% до 4%, відставання нічної черги скоротилося з 6–8 годин до менш ніж години.
Стійкість до піків перевіряли окремо: за зростання потоку в 2,5 раза частка автоматики трималася на 89–91%, бо навантаження лягає на коротку чергу розбору, а не на людей.
Кожне оновлення проходить регресійну перевірку на відкладеному наборі історичних звернень — якщо точність на рідкісній темі знижується, версія не викочується.
Чим відрізняється навчання на історії від правил і словників?
Правила виграють там, де формулювання стабільне й ціна помилки висока.
Номер договору, реквізити, запит виписки, заявка на закриття рахунку — це лексикон із фіксованим словником, і правило за ним дає точність, яку модель не відтворює: воно або спрацювало, або ні, і відповідь повторюється від прогону до прогону.
Поки тематик десяток і потік однорідний, словників достатньо — їх простіше пояснити підтримці та розібрати спірний випадок.
Модель обходить правила там, де словник закінчується. «Перестало приходити», «списали двічі», «хочу як минулого разу» — на такі формулювання правил не напасешся, а навчений на історії розбір веде їх за змістом і стійкий до одруківок, трансліту та двох тем в одному зверненні.
Плата за це — імовірнісна відповідь: на виході розподіл за тематиками, і рішення ухвалюється за порогом упевненості.
Гібридний підхід будується на розподілі ролей. Правила беруть короткі однозначні маршрути й захищені категорії, де помилка дорожча за відмову від автоматизації, а модель — усе, що залишилося після відсікання.
Звернення нижче порога йдуть у чергу оператора, і саме вона стає джерелом розмітки для наступного донавчання.
Словники при цьому не скасовуються, а звужуються до ролі довідника та страховки. Раз на квартал розбираємо, що потрапило в «інше» і де правило спрацювало хибно, додаємо формулювання — але щойно одна фраза підходить двом правилам, тему вигідніше перевести в модель. Перегляд словників стає регулярною процедурою, а не ремонтом накопичених конфліктів.
Розмітка, якість і перегляд: питання перед стартом
Перед стартом замовник зазвичай перевіряє чотири речі: чи вистачить даних і як забезпечити якість розмітки, що робити з пересічними та рідкісними темами, як підключати нові канали звернень і чи можна навчати модель на реальних діалогах. Нижче — прямі відповіді, без загальних слів.
Скільки звернень потрібно, щоб якість розмітки не розвалилася?
Вирішує не обсяг, а згода розмітників: на спірних темах двоє фахівців розходяться в 15–20% випадків, і цю дельту потрібно зняти до навчання. Ми закладаємо інструкцію розмітки з граничними прикладами, контрольну вибірку та замір згоди — інакше модель вивчить шум замість тематики.
Теми перетинаються й постійно переглядаються — що тоді?
Перетин — норма: доставка й повернення живуть в одному зверненні. Ми задаємо правила пріоритету та дозволяємо зверненню отримувати основну тему плюс суміжні, а перегляд тем ведемо за журналом помилок: дивимося, які пари класів плутаються найчастіше, і уточнюємо межі формулювань.
Рідкісні теми не тонуть у загальному потоці?
За рідкісними класами точність падає першою, тому ми рахуємо якість окремо за кожною темою, а не однією середньою цифрою. Дисбаланс вирівнюємо вагами й додаванням прикладів, а рідкісні теми позначаємо для ручної перевірки — так вони не розчиняються в масових.
Як підключаються нові канали і що з персональними даними?
Новий канал входить як окреме джерело зі своїм форматом, і ми звіряємо його розмітку з уже ухваленою — інакше класифікація звернень клієнтів дасть збій на незвичних формулюваннях.
Персональні дані знеособлюються до навчання: телефони, адреси й номери замовлень замінюються мітками, доступ до вихідних даних обмежений.
Обговоримо задачу й повернемося з оцінкою та планом
Старт проєкту впирається не в модель, а в дані та в рішення, які може ухвалити тільки ваша сторона. Готова чиста вигрузка нам не потрібна — приведення звернень до єдиного вигляду та первинна обробка на нашій стороні. Що дійсно потрібно з вашого боку, щоб не втрачати час на перші тижні:
- історію звернень за кілька місяців у вихідному вигляді: листи, тікети, діалоги в чатах, розшифровки дзвінків — без ручного чищення та фільтрації;
- наявна рубрикація, якщо вона є: список тем, інструкції для операторів, приклади спірних випадків;
- відповідальний за тему з вашого боку — той, хто підтверджує межі категорій і розбирає різночитання, інакше класифікація розійдеться з вашою внутрішньою логікою;
- доступ до реального контуру джерел (пошта, система обліку звернень, довідкова служба, месенджери) з тими самими правами, що в операторів;
- перелік тем, де оператори розмічають упевнено, і тих, де сперечаються — ця межа визначає, де на виході потрібна людина;
- обмеження щодо персональних даних і вивантаження за периметр — від них залежить схема обробки;
- критерій приймання: яка частка правильних влучень вважається робочою і на якій вибірці її вимірюємо.
Опишіть задачу — за цими пунктами повернемося з оцінкою обсягу та планом робіт, включно зі схемою тем, порядком розмітки та способом контролю якості на ваших даних.
