Switch active bot
Description of the Workflow
Below we will provide some examples where this work scheme is useful, followed by a detailed guide on configuring it in one of the examples.
Organizing Work with Different Types of Clients
Suppose we have a task to organize the work of a consultant bot. In this case, depending on the status of the interlocutor (whether they are an existing client or not), answers to their questions, as well as the information available to them, are completely different. That means if the interlocutor is already our client, we conduct the dialogue based on one business process, and if not yet a client, then on a completely different one. Solution options:
We could do all this on one bot, by instructing it to first determine the client’s status and then, based on the status, provide relevant responses. However, in this case, our bot’s instructions would be overly complex, leading to the following consequences:
Increased likelihood of the bot getting confused and delivering information that doesn’t match the client’s status;
Responses would be more expensive since the bot's instructions include descriptions of all business processes and also indicate the necessity to determine the client’s status;
Supporting such a large instruction set would be complicated;
We split the task into 3 subtasks:
Determine the client's status;
Work with existing clients;
Work with prospective clients;
For each subtask, we create a separate bot, similar to how in real life, there could be a separate employee for each such task: a secretary, client manager, and prospective client manager:
"Secretary" bot whose only task is to determine the client’s status and then switch the dialogue to the respective bot;
"Client Working" bot which only has information about working with existing clients and knows nothing about the secretary's tasks or the prospective client manager’s responsibilities;
"Prospective Client Working" bot which similarly only knows its tasks.
In this setup, the "Secretary" bot initiates the dialogue, answers the call, identifies the client, determines the status, and switches the client to the appropriate specialist (another bot). The respective bot then takes over the dialogue. Such a setup offers:
Scalability potential (adding other specialists, e.g., for working with VIP clients);
Each bot's instructions only pertain to its tasks, preventing the bot from reverting to incorrect responses or worse, providing inaccessible information for that client status;
The cost of dialogue is significantly cheaper since the response involves only the instructions pertinent to this dialogue and its current state. Furthermore, if the bot makes fewer mistakes, dialogues are shorter since the client gets results without additional unnecessary questions and clarifications.
Organizing Company Work across Multiple Branches
Another example where a schema with switching the active bot may be useful is organizing a company’s work with multiple branches but a single incoming phone number. Different branches may have varying lists of services, price lists, contact information, delivery times, and so on. Trying to describe all this in one bot would result in chaos, and achieving proper bot operation would likely be unattainable. However, creating a bot for each branch and adding a "Secretary" bot will resolve the issue.
Some companies fundamentally need to implement a schema with multiple bots; these are companies using integration with a CS (have multiple branches and one incoming communication channel), as integration is based on a unique branch identifier, and a bot is created for each branch linked with the CS branch. If a company has one incoming number, there must be someone to determine which branch to switch the client to—hence, an additional "Administrator" bot is necessary. Below, we’ll look at creating such an "Administrator" bot for a company using CS integration.
Creating Bots
At this stage, standard bot creation actions are performed. Since we've decided to create an example with CS, at this stage we create bots for each branch in accordance with the CS operations manual. After the bots are created and tested, we proceed to create the "Administrator" bot. This bot is created in the personal account, just like any regular bot. Integration with CS isn't required; it should know nothing about CS; its only task is to know what branches exist and find out from the client which branch they want to connect to. Therefore, we add a new bot on the "Bots" tab and write the basic instruction regarding the order of greetings, response styles, and the main task—determine the branch.
Once the "Administrator" bot is created, it is essential to set its name and describe its task in the instructions. All other settings are performed individually, based on the specifics of the particular task.
Creating Actions for implementing bot dialogue switching
In the "Administrator" bot, we navigate to the "Action" tab and create an action for each branch to switch the active bot:
Action Name - simply a name for display in the list.
Function Name - the name of the function the LLM model will see. It should be in English without spaces, representing the general sense of the action.
Function Description - a more detailed description of the action's meaning. Based on this description, Suvvy will understand when to invoke it.
Error Message - the message Suvvy will receive from the action in case an error is returned from the webhook. Can be empty, in which case Suvvy will get the error text from the URL where the webhook is sent.
Adding a Step
Within Action, you can call a sequence of actions using different types of calls, hence it’s called steps.
We need to add a step and select the step type "Switch the Active Bot":
When filling out the step form, your task is only to select the bot to which the dialogue will be switched:
Executing the Active Bot Switch
Overall, filling out the action description and names is sufficient for the "Administrator" bot to automatically call the required action and switch dialogue to the respective branch bot. However, there’s an option to directly specify in the "Administrator" bot’s instruction when to call each action:
With the bot switch implemented, we need not just to change the bot but also ensure the dialogue continues. In the basic scenario, we should indicate in the instructions which question should be asked to the client after branch change so that the client will be interacting with the corresponding branch bot.
However, this "basic" scenario does not account for when the client already mentioned the service they want, making it redundant to ask again about something they’ve already specified. Therefore, another option is to task the "Administrator" bot with creating a "summary" of communication with the client and passing it as an incoming question to the accepting branch bot. This requires adding an argument to the actions for switching the bot, where the "Administrator" bot can transfer this "summary," and add another step to send this summary to the receiving branch bot:
In the action description, we add information on what to pass to the argument and add the argument.
Add a "Bot Call" step.
In the step settings, specify the call to the same branch bot along with the request text to the bot.
Since we have a separate action for switching to each branch, the changes need to be made in each action (for every branch).
Bot Operation Analysis
Check the bot’s operation correctness in the personal account in the test chat. Select the bot "Administrator" in the window and start a dialogue. According to the instructions, it will switch the active bot and continue communication with the selected branch bot.
The presented example shows that the dialogue is conducted with the administrator bot, but the last message has already been formed by the branch bot, as this example implements the scheme of transferring the dialogue summary with the administrator to the receiving bot.
Order of Connecting Channels
Since the administrator handles the reception of the first message, incoming channels must be connected to the administrator bot. Do not connect channels to other bots.
Last updated
