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

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

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

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

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

1. Мы могли бы сделать это все на одном боте, описав ему в инструкции, что он сначала должен определить статус клиента, далее в зависимости от статуса давать соответствующие ответы, но в этом случае у нас инструкция для бота была бы сильно перегружена, а это приведет к следующим последствиям:
   * Повышение вероятности, что бот будет путаться, и давать информацию не соответствующую статусу клиента;
   * Ответы будут более дорогие, так как инструкция у бота имеет описание всех бизнес - процессов, а еще и указаний на необходимость определения статуса клиента;
   * Сложная поддержка такой большой инструкции;
2. Мы разделяем задачу на 3 подзадачи:

   * Определить статус клиента;
   * Работа с клиентами;
   * Работа с будущими клиентами;

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

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

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

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

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

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

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

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

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

<figure><img src="/files/GsD7HxZ1WumGpp4wXbUA" alt=""><figcaption></figcaption></figure>

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

<figure><img src="/files/29bkBVhF8xmdCvdo1wGM" alt=""><figcaption></figcaption></figure>

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

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

<figure><img src="/files/UsXzpcx9Fb1YRMugH8Fb" alt=""><figcaption></figcaption></figure>

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

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

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

<figure><img src="/files/H4Jk1iJB1G3kDYjpIjFi" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/iE33DoxmXkFYmr09N0qo" alt=""><figcaption></figcaption></figure>

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

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

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

<figure><img src="/files/Tph8w0aJCmG2Y4RC45Mj" alt=""><figcaption></figcaption></figure>

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

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

<figure><img src="/files/wvFRSJ7wPlThHuwBWVvw" alt=""><figcaption></figcaption></figure>

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

<figure><img src="/files/WkOBQWfiyzovXZ5Ich5L" alt=""><figcaption></figcaption></figure>

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

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

<figure><img src="/files/SiO1i4F0VmYjDShRHDq3" alt=""><figcaption></figcaption></figure>

Назначаем аргумент в разделе **Переменные действия**:

<figure><img src="/files/5kJjtCn9Q9jcfvEH72I8" alt=""><figcaption></figcaption></figure>

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

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

<figure><img src="/files/2eSQGyeqJIn5gydQLPYw" alt=""><figcaption></figcaption></figure>

На представленном примере видно, что диалог ведется с ботом администратором. После выбора филиала, произошло переключение на бота Филиал 1. При переключении диалога было передано краткое содержание диалога бота Администратор в переменной 'user\_message' и дальше уже отвечает бот Филиал 1.

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

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

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

{% hint style="success" %}
Данная схема подключения актуальна для CRM-систем [Битрикс24](/ru/kanaly/crm-sistemy/bitriks24.md), [amoCRM](/ru/kanaly/crm-sistemy/amocrm.md), [Kommo](/ru/kanaly/crm-sistemy/kommo.md).
{% endhint %}

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

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

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

* на боте-администраторе подключён канал общения
* на боте-сотруднике подключены функции

> ***Например**:*
>
> * 1 бот подключен только к WhatsApp — отвечает на сообщения клиента
> * 2 бот подключён только к Yclients — записывает клиента на сеанс


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.suvvy.ai/ru/deistviya/multiagentnost/pereklyuchenie-aktivnogo-bota.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
