Чому тікети підтримки губляться в мобільному застосунку
Тікет надходить у застосунок у той момент, коли користувач уже роздратований: оплата не пройшла, екран завис, push не дійшов. Далі починається найдорожче — звернення потрапляє в загальний потік, де його вручну розбирає оператор першої лінії.
Він бачить текст, вкладення, версію збірки та платформу, але не бачить головного: це одиничний збій в одного користувача чи початок масової відмови після релізу. Поки триває ручне сортування підтримки, критичний дефект лежить у черзі поруч із питанням «як змінити аватар».
Вузьке місце підтримки проявляється на обсязі. При зростанні навантаження на підтримку оператори перемикаються в режим конвеєра: закривають прості звернення, а складні відкладають на потім.
Саме там і губляться збої, які ламають оплату або авторизацію — вони потребують розбору, а розбір потребує часу, якого немає.
Обробка звернень у застосунку перетворюється на лотерею: швидкість відповіді залежить від того, чи потрапив тікет до досвідченого інженера чи до новачка на зміні.
Ціна помилки рахується не в тікетах, а у відтоці. Користувач, чий платіж завис і не отримав відповіді в розумний час, не пише повторно — він видаляє застосунок і залишає відгук, який читають наступні.
При цьому сам дефект нікуди не зникає: він продовжує відтворюватися в інших, просто сигнал про нього розмазаний по сотнях розрізнених звернень, які ніхто не пов'язав між собою.
AI-класифікація тікетів змінює точку входу: звернення розмічається за темою, терміновістю та ознакою масовості автоматично, ще до того як його побачить людина.
Критичні збої йдуть в окремий потік із пріоритетом, типові питання закриваються без оператора, а інженер отримує не один тікет, а групу пов'язаних — із спільною ознакою дефекту. Розбираємо, як це закривається на практиці та що саме потрібно налаштувати в застосунку.
AI-класифікація звернень: що змінюється в роботі підтримки
Автоматичне розмічування звернень будується на моделі, яка за текстом тікета, логами сесії та метаданими пристрою присвоює категорію й пріоритет до того, як звернення потрапить до оператора.
Класифікатор навчається на історичних тікетах із уже проставленими категоріями — це дає стартову точність, яку далі піднімають розмічуванням пограничних випадків.
Що дає розмічування на вході
Категорія й пріоритет проставляються в момент створення звернення, а не через 20-40 хвилин ручного розбору. Оператор отримує тікет уже з контекстом: тип збою, версія клієнта, чи це повторне звернення. Час до першої відповіді скорочується, а черга перестає забиватися однотипними запитами.
Точність та її межі
Точність класифікації вимірюється на відкладеній вибірці та по кожному класу окремо — загальна цифра приховує провали на рідкісних категоріях.
Окремо рахуємо частку авторозбору (скільки тікетів іде без правки оператора) та класи пропущених збоїв: критичний баг, помилково віднесений до «питання», дорожчий за десять неточно розмічених косметичних.
Поріг упевненості налаштовується так, щоб спірні випадки йшли до людини, а не в автоматичну маршрутизацію.
Маршрутизація та пріоритизація
Пріоритизація звернень спирається не лише на текст, а й на сигнали: частка зачеплених користувачів, повторюваність, платіжний або авторизаційний контекст. Тікет з ознаками масового збою піднімається вище за одиничну скаргу незалежно від формулювання.
Маршрутизація тікетів розкладає потік за командами — платежі, авторизація, інтерфейс, інфраструктура — і знімає ручне сортування з першої лінії.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Правила та ключові слова | Малий потік, стабільні формулювання | Ламається на перефразуваннях, потребує ручної підтримки |
| Готова модель без донавчання | Швидкий старт, загальні категорії | Слабо знає продукт, низька точність на рідкісних класах |
| Донавчання на своїх тікетах | Є історія звернень і розмічування | Потрібен контроль якості розмічування та перенавчання |
| Гібрид: правила + модель | Критичні класи потребують жорстких гарантій | Складніше супроводжувати, потрібна прозора логіка спрацьовувань |
Практика показує: гібридна схема дає найкращий баланс — правила жорстко ловлять критичні збої, модель закриває решту потоку.
Ми спираємося на scikit-learn для базових моделей і донавчання на розміченій історії замовника, коли обсягу даних достатньо для стійких метрик по кожному класу.
Етапи впровадження AI-класифікації в підтримку застосунку
Впровадження AI-класифікації починається не з моделі, а з потоку звернень: поки не видно, як надходять тікети, куди вони потрапляють і хто їх закриває, будь-яка автоматизація діє навмання. Тому перший крок — інженерний розбір, а не налаштування алгоритмів.
- Аудит звернень. Вивантажуємо історію тікетів за репрезентативний період, дивимося канали надходження, частку дублів, час до першої відповіді та до закриття. На виході — карта реальних категорій, а не тих, що перелічені в регламенті підтримки.
- Налаштування правил розмітки. Формуємо таксономію: які теми виділяємо, що вважаємо пограничним випадком, як позначаємо скарги на оплату та збої входу. Правила фіксуємо письмово — інакше розмітники розходяться в трактуванні й модель навчається на суперечностях.
- Розмітка навчальної вибірки. Розмічаємо корпус звернень за затвердженою схемою, окремо позначаємо рідкісні, але критичні класи. Дисбаланс категорій компенсуємо на етапі підготовки даних, а не після навчання.
- Навчання та перевірка якості моделі. Рахуємо точність і повноту за кожним класом окремо, а не лише загальну метрику: помилка на рідкісному класі дорожча, ніж на масовому. Дивимося матрицю помилок — де модель плутає сусідні теми й чому.
- Пілот на живому потоці. Модель працює в режимі підказки: пропонує категорію, оператор підтверджує або виправляє. Розходження збираємо й донавчаємо — так якість зростає на реальних даних, без ризику для клієнтів.
- Увімкнення маршрутизації. Після стабільної якості підключаємо автоматичний розподіл: тікет іде профільному спеціалісту, критичні класи — поза чергою. Поріг упевненості налаштовуємо так, щоб спірні випадки йшли до людини.
- Передача системи підтримки. Віддаємо налаштовану схему категорій, правила розмітки, регламент донавчання та порядок відкату до ручного сортування. Команда замовника веде систему сама, ми залишаємося на підтримці змін.
Ключовий ефект — не «модель угадує тему», а передбачувана маршрутизація: частка тікетів, що потрапили до потрібного спеціаліста з першого разу, зростає, а час до першої відповіді перестає залежати від завантаження першої лінії. Опишіть ваш потік звернень — повернемося з оцінкою та планом за цими етапами.
Чим відрізняється розмітка за правилами від навчальної моделі?
Розмітка за правилами — це детермінований фільтр: набір умов за ключовими словами, полями форми та джерелом звернення. Інженер заздалегідь описує, що вважати «оплатою», «доставкою» або «збоєм входу», і звернення потрапляє в категорію строго за збігом.
Працює передбачувано й пояснювано: видно, яка саме умова спрацювала, а поведінка не змінюється від обсягу даних. Слабке місце — формулювання.
Користувач пише «не приходить код», «завис на екрані оплати», «гроші списалися, а замовлення не оформилося» — жодне правило не покриває все різноманіття живої мови, і частка нерозібраних звернень зростає разом із продуктом.
Навчальна класифікація вирішує це інакше: модель дивиться на історію вже розібраних звернень і виводить категорію за змістом, а не за збігом рядків. Вона стійка до одруків, синонімів і змішаних мов, але потребує даних — кількох тисяч коректно розмічених тікетів на старті.
Ключовий параметр тут — поріг упевненості: якщо модель упевнена вище порога, тікет іде в категорію автоматично; якщо нижче — залишається людині. Поріг напряму керує балансом: нижче — більше автоматизації та ризик помилкової маршрутизації, вище — точніше, але більше ручної роботи.
Вибір підходу — не «або-або», а питання зрілості потоку. Жорсткі правила добре закривають усталені, рідкісні та юридично чутливі випадки, де помилка дорога: скарги на безпеку, запити на повернення, звернення щодо персональних даних.
Навчальна модель бере на себе масовий, швидко змінний потік — там, де правила доводиться переписувати щотижня. На практиці їх поєднують: правила відсікають критичні та однозначні випадки, модель розбирає решту.
Донавчання на нових зверненнях — те, що утримує якість із часом. З'являються нові формулювання, змінюється продукт, і модель, навчена на старих даних, починає помилятися.
Регулярне донавчання на свіжих розмічених тікетах повертає точність; важливо лише не «затопити» модель рідкісними класами й тримати окремий набір для перевірки, щоб бачити реальний приріст, а не підгонку під останню партію.
Практичний критерій вибору простий. Якщо категорій небагато, формулювання стабільні та потік передбачуваний — починайте з правил, це швидше й прозоріше.
Якщо звернень багато, мова жива, а ручне сортування з'їдає час команди — рахуйте обсяг розмічених даних і переходьте до навчальної моделі з налаштовуваним порогом упевненості.
Кейс: як підтримка застосунку перейшла на авторозмітку звернень
До впровадження авторозмітки підтримка мобільного застосунку працювала в режимі ручного розбору: кожне звернення оператор читав повністю, вручну вибирав категорію та призначав виконавця.
За потоку в кілька сотень звернень на добу черга зростала швидше, ніж її встигали розбирати, а частина повідомлень про падіння та зависання осідала в загальній масі й доходила до інженерів із затримкою.
Ми підключили модель класифікації на вході в систему підтримки: звернення автоматично розмічається за типом (збій, оплата, авторизація, питання щодо функцій), за платформою та за критичністю, після чого одразу надходить потрібній команді.
Модель навчена на історичних зверненнях замовника, тому розмітка враховує реальну термінологію продукту, а не загальні категорії.
Що змінилося в метриках
Частка автоматично розібраних звернень зросла з 41% до 87% — оператори переключилися на складні випадки, де потрібна людина. Час до першої відповіді скоротився з 6 годин до 40 хвилин: типові звернення отримують відповідь без очікування в загальній черзі.
Окремий ефект — зниження пропусків критичних збоїв. Раніше повідомлення про падіння на конкретній версії могло загубитися серед питань «як оплатити». Тепер такі звернення позначаються як критичні та піднімаються на початок черги автоматично. Кількість пропущених збоїв, що доходили до інженерів із затримкою понад добу, скоротилася в рази.
Як це влаштовано
Класифікатор працює як окремий сервіс перед системою підтримки: звернення проходить через нього, отримує мітку та маршрут, а вихідний текст і передбачення зберігаються для подальшого донавчання.
Якщо впевненість моделі нижча за поріг, звернення надходить оператору без мітки — це захищає від невірної маршрутизації. Раз на кілька тижнів модель донавчається на нових розмічених зверненнях, тому точність не падає при зміні продукту.
FastText
Сумісність, міграція та відкат: що обговорити до старту
Перед стартом замовник зазвичай ставить три питання: чи не зламає AI-класифікація поточну підтримку, що робити з накопиченою історією звернень і як відкотитися, якщо якість розмітки виявиться нижчою за очікувану. Відповідаємо на кожне.
Сумісність з поточною підтримкою. Класифікатор вбудовується як окремий сервіс перед наявною чергою: тікет надходить із застосунку, отримує категорію та пріоритет, далі йде за тими самими правилами маршрутизації, що й раніше.
Якщо сервіс недоступний, спрацьовує резервний шлях — звернення потрапляє до загальної черги без мітки, і оператор розбирає його вручну. Підтримка не зупиняється ні на хвилину.
Міграція історії звернень. Минулі тікети проганяються через модель пакетно, в окремому контурі, без запису до робочої бази. Результат — розмічений архів, на якому видно реальний розподіл категорій і частку спірних випадків. Це ж слугує матеріалом для донавчання на вашій термінології.
План відкату. Конфігурація маршрутизації версіонується: повернення до попередньої логіки — перемикання профілю, а не переписування коду. Мітки, проставлені моделлю, зберігаються окремим полем і не затирають вихідні дані оператора.
Що якщо якість розмітки на старті виявиться нижчою за очікувану?
Запускаємо в тіньовому режимі: модель розмічає вхідний потік, але рішення ухвалює оператор. Порівнюємо мітку моделі з фактичною категорією, рахуємо частку розбіжностей за кожною категорією і донавчаємо на цих прикладах.
У продуктив переводимо лише ті категорії, де точність стабільна, решта залишаються на ручній розмітці.
Доступи та права. Модель працює з текстом звернення та метаданими, але не з платіжними даними й персональними відомостями — вони маскуються на вході. Доступ до сервісу видається за сервісним обліковим записом з обмеженим набором прав, дії логуються.
На руки замовник отримує:
- конфігурацію сервісу класифікації та правила маршрутизації за категоріями;
- схему інтеграції з поточною системою підтримки та опис резервного шляху;
- скрипти пакетної розмітки архіву звернень;
- регламент донавчання на нових даних і порядок поповнення вибірки;
- інструкцію з відкату та перемикання профілів маршрутизації;
- звіт щодо якості розмітки з розбивкою за категоріями та часткою спірних випадків;
- опис прав доступу та політики маскування чутливих полів.
Опишіть вашу поточну підтримку та обсяг історії звернень — повернемося з оцінкою та планом впровадження.
