Проверка ИИ-бота перед запуском: 15 пунктов

Запуск начинается с условий остановки

Демонстрация на удобных вопросах показывает лишь часть работы. В реальном чате человек пишет с ошибками, меняет решение и отправляет данные несколькими сообщениями. Перед запуском нужно проверить, что бот делает в этих ситуациях и кто получает запрос, который он обработать не смог.

У каждого пункта ниже должно быть свидетельство проверки. Отметка «готово» без примера или ответственного не помогает разбирать сбой.

Пятнадцать проверок

1. Для бота задан один понятный результат первого запуска.
2. Прайс и условия имеют владельца и дату обновления.
3. Старые документы исключены из поиска или явно помечены.
4. Есть правило ответа, когда нужных сведений нет.
5. Бот не обещает услугу, которой нет в подтверждённом предложении.
6. Обязательные поля собираются без повторного допроса.
7. Пользователь может исправить ранее названные данные.
8. Передача человеку проверена на настоящем уведомлении.
9. После принятия чата сотрудником автоматические ответы останавливаются.
10. Повторно доставленное сообщение не создаёт дубль заявки.
11. Сбой внешнего сервиса приводит к понятному запасному действию.
12. Чужие инструкции в сообщении не меняют полномочия бота.
13. Доступ к клиентским сведениям ограничен по роли.
14. Установлены расходный лимит и уведомление об ошибках.
15. Назначены ответственный за первые дни работы и способ быстрой остановки.

Проверьте середину разговора

Возьмите учебную заявку на установку окна. Клиент сначала называет один адрес, затем исправляет его и спрашивает о монтаже в другой день. В карточке должны остаться актуальные сведения, а история изменений не должна потеряться.

Добавьте вариант с неизвестным размером и просьбой назвать окончательную цену. Если расчёт требует замера, бот должен объяснить следующий шаг. Уверенная выдуманная сумма считается ошибкой даже при красивой формулировке.

Отдельные испытания для данных и интеграций

Проверка базы знаний отвечает на вопрос, откуда взялось правило. Проверка подключения отвечает за то, куда попала заявка. Их удобно разделять: так проще понять, нужно исправлять документ, текст инструкции или передачу данных.

Проверьте пустой файл, неверный формат телефона и отказ пользователя оставлять контакт. Для персональных данных заранее определите, что действительно нужно собирать. Полная переписка не обязана бессрочно храниться во всех подключённых сервисах.

Как оформить приёмку

Составьте таблицу с входным сообщением, ожидаемым действием и фактическим результатом. Для перехода к сотруднику добавьте имя получателя и подтверждение доставки уведомления. Не записывайте секреты в примеры: для проверки формата контакта достаточно тестовых данных.

У проверки должен быть итог по каждому существенному риску. Допустимые мелкие отклонения в стиле можно исправить позже. Утечка данных, неверная цена и потерянная заявка требуют остановки запуска до исправления. После исправления проверьте исходный пример и соседние сценарии. Сохранённый набор примеров пригодится при смене модели, расширении базы знаний или переносе бота на другую платформу. Так приёмка становится повторяемой работой, а не разовой демонстрацией.

Первые дни после включения

Откройте систему на ограниченный поток и ежедневно разбирайте ошибки по причинам. Неверная цена требует проверки прайса; пропавшая заявка требует проверки событий и повторов. Исправление приветствия не устраняет ни одну из этих проблем.

Перед расширением потока повторите тесты, связанные с изменённым поведением. Сохраните примеры, по которым ошибка однажды возникла: они станут постоянной проверкой. Помочь подготовить такой запуск может АГЕНСТВО ИИ TRUE.