Переключение активного бота

Описание работы

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

Организация работы с разными типами клиентов

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

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

   • Повышение вероятности, что бот будет путаться, и давать информацию не соответствующую статусу клиента;

   • Ответы будут более дорогие, так как инструкция у бота имеет описание всех бизнес - процессов, а еще и указаний на необходимость определения статуса клиента;

   • Сложная поддержка такой большой инструкции;

2. Мы разделяем задачу на 3 подзадачи:

   • Определить статус клиента;

   • Работа с клиентами;

   • Работа с будущими клиентами;

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

   • Бот "Секретарь", у него одна задача, определить статус клиента, и далее переключить диалог на соответствующего бота;

   • Бот "Работа с клиентами", имеет описание бизнес - процесса только по работе с действующими клиентами, и ничего не знает о задачах секретаря, или менеджера работы с будущими клиентами;

   • Бот "Работа с будущими клиентами". Аналогично, имеет описание только своих задач.

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

   • Возможность масштабирования (добавления других специалистов, например по работе с ВИП клиентами);

   • Инструкции каждого бота имеют информацию относящуюся только к его задачам, а значит бот не сможет сбиться и ответить некорректно, или хуже того предоставить информацию которая для клиента с этим статусом недоступна;

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

Организация работы компании с несколькими филиалами

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

Но есть компании, которым в принципе не обойтись без реализации схемы с несколькими ботами, это компании которые используют интеграцию с УС (имеют несколько филиалов и один входящий канал связи), так как интеграция построена на уникальном идентификаторе филиала и для каждого филиала создается свой бот, связанный с филиалом в УС. А если у компании один входящие номер, то требуется кто-то, кто будет определять на какой филиал надо переключить клиента - то есть обязательно нужен дополнительный бот "Администратор". Ниже, на примере, рассмотрим создания такого бота "Администратора" для компании использующей интеграцию с УС.

Создание ботов

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

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

Создание действий для реализации переключения активного бота диалога

В боте "Администратор", переходим на закладку "Действие" и для каждого филиала создаем свое действие для переключения активного бота:

Название действия - просто название для отображения в списке.

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

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

Сообщение об ошибке - сообщение, которое будет получать Савви от действия, в случае, если на стороне веб-хука вернется ошибка. Может быть пустым, в этом случае Савви получит текст ошибки от URL-адреса, на который отправляется веб-хук.

Добавление шага

Внутри Действия можно вызывать последовательность действий, используя разные типы вызовов, поэтому это называется шагами.

Нам необходимо добавить шаг и выбрать тип шага "Переключение действующего бота":

При заполнении формы шага ваша задача только выбрать бота, на какого будет переключен диалог:

Выполнение переключения активного бота

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

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

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

В описание действие добавляем информацию что передать в аргумент и добавляем аргумент.

Добавляем шаг "Вызов бота".

В настройках шага указываем вызов бота того же филиала а также текст запроса в бот.

Так как у нас на каждый филиал создано свое действие по переключению, то выполнить эти изменения надо в каждом действии (для каждого филиала).

Анализ работы бота

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

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

Порядок подключения CRM-каналов

Правильное подключение выглядит следующим образом:

• Бот-администратор — подключён канал, включены ответы, выключены дополнительные функции (заполнение сделки и т.п.)

• Бот, на который переключаем — подключён канал, выключены ответы, включены дополнительные функции

Данная схема подключения актуальна для CRM-систем Битрикс24, amoCRM, Kommo.

Порядок подключения остальных каналов

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

Общее правило такое:

• на боте-администраторе подключён канал общения

• на боте-сотруднике подключены функции

Например:

• 1 бот подключен только к WhatsApp — отвечает на сообщения клиента

• 2 бот подключён только к Yclients — записывает клиента на сеанс