Чому класифікація звернень громадян ламається на потоці
Ручне сортування звернень тримається рівно до певного обсягу.
Оператор читає текст повністю, відносить його до теми за ключовими словами й передає далі — на сотнях звернень на добу це ще працює, на тисячах починає зростати черга в контакт-центрі, і час до першої відповіді збільшується швидше, ніж штат.
Далі ламається маршрутизація за темами. Одна тема часто стосується кількох відомств, а кожне бачить лише свою чергу — звернення, що пішло не в той ящик, повертається назад або зависає до ручного нагадування.
Дублікати погіршують картину: те саме звернення надходить кількома каналами, його реєструють повторно, і помітна частка ресурсу йде на розбір повторів замість нових.
Втрата звернення рідко виглядає як явний збій — зазвичай це тихий розрив на стику. Немає наскрізного ідентифікатора, немає журналу передач між відомствами, і в будь-який момент ніхто не може сказати, у кого звернення перебуває зараз.
Єдине вікно приймання без такого зв’язку перетворюється на ще один вхід, а не на єдину точку відповідальності.
Ціна помилки не закінчується затримкою: неправильно визначена тема дає відповідь не за адресою, громадянин пише повторно, і потік зростає сам на собі.
Розбираємо, як це закривається — де ручний розбір замінюється моделлю, як маршрутизація за темами враховує правила відомств і як будується єдине вікно приймання з наскрізним статусом.
Що змінюється після впровадження: ефект у цифрах процесу
Вимірюваний ефект з’являється лише там, де рішення класифікатора й дія оператора фіксуються в одному журналі обробки.
Для кожного звернення зберігаємо запропоновану рубрику, впевненість моделі та підсумкове рішення людини — розходження стає навчальною вибіркою, і якість зростає разом з обсягом потоку, а не сама по собі.
Додатково розмічаємо контрольну вибірку вручну: вона показує, чи не зростає частка авторозбору ціною помилкових маршрутів.
Поріг упевненості задає межу авторозбору: типові теми — скарги на роботу керуючих організацій, питання щодо виплат, запис на прийом — надходять до профільного відомства без оператора, спірні формулювання ескалюються людині.
Поріг налаштовується окремо для кожного каналу, тому потік через Госуслуги, паперова кореспонденція та пошта не заважають одне одному. У міру накопичення підтверджених прикладів поріг підвищується, і частка авторозбору зростає без втрати точності.
Час відповіді заявнику скорочується на етапі, де раніше накопичувалася черга: реєстрація й направлення за адресою відбуваються в момент надходження, а не після ручного сортування.
Частка повторних звернень працює як зворотний зв’язок — якщо людина пише знову з того самого приводу, маршрут вибрано неправильно або відповідь не закрила питання; такі ланцюжки розбираємо окремо й додаємо в навчання.
Навантаження на операторів перестає лінійно залежати від піків: сортування переходить до машини, фахівці займаються змістовними відповідями та перевіркою спірних випадків.
Ранковий вал звернень більше не зростає разом із чергою, а вивільнені руки йдуть на скорочення строків за складними категоріями.
Режими розбору: порівняння варіантів впровадження
Вибір схеми розбору диктує не модель, а профіль навантаження: скільки звернень надходить на добу, чи є піки, чи потрібна відповідь за хвилини або достатньо вивантаження раз на кілька годин. Нижче — чотири контури, які ми розгортали, з їхньою застосовністю та обмеженнями.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пакетна обробка потоку | Звернення накопичуються, важлива повнота розбору, а не швидкість реакції | Відповідь відстає від надходження на вікно вивантаження, пікові дні розбираються із затримкою |
| Потоковий розбір | Потрібна реакція за хвилини, звернення надходять виконавцям одразу | Чутливий до збоїв: без повторів і черги нерозібраних звернення губляться |
| Гібридна схема розбору | Піки та фон різняться в рази, частина звернень не терпить очікування | Складніша в супроводі: дві гілки, два набори метрик, потрібен контроль розходжень |
| Розбір за участю оператора | Теми нові, навчальних прикладів мало, ціна помилки висока | Навантаження на штат зростає разом із потоком, якість тримається на людях, а не на системі |
Ключовий параметр будь-якої схеми — поріг упевненості: нижче нього звернення не надходить в автоматичну маршрутизацію, а потрапляє на ручний розбір. Саме цей поріг, а не вибір контуру, визначає частку звернень, розібраних без людини.
Починати майже завжди варто з пакетного контуру: він дає розмітку та метрики якості, на яких потім будується потокова або гібридна гілка.
Етапи впровадження: від аудиту потоку до експлуатації
Перш ніж навчати модель, ми рахуємо сам потік: скільки звернень надходить, якими каналами і як вони розподіляються між виконавцями зараз. На цьому етапі видно, де ручне сортування з’їдає час, а де вже працюють прості правила і їх достатньо розширити.
- Аудит потоку звернень: вивантажуємо історію, рахуємо частки типових і нетипових запитів, фіксуємо поточний час обробки та точки, де звернення зависає без виконавця.
- Проєктування схеми класів і маршрутів: узгоджуємо перелік категорій, пріоритети й те, який підрозділ отримує кожну тему. Схема має збігатися з реальною оргструктурою, інакше маршрут уткнеться у відсутність виконавця.
- Розмітка прикладів: збираємо навчальну вибірку, спірні звернення розмічаємо вручну й фіксуємо правила для пограничних випадків. Рідкісним темам потрібно достатньо прикладів, інакше модель звалює їх у популярні класи.
- Налаштування порогу впевненості: модель видає ймовірності за кожним класом, поріг вирішує, чи надходить звернення автоматично або на ручний розбір. Занадто низький поріг дає помилки, занадто високий — повертає всю роботу оператору.
- Перевірка якості моделі: на відкладеній вибірці рахуємо точність за класами, окремо дивимося хибні спрацювання на рідкісних темах і стійкість до друкарських помилок, коротких і змішаних за мовою звернень.
- Пілот на живому потоці: система працює в режимі рекомендацій — модель пропонує маршрут, оператор підтверджує або виправляє. Розходження розбираємо й донавчаємо, доки частка правок не стабілізується.
- Передавання в експлуатацію: віддаємо конфігурацію, регламент розмітки нових прикладів і моніторинг дрейфу — при зміні розподілу тем модель перенавчається на правках операторів.
Комплект постачання: моделі, правила маршрутизації, регламенти
Комплект постачання — не архів із файлами, а робочий контур: його можна передати іншій команді, не відновлюючи логіку з листування. Кожен артефакт версіонується й має власника — зрозуміло, хто і що змінює при появі нових типів звернень.
- Модель класифікації та її картка. Де навчалася, яку частку звернень розмічає автоматично, яка точність на відкладеній вибірці та на яких формулюваннях упевненість падає.
- Довідник тем і рубрикатор. Ієрархія категорій із прикладами формулювань, правилами поповнення та порядком узгодження нових тем без перезбирання всієї системи.
- Правила маршрутизації. Таблиця «тема → підрозділ → строк реакції», включно з гілками для змішаних звернень, де модель бачить дві теми з близькою впевненістю.
- Регламент для операторів. Як підтвердити або виправити автоматичну мітку, що робити при низькій упевненості, куди надходить звернення, якщо тему не визначено.
- Політики доступу. Ролі та межі видимості: оператор бачить звернення, аналітик — знеособлену статистику; журнал доступу й правила роботи з персональними даними.
- Документація із системи. Схема потоків, точки інтеграції з обліковою системою, порядок оновлення моделі та відкату на попередню версію.
- Перевірний набір звернень. Кілька сотень розмічених прикладів, на яких проганяємо кожне оновлення, щоб переконатися: старі гілки маршрутизації не зламалися.
Усе передається в контурі замовника, з інструкцією з донавчання та розбором типових збоїв — команді не потрібно повертатися до нас за кожною правкою рубрикатора.
Кейс: єдиний контакт-центр і маршрутизація за темами
Вихідна ситуація
Клієнт — регіональний оператор приймання звернень: вісім вхідних каналів, десятки тем у класифікаторі та ручне сортування.
Оператор читав текст і вибирав тему сам, тому в пікові тижні до третини звернень надходили не до того підрозділу й поверталися з позначкою «не за компетенцією». Строк розбору теми сягав чотирьох робочих днів — ще до того, як звернення потрапляло до виконавця.
Зібрали єдину точку приймання — Единое окно обращений: пошта, форми на сайті, телефонні розмови та листування в чатах зводяться в один потік із спільною нумерацією та історією.
Модель класифікації навчили на архіві звернень і розмітці самих фахівців: вона визначає тему, підтему та ознаку терміновості. Спірні випадки з низькою впевненістю надходять оператору — правило залишили жорстким навмисно, бо ціна помилки в соціальних темах вища за швидкість.
Результат
Через два місяці частка звернень, розібраних автоматично без правки оператора, вийшла на 78%, а строк маршрутизації скоротився з двох-чотирьох днів до хвилин.
Повторні перенаправлення між підрозділами впали втричі, частка відповідей із порушенням регламентного строку — з 22% до 4%.
Модель донавчається на правках операторів: кожне виправлення теми — сигнал для наступної ітерації. Список тем переглядаємо за накопиченою статистикою раз на місяць — формулювання громадян змінюються швидше, ніж будь-який фіксований довідник.
Що робити, якщо звернення вже сортують вручну?
Розбір за правилами ламається на першому ж зверненні, написаному не так, як очікував автор шаблону: синонім, друкарська помилка, дві теми в одному листі, цитата чужого тексту.
Кожен новий випадок додає правило, правила починають конфліктувати, а правка одного ронить точність на сусідніх — супровід зростає швидше, ніж кількість звернень.
Вимикати правила за один день не потрібно. Робоча схема — гібридний підхід: детермінований шар ловить формальні та рідкісні категорії, де важлива однозначність формулювання, а модель машинного навчання розбирає варіативну частину — теми, вкладені питання, неявні прохання.
Ознаки з правил подаються в модель як вхід, тому вона успадковує накопичену експертизу, а не стартує з нуля.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Тільки правила | 3–5 стабільних категорій, формальні ознаки | Ламається на перефразуваннях, зростає ціна правки |
| Модель машинного навчання | Категорій багато, формулювання вільні | Потрібна розмітка, рідкісні класи провалюються |
| Гібридний підхід | Перехід без втрати якості на старті | Потребує узгодження шарів і пріоритетів |
| Модель плюс перевірка оператором | Висока ціна помилки | Нижча частка автоматичних рішень |
Перехід на модель ведуть поетапно: спочатку вона працює поряд із правилами, її рішення звіряють із висновками операторів, розходження розбирають і додають у розмітку. Автомаршрутизація вмикається для класів, де точність тримається вище заданого порогу, решта йде на ручний розбір.
Тут допомагає попередньо навчена мовна модель ruBERT — вона вже розуміє російський синтаксис, і донавчання потребує в рази менше розмічених прикладів, ніж навчання з нуля.
Технічні сумніви перед стартом проєкту
Сумніви перед стартом зазвичай одні й ті самі: чи спрацює класифікація звернень громадян на темах, яких не було у вибірці, що робити з друкарськими помилками та змішаними мовами, хто бачить персональні дані й як результат потрапляє в облікові системи. Розбираємо кожне місце предметно.
Окремо варто згадати зміну правил: рубрикатор і логіка маршрутизації зберігаються в конфігурації, а не всередині моделі. Тому нова гілка або зміна пріоритетів — регламентна правка з прогоном на наборі минулих звернень, а не перенавчання з нуля.
А якщо з’явиться нова тема, якої не було у вибірці?
Звернення з низькою впевненістю за всіма рубриками не «приклеюється» до випадкового класу, а надходить у гілку «не визначено» й на розбір оператору.
Далі працює потік розмітки: спірні приклади потрапляють у чергу, раз на ітерацію рубрикатор і модель оновлюються — нові теми стають матеріалом для донавчання, а не збоєм маршрутизації.
Що з друкарськими помилками, скороченнями та текстом різними мовами?
Текст проходить нормалізацію: розкриття абревіатур, виправлення частих друкарських помилок, трансліт, розмітка змішаних фрагментів. Мова визначається на вході, і для кожної своя гілка обробки, тому звернення з вставками іншої мови або відомчими скороченнями не втрачає рубрику.
Як забезпечується захист персональних даних?
Знеособлення відбувається до класифікації: імена, адреси, телефони та номери документів маскуються, у модель надходить лише текст без ідентифікаторів. Доступи розмежовані за ролями, кожне звернення до даних пишеться в журнал, а обробка може йти цілком у контурі замовника.
Як результат передається в облікові системи?
Передавання йде через програмний інтерфейс або шину: картка отримує рубрику, пріоритет і виконавця. Повторні спроби та захист від дублів гарантують, що при недоступності системи звернення не загубиться, а доїде після відновлення; розходження видно в журналі обміну.
Обговоримо задачу та повернемося з оцінкою і планом
Перший крок — короткий аудит перед стартом: дивимося, звідки надходять звернення, в якому вигляді, скільки їх і як вони розмічаються зараз. Без цього будь-яка оцінка строків буде на око, а класифікація звернень громадян уткнеться в якість вихідних даних, а не в модель.
Щоб розмова була предметною, корисно підготувати:
- перелік каналів надходження та форматів — листи, електронні форми, скани, розшифрування дзвінків;
- вивантаження історичних звернень і вже прийняті за ними рішення та маршрути;
- чинний рубрикатор відомства, якщо він є, або його робоча чернетка;
- приклади спірних випадків, де звернення підходить одразу під кілька тем;
- обсяги потоку та пікові періоди, коли ручне сортування перестає справлятися;
- вимоги до роботи з персональними даними та правила доступу до них;
- точки стикування: куди повертається маршрут, хто і як його підтверджує;
- критерії приймання — цільова частка правильно направлених звернень і допустима частка ручного розбору.
Після аудиту повертаємося з планом впровадження: склад робіт за етапами, оцінка строків, зони відповідальності та що потрібно від вашої сторони. Опишіть задачу у вільній формі — цього достатньо, щоб почати, решту уточнимо в розмові.
