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

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

Какую задачу поручить чат-боту

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

В этом сценарии бот собирает исходные данные для сотрудника. Из описания диалога нельзя сделать вывод об ускорении обработки или росте продаж: такой эффект потребует отдельных измерений.

Начало диалога и выбор следующего шага

Первая реплика бота сообщает, чем он может помочь, и предлагает выбрать направление. Назначение такого начала — не развлечь посетителя, а сразу показать конкретные действия. Учебный пример приветствия:

— Здравствуйте! Я помогу оставить заявку на услугу. Выберите, что вас интересует: узнать об услуге, оставить заявку или связаться с сотрудником.

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

Как уточнить задачу посетителя

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

— Какая услуга вас интересует?
— Консультация по настройке формы заявки.
— Уточните, пожалуйста, что именно нужно настроить. Если не хотите отвечать сейчас, напишите «пропустить».
— Пропустить.

— Понял: консультация по настройке формы заявки, подробности пока не указаны. Можно исправить запрос, выбрать способ связи или отменить заявку.

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

Пример диалога для заявки на услугу

Ниже — цельный вымышленный пример, а не кейс какой-либо компании. Он показывает последовательность от первого контакта до передачи заявки. Контакт указан условным шаблоном. В финальной реплике предполагается, что система уже получила подтверждение доставки в согласованный канал сотрудника. Если подтверждения нет, бот сообщает: «Не удалось подтвердить передачу заявки. Можно повторить попытку или выбрать другой способ обращения».

Посетитель: Здравствуйте.
Бот: Здравствуйте! Я помогу оставить заявку на услугу. Выберите, что вас интересует: узнать об услуге, оставить заявку, связаться с сотрудником.
Посетитель: Оставить заявку.
Бот: Какая услуга вас интересует?
Посетитель: Консультация по настройке формы заявки.
Бот: Уточните, пожалуйста, что именно нужно настроить. Если не готовы отвечать — напишите «пропустить».
Посетитель: Пропустить.
Бот: Понял, пропускаем уточнение. Как вам удобнее связаться с сотрудником: по телефону или электронной почте? Укажите выбранный способ и контакт либо отмените заявку.
Посетитель: По телефону: +7 XXX XXX-XX-XX.
Бот: Спасибо! Получено подтверждение доставки вашей заявки в канал приёма обращений.

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

Что делать с непонятным ответом или отказом

На том же учебном примере рассмотрим тупиковые ситуации.

Непонятный ввод и понятный вопрос вне возможностей бота — разные ситуации. Ниже два учебных варианта продолжения того же сценария.

Непонятный ввод:

Посетитель: ???
Бот: Не удалось понять ответ. Выберите: узнать об услуге, оставить заявку или связаться с сотрудником.

Понятный вопрос вне возможностей учебного бота:

Посетитель: А сколько стоит?
Бот: Я не могу ответить на вопрос о стоимости. Вы можете связаться с сотрудником или вернуться к выбору: узнать об услуге, оставить заявку.

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

Посетитель: Не хочу оставлять заявку.
Бот: Понял, заявку не оформляем. Если понадобится — возвращайтесь, я буду здесь.

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

Как передать диалог менеджеру

Когда бот собрал данные, он формирует карточку для сотрудника. Учебный состав карточки:

— Задача: консультация по настройке формы заявки (уточнение пропущено).
— Ответы посетителя: услуга — консультация по настройке формы заявки; контакт — +7 XXX XXX-XX-XX.
— Способ связи, выбранный посетителем: телефон.

После подтверждения доставки карточки в согласованный канал бот сообщает посетителю:

— Спасибо! Получено подтверждение доставки вашей заявки в канал приёма обращений.

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

Если менеджер недоступен

Ситуация: сотрудник, который принимает заявки, не в сети. Учебная реплика:

— Сейчас сотрудник недоступен. Вы можете оставить обращение или вернуться позже.

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

Проверка сценария перед запуском

Чек-лист для ручной проверки каждой ветки сценария. Для каждого пункта указано ожидаемое поведение без числовых нормативов.

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

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

Как оценивать работу после запуска

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

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

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

Что согласовать с командой

Перед внедрением зафиксируйте четыре решения.

1. Кто принимает заявку: конкретный сотрудник или группа, чтобы карточка не терялась.
2. Что бот может сообщать: получение заявки, подтверждённую доставку или отсутствие подтверждения. Обратную связь обещают только тогда, когда команда действительно организовала этот процесс.
3. Какие вопросы бот передает человеку: все, что выходит за рамки сбора заявки, включая вопросы о стоимости, сроках и гарантиях.
4. Как проверяется доставка: подтвердить получение тестовой заявки сотрудником, проверить обработку ошибки и повторной отправки; после запуска сопоставлять записи отправки с получением.

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

Опишите задачу вашего чат-бота в форме обратной связи, чтобы обсудить возможный сценарий.