Пять ошибок ИИ-бота: как найти причину провала до повторной разработки

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

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

1. У сценария нет завершения

Инструкция «консультируй клиентов» не определяет, что считается выполненной работой. Бот может бесконечно рассказывать о компании и считать себя полезным. Для записи на услугу завершением будет подтверждённый слот, для квалификации заявки – заполненная карточка и назначенный ответственный.

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

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

2. Одной роли поручили несовместимые решения

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

Помощник проката может объяснить утверждённые условия и передать запрос на возврат. Обещать полное возмещение можно только по утверждённому правилу. Текст «клиент очень недоволен» не даёт модели дополнительных полномочий.

Обращение	Допустимое действие	Кто решает дальше
Наличие велосипеда	Проверить актуальный источник или уточнить у сотрудника	Администратор при отсутствии данных
Перенос брони	Собрать пожелание и проверить правила переноса	Сотрудник, если условия нестандартные
Спор об оплате	Сохранить обращение и остановить продажу	Уполномоченный специалист

3. Передача человеку существует только в тексте

Сообщение «сейчас позову менеджера» ничего не передаёт само по себе. Нужны назначение ответственного, уведомление и остановка ответов бота. Клиенту надо сообщить реальный следующий шаг, включая ситуацию, когда сотрудник сейчас недоступен.

Проверьте просьбу о человеке в начале разговора и после нескольких уточнений. Если пользователь повторяет «соедините с оператором», не заставляйте его снова выбирать тему в меню. Неясные случаи тоже должны иметь запасной маршрут, который не заканчивается тупиком.

На стороне сотрудника сохраняется краткое содержание запроса и уже собранные сведения. Иначе клиенту приходится заново объяснять всё после длинной анкеты. Это дефект передачи, который не виден по скорости первого ответа.

4. Тестировали только собственные формулировки

Разработчик знает, какие слова ждёт сценарий. Клиент этого не знает. Дайте тестировщику задачу обычным языком, например «поменяйте дату, потому что планы изменились», и не показывайте правильную последовательность кнопок.

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

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

Тон тоже проверяют на таких диалогах. Фамильярный ответ на жалобу может формально содержать нужный маршрут и всё равно испортить разговор. Нужны примеры допустимых формулировок для спорной ситуации, а не абстрактная команда «будь дружелюбным».

5. После запуска никто не обновляет систему

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

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

Как проверить исправление

1. Сохраните проблемный диалог как повторяемый тест.
2. Измените одну причину: правило, источник данных или действие системы.
3. Повторите исходную ситуацию и соседние случаи.
4. Сравните завершение задачи, число уточнений и необходимость ручной переделки.
5. Запишите, кто следит за этим участком после запуска.

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