Відділ обслуговування клієнтів інтернет-магазину отримує 200 рекламацій на тиждень. Тридцять відсотків — це повторювані справи: пошкоджений товар під час доставки, помилка у рахунку-фактурі, відсутня позиція в посилці. Консультант відповідає на них майже однаково щотижня, місяцями. Ще 40% потребують перевірки одного факту в системі складу або ERP, а потім — стандартної відповіді. Решта — складні справи: правові суперечки, клієнти після кількох невдалих спроб, звернення з чутливими даними.
AI добре справляється з першими двома групами. З третьою не повинен працювати самостійно.
Чотири рівні тріажу: що AI робить перед першою відповіддю#
Перш ніж будь-яка рекламація потрапить до черги консультанта або генератора відповідей, добре спроєктована система пропускає її через чотири етапи.
Етап 1: класифікація типу рекламації. Багатомітковий класифікатор визначає одночасно категорію (пошкодження товару, помилка розрахунку, затримка доставки, невідповідність опису, гарантійна рекламація), канал (електронна пошта, форма, чат, телефон STT) та мову. При 500 або більше прикладах для навчання на категорію точність 85-92% є досяжною. При менш ніж 200 прикладах краще працюють базові моделі з few-shot prompting, ніж fine-tuning.
Етап 2: виявлення терміновості та сентименту. Терміновість — це окремий вимір, асиметричний за вартістю. Пропуск термінової справи (клієнт втратив доступ до послуги, справа потрапила до медіації) коштує набагато дорожче, ніж хибна тривога ескалації. Тому класифікатор терміновості працює з чіткою асиметрією: краще хибна тривога, ніж пропуск. Дуже негативний сентимент (багаторазові слова на кшталт «скандал», «беззаконня», «позов») запускає ескалацію до консультанта незалежно від категорії.
Етап 3: вилучення фактів з тексту. Structured output з валідацією схеми виокремлює номер замовлення, дату покупки, суму, опис проблеми та додані докази (фото, PDF чека). Вилучені факти одразу доступні для генератора відповідей та консультанта без ручного переписування з тексту електронного листа.
Етап 4: верифікація в зовнішніх системах. Агент запитує ERP або систему складу: чи існує замовлення, який був статус доставки, чи діє гарантія. Відповідь повертається як факти, а не як готове рішення. Модель знає, що замовлення було доставлено вчасно. Чи означає це, що рекламація безпідставна? Це оцінка для людини.
Таблиця: тип рекламації, роль AI, обов’язковий human-gate, рівень ризику#
| Тип рекламації | Роль AI | Обов’язковий human-gate | Рівень ризику |
|---|---|---|---|
| Пошкоджений товар (стандартний) | Класифікація, проєкт відповіді з шаблону RAG | Консультант затверджує проєкт перед відправкою | Низький |
| Помилка у рахунку-фактурі | Класифікація, вилучення суми та номера, проєкт корекції | Бухгалтерія затверджує корекцію | Середній |
| Затримка доставки | Перевірка статусу в системі, проєкт відповіді з фактами | Консультант верифікує факти перед відправкою | Низький |
| Відмова у рекламації | Проєкт обґрунтування з цитуванням регламенту (RAG) | Людина приймає рішення про відмову, а не AI | Високий |
| Компенсація або бонус | Проєкт пропозиції на основі політики компанії | Людина погоджує суму та форму, підписується під рішенням | Високий |
| Дуже негативний сентимент або правовий аспект | Виявлення, пріоритет ескалації, збір контексту | Виключно людина, AI не генерує відповіді | Дуже високий |
| Звернення з чутливими даними (GDPR) | Виявлення PII, маскування перед хмарною моделлю, ескалація | Людина вирішує кожен крок | Дуже високий |
Як RAG створює проєкт відповіді#
Коли класифікатор визначив, що справа підходить для автоматичного проєкту, система запитує базу знань через RAG. База містить затверджені шаблони відповідей, регламенти, гарантійну політику та процедури повернення. Модель не вигадує зміст: вона поєднує факти, вилучені з рекламації, з фрагментами, знайденими в базі.
Умова коректної роботи: база знань має бути актуальною та охоплювати всі категорії рекламацій. Якщо компанія змінила політику повернення, а база не оновлена, модель згенерує проєкт на основі застарілої процедури. Тому оновлення бази знань — це не одноразовий проєкт, а постійний операційний обов’язок. Стаття про оновлення знань RAG розглядає патерни інкрементальної реіндексації.
Проєкт відповіді потрапляє до консультанта як готовий текст для затвердження або редагування, а не як відправлене повідомлення. Консультант бачить: категорію рекламації, вилучені факти, фрагмент регламенту, який використано як джерело, та пропозицію тексту. Може прийняти одним кліком або відредагувати та відправити. Час обробки скорочується, якість зростає, відповідальність залишається за людиною.
SLA-трекінг та observability: як знати, що система працює#
Observability системи рекламацій починається з чотирьох метрик, які вимірюються з першого дня пілоту.
Час до першої відповіді. Час від надходження рекламації до відправлення першої відповіді (через AI або консультанта, який затверджує проєкт AI). Ціль для стандартних справ: менше 2 годин у робочий час. Стаття про моніторинг якості агента AI описує детальні патерни збору цих метрик.
Показник затвердження проєктів без змін. Відсоток проєктів відповідей, які консультант прийняв без змін. При добре відкаліброваній базі знань та вузькому діапазоні категорій цей показник досягає 60-75% для стандартних справ. Якщо падає нижче 40%, базу потрібно доповнити або діапазон категорій, які обробляє AI, є надто широким.
Escalation rate та re-classification rate. Відсоток справ, перенаправлених до вищої черги після першого маршрутизації. Високий escalation rate (понад 15%) сигналізує про помилкову класифікацію терміновості. Re-classification rate понад 20% для однієї категорії — сигнал для перегляду навчальних міток або розділення категорії, як це обговорюється в статті про класифікацію та маршрутизацію звернень.
SLA compliance за категоріями. Чи закриваються справи з певної категорії у заявлений термін? Система має позначати справи, які наближаються до межі SLA, та автоматично підвищувати їх пріоритет до закінчення терміну.
Межі автоматизації: де AI не застосовується#
Деякі категорії залишаються поза межами автоматичної обробки незалежно від точності класифікатора.
Відмови у рекламаціях. Клієнт, який отримує відмову від автоматичної системи, має гірше враження, ніж клієнт, який отримує відмову від людини з обґрунтуванням. Проєкт відмови може підготувати AI (з цитатою з регламенту), але рішення приймає та підписує консультант. Це також вимога AI Act для систем, що впливають на права споживачів.
Компенсації та бонуси на суму вище встановленого порогу. Компанія має визначити грошовий поріг, вище якого кожне фінансове рішення потребує затвердження людиною. Нижче порогу система може автоматично генерувати бонус на знижку згідно з таблицею політики, завжди з можливістю аудиту.
Рекламації з чутливими даними. Звернення, в якому клієнт описує проблему зі здоров’ям через використання продукту або містить фінансові дані, потребує маскування PII перед будь-якою обробкою хмарною моделлю. Якщо система не self-hosted, чутливі дані не повинні залишати локальну інфраструктуру.
Справи після багатьох контактів. Клієнт, який пише втретє з тієї ж справи, вже розчарований. Система має автоматично ескалувати такі звернення до старшого спеціаліста або до виділеної черги ретенції, а не надсилати черговий проєкт відповіді з шаблону.
Патерн пілоту: shadow mode протягом 4 тижнів#
Безпечне впровадження починається з режиму shadow. Протягом перших 4-6 тижнів класифікатор та генератор проєктів працюють паралельно з існуючим процесом: класифікують, вилучають факти та готують проєкти, але консультанти обробляють справи самостійно та бачать результати AI поряд зі своїми рішеннями.
Порівняння рішень AI з рішеннями консультантів формує ground truth: де модель помиляється з категоріями, де проєкти прийнятні без змін, де сентимент виявляється правильно. Через 4 тижні у вас є дані, щоб безпечно увімкнути автоматизацію для вибраних категорій низького ризику.
Стаття про сервісні компанії та AI та про обов’язки компаній згідно з AI Act та GDPR розглядає вимоги до документації, які варто підготувати перед запуском системи на даних клієнтів.
Ми в Cashcrown будуємо такі системи як дослідницький центр: кожен компонент (класифікатор, генератор проєктів, human-gate, observability) вимірюється окремо перед інтеграцією. Немає єдиного правильного порогу терміновості чи готової таксономії рекламацій. Калібрування під конкретну галузь та історичні дані клієнта — це те, що визначає результат.
FAQ#
Чи може AI самостійно приймати рішення про прийняття або відхилення рекламацій?#
Не повинен. Змістовне рішення щодо рекламації має юридичні та реляційні наслідки: помилкова відмова може наразити компанію на розгляд у Держпродспоживслужбі або втрату клієнта. AI може підготувати проєкт обґрунтування з цитатою з регламенту, але остаточне рішення приймає та підписує людина. Діючий з 2026 року AI Act прямо встановлює цю вимогу для систем, що впливають на права споживачів, а обробка рекламацій належить саме до цієї категорії.
Як захистити персональні дані клієнтів у системі обробки рекламацій?#
Рекламації часто містять персональні дані: ім’я, адресу, номер замовлення, іноді медичні або фінансові дані. Перед відправкою тексту до хмарної моделі ці дані мають бути замасковані локально системою маскування PII. Якщо справа містить особливо чутливі дані, весь процес має працювати на self-hosted інфраструктурі або справа має оброблятися виключно людиною. Перед впровадженням варто провести DPIA, особливо якщо ви обслуговуєте чутливі галузі (охорона здоров’я, фінанси, діти).
Скільки триває впровадження такої системи?#
Пілот у режимі shadow з класифікатором на основі few-shot prompting можна запустити за 3-5 тижнів, якщо у вас є історичні дані рекламацій з мітками. Повне впровадження з інтеграцією до ERP або системи helpdesk, метриками SLA та процедурами ескалації займає 8-14 тижнів. Найбільше часу забирає збір та перевірка навчальних даних, калібрування порогів ескалації та навчання консультантів у новому робочому процесі, а не саме програмування.
Які метрики вимірювати, щоб оцінити ефективність системи?#
Чотири цифри говорять правду: час до першої відповіді (ціль: менше 2 годин для стандартних справ), показник затвердження проєктів без змін (ціль: 60-75% для вузьких категорій), escalation rate (сигнал про помилкову класифікацію терміновості, якщо понад 15%) та SLA compliance за категоріями (відсоток справ, закритих вчасно). Containment rate, тобто відсоток справ, закритих без участі людини, має сенс як метрика лише після щонайменше 8 тижнів стабільної роботи системи.
Що робити, якщо клієнт пише втретє з тієї ж справи?#
Клієнта з багаторазовими зверненнями в одній справі слід автоматично ескалувати до старшого спеціаліста або до виділеної черги ретенції, а не направляти знову до автоматичного генератора проєктів. Система має виявляти історію контактів (кількість звернень за останні 14 днів щодо того ж замовлення або теми) та розглядати це як сигнал пріоритетної ескалації незалежно від категорії та сентименту поточного звернення.