Три решения, которые определяют, будет ли L1-бот работать или станет источником жалоб: где проходит граница бота (чеклист из 10 пунктов), как выглядит SLA-матрица по приоритетам P1–P4, и что считать успехом на день 30 и день 90. Containment rate без CSAT — ложный ориентир. Эскалация без handoff-пакета — системная потеря. Запуск без AI-ready KB — гарантированные галлюцинации. Три решения до запуска Большинство проектов по ИИ-поддержке начинаются с выбора платформы или модели. Это неправильный порядок. Технология вторична — сначала нужно зафиксировать три операционных решения, которые определяют архитектуру всего остального. Решение 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 не готова к запуску бота