automation
Как протестировать сценарий диалога чат-бота перед сдачей клиенту
Бот клиента запускается со сломанным сценарием, а вы узнаёте об этом из злого сообщения в Slack. Вот как тестировать сценарии диалогов до того, как это произойдёт.
Вы сдаёте бота в пятницу днём. В понедельник утром клиент пишет вам: его бот три раза подряд сказал потенциальному клиенту «я не понимаю», а потом зациклился на приветствии. Этот лид потерян, а вместе с ним — и часть доверия клиента к вам.
Такое случается чаще, чем агентства готовы признать. Сценарий диалога, который выглядит идеально в вашем тестовом чате, разваливается в тот момент, когда реальный человек формулирует что-то чуть иначе. Тестирование бота перед сдачей — это не необязательный штрих, а разница между продлением контракта с клиентом и требованием возврата денег.
Сколько тестовых диалогов нужно провести перед запуском чат-бота?
Проведите как минимум 15-20 отдельных тестовых диалогов, охватывающих основной сценарий, распространённые пограничные случаи и намеренные попытки «сломать» бота, прежде чем передавать его клиенту. Это число не взято с потолка — примерно на этом этапе вы исчерпываете очевидные варианты формулировок, которые использовал бы реальный потенциальный клиент, а оставшиеся баги можно задокументировать как известные ограничения, а не преподносить как сюрприз.
Меньше 10 тестовых прогонов — и вы почти гарантированно пропустите тупиковый путь. Больше 25-30 — и вы, как правило, просто повторяете одни и те же сценарии сбоев с другой формулировкой; лучше потратить это время на базу знаний.
Что на самом деле нужно тестировать в сценарии диалога?
Не просто прокручивайте «идеальный» диалог, который вы написали в промпте. Тестируйте пути, которые реально проходит потенциальный клиент, включая самые неудобные.
Основной сценарий: Потенциальный клиент отвечает именно так, как ожидается, и плавно доходит до записи на встречу или заполнения формы.
Вопросы не по теме: Спросите бота о чём-то не связанном с продуктом («какой у тебя любимый цвет») и проверьте, перенаправляет ли он разговор корректно, а не выдумывает ответ.
Неоднозначные ответы: Отправьте односложные ответы вроде «может быть» или «не знаю» и посмотрите, задаёт ли бот уточняющий вопрос или просто гадает.
Возражения и сопротивление: Скажите «это слишком дорого» или «не интересно» и убедитесь, что у бота есть реальный ответ, а не зацикленное шаблонное извинение.
Переключение языка: Если аудитория клиента многоязычная, переключите язык посреди диалога и проверьте, следует ли бот за этим или корректно деградирует.
Повторы и зацикливание: Задайте один и тот же вопрос дважды подряд — плохой сценарий повторится слово в слово, что звучит роботизированно и быстро подрывает доверие.
Триггеры передачи человеку: Скажите что-то, что должно эскалировать диалог к человеку («хочу поговорить с кем-то») и убедитесь, что эскалация действительно срабатывает.
Если вы выстраиваете путь эскалации, посмотрите как передать AI-диалог в Telegram живому оператору — сценарий, который не может корректно выйти на человека, обязательно будет раздражать реальных потенциальных клиентов.
Почему бот, который работает в вашем тестовом чате, ломается в продакшене?
Самая частая причина: ваш тестовый чат — это вы сами, и вы уже знаете, чего бот ожидает. Реальные потенциальные клиенты — нет. Они делают опечатки, отправляют голосовые сообщения, отвечают эмодзи или отвечают на вопрос, который бот задал три сообщения назад.
Вторая по частоте причина — скудная база знаний. Если промпт бота ссылается на FAQ или детали продукта, которые никогда реально не были прописаны в базе знаний, он начинает импровизировать — а импровизация это как раз то место, где живут галлюцинации. Прежде чем тестировать логику диалога, убедитесь, что базовый контент надёжен. Смотрите как построить базу знаний для бота поддержки в Telegram — этот материал описывает основу, от которой всё зависит.
Как быстрее всего тестировать, не раздражая реальных потенциальных клиентов?
Тестируйте в изолированной среде, прежде чем что-либо коснётся живого аккаунта. Никогда не тестируйте изменения в логике диалога напрямую на потенциальных клиентах, которые уже находятся в середине последовательности, — одно неудачное сообщение в продакшене, и вы сожгли лида, за которого заплатил клиент.
Настройте выделенный тестовый аккаунт, отдельный от живого аккаунта аутрича клиента.
Прогоните полный список тестовых диалогов (те 15-20 сценариев выше) на этом аккаунте.
Фиксируйте каждый провал — точное сообщение, которое всё сломало, что сказал бот, что он должен был сказать.
Исправьте промпт или базу знаний, затем повторно прогоните только провалившиеся сценарии, а не весь список.
Когда всё проходит успешно два раза подряд, переходите к staging-настройке, которая копирует продакшен-аккаунт, перед финальной сдачей.
Если вы ещё не оформили это в повторяемый процесс перед запуском, статья про настройку staging-окружения для Telegram-бота перед запуском расскажет, как правильно выстроить это разделение, чтобы вы никогда не тестировали на живой кампании клиента.
Как протестировать суждение AI-агента, а не только его сценарные ответы?
AI-агент продаж в Telegram от CRMChat работает внутри вашего Telegram-аккаунта и отвечает на основе промпта плюс опциональной базы знаний — а значит, его поведение в серых зонах полностью зависит от того, насколько хорошо вы определили и то, и другое. Тестировать его — значит задавать вопросы, которые явно не покрыты в FAQ, и проверять, корректно ли он передаёт вопрос дальше, а не гадает.
CRMChat включает логику передачи, которая позволяет боту приостановиться и подождать вашего вмешательства, когда вопрос неясен, поэтому часть вашего теста должна конкретно подтвердить работу этого триггера — отправьте боту действительно запутанное или выходящее за рамки сообщение и убедитесь, что он останавливается и помечает диалог для человека, а не отвечает с уверенностью, которой у него нет.
Задайте вопрос, который не покрыт базой знаний — бот должен эскалировать или признать неуверенность, а не выдумывать ответ.
Задайте вопрос о цене, если ценообразование не было включено в промпт — проверьте, что бот не изобретает цифру.
Отправьте противоречивую информацию в двух сообщениях — посмотрите, замечает ли бот противоречие или просто соглашается с последним сказанным.
Что нужно задокументировать перед передачей бота клиенту?
Тестирование не завершено, пока оно не записано где-то, где команда клиента может это увидеть. Бот с недокументированным слабым местом — это бот, который рано или поздно кого-то подведёт.
Составьте список известных пограничных случаев, с которыми бот справляется плохо, с планом исправления или пометкой, что это вне зоны ответственности.
Задокументируйте точные фразы эскалации, которые запускают передачу человеку.
Включите короткий лог ваших тестовых диалогов, чтобы клиент видел, что сценарий действительно был стресс-тестирован, а не просто собран и сдан.
Эта документация также облегчает переход, когда бот переходит в руки клиента — смотрите как передать готовый проект чат-бота внутренней команде клиента, чтобы узнать, что ещё должно входить в пакет передачи. Если клиенту когда-нибудь понадобится перенести бота на другой Telegram-аккаунт, статья про перенос чат-бота клиента с одного Telegram-аккаунта на другой тоже стоит сохранить в закладки — тестирование не перестаёт быть актуальным только потому, что сдача завершена.
Вся эта дисциплина тестирования не требует экзотических инструментов. CRMChat позволяет управлять аккаунтом, на котором работает бот, назначить его на изолированное рабочее пространство клиента и полностью отделить тестовую активность от живых кампаний — так что сломанное тестовое сообщение никогда случайно не дойдёт до реального потенциального клиента. Подробности настройки смотрите в Help Center, а если хотите скриптовать автоматические тестовые прогоны вместо ручного тестирования — в документации CRMChat API.
