Сценарии для чат-бота: Готовые идеи автоматизации поддержки, продаж и обучения

Если человек написал «Где мой заказ?», намерение уже понятно: он хочет узнать, что происходит с оформленной покупкой. Номер заказа или выбор из списка — не уточнение смысла, а данные, необходимые для проверки. Спрашивать «Вы хотите узнать статус, оплатить или отменить?» — значит не заметить прямую формулировку. А если сообщение звучит как «По заказу вопрос», намерение неясно. Тогда можно предложить варианты: доставка, оплата, изменение или отмена заказа, другой вопрос.

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

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

Сохранять контекст — значит не только помнить предыдущие реплики, но и не запрашивать заново сведения, которые клиент уже сообщил. Если в разговоре названы цвет и модель, не нужно спрашивать: «Какой товар вас интересует?» Если человек указал город, не надо снова уточнять, куда доставлять. При передаче беседы сотруднику вместе с ней следует передать исходное сообщение и уже собранные сведения. Иначе бот вроде бы распознал запрос, но всё равно заставил клиента начать сначала.

Предел расспросов

Можно установить жёсткое правило: задавать не больше одного уточняющего вопроса. Но механическое ограничение приведёт к сбоям. Человеку с понятным вопросом о заказе иногда нужно сообщить номер заказа, а затем подтвердить действие. Это разные шаги: первый собирает обязательные данные, второй помогает избежать ошибки.

Ограничивать нужно не число сообщений само по себе, а повторные попытки угадать смысл. Практический предел такой: после одного неудачного уточнения бот не задаёт второй вопрос вроде «Можете пояснить иначе?» и не повторяет тот же вопрос, лишь переставив слова. Вместо этого он предлагает простой выбор, позволяет описать запрос заново или передаёт обращение сотруднику. Обязательные данные для уже понятной задачи можно собирать отдельно, если клиент продолжает сценарий.

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

Не каждую ситуацию стоит доводить уточнениями до полной ясности. Иногда автоматизированный ответ неуместен: нужна индивидуальная оценка, ситуация спорная или требуется проверить конкретную операцию. Тогда передача специалисту — не провал распознавания, а правильный выбор маршрута. Бот может объяснить, что именно передаёт, и запросить только те сведения, без которых обращение нельзя обработать. Он не должен просить сообщать в чате пароль, код подтверждения или полные данные банковской карты.

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

Если смысл не распознан

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

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

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

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

Просьбу переформулировать тоже нужно составить так, чтобы клиенту не пришлось угадывать нужный термин. Не нужно требовать написать «наличие товара» или «информация о платеже»: это язык классификатора, а не обычного разговора. Лучше дать ориентиры: «Напишите, какой товар ищете, что случилось с оплатой или что хотите узнать о заказе». Человек может выбрать близкое направление или оставить сообщение в свободной форме.

Проверка перед запуском

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

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

Для каждого тестового сообщения редактор может пройти путь от начала до результата. Например, в диалог добавляют карточку товара, а затем фразу «А серый есть?». Если бот снова спрашивает название товара, проблема не в распознавании слова «серый», а в потере контекста. В другом тесте карточку убирают: теперь вопрос о товаре необходим. Такие пары показывают, умеет ли сценарий учитывать обстоятельства, а не просто узнавать шаблон.

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

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

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

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