Do you capture user input in your chatbot?
For example, do you ask them to provide their name, or email, or other information?
I have recently started using the following convention in the bots I am building (as well as advising on).
Suppose you have an intent which should get user’s email address. You can, of course, name it “EmailAddress”, but that isn’t very obvious.
Obvious to whom, you might ask.
Where you use it
The key, of course, is where you use the intent name.
One use for the intent name, for example, is in the test console. Looking at the intent name, you can tell what intent was just mapped. When you receive user input, you want the intent name to convey that some input was indeed received.
Another use is when you are accessing the agent via Dialogflow’s REST API. In this case, it is even more important to have the intent be as self-descriptive as possible because often you don’t have the additional context that you sometimes get when you are inside the Dialogflow console.
A final use for the intent name is in your training and history tab. Here again, you want the intent name to be as descriptive as possible. Almost certainly, you don’t want a misleading intent name in your training tab.
Suggested intent naming convention
Here is what I suggest. Name your intent based on the action which was completed – that is, what is the conclusion you can make from that intent firing?
If you are collecting the user’s email address, you can conclude that “UserProvidedEmailAddress”. That is how specific the intent name should be.
The next question is – how do we know that the intent is ready to accept an email address?
Usually, we set an output context on the previous intent which was triggered. For an intent which is supposed to collect an email address, we should have already set a context indicating that that’s what we wish to do.
Suggested context naming convention
So in the previous intent, set the following as the output context: awaiting_email_address
Or maybe you can use expecting_email_address.
A simple example
Let us look at a simple example. First, in your Default Welcome Intent, as soon as the user types Hi, ask them for their email address and set the output context to awaiting_email_address. This is what my welcome intent looks like:
Create another intent called “UserProvidesEmailAddress”. Now use awaiting_email_address as the input context, and add a few userSays phrases to collect the email address. This is what my intent looks like:
When you interact with the agent in the test console, you can immediately see the benefits.
The state of the agent becomes clearer
Note that the output context name for the Welcome intent immediately describes the state of the system.
A good intent name tells us that the agent is on track
For example, in the image below the intent name is “UserProvidesEmailAddress” and it is immediately clear that the agent is on track.
The history tab tells the story
This is one of nicest benefits of this approach. While you cannot always make the history tab narrate a story of how the conversation went, it is simple to observe for this particular scenario.
Just for kicks, I added an extra intent to capture the zip code, pretty much in the same way. This is what the history tab looks like:
If you can just read the history tab and already understand whether or not the agent succeeded (remember I haven’t yet shown you the UserProvidesZipCode intent), then you can see the power of using this approach. 🙂
So what do you think of this approach? Let me know in the comments.
- Actions Builder vs Dialogflow CX
- 5+ ways Dialogflow CX is better than Dialogflow ES
- How to bulk upload training phrases for Dialogflow Messenger
- Dialogflow CX vs ES: First look
- How to send rich responses from webhook to Dialogflow Messenger
- Dialogflow CX now generally available
- Dialogflow CX Missing Features
- Dialogflow Messenger integration for CX: First look
- Dialogflow Conversation Analytics Tips
- A simple method to evaluate multiple bot frameworks