Кейс Сервис: −28% TTR, −32% просрочек SLA, NPS +12

Федеральная сервисная сеть (электро- и бытовая техника), 12 региональных хабов, ~120 агентов поддержки (омниканал: телефон, почта, чат, мессенджеры). За 8 недель внедрили Support-агента с RAG-базой знаний, приоритизацией по SLA и графом причин инцидентов. Итог: −28% к TTR (Time-to-Resolve), −32% к просрочкам SLA, −17% к повторным тикетам, NPS +12. Все данные агрегированы/обезличены (соответствие 152-ФЗ).

1) Клиент и исходная ситуация

Профиль. Сеть сервисных центров и курьерской логистики; helpdesk + полевой сервис. Боли. Долгие «раскачки» по тикетам, разрозненная база знаний, много «повторов» из-за неполных ответов, слабый контроль SLA по приоритетам P1/P2. Базовые метрики (4 недели до пилота).

• TTR (медиана): 19.6 ч.
• Просрочки SLA (P1–P3): 6.0% тикетов.
• Повторные тикеты (30-дневный лаг): 22.0%.
• NPS (после решения): 31.

Цель пилота (8 недель). Ускорить решения и снизить просрочки/повторы без наращивания штата; улучшить клиентский опыт.

2) KPI и дизайн эксперимента

• TTR (медиана/квантили) — время от создания до закрытия.
• SLA-бричи (P1–P3) — доля тикетов с нарушением целевых сроков.
• Repeat-rate (30d) — доля повторов по тому же клиенту/проблеме.
• NPS после решения — eNPS/CSAT при необходимости.
• Экономика: стоимость/тикет, цена запроса к LLM (учёт cached input).

A/B-дизайн. Очереди разбиты на A (контроль) и B (с агентом); выравниваем по каналам и времени суток; отчёт — еженедельно.

3) Решение: Support-агент + RAG + граф причин

• RAG-база знаний. Регламенты, ответы, чек-листы и записи «кейсов» → векторный индекс (Qdrant) + гибридный поиск BM25+dense + rerank. Обязательные цитаты/версии в ответах.
• Приоритезация по SLA/влиянию. Маршрутизация P1/P2, автоназначение исполнителей, дедлайны, напоминания, эскалации.
• Граф причин инцидентов. Neo4j: Process/Policy/Risk/Service/Part → «дерево решений» и повторяемые корневые причины (RCA).
• Авто-черновики ответов. Генерация шаблонов писем/сообщений с «чек-листом» действий и ссылками на источники.
• Интеграции. Helpdesk (API/webhooks), телефония, почта, мессенджеры, CMMS/склады (наличие запчастей), Telegram-уведомления.

Поток (Mermaid)

4) Пилот: план на 8 недель

• Недели 1–2: аудит очередей/политик, сбор KB, инжест и версии; настройка вебхуков/idempotency, карта причин (RCA).
• Неделя 3: auto-draft ответов с цитатами, приоритезация и напоминания, закрытое тестирование.
• Неделя 4: A/B на 25–30% трафика; сбор обратной связи.
• Недели 5–6: тюнинг ретрива/шаблонов, подключение складов/CMMS (запчасти), автоматический чек-лист.
• Недели 7–8: масштаб 50–60% трафика, контроль стабильности SLA, финзамер и ROI.

5) Результаты (8 недель)

Контрольная группа A показывала колебания в пределах сезонной нормы; статистическая значимость достигнута по TTR/SLA/Repeat (p<0.05).

6) Экономика и ROI (оценка на 8 недель)

Вводные. ~50 000 тикетов/мес; 8 недель ≈ 100 000 тикетов. Ставка агента — 1 100 ₽/ч. Экономия труда (AHT). 1.5 мин × 100 000 / 60 × 1 100 ₽ ≈ 2 750 000 ₽. Меньше повторов. Δповторов ≈ 3.7 п.п. → 3 700 тикетов × (6.0/60×1 100 ₽) ≈ 407 000 ₽. Меньше штрафов за SLA. Δбричей ≈ 1.9 п.п. → 1 900 тикетов × 700 ₽ ≈ 1 330 000 ₽. Итого эффект: ≈ 4.49 млн ₽. Стоимость пилота: интеграции/инфра/LLM/обучение — ≈ 900 000 ₽. ROI: (4.49 − 0.90) / 0.90 ≈ ≈ 3.99× (~399%). Окупаемость: ~2.5 недели.

Примечание: оценки консервативные, без учёта эффекта от NPS/retention и снижения нагрузки на 2-ю линию.

7) Что сработало лучше всего

• Шаблоны и цитаты → меньше уточнений и спорных «толкований» в переписке.
• SLA-приоритезация и напоминания → падение просрочек P1–P3.
• RCA-граф → быстрее находим корневые причины и единые фикс-гайды для повторяющихся проблем.
• Гибридный поиск + rerank → лучше качество контекста и стабильные ответы.

8) Ограничения и уроки

• В мессенджерах приходят «шумные» сообщения → добавили нормализацию и авто-классификацию намерений.
• Для узких экспертных тем оставили «ручную» эскалацию на экспертов (вместо автогенерации).
• Провели ревизию статей KB: без версий/владельцев качество снижалось.

9) Масштабирование

1. Расширяем на все очереди/каналы, сохраняем A/B-хвост 10–20%.
2. Добавляем self-service (портал/чат-бот) с тем же RAG-ядром и KB.
3. Внедряем Quality Review ответов (выборочно) и «долю ответов с цитатами» как метрику.
4. Делаем дашборд руководителя: TTR/SLA/Repeat/NPS/AHT по сегментам/каналам.

10) Комплаенс (152-ФЗ)

• Индексы/логи в RU-инфраструктуре; обезличивание ПДн на ingest/логах; доступы по RBAC/ACL.
• Внешние LLM-вызовы проходят через шлюз с маскированием и кэшем; запрещены «сырые» ПДн в промптах.
• Журналы доступа и версии KB/шаблонов; политика трансграничной передачи — «по умолчанию: запрет».

FAQ (коротко)

Можно ли начать без больших доработок helpdesk? Да, через webhooks/API или fallback-polling. Что делать с «редкими» проблемами? Эскалировать; накапливать KB-статьи с источниками и версиями. Как повышаете NPS? Полные, однозначные ответы (чек-лист) + меньше просрочек и повторов; быстрые подтверждения по SLA.

Связанные материалы

• Методология: AI-аудит процессов + RAG + ROI
• Техника: RAG на реальных документах SMB
• Интеграции: Интеграция чат-ботов с SberCRM: схема и типовые сценарии
• Право: 152-ФЗ и AI: локализация и обезличивание

Примечание о данных

Все цифры кейса — агрегированы и анонимизированы; персональные данные клиентов/сотрудников не использовались в моделях. Методики измерений/расчётов доступны по запросу.