Перевірка якості відповідей підтримки

AI-агент виконує роботу QA-інженера підтримки: щоранку забирає закриті за добу діалоги, перевіряє кожну відповідь за фіксованою рубрикою та збирає звіт для тімліда.

Завдання автоматизації — закрити розрив між декларованими стандартами підтримки та тим, що реально надходить клієнтам.

Покроковий процес

1. Вивантаження зі служби підтримки закритих за останні 24 години діалогів — мінімум 10% від денного обсягу, стратифікована вибірка за агентами та категоріями звернень.
2. Прогін кожного діалогу через QA-рубрику: точність вирішення, тон спілкування, дотримання скриптів, дотримання SLA, коректність тегів класифікації, повнота відповіді.
3. Оцінка за кожним критерієм за шкалою та загальний бал діалогу з цитатою-обґрунтуванням із тексту відповіді.
4. Збірка щоденного звіту: еталонні відповіді, відповіді з відхиленнями, загальні тренди за агентами та категоріями за минулий тиждень.
5. Надсилання звіту тімліду у Slack або на пошту з прямими посиланнями на кожен тикет у службі підтримки для швидкого розбору.
6. Повторення циклу кожного робочого дня без пропусків і без «забули цього понеділка».

Рубрика QA — що перевіряється

• Точність: чи вирішує відповідь проблему клієнта по суті.
• Тон: чи відповідає заявленому тону голосу бренду.
• Скрипти: чи використані затверджені формулювання для типових ситуацій.
• SLA: чи вклався агент у нормативи за часом першої відповіді та закриття тикету.
• Теги: чи коректно проставлені категорії звернення для подальшої аналітики.
• Повнота: чи закрите питання без хвостів та неявних припущень.

Що автоматизація НЕ робить

• Не замінює живого розбору. AI-агент підсвічує відповіді, що вибиваються з рубрики; остаточний висновок — чому і що з цим робити — залишається за тімлідом.
• Не навчає агентів у реальному часі. Звіт показує, що зламалось за минулу добу; коучинг, апдейт скриптів та 1:1 — робота керівника, не скрипту.
• Не редагує відповіді. Перевірка йде за вже надісланими діалогами, у момент переписки з клієнтом автоматизація не втручається.

Архітектура побудована як custom-code сценарій з LLM-evaluator і прямою інтеграцією в API служби підтримки. Центральний компонент — evaluator, який отримує на вхід текст діалогу та YAML-опис рубрики, а на виході віддає структурований JSON з оцінками та цитатами-обґрунтуваннями по кожному критерію.

Технічний потік

Скрипт запускається за розкладом, витягує дані зі служби підтримки, пропускає через LLM з фіксованим промптом рубрики і записує результат до звітної бази. Модель дає не лише бал, а й цитату з діалогу, що обґрунтовує оцінку, — щоб тимлід не розбирався в питанні «чому AI так вирішив».

Компоненти рішення

Кроки впровадження

1. Фіксація рубрики. Команда Grow2.ai разом з тимлідом підтримки формалізує чинні критерії якості у вигляді YAML: по кожному пункту формулюється питання та шкала. Без цього кроку автоматизація не має сенсу: модель перевіряє те, що записано, а не те, що «всі в голові знають».
2. Підключення до служби підтримки. Створюється сервісний токен з правами лише для читання на закриті діалоги за вибраний період. Інтеграція працює з будь-якою службою підтримки, що має API для вивантаження розмов.
3. Калібрування evaluator. На історичній вибірці діалогів запускається evaluator, результати звіряються з ручними оцінками тимліда. Розбіжності розбираються, рубрика та промпт уточнюються. Мета — узгодженість оцінок моделі та тимліда у більшості випадків.
4. Налаштування вибірки. Sampler бере 10% від денного обсягу та стратифікує: мінімум один діалог на активного агента на тиждень і мінімум один діалог на кожну основну категорію звернень.
5. Формат звіту. Тимлід з командою Grow2.ai погоджують структуру щоденного листа — що виноситься в топ, які метрики у зведенні, які графіки за 7 і 30 днів.
6. Запуск у пілот. Два тижні evaluator працює паралельно з ручним аудитом: це дає можливість ловити розбіжності та допрацьовувати рубрику без ризику для продакшну.
7. Перехід у продакшн. Ручний аудит залишається лише для граничних випадків та ескалацій, рутинна перевірка переходить на автоматизацію.

Як модель дає обґрунтовану оцінку

Промпт evaluator-а структурований явно: спочатку модель читає рубрику та діалог, потім за кожним критерієм виділяє конкретну цитату з відповіді агента, і лише після цього виставляє бал. Така схема з цитатами-обґрунтуваннями знижує вірогідність галюцинацій і робить оцінку перевіряємою — тимлід бачить, на підставі чого модель прийняла рішення, і може швидко погодитися або оскаржити висновок.

Для впровадження потрібна мінімальна, але конкретна інфраструктура та готовність команди.

Доступи та дані

• API служби підтримки з правами на читання закритих діалогів — Zendesk, Intercom, Freshdesk, HelpScout, Front або будь-яка система з conversations endpoint.
• Історія закритих діалогів за останній місяць в обсязі, достатньому для калібрування (кілька сотень записів).
• Поточні критерії якості в будь-якому вигляді: google-doc, notion-сторінка або усна домовленість тимліда. Формалізацію в YAML візьме на себе команда впровадження.
• Канал для доставки звіту: Slack workspace з правом створити бот-інтеграцію або робоча пошта тимліда.

Готовність команди

• Тимлід підтримки готовий виділити 4–6 годин на першому тижні для фіксації рубрики та 2–3 години на тиждень протягом першого місяця на калібрування.
• Керівник підтримки погоджується, що автоматизація знімає рутину відбору та оцінки, але не замінює ручний розбір складних кейсів.
• Агенти попереджені про перехід на регулярний QA і розуміють, що перевіряються вже закриті діалоги, а не робота в реальному часі.

Терміни

Повна імплементація займає 2–4 тижні:

1. Тиждень 1: фіксація рубрики, підключення до служби підтримки, перший прогін на історичних даних.
2. Тиждень 2: калібрування evaluator, узгодження формату звіту.
3. Тижні 3–4: пілот у паралельному режимі з ручним аудитом та перехід у продакшн.

Після запуску автоматизація працює без втручання; команда Grow2.ai залишається на підтримці рубрики та промптів.