Take Blip Bot Router Guidelines
By: Gabriel Rodrigues Dos Santos
Tags: Guidelines, Blip, Chatbots, Chatbot Design, Router

Redirect Messages

As previously stated, every redirect will have to be done using a message, that message should be a JSON, so you can customize it as needed but as a standard we use those fields:

Other standard fields to be used are:

"flow": "someId" which contains an identifier that allows you to send the flow to this particular state in the destination bot

which contains an identifier that allows you to send the flow to this particular state in the destination bot "custom": {"field":"value"} if you need to add more information use this field to do this.

if you need to add more information use this field to do this. "callback": {"serviceName":"name","flow":"someId","parameters":{}} use this if you need to send the flow back to another service after executing what you want.

You may want to create this redirect messages throughout a script as the blip UI limits the size of those messages to 140 characters.

Flow must go on

Bear in mind that when you redirect from one bot to another the flow in the origin bot will keep running until it gets to wait for another user input, that may lead to some issues and/or users stuck in the middle of your flow if not treated correctly.

To prevent that we should always send the user back to the start block, except for the main bot. That means that every skill of your bot should do your job and then come back to the starting point so it would know where to send the user next time it passes by. Its like your skill is a function or method, whenever you call it, it has to start from the begining.

Artificial intelligence

First of all, we must define a pattern which simplifies the consumption and maintenance of artificial intelligence (AI) in router architecture. You’ll probably have one or more AI model and will consume these AI models in all skills. And we must know where we should train and publish these AI models.

In the simplest case, we have only one AI model which answer about all matters of our smart contact. It doesn’t make sense to train and publish the same AI model over all skills. It must be trained and published only in main bot (never in the router to allow share one skill with different companies for example).

To use this AI model in any skill, we must create an API endpoint which encapsulate the analysis of the user’s message (instead of using blip’s output conditions).

The endpoint must be built using the following request and response patterns:

Request

Headers:

Body:

Response

Body:

In the complex case, we have more than one AI model in our smart contact, for example, a model which answer about Services and another one which answer about Products. In this case, the AI model must be trained and published in the respective skill for that service. The use of these AI models can be switched in the skills by changing the "AuthorizationKey" passed in the endpoint header's request.

Your smart contact can also have a specific flow to deal with valid answers detected by an AI model. This flow must be in the skill which contains the AI model to avoid replicating it over the others skills.

As a best practice, the API request to analyze an user’s message should be centralized in a skill’s specific state to avoid action replication. If this request returns a valid answer, the user must be redirected to the flow responsible to deal with this valid answer.

Use Cases

Regional Branches

If you gonna have different initial contacts with the same content or services like, for instance, a bot connected to whatsapp but with different numbers for each regional branch the company has, lets say Belo Horizonte and São Paulo, you just need to register all the services in all routers created and in the main bot you execute a Script like this:

The input parameter for this script is the Blip native variable tunnel.owner .

So now you have the origin of your router for the rest of the flow and you can add this information to the message being sent between your bots on the custom field:

Help Desk

This is quite common actually, your bot will need to send the user to a help desk if it is not able to find a solution to the user’s problem itself. For that, create a bot to handle only the help desk, so it will have any kind of checking for time frames, online agents, anything related to make the help desk service available or not.

Now, sometimes you will want a particular team to take the tickets of one of your services and another team if it is from another service. To solve that, before sending the flow to Help Desk, determine which team will be dealing with tickets from this services and send it with your redirecting messages.

For instance, on our Such WoW Pet Shop, lets suppose we have a team for dealing with Bath and Trim and another one to deal with Hotel. So when the service of Bath and Trim is called, one of the first things I could do is just set a variable hdTeam to "bathTrim" and if the user is redirect to Help Desk we will send a message like this:

Contact’s information

When the user is sent to help desk, the contact that is fetched by the Desk is the tunnel’s one, not the router’s! It means that changes on contact won’t reflect on desk.

To force the sub-bot to obtain the updated contact from the router, it is necessary to perform a few steps.

First Action (JS Script):

Input Variables: contact.serialized, tunnel.identity

Return variable: subbotContact