Dialogflow is a development suite for building conversational interfaces commonly called assistants. For starters, Dialogflow comes in handy: It’s easy to add, simulate responses; integrate your agent with the platform of your choice and also keep a check on your analytics!
Although it looks simple and straightforward, there are a few tips that could make it easier for you.
If you too are looking to build a bot, you need to know these 5 things before you go ahead with it!
1. The idea behind a smart assistant is to make it as direct and user friendly as possible.
If it’s trained to expect only definite inputs, how will it tackle ambiguous requests?
Sometimes your agent will need to pose questions to users to get the details you need. In that case, your questions need to be to the point and clear. Keep your questions direct- guide the users to answers you want. Human brain tends to begin an answer from the format of the question at most times.
Suppose your bot wants the user’s location, you need to first decide from the list of system entities which one will be easier for your to process- location, address or cities etc. Pick your entity and frame the question to get the right details.
Take the following conversation for example,
User: Find me a good Chinese restaurant nearby
Agent: Sure, Where do you stay?
User: I stay in the Bay area
In the above example, the user reply could be anything starting from her city to street address. If your agent doesn’t ask appropriate questions, the user input will not be useful for processing.
So, your agent could respond with a question like “Sure, I’ll need your address for that.” instead of “Where do you stay?” which could give rise to a range of user inputs.
This way, you can avoid input mismatch from the user and tailor the request to closely match with the agent’s expected one.
No more fallback responses from your agent 🥳
2. Naming parameters
Why is the name of your parameters important? Because it’s a unique identifier for the parameters you will be receiving- It is relevant to the intent but unique within the intent.
Take the case of user details where your assistant gets some user information. You could name the action as ‘getUserDetails’. Here, the parameters need not contain the word ‘user’ in every field: userName or userMail. This is because, the fulfillment request contains both the action and the parameters. Each parameter is received in context with the intent.
Next, when we have intents with follow-up, we need to be careful about the parameter name belonging to each intent. The fulfillment response contains a list of parameters in the output contexts from the final intent that triggers the webhook. Parameters with same names are like variables with the same names. The value gets replaced. Suppose you want to get two locations- the user’s location and the destination location, you cannot generalise the parameter name to be ‘location’. If you do that, the fulfillment response will be overwritten to contain only one of the locations. So, you must give distinct yet relevant names like ‘currentLocation’ and ‘destLocation’.
You will get the request with distinct parameters which can be easily processed!
3. When you’re your agent for non-linear dialog, the agent needs to remember the context. The parameters that you get from each intent, needs to be available till the point of fulfillment is reached. Now here comes the catch: setting the right lifespan.
Lifespan is nothing but the number of exchanges for which your agent must remember the context. Suppose our dialog is like this:
> User: I want to send an email>> Agent: Sure, to whom do you want to send the email?>> \----->> User: To [email protected]>> Agent: Is this email correct: [email protected]>> \----->> User: Yes. It's correct>> Agent: Alright I'll send this mail for you!We have 2 exchanges here: Ask and get the correct mail; If yes, send the email.
So our ‘mailID’ parameter has to be alive for 2 exchanges. Just to be on the safe side and to make sure that you receive all the parameters you need, you set your lifespan as 4, the next intent that gets triggered, carries this parameter along with itself. When the parameter from a previous intent is still alive, it creates confusion while you process the user’s request. To keep it clean, setting the right and minimum lifespan is key and could save you a lot of time and effort.
To read more son setting the right lifespan, see Optimal Context lifespan
4. We see that Dialogflow gives us plenty of system entities. When we can’t fit our parameters into any of these entities, we might think of using sys.any and sys.any could literally mean anything!
This could bring you problems in the form of wrong intents being triggered and irrelevant details extracted as entities.
To avoid ambiguity, avoid using sys.any. Always remember, you can create your own set of entities or even upload one to your agent! So stay away from sys.any. Even if it’s just a single reference entity, keep it custom. Beware of the ambiguity sys.any could bring you!
5. The Help Intent
Whenever a user is talking to your bot for the first time, they must know what your user can do. Most platforms support the ’/’ command format in which you can include help. This is your card to directing the conversation to how the user could ask your bot for information. So, Don’t forget to add the help intent. Give examples of how the user could ask and keep it simple. Remember, humans are lazy and random. If you have default responses, give 4-5 variations. You can avoid the ‘bot-feel’ this way.
There you go! Those are some important tips that could help you get some clarity with Dialogflow entities,intents and contexts.