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

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

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

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

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

Проверка статуса — не чтение сырой отметки

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

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

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

У системы могут быть ограничения: сведения перевозчика поступают с задержкой, в карточке заказа нет номера отправления, интеграция временно недоступна. Карта должна различать такие случаи. «Заказ не найден» и «Система сейчас не смогла проверить заказ» — не одно и то же. В первом случае можно проверить идентификатор или способ поиска. Во втором — повторить попытку позже или передать запрос. Если смешать эти причины, пользователь будет делать бесполезные шаги, а разбираться в сбое станет сложнее.

Развилки, подтверждения и отмена

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

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

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

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

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

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

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

Незавершённый путь — не тупик

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

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

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

Сотрудник в маршруте, а не в конце лабиринта

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

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

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

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

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

Карта проверки заказа

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

Понять задачу. Пользователь описывает вопрос о заказе. Бот определяет, нужно ли проверить статус, разобраться с доставкой или изменить заказ. Если намерение неясно, он уточняет выбор. Результат — понятный запрос или конкретный вопрос для уточнения.

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

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

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

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

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

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

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

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

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

Перенос карты на другую задачу

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

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

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

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