Качество ИИ-бота проверяют на реальных диалогах, а не только на удачном демо. До запуска малого бизнеса нужно убедиться, что бот правильно понимает вопросы, отвечает по базе знаний, собирает нужные данные и вовремя передаёт разговор менеджеру. В статье разберём пошаговый чек-лист: какие сценарии подготовить, что проверить в ответах, как оценить интеграцию с CRM и какие ошибки исправить до первого клиента.
С чего начать проверку ИИ-бота?
Сначала опишите задачу бота одним предложением. Например: «Бот принимает входящие обращения от компаний, выясняет потребность и передаёт подходящие заявки менеджеру». Такая формулировка задаёт границы теста. Если бот должен одновременно консультировать, продавать, оформлять документы и поддерживать клиентов, проверить результат будет сложнее.
Соберите список вопросов, которые действительно задают вашим сотрудникам. Для B2B-компании это могут быть запросы о сроках поставки, минимальной партии, характеристиках услуги, порядке оплаты или возможности получить коммерческое предложение. Включите также короткие сообщения вроде «Сколько стоит?», опечатки и неполные фразы. Клиент редко формулирует запрос так подробно, как автор сценария.
Заранее зафиксируйте правильный результат для каждого теста. Ответ «информация передана менеджеру» подходит для вопроса о нестандартных условиях, но не для простого запроса о графике работы. Если ожидаемый результат не описан, проверка быстро превращается во вкусовую оценку ответа.
Какие тестовые вопросы подготовить?
- Прямой запрос: «Нужен расчёт поставки для компании из Минска».
- Неполный запрос: «А по срокам что?».
- Вопрос с ошибкой или разговорной формулировкой.
- Несколько вопросов в одном сообщении.
- Запрос вне компетенции бота.
- Попытка получить сведения, которых нет в базе знаний.
- Ответ пользователя, который не заполняет обязательное поле.
Для каждого сценария запишите четыре пункта: что написал пользователь, какой ответ считается правильным, какие данные нужно сохранить и какое действие должно произойти дальше. В B2B-воронке это часто имя, компания, контакт для связи, задача клиента и удобное время разговора. Набор полей зависит от процесса продаж, поэтому его лучше согласовать с менеджером до настройки бота.
Как проверить ответы ИИ-бота?
Читайте диалог целиком, а не только отдельную реплику. Бот может дать точный ответ на первый вопрос, а затем потерять контекст и снова запросить уже указанную информацию. Проверьте, помнит ли он название компании, выбранную услугу и предыдущие ограничения клиента в рамках одной сессии.
Отдельно проверьте фактическую точность. Возьмите несколько страниц базы знаний или утверждённых материалов компании и задайте по ним вопросы в разных формулировках. Бот должен передавать только подтверждённые сведения. Если данных нет, корректный сценарий выглядит так: бот прямо сообщает об ограничении и предлагает передать вопрос сотруднику.
Обратите внимание на тон ответа и его длину. Менеджеру в отделе продаж не нужен длинный текст с общими рассуждениями, когда клиент спросил о сроке расчёта. При этом слишком короткая реплика может оставить без ответа часть запроса. Для каждой группы вопросов задайте рабочий формат: один ответ с пояснением, список условий или уточняющий вопрос.
| Что проверять | Хороший результат | Повод остановить запуск |
|---|---|---|
| Понимание запроса | Бот определяет задачу клиента и задаёт уместный вопрос | Отвечает по случайной теме или повторяет приветствие |
| Факты | Использует сведения из утверждённой базы | Придумывает цену, срок или характеристику |
| Контекст | Учитывает предыдущие сообщения | Каждый раз начинает разговор заново |
| Неясный вопрос | Просит уточнить конкретную деталь | Делает уверенный вывод без достаточных данных |
| Нестандартный запрос | Передаёт диалог человеку с кратким пояснением | Замыкает клиента в повторяющемся сценарии |
Для сценария квалификации полезно отдельно проверить порядок вопросов. Если бот сначала просит телефон, а клиент ещё не понял, подходит ли ему услуга, это может снизить готовность продолжать разговор. Логику квалификации и набор полей можно сверить с практическим сценарием для B2B-лидов в Telegram.
Как проверить передачу диалога менеджеру?
Передача человеку должна запускаться по понятному условию. Это может быть просьба о нестандартном расчёте, вопрос по индивидуальным условиям или несколько неудачных попыток распознать запрос. Протестируйте каждый триггер отдельно и посмотрите, получает ли менеджер сам диалог, а не только уведомление о том, что клиент написал.
Проверьте, какие сведения уходят вместе с обращением. Менеджеру обычно нужны исходный запрос, имя клиента, компания, выбранное направление и уже собранные ответы. Если сотрудник снова задаёт те же вопросы, автоматизация теряет смысл. В отдельной проверке убедитесь, что после передачи бот прекращает отвечать там, где должен говорить менеджер.
Полезно провести тест с резкой сменой темы. Клиент сначала спрашивает о сроках, затем просит соединить его со специалистом, а после передачи уточняет ещё одну деталь. Такой диалог показывает, где заканчивается зона бота и кто отвечает за следующее сообщение. Подходы к сохранению контекста разобраны в материале о передаче разговора от ИИ-бота менеджеру.
Что проверить в CRM?
- Создаётся ли новая заявка после целевого действия.
- Попадают ли поля в правильные колонки или карточки.
- Не появляются ли дубли при повторной отправке сообщения.
- Видит ли менеджер источник обращения и историю диалога.
- Фиксируется ли статус после передачи заявки.
- Что происходит, если CRM временно не отвечает.
Последний пункт часто пропускают. Имитируйте ошибку интеграции и проверьте, сохраняется ли обращение в очереди, появляется ли уведомление ответственному сотруднику и можно ли повторить отправку без потери данных. Схемы передачи заявок и варианты связки с CRM можно сравнить в разборе интеграции Telegram-бота с CRM.
Как проверить бота под нагрузкой и в разных сценариях?
Даже небольшой бизнес получает обращения не только в рабочее время. Проверьте несколько параллельных диалогов с разными запросами и убедитесь, что бот не смешивает контекст пользователей. Для теста удобно открыть отдельные сессии: в одной клиент просит расчёт, в другой задаёт вопрос по поддержке, в третьей отказывается оставлять контакт.
Проверьте повторный вход пользователя. Клиент может вернуться через некоторое время, продолжить старый вопрос или начать новый. Сценарий должен заранее определять, что увидит бот и менеджер: продолжение заявки, новое обращение или предложение выбрать тему.
Отдельно протестируйте нештатные ситуации: пустое сообщение, вложение, непонятный набор символов, несколько обращений подряд, отказ отвечать на вопрос и просьбу поговорить с человеком. Бот должен давать понятный следующий шаг. Сообщение «Я не знаю» без маршрута к сотруднику оставляет клиента в тупике.
Какие ошибки чаще всего находят перед запуском?
- База знаний содержит старые условия, а бот уверенно сообщает их клиенту.
- Сценарий рассчитан на идеальные ответы и не учитывает опечатки, сокращения и смену темы.
- Бот собирает контакт, но не передаёт его в рабочую систему.
- Менеджер получает заявку без истории разговора и повторяет вопросы.
- У пользователя нет понятной кнопки или команды для перехода к сотруднику.
- После ошибки интеграции обращение исчезает, а ответственному никто не сообщает о сбое.
Каждую найденную ошибку занесите в таблицу с четырьмя колонками: сценарий, фактический ответ, ожидаемый результат, решение. После исправления повторите исходный тест и добавьте похожий вопрос с другой формулировкой. Иначе можно исправить одну фразу, но оставить ту же проблему в соседнем сценарии.
Перед запуском полезно провести финальную проверку человеком, который не участвовал в настройке. Дайте ему список задач без подсказок и попросите пройти диалог как клиент. Такой тест показывает, понятны ли формулировки, легко ли найти нужный вариант и замечает ли пользователь возможность связаться с менеджером.
Три шага, которые можно сделать на этой неделе:
- Соберите 20–30 реальных вопросов клиентов и разделите их по сценариям.
- Для каждого вопроса укажите правильный ответ, обязательные поля и действие после диалога.
- Проверьте отдельными сессиями ответы, передачу менеджеру и запись заявки в CRM.
После запуска проверку стоит повторять при изменении базы знаний, сценария или интеграции. Для малого бизнеса достаточно начать с короткого списка критичных диалогов и регулярно разбирать реальные обращения: так ошибки находятся по конкретным репликам, а улучшения попадают в рабочий сценарий без лишней переделки.
