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

Где автоматизация помогает, а где мешает

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

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

Один поток, три разных риска

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

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

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

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

Различие между «ответить» и «решить» — отправная точка отбора. Бот может сказать что-то уместное, но не выполнить обещанное действие: не проверить статус в системе, не создать заявку, не передать контекст оператору. Тогда очередь уменьшится только на экране. Работа останется у команды, а ей ещё придётся исправлять ошибку.

Частота полезна, но не решает всё

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

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

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

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

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

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

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

Частота споров о возврате различается, но результат трудно определить без изучения истории и обстоятельств. Цена ошибки и эмоциональная нагрузка высоки. Боту можно поручить показать подтверждённый статус, оформить передачу сотруднику и сохранить контекст.

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

Когда бот знает ответ

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

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

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

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

Когда нужен выбор

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

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

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

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

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

Когда одной формы недостаточно

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

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

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

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

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

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

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

Права бота и цена решения

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

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

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

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

Матрица без магического балла

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

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

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

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

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

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

Карта задач для магазина

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

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

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

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

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

Диалог как путь к выполненной работе

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

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

Намерение — деловая задача — результат

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

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

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

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

Один узел — одна работа

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

Для каждого узла важно зафиксировать четыре вещи.

Цель — зачем нужен этот шаг и что должно измениться после него.

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

Решение — какое условие проверяется и какие варианты допустимы.

Выход — следующий узел, успешное завершение, незавершённый путь или передача сотруднику.

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

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

Первое сообщение и минимальные данные

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

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