Статические сценарии для чат-бота: бюджетно, быстро, проверено временем
Сегодня расскажу о сценариях и более подробно — о статических, для реализации которых не требуется сложных технических решений. При этом они закрывают довольно большой процент обращений. В некоторых случаях можно вообще обойтись только ими, не создавая динамические.
Демьян Грин, гендиректор и основатель сервиса автоматизации коммуникации с клиентами Лия
Напомню, что для автоматизации коммуникации службы клиентского сервиса на старте нужно обязательно выделить семантические группы интентов (намерений, тематик запросов клиентов) и составить к ним сценарии — варианты общения бота с пользователями.
Может показаться, что количество сценариев и интентов должно быть одинаковым: вот вопрос — вот вариант его обработки. Но это не так. Один сценарий может быть актуален для целого списка намерений. Они все равнозначны для него — схематично это выглядит как один кубик из конструктора бота, в котором собрано несколько интентов.
Сколько сценариев нужно писать для запуска автоматизации коммуникации
Можно ли на этапе запуска определить оптимальное количество сценариев? Оптимальное число определяется тем, насколько объемный датасет передает нам клиент. Если это большой показательный датасет за полгода, и мы можем выделить из него 25 интентов, то будем работать с полным набором.
Если же на этапе запуска нам передают датасет за 3 недели, и из него мы худо-бедно «наскребаем» 15 интентов — что ж, будем работать с тем, что имеем. Количество интентов (и сценариев) на этапе запуска напрямую зависит от объема датасета, который нам передают для разметки/анализа.
Мы не рекомендуем запускать менее 15 сценариев, особенно если это какой-то крупный или даже средний проект — при меньшем количестве просто невозможно добиться хорошего покрытия. 15−20 — это тот золотой стандарт, к которому мы призываем. Но конечный итог зависит от специфики бизнеса и выбранного тарифа — если он базовый, будем размечаться на 15, на этапе запуска чаще всего этого достаточно. Даже если хочется больше, то не проблема добавить новые сценарии через неделю-две.
Не стоит хвататься за все и сразу со старта. Начинать автоматизацию стоит по принципу от простого к сложному, и сначала есть смысл работать со статическими сценариями.
Эти сценарии шаблонны, не требуют обращения бота к внутренним базам данных компании, интеграции с CRM и каких-либо сложных технических решений для корректной работы. Они хорошо подходят для ответов на общие вопросы — например, «есть ли у вас скидки в день рождения». Они также хорошо проявляют себя при ответе на запросы, не требующие обработки каких-либо уникальных данных (адреса, номера заказа) и создания сущностей. В некоторых случаях компания может обойтись только статикой, без динамических сценариев — они более дорогие и на их создание, как правило, уходит много времени.
Примеры статических сценариев для разных ниш бизнеса:
- фудтех — действия с заказами (отмена, перенос, статус);
- кикшеринг — проблемы с самокатом, возврат депозита, зоны, парковки;
- e-commerce — действия с заказами, возврат денег, статус доставки;
- беттинг — вывод средств, верификация, вопросы по документам, вопросы по ставкам.
Непродуктовые системные сценарии: базовые варианты
На некоторые часто задаваемые вопросы клиентов бот может дать четкий стандартизированный ответ. Для этого не нужно разрабатывать сценарий с несколькими ветками (вариантами хода разговора). Например, если пользователь спросит, есть ли у вас доставка, чат-бот может ответить ему: «Да, мы доставляем заказы по городу» (или «Нет, действует только самовывоз»).
Работая с разными компаниями из одной ниши, мы заметили, что некоторая часть задач, требующих автоматизации, постоянно повторяется. Чтобы упростить работу клиентам, мы на старте подключения чат-бота загружаем в проект базовый набор сценариев. Они актуальны для 99% бизнесов этого сегмента. Как правило, они не касаются продуктов компании.
Ряд системных сценариев, которые подходят абсолютно для всех, мы загружаем как базу в каждый проект. Например, сценарий, когда Лия переводит на оператора, прощается с пользователем, благодарит его, получает его согласие или реагирует на отказ. Это непродуктовые сценарии, одинаковые от клиента к клиенту — мы добавляем их как шаблон в каждый новый проект, который делаем. Их список не вносится в коммерческое предложение для запуска проекта. Те 15−20 базовых сценариев, о которых шла речь выше, как раз и относятся к непродуктовым.
Такой подход позволяет быстро прописать сценарии для типовых простых запросов, сохранив ToV компании (стиль, тональность общения с клиентами). Допустим, подавляющему большинству пользователей авиаперевозчиков интересны цены на билеты, даты, перенос вылета, исправление ошибки в оформлении и т.п. — мы это знаем по опыту плюс анализируем датасет, актуализируя запросы. Поэтому у нас есть готовые варианты, что точно должно быть на старте в каждом бизнес-сегменте.
Совсем не обязательно использовать сразу все сценарии и в том же виде, в котором их загрузили на старте. Если определенные ответы для клиента перестают быть актуальными (то же прощание с пользователем, сроки проведения акции), они архивируются. И, наоборот, что-то может быть доработано, кастомизировано.
Даже если сценарий основывается на базовой сборке, специалисту, впервые работающему на нашей платформе, рекомендуем обязательно его протестировать — для этого у нас предусмотрен удобный дебаг-чат.
Настройка сценариев под бизнес-процессы компании
Несмотря на то, что запросы клиентов могут быть одинаковыми, у каждой компании свое видение того, как эффективнее всего работать с пользователями. Поэтому и сценарии для одного и того же интента отличаются. Например, клиент пишет: «Отмените заказ». Для одной фирмы мы создаем (или она сама создает) сценарий, в рамках которого после такой фразы подключается оператор с целью удержать покупателя: он начинает выяснять причину отказа, предлагать другие варианты, то есть влиять на то, чтобы человек поменял решение.
А у другой компании нет задачи удерживать пользователей — и они просят сценарий, согласно которому чат-бот сразу передает информацию о необходимости смены статуса заказа. Важно слышать клиента, понимать потребности и цели конкретного бизнеса и учитывать это при настройке автоматизации коммуникации.
Мы не предлагаем какие-то унификации в клиентских бизнес-процессах, не диктуем заказчикам автоматизации, как надо работать. Собираем сценарии по той логике и скриптам, которые передает клиент, и опираемся на его пожелания. Однако если нам очевидно, что какой-то сценарий не будет эффективным, и мы точно это знаем по предыдущему опыту, то порекомендуем переделать или доработать его. В проектах, которые полностью лежат на нас, мы более решительны: сами предлагаем типы сценариев, активно советуем добавлять необходимые интенты.
👉 Ближе познакомиться с моей компанией, ее предложениями и возможностями Лии вы сможете на нашем сайте.