Три решения до запуска
Большинство проектов по ИИ-поддержке начинаются с выбора платформы или модели. Это неправильный порядок. Технология вторична — сначала нужно зафиксировать три операционных решения, которые определяют архитектуру всего остального.
Решение 1: Где проходит граница бота — что он делает, а что никогда не делает.
Решение 2: Как выглядит SLA-матрица — разные временные окна для разных приоритетов и уровней.
Решение 3: Что считать успехом — метрики по фазам, а не единственная цифра containment rate.
Разберём каждое.
Решение 1: Граница бота — чеклист запрещённых зон
Граница бота — это не технический параметр, это операционная политика. Она должна быть зафиксирована в документе и доведена до команды до запуска.
Что бот НЕ делает — обязательный чеклист:
- Не обрабатывает персональные данные в диалоге. ФИО, паспортные данные, номера договоров, банковские реквизиты — бот не запрашивает и не хранит в контексте диалога. Требование 152-ФЗ, не рекомендация.
- Не выполняет финансовые операции. Возвраты, корректировки счетов, изменение тарифов — только через авторизованного оператора с подтверждением личности.
- Не принимает решения по инцидентам информационной безопасности. Подозрение на утечку данных, компрометацию учётной записи, несанкционированный доступ — немедленная эскалация без попытки диагностики.
- Не даёт юридических интерпретаций. Вопросы о договорных обязательствах, ответственности, штрафных санкциях — только к уполномоченному сотруднику.
- Не работает с VIP-клиентами без уведомления. Если CRM-интеграция идентифицирует клиента с флагом VIP или стратегический аккаунт — тихая эскалация менеджеру с первого сообщения.
- Не продолжает диалог при повторном обращении по той же проблеме. Если пользователь обращается второй раз по идентичной теме в течение 48 часов — это сигнал нерешённой проблемы, не новый тикет.
- Не отвечает при confidence level ниже порога. Если RAG-модель не нашла релевантной статьи или уверенность ответа ниже установленного порога (типично: 0.65–0.75) — эскалация, не попытка угадать.
- Не обсуждает внутренние политики и регламенты в открытом канале. Документы с грифом «для внутреннего использования» не попадают в KB бота.
- Не принимает жалобы на сотрудников компании. Эти обращения требуют конфиденциальности и фиксируются только через защищённый канал с HR или руководством.
- Не обещает сроки, которые не закреплены в SLA. Бот не говорит «мы решим это сегодня», если это не зафиксировано в матрице приоритетов.
Этот список — минимум. Каждая компания добавляет свои пункты исходя из отраслевой специфики.
Решение 2: SLA-матрица по приоритетам
Единственное время реакции для всех тикетов — антипаттерн. P1-инцидент (полная недоступность системы) и вопрос «как сбросить пароль» не могут иметь одинаковый SLA. Матрица ниже — рабочий шаблон, цифры калибруются под конкретный бизнес.
| Приоритет | Описание | Бот: первый ответ | Бот: решение / эскалация | L1-оператор: принятие | L2: решение | Триггер эскалации |
|---|---|---|---|---|---|---|
| P1 | Критический инцидент, система недоступна | 30 сек | Эскалация немедленно | 5 мин | 1 час | Автоматически, без попытки решить |
| P2 | Серьёзная деградация, бизнес-процесс нарушен | 1 мин | Эскалация ≤5 мин | 15 мин | 4 часа | Confidence <0.8 или тема вне KB |
| P3 | Частичная проблема, есть обходное решение | 2 мин | Решение ≤15 мин или эскалация | 1 час | 1 рабочий день | Confidence <0.7 или повторное обращение |
| P4 | Вопрос, запрос на информацию, FAQ | 2 мин | Решение ≤10 мин | 4 часа | 3 рабочих дня | Пользователь запросил человека |
Важно: приоритет определяется при классификации тикета — ботом автоматически или оператором вручную. Для P1 и P2 бот не пытается решить самостоятельно: его задача — мгновенно собрать контекст и передать с полным handoff-пакетом.
Тихая эскалация — отдельный механизм: бот ставит флаг в тикете и уведомляет дежурного менеджера, не прерывая диалог. Применяется при: приближении к SLA-дедлайну (>70% времени истекло), обнаружении VIP-клиента, sentiment score ниже -0.5, повторном обращении по той же проблеме.
Шаблон handoff-пакета при эскалации
Эскалация без контекста — это когда оператор L2 звонит клиенту и первым делом спрашивает: «Расскажите, в чём проблема?» Это разрушает доверие к системе поддержки быстрее, чем любой технический сбой.
Handoff-пакет — структурированный блок данных, который бот передаёт оператору в момент эскалации. Минимальный состав:
| Поле | Содержание | Пример |
|---|---|---|
| Transcript summary | Краткое изложение диалога (3–5 предложений) | «Пользователь сообщил о недоступности модуля отчётности с 09:15. Проверил статус сервиса — не помогло. Запросил перезапуск — не в компетенции бота.» |
| Detected intent | Классифицированная тема обращения | technical_outage / reporting_module |
| Sentiment score | Числовая оценка тональности (-1 до +1) | -0.6 (фрустрация) |
| Actions taken | Что бот уже сделал | «Предложил перезапуск кэша, проверил статус-страницу, создал тикет #4821» |
| Confidence level | Уверенность последнего ответа бота | 0.52 (ниже порога 0.70) |
| Escalation type | Причина передачи | functional / emotional / compliance |
| Recommended next step | Рекомендация для оператора | «Проверить логи сервера отчётности, эскалировать в DevOps при подтверждении» |
Escalation quality score — доля эскалаций, в которых handoff-пакет заполнен полностью. Целевое значение: >90%. Если ниже — проблема в конфигурации бота, не в операторах.
Антипаттерн: containment trap
Containment rate — процент диалогов, завершённых ботом без эскалации. По Gartner 2025, для RAG-бота норма: 55–65%. Это полезная метрика, но она становится ловушкой, если оптимизировать её в отрыве от CSAT.
Симптомы containment trap:
- Containment rate растёт (бот «решает» всё больше тикетов)
- CSAT по ботовым диалогам падает или стагнирует
- Repeat contact rate растёт (пользователи возвращаются с той же проблемой)
- Количество жалоб на поддержку растёт
Механизм: бот блокирует путь к оператору — явно (нет кнопки «поговорить с человеком») или неявно (бесконечные уточняющие вопросы). Пользователь сдаётся и закрывает чат. Система фиксирует это как «решённый диалог». Containment растёт, проблема не решена.
Диагностика: сравните CSAT диалогов, завершённых ботом, с CSAT эскалированных диалогов. Если первый ниже второго более чем на 0.5 балла — система в ловушке. Дополнительный сигнал: KB coverage gap >25% (каждый четвёртый запрос бот не может покрыть).
Решение: добавить явную кнопку эскалации в каждый диалог, снизить порог confidence для автоэскалации, пересмотреть список запрещённых тем.
Решение 3: Метрики по фазам
Одна метрика на все случаи жизни — антипаттерн. Что важно в первые 30 дней, отличается от того, что важно через 90.
| Метрика | День 0–30 (baseline) | День 31–90 (оптимизация) | День 90+ (зрелость) | Целевое значение |
|---|---|---|---|---|
| Containment rate | Фиксируем baseline | Дельта к baseline | Стабилизация | 55–65% (RAG) |
| CSAT (бот) | Baseline | Тренд | Норма | >4.2 / 5 |
| FCR | Baseline | Рост | Норма | 70–80% |
| Escalation quality score | — | >80% | >90% | >90% |
| Repeat contact rate | Baseline | Снижение | <10% | <10% за 48 ч |
| KB coverage gap | Топ-10 пробелов | Закрытие пробелов | <15% | <15% |
| Fallback rate | Baseline | Снижение | <20% | <20% |
| SLA compliance (P1/P2) | Baseline | >90% | >95% | >95% |
| Time-to-escalation | Baseline | Оптимизация | Норма | Зависит от P-уровня |
День 0–30: не оптимизируйте — измеряйте. Главная задача — собрать baseline по всем метрикам и выявить топ-10 нераспознанных интентов. Это сырьё для следующей фазы.
День 31–90: закрываете пробелы в KB, калибруете пороги confidence, настраиваете триггеры тихой эскалации. Смотрите на дельту, не на абсолютные значения.
День 90+: система работает в штатном режиме. Добавляете метрики бизнес-эффекта: cost per resolution, экономия FTE, NPS по каналу поддержки.
Данные до запуска: чеклист AI-readiness
Запуск бота без готовой базы знаний — самая частая причина провала. Бот начинает галлюцинировать политики компании, потому что в KB противоречивые или устаревшие статьи.
Минимальные требования к KB:
- 80–120 статей, покрывающих топ-80% входящих запросов (проверяется по историческим данным тикетов)
- Каждая статья обновлялась не позднее 6 месяцев назад
- Нет статей с формулировками «уточните у менеджера» или «зависит от ситуации» без конкретизации
- Все статьи на русском языке (или на языке целевой аудитории) — не машинный перевод
- Есть процесс ревизии: ответственный за обновление и периодичность (Gartner: 61% компаний не имеют такого процесса)
- KB проиндексирована и протестирована на топ-20 реальных запросов из истории тикетов
Минимальные интеграции:
- Ticketing-система (HelpDeskEddy, Омнидеск, Битрикс24, Jira Service Management) — для создания и обновления тикетов
- CRM или справочник клиентов — для идентификации VIP и получения контекста аккаунта
- Логирование диалогов в периметре (см. ниже про 152-ФЗ)
RU-специфика: on-prem, 152-ФЗ и отечественные системы
Корпоративный сектор РФ имеет ограничения, которые не учитывают западные playbook'и.
152-ФЗ и хранение диалогов. Диалоги, содержащие персональные данные пользователей, должны храниться на серверах в РФ. Если используется внешний LLM-API (даже для генерации ответа), персданные должны быть обезличены до отправки запроса. Это не опционально — это требование закона. Практическое решение: обезличивание на уровне middleware перед вызовом API, или переход на on-prem / private cloud LLM.
On-prem и private LLM. Для компаний с высокими требованиями к безопасности (финансы, госсектор, промышленность) — развёртывание модели в собственном контуре. Это влияет на выбор архитектуры: вопросы выбора стека разобраны в статье «LLM в продакшене: чеклист без ML-отдела».
Совместимость с отечественными helpdesk. HelpDeskEddy и Омнидеск поддерживают API-интеграцию с внешними ботами. Битрикс24 имеет встроенный конструктор чат-ботов и открытые линии. 1С:ITIL — интеграция через REST API или через коннекторы. При выборе платформы проверяйте наличие webhook-поддержки для передачи handoff-пакета.
Эскалация — признак зрелости, не провала
Последний вопрос, который регулярно возникает при внедрении: «Если бот так часто эскалирует, зачем он вообще нужен?»
Ответ: бот нужен не для того, чтобы заменить всех операторов. Он нужен для того, чтобы операторы занимались сложными случаями, а не FAQ. Если бот корректно обрабатывает 60% входящих запросов и передаёт остальные с полным handoff-пакетом — это успех. Если он пытается обработать 90% и делает это плохо — это провал.
Зрелая система знает границы своей компетенции. Escalation quality score >90% — это показатель того, что система работает правильно. Containment rate 55% с CSAT 4.5 лучше, чем containment rate 75% с CSAT 3.2.
Объясните команде: каждая эскалация с полным handoff-пакетом — это данные для улучшения KB. Это не ошибка бота, это сигнал о пробеле в базе знаний. Система, которая честно говорит «я не знаю», надёжнее системы, которая уверенно галлюцинирует.
Смежные материалы в блоге:
- LLM в продакшене: чеклист без ML-отдела — архитектура и инфраструктура для тех, кто выбирает стек
- База знаний vs RAG: как устроить knowledge management — устройство KB, которая станет основой для L1-бота
Ключевые факты
- Containment rate RAG-бота: 55–65% по Gartner 2025 — но без контроля CSAT этот показатель становится ловушкой
- FCR для L1 в норме: 70–80% тикетов закрываются без эскалации — это ориентир для калибровки границ бота
- Эскалация без handoff-пакета: оператор L2 тратит 3–7 минут на повторный сбор контекста — это системная потеря, не единичная
- 152-ФЗ: диалоги с персданными не могут храниться в публичных LLM-API без обезличивания — это требование, а не рекомендация
- Repeat contact rate >15% в первые 30 дней — сигнал, что KB не готова к запуску бота
Частые вопросы
- Как объяснить команде, что эскалация — это не провал бота, а признак зрелой системы?
- Эскалация — это корректное срабатывание триггера, а не ошибка. Зрелая система знает, чего она не знает. Метрика качества — не 'сколько бот решил сам', а 'насколько полным был handoff-пакет при передаче'. Если escalation quality score >90%, система работает правильно вне зависимости от containment rate.
- Какой минимальный объём базы знаний нужен до запуска бота?
- Практический минимум: 80–120 статей, покрывающих топ-80% входящих запросов по историческим данным тикетов. Каждая статья должна иметь дату последнего обновления не старше 6 месяцев и однозначный ответ без отсылок к 'уточните у менеджера'.
- Что такое 'тихая эскалация' и когда она нужна?
- Тихая эскалация (silent escalation) — бот уведомляет менеджера или ставит флаг в тикете, не прерывая диалог с пользователем. Применяется при риске SLA-нарушения, при повторном обращении по той же проблеме, при обнаружении VIP-клиента или при негативном sentiment score ниже порога.
- Как хранить диалоги бота в соответствии с 152-ФЗ?
- Диалоги, содержащие персональные данные (ФИО, контакты, номера договоров), должны храниться на серверах в РФ. При использовании внешних LLM-API — обязательное обезличивание перед отправкой запроса. Оптимальное решение для корпоративного сектора — on-prem или private cloud LLM с логированием в периметре.
- Чем отличается функциональная эскалация от эмоциональной?
- Функциональная: бот не нашёл ответа в KB или confidence level ниже порога (например, <0.7). Эмоциональная: пользователь явно требует человека или sentiment score сигнализирует о фрустрации. Compliance-эскалация: тема запроса попадает в запрещённую зону (персданные, финансовые операции, инциденты ИБ). Каждый тип требует отдельного триггера и отдельной метрики.
Источники
- AI Workers for L1 Support: A Director's Practical Playbook
- AI-Powered Escalation Playbook for Customer Support Leaders
- 9 Steps to Automate Ticket Escalation Workflows Using AI
- AI Chatbot KPIs: 15 Metrics That Actually Matter in 2026
- AI Support SLA Management Guide 2026
- AI Guardrails: Complete Guide to LLM Safety & Chatbot Protection 2026
- Чат-бот ИИ для техподдержки: интеграция за 5 шагов
О brezatech
brezatech — интегратор ИИ в данные и процессы: разработка, BI и автоматизация для B2B. ИИ-агент продаж 24/7 →