This article was originally published on QBox’s blog, prior to Cyara’s acquisition of QBox. Learn more about Cyara + QBox.
You wish to progress from building a simple Dialogflow ES chatbot to more complex, multi-step dialog-based interaction with an AI assistant in Dialogflow CX? Many Dialogflow users are making this upgrade now, but the step up to CX comes with significant changes to how you approach the building process. We will outline the process of chatbot design and best practices for CX here, followed by a second blog where we look in more detail at how CX specifically handles low confidence and misclassification of intents.
Learn how you can optimize your chatbot performance with Cyara’s conversational AI testing and monitoring solution.
How is Dialogflow CX Different from Dialogflow ES?
The most obvious difference is that CX features a graphical interface (see Fig 1) with dialog fulfilment processes that are easier to interpret than the node and table-based display of ES (see Fig 2). Your interactions with ES would have been purely text-based, whereas much of how you interact with CX will be done clicking on bubbles to edit the flow diagrams.
Figure 1: The “Claim Status” flow in Dialogflow CX’s example Healthcare chatbot
Figure 2: The Intent-editing page in Dialogflow ES
This flow-based structure in CX allows for a more nuanced conversational interaction with the user. In ES, a user may ask to “check their bank account” which would activate a “checking_account” context and unlock new context-specific intents, but in general, most interactions would have a single-step response or other simple fulfilment. While in CX, when a user asks the same thing, they can be taken down a “route” that then prompts them for more information and only allows for related queries.
CX is better suited for larger-scale, multi-bot approaches than ES is; it can house multiple chatbot agents in a project whereas ES can only have one agent in a project. Each agent can be more easily scaled in CX because each agent can have one or more flows (each flow equates to its own NLU model), and each of those flows has their own pages, all of which can be edited independently.
Figure 3: Example of an agent containing multiple flows and their own pages
CX is also equipped to allow the agent to query a different flow depending on where in the conversation the user is, allowing the chatbot builder to focus their training efforts and avoid unnecessary confusion. This can also have drawbacks as we will find out later. You can train each flow with either “standard” or “advanced” machine learning, where the latter will tend to have higher accuracy and confidence but will take longer to retrain each time changes are made.
There are other minor differences relating to how parameters and errors are handled, but the above information is all you need to get started on the best practices for structuring your improved CX chatbot.
Intents and Routes in Dialogflow CX
The basic structure of intents and how they work is the same in CX as it is in ES (see Fig 4), apart from the addition of new “Default Negative” intent that cannot be deleted. The Default Negative Intent is initially empty but can be trained on “negative” phrases—i.e., user utterances that are outside of the subject matter you want your bot to cover. This Default Negative Intent is discussed in more detail in Part 2 of this 2-part blog.
Figure 4: How model intents are listed in the “Manage” section of the bot-building interface on Dialogflow CX
While much of how you design and train intents will be the same as in Dialogflow ES, intents are now used to direct the user along only the declared routes between pages. Routes can be triggered by either an intent classification or by certain parameters being extracted from the user (e.g., this is a new customer, they have <£50 in their account, they have asked for a business rather than personal loan, etc.).
This means that, depending on where the user is in a conversation, only the intents that are mapped to the routes on the current page will be available to be triggered by the chatbot user. If an utterance matches an intent that does not correspond to a route on the current page, then the bot will simply respond with a “no-match” event, which by default results in the bot asking the user to try again.
This functionality allows you as the bot builder to tailor the bot’s state more tightly at each step of the user’s conversation and avoid taking the user down inappropriate route paths. There is a downside to this though, the user cannot break out of the conversation.
Routes in and out of each page are often going to be controlled by intents, so when you are mapping out all the intents in your chatbot model (usually one of the very first steps), you should keep in mind that the intents you create can be used for multiple purposes. For example, you could create the following intents:
- Yes: Phrases like “yeah,” “yup,” etc.
- No: Phrases like “nope,” “no thanks,” etc.
Use those phrases multiple times across several different pages in your flows.
However, it should also be noted that each flow is trained separately on the pool of intents currently assigned to its pages. When considering the potential for confusion between intents, remember that intents are being considered alongside the other intents that appear in the current flow, not just those defined on the current page.
Flows in Dialogflow CX
A chatbot in Dialogflow CX is made up of one or more flows (illustrated in Fig 1)—conversation paths which can take different routes depending on the responses and requested topics the user gives the bot. End users will always start at the Default Start Flow and it is up to this flow to direct them to other flows. Each flow contains “pages” that represent steps in the conversation and can redirect to other flows as well. A simple bot with limited fulfilment processes will only require a single flow, whilst a more complex bot can cover a wide subject area with several interconnected flows.
Once you start adding additional features, like handling requests for additional information from the user, even the flow structure in a small-to-medium bot can become complex and difficult to manage as a single flow (see Fig 5).
Figure 5: One of the 3 flow structures in Dialogflow CX’s example “Healthcare” chatbot, which handles locating a nearby doctor that covers a customer’s insurance
Because of this, it is recommended you consider splitting your bot into multiple flows from as early as the planning stage. This can be done by identifying the subject matter categories (see Fig 6 for an example) across all your mapped intents, and building a separate flow for each sub-category, in addition to a start flow that directs the user to the right category when they first interact with the bot.
It is also beneficial to split your chatbot into multiple flows because intents will only be trained together with other intents that appear in the same flow. If your chatbot has five intents but only two of them appear in a flow, then only those two will be trained together and compared for prediction while in that flow. This can be useful in improving intent recognition if your chatbot has accumulated many intents during scaling.
Figure 6: The three flow topics in the healthcare bot, plus the structure of the “Start Flow” which decides what flow a user should go to
Pages in Dialogflow CX
Flows are made up of pages connected by routes, which are decided by either intent classifications or certain parameter values. It can be useful to think of pages as steps and signposts within the conversation, and the route decides which way to go. Each page is either identifying what the customer needs or asking for more information to help them, before proceeding to the next page, another flow, or ending the conversation altogether.
Within each page you can edit features such as what the bot initially says to the user, what the active Parameters are, and what routes are available to the user based on what they say or what information they provided—see Fig 7.
Figure 7: The Default Landing Page which handles user interactions when they first start talking to the healthcare chatbot and pick a route based on what intent is detected. Since this bot is designed to be used via phone you can see a “Dual Tone Multi-Frequency (DTMF)” parameter.
Once you’ve designed the basic outline of your flows, you can start building your pages. Based on your flow outline you should have some idea of what intents and parameters will be required at each step, and what possible final destinations you expect for a user. Mapping out the steps in your ideal customer journeys should give you an idea of how many pages, intents, and parameters you need—what intent are you expecting at each step? What information do you need from your customer to proceed to the next step?
An important feature to keep in mind is that once you’re on a page, an intent will only be matched if you have assigned a route for that intent on that page. For example, in Fig 6 there are only 12 intents that trigger a route (plus one parameter value), but 36 intents in the bot in total (shown in Fig 4). This means that if a user triggers a match with an intent that does NOT have a route out of this page, they won’t proceed.
An issue with this approach is that you will risk users becoming stuck if you don’t have appropriate error-handling (e.g., taking the user back to an earlier page after a certain number of failures) or haven’t anticipated some interaction steps that might require new intents or routes. Thus, it is essential to methodically go through how users interact with each page.
Summary
In this blog we’ve briefly summarised how Dialogflow CX differs from ES. We also outlined the basic structure and building blocks of chatbots in CX. Within that framework we have highlighted a few pointers for you to consider when you start building your first chatbot in CX:
- Dialogflow CX is better suited for large, complex chatbots with multi-step fulfilment processes. Dialogflow ES is still sufficient for building effective single-step question-answer bots.
- When building a large bot or one with complex fulfilment processes, you should identify a few subject matter areas from your intent pool and make a separate flow for each. This both makes it easier to manage and scale the model and allows you to narrow down how many intents are being compared for classification in each flow.
- Limit the number of intent and parameter routes that connect your pages. That way you can better control the user’s place in the conversation. Just remember to consider error-handling and test thoroughly.
- Because the way pages are structured allows you to limit and re-use intents, you can be flexible with their design and use, e.g., handling yes or no answers to take you down different paths depending on what flow or page the user is currently on. Be sure to design your training data to reflect the multi-purpose nature of your intents.
