Тестирование и запуск: ошибки, аналитика, модерация, безопасность
Запуск чат-бота — это не «нажать кнопку опубликовать», а переход в режим продукта: бот должен стабильно работать в реальном канале, измеряться, быть безопасным и управляемым. Сценарии, интеграции, вебхуки и платежи мы уже разобрали в прошлых статьях — здесь фокус на проверках перед релизом и на том, что нужно для устойчивой эксплуатации.
1) Тестирование: что проверять, чтобы не краснеть на запуске
1.1. Матрица тестов: минимум, который реально покрыть
Соберите тесты не «по сообщениям», а по рискам.
| Область | Что проверяем | Пример ошибки | Как заметить заранее |
|---|---|---|---|
| Сценарии | переходы, “Назад/Меню/Оператор”, повторный ввод | пользователь застрял на шаге | чек-лист по каждому узлу карты сценария |
| Валидации | формат телефона/даты/номера заказа | “приняли мусор” и ушли в API | набор негативных кейсов |
| Интеграции | таймауты, пустые ответы, недоступность | бот молчит или обещает то, чего нет | имитация сбоя (тестовая среда/заглушки) |
| Платежи | pending/failed/success + повторы вебхуков | двойное подтверждение | тестовые оплаты + идемпотентность по event_id |
| Эскалация | передача оператору + контекст | оператор не понимает, что случилось | проверка «пакета контекста» |
| Контент | тональность, юридические тексты, кнопки | жалобы, блокировки канала | ревью текста + требования каналов |
1.2. Тестовые сценарии: «позитив», «негатив», «края»
Позитивные: пользователь идёт идеальным путём и достигает успеха.
Негативные: ошибки формата, отсутствующие данные, отмена на середине.
Краевые: длинные сообщения, эмодзи/фото вместо текста, двойные клики по кнопке, тишина 30 минут, возврат в диалог через сутки.Практика: для каждого ключевого сценария подготовьте 10–20 тест-кейсов в виде таблицы: «шаг → ввод → ожидаемый ответ → ожидаемое состояние».
1.3. Регресс и контроль изменений
Даже маленькая правка текста может сломать ветку или аналитику.
Версионируйте сценарии (например, “v1.3”).
Держите короткий регресс-чек-лист: 5–10 критических путей (старт, основной сценарий, ошибка формата, оператор, оплата).
Обновления выкатывайте через тестовый канал/бота, а затем — в прод.2) Ошибки в проде: как сделать их управляемыми
Ошибки неизбежны: сеть, API, человеческий ввод, ограничения канала. Важно, чтобы ошибки были наблюдаемыми и обрабатываемыми.
Минимальный стандарт эксплуатации:
Единый идентификатор диалога (conversation_id) во всех логах и обращениях к операторам.
Классификация ошибок: пользовательская (ввод), внешняя (API), внутренняя (логика).
План деградации: что бот делает, если ключевой сервис недоступен (например, создать заявку «в очередь» или сразу эскалировать).
Алёрты: резкий рост ошибок интеграций, недоставок, провалов платежей.Визуально удобно фиксировать маршрутизацию инцидента:
3) Аналитика: что измерять, чтобы улучшать, а не спорить
Аналитика бота — это ответы на вопросы «где мы теряем пользователей?» и «какой сценарий окупается?». Метрики выбираются от цели (см. статью про задачи и метрики), а здесь — как организовать сбор.
3.1. События и воронки
Заложите события на уровне шагов сценария и результатов.
Показ стартового меню.
Выбор сценария (например, “Запись”, “Статус”).
Успешный ввод ключевого идентификатора (телефон/номер заказа).
Успешное действие (заявка создана, слот забронирован, статус показан).
Эскалация к оператору (с причиной).
Отказ/выход (таймаут, “не хочу”, “передумал”).Соберите простую воронку по каждому сценарию:
3.2. Причины эскалации — главный источник улучшений
Вместо «много ушло к оператору» фиксируйте почему:
Не прошла валидация.
Нет данных в системе.
Сбой интеграции.
Пользователь пишет “другое/нестандартное”.
Конфликт/жалоба.Это превращает поддержку в список конкретных задач: улучшить подсказки, добавить ветку, починить интеграцию, уточнить ограничения.
4) Модерация и соответствие правилам каналов
Под модерацией здесь — не только «антиспам», но и контроль контента и процесса общения.
Проверка текстов: обещания, сроки, формулировки про оплату/возвраты, корректность тональности.
Правила рассылок и шаблонов (особенно в строгих каналах): отправляйте только то, на что есть согласие и реальная ценность.
Контроль “опасных тем”: медицина/юридические советы, персональные данные — заранее определите стоп-темы и маршрутизацию.
Операторская модерация: роли, кто может писать от имени бота, кто видит данные, кто подтверждает спорные ответы.Практический приём: заведите «контент-политику бота» на 1 страницу: что можно, что нельзя, и как эскалировать.
5) Безопасность: минимум, без которого лучше не запускать
5.1. Данные и доступ
Сбор только необходимого (минимизация данных).
Разделение доступов: у бота — только нужные права в CRM/платежах.
Маскирование персональных данных в логах и выгрузках.
Хранение согласий пользователя на коммуникации и уведомления.5.2. Защита от злоупотреблений
Лимиты на частоту сообщений (rate limiting) и антифлуд.
Защита от «перебора» кодов/номеров (ограничение попыток + охлаждение).
Белые списки действий: бот не должен выполнять непредусмотренные операции по свободному тексту.5.3. Секреты и инфраструктура
Токены каналов и ключи API хранятся как секреты, а не в документах/чатах.
Логи доступа: кто менял настройки, кто запускал рассылки.
План отката: как быстро выключить проблемный сценарий или переключить на оператора.6) Чек-лист запуска (короткий, но практичный)
Пройден регресс-чек-лист по критическим путям.
Подключены логи + алёрты на ошибки и платежи.
Настроены события аналитики и воронка по ключевым сценариям.
Проверены тексты и правила канала (включая согласия).
Настроены роли операторов и пакет контекста при эскалации.
Есть план аварийного режима: “только меню + оператор”.---
Задания для закрепления
1) Составьте матрицу тестов для одного сценария (8–12 тестов): позитив, негатив, краевые случаи.
2) Опишите 6 событий аналитики для вашего бота и одну воронку (этапы → где возможен отвал).
3) Придумайте классификацию причин эскалации (минимум 5 причин) и что вы будете улучшать по каждой.
4) Составьте «контент-политику бота» на 10 пунктов: что можно/нельзя говорить и когда подключать оператора.
5) Сделайте чек-лист безопасности (10 пунктов) для вашего запуска: данные, доступы, антифлуд, секреты.
<details>
<summary>
Ответы (примерные)
</summary>
1) Пример матрицы тестов (фрагмент):
Старт → кнопка “Запись” → показ выбора услуги.
Ввод услуги текстом вместо кнопки → бот предлагает кнопки или уточнение.
Неверный формат телефона → подсказка + повтор.
Таймаут расписания → “не могу проверить слоты” + оператор.
Двойной клик по “Подтвердить” → запись создаётся один раз.
Платёж pending → сообщение “проверяю оплату”, без дублей.
Платёж failed → предложить повтор/другой способ/оператор.
Пользователь пишет “хочу пожаловаться” → эскалация с меткой “жалоба”.2) Пример 6 событий:
bot_start_shown
scenario_selected (value: status/booking/support)
identifier_collected (type: phone/order_id)
api_call_result (service, success/fail, latency_bucket)
handoff_to_operator (reason)
scenario_completed (result: success/fail/cancel)Пример воронки: start_shown → scenario_selected=booking → identifier_collected(phone) → slot_selected → payment_link_sent → completed(success).
3) Пример причин эскалации и улучшений:
Нестандартный вопрос → добавить FAQ/ветку.
Ошибка ввода → улучшить подсказку и примеры.
Нет данных в CRM → добавить альтернативную идентификацию.
Сбой API → очередь/повтор + алёрты.
Жалоба/конфликт → отдельный “стресс-сценарий” + приоритет оператору.4) Пример «контент-политики» (фрагмент):
Не просить пароли.
Не давать медицинских/юридических рекомендаций — только маршрутизация.
Не обещать сроки, которых нет в системе.
Всегда объяснять, зачем нужен телефон.
В ошибках — варианты действий (повтор/меню/оператор).
В жалобах — нейтральный тон и быстрый перевод к человеку.
Любые платежи подтверждать только по статусу платежной системы.
Не отправлять уведомления без согласия.
Сохранять краткость: одно сообщение — одно действие.
В спорных случаях — оператор.5) Пример чек-листа безопасности:
Минимизация данных (собираем только нужное).
Маскирование PII в логах.
Разделение прав доступа в CRM.
Ограничение попыток ввода кода/номера.
Rate limiting и антифлуд.
Проверка источника входящих событий (вебхуки).
Хранение токенов как секретов.
Аудит изменений сценариев и рассылок.
Аварийный режим “меню + оператор”.
Регулярный просмотр логов/алёртов и разбор инцидентов.</details>