Проверка качества ответов поддержки

AI-агент выполняет работу QA-инженера поддержки: каждое утро забирает закрытые за сутки диалоги, проверяет каждый ответ по фиксированной рубрике и собирает отчёт для тимлида. Задача автоматизации — закрыть разрыв между декларируемыми стандартами поддержки и тем, что реально уходит клиентам.

Пошаговый процесс

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

Рубрика QA — что проверяется

• Точность: решает ли ответ проблему клиента по существу.
• Тон: соответствует ли заявленному tone of voice бренда.
• Скрипты: использованы ли утверждённые формулировки для типовых ситуаций.
• SLA: уложился ли агент в нормативы по времени первого ответа и закрытия тикета.
• Теги: корректно ли проставлены категории обращения для дальнейшей аналитики.
• Полнота: закрыт ли вопрос без хвостов и неявных допущений.

Что автоматизация НЕ делает

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

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

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

Скрипт запускается по расписанию, вытягивает данные из helpdesk, прогоняет через LLM с фиксированным промптом рубрики и записывает результат в отчётную базу. Модель даёт не только балл, но и цитату из диалога, обосновывающую оценку, — чтобы тимлид не разбирался в вопросе «почему AI так решил».

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

Шаги внедрения

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

Как модель даёт обоснованную оценку

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

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

Доступы и данные

• API helpdesk с правами на чтение закрытых диалогов — Zendesk, Intercom, Freshdesk, HelpScout, Front или любая система с conversations endpoint.
• История закрытых диалогов за последний месяц в объёме, достаточном для калибровки (несколько сотен записей).
• Текущие критерии качества в любом виде: google-док, notion-страница или устная договорённость тимлида. Формализацию в YAML возьмёт на себя команда внедрения.
• Канал для доставки отчёта: Slack workspace с правом создать бот-интеграцию или рабочая почта тимлида.

Готовность команды

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

Сроки

Полная имплементация занимает 2–4 недели:

1. Неделя 1: фиксация рубрики, подключение к helpdesk, первый прогон на исторических данных.
2. Неделя 2: калибровка evaluator, согласование формата отчёта.
3. Недели 3–4: пилот в параллельном режиме с ручным аудитом и переход в production.

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