Undestanding bot and subbot hierarchy (or architecture)

The construction of flexible software, to solve a problem, provides those who built it, the power to replicate and reuse it in different contexts.

Technology companies, for example, build software on a daily basis and almost always reuse it to solve new types of even more complex problems.

Think of a bank. Even before building an application, capable of displaying an account holder's balance, a financial institution needs software capable of processing the client's balance over the past 24 hours.

Ideally, if this same customer wants to check their balance through the bank's website, the same processing software will be used to return the amounts. Realize that the processing software has become a bank asset and can / should be reused whenever necessary.

In the world of bots something very similar happens. Your company can count on different points of relationship with customers, subdivided by products or channels. However, it is a fact that at some point the subject / content being discussed may be the same in different locations.

Thinking about this problem, Blip developed the concept of bots and subbots. Through a bot router - bot responsible for managing the subbots, it is possible to create a hierarchy of subbots that work together during user interaction.

One of the advantages of working on this model is having the possibility to reuse an already built bot within a new bot. Imagine, for example, a company that has branches in Brazil and the USA.

The Brazilian branch needs a bot capable of meeting customer requests in Portuguese, while the North American branch needs the application to be able to meet customer requests in English.

In this scenario, an interesting solution would be to build two bots, one for each language and cultural context.

However, the company has just closed a new contract and will open a new branch in Dublin, Ireland - a country that has English as its official language, but has a large concentration of people who speak Portuguese.

It will now be necessary to build a new bot capable of responding to customers according to the customer's preferred language (Portuguese or English).

A possible solution for this scenario is to build a new bot with the replication of all the data / contents of the previously created bots. However, this is not a very flexible solution, since the data would be duplicated in different locations.

Through the Blip bot and subbot hierarchy, it is possible to solve this problem by adding 2 new bots.

The first will be the bot router - the bot for the Irish branch, capable of conversing in any language, and the second will be the main bot, responsible for finding out the user's preferred language and sending it to one of the existing bots (Brazil or USA).

The drawing below shows the architecture of this solution.

Note that the subbots continue to work to serve the branches (Brazil and USA) directly, and now they can also help to serve customers in Ireland indirectly.

In addition, any corrections or changes made to the Brazilian Branch or US Branch applications will also be available to the Irish bot.

Before you start using the Blip bot and subbot hierarchy, you need to understand some theoretical concepts:

Bot Router - bot responsible for managing the subbots. This is the bot that the customer will see, so it is this bot that should be published and tested on the channels. The bot router has no rules or content, it only has the reference of all subbots. Any bot router must have at least 1 subbot.

Main SubBot - Whenever a user talks to a bot router for the first time, he is directed to the main subbot of the hierarchy. He is responsible for defining, for the first time, which subbot will serve the customer. If the bot router has only one bot, it will be the main bot.

Subbot - Any bot belonging to the hierarchy of a bot router.

Service - Every subbot is recognized as a bot router service. This name is necessary so that subbots with the same name can be used within a bot router. You will need to give a name (Service name) for each subbot. This will be the name used to reference your subbot during the exchange between bots.

Redirection expiration - It is possible to define a downtime for each subbot. Imagine a subbot that can only serve the customer at a specific time. Thus, the expiration time defines a limit, in seconds, of the period during which this subbot must be active in the conversation in relation to the last interaction of the client.