Watson Assistant is a powerful cognitive solution which lets you quickly build a virtual assistant. But with the wide variety of features available, you need to be aware how best to utilise them to build a successful assistant.
The feature we’ll be looking at in this article is multiple conditioned responses.
Please note, this article assumes you are aware of dialog nodes (see the Dialog Overview page for more information).
Multiple conditioned responses allow you to provide different answers based on conditions related to the intent — all in one dialog node.
A very simple example would be a customer saying “Hello” to your assistant. Typically, you would have a single response (such as “Hello, I am here to help you with…”). But, you can customize the node to provide a different answer based on certain criteria.
For example, responses which differ based on the time of day, or, responses which incorporate the customer’s name to provide a personalized response.
The scenario below provides a greeting based on the time of day. The conditions here are looking to match to:
- Time of day which is after 5:59pm and before 11:59pm
- Time of day which is before 12pm (noon)
- Time of day which is before 6pm
- True condition (default/catch-all value)
The system will look at these conditions (starting from the top of the list and working its way down) until a match occurs, then it will send the corresponding response to the customer.
A Closer Look
At its core a normal response node has a single intent which provides a single response (or a single response with slight variations).
A conditioned response is different to a standard response as the customer will see a different answer based on:
- Their previous interactions with the assistant
- External criteria, such as the time of day
Typically, the multiple responses will be based on data collected about the customer during their interactions to personalize the conversation.
As mentioned, the conditions are processed from top to bottom. If an important condition is further down in the list, it will be ignored if the system finds a matching condition further up.
Let’s look at the Hello/Greeting example.
The first item (1) in our conditions list is set to “now().after(’17:59:59’)…”. This is checking to see if the current time (now) is after 5:59pm and before midnight. The system will look at this first condition and compare it to the time. If the current time is anywhere between 6pm and midnight, it will respond with “Good evening…”.
If the condition is not met (in other words if the time falls outside this range), the system goes to the next condition in the list and checks to see if that condition can be met. In this case, it checks to see if the current time (now) is before noon. If it is, it responds with “Good morning…”.
If that condition isn’t met it continues on to the next. The system will continue processing the list until it either finds a condition which matches, or it runs out of conditions to check. That’s why it’s important to make a note of which conditions should take priority and the logical steps between them.
If we had item 3 — now().before(’18:00:00’) — in position 2, the system would be saying “Good afternoon…” at 8am, because 8am does indeed occur before 6pm!
In this example we used a function called now(). But you can use any criteria/condition in your node such as entities (see article Beyond Coding: Watson Assistant Entities — Part 1, A Quick Overview for more information about entities).
You can also find more information about the now() function at the Dialog Methods page.
The more common conditions implemented are:
- Check to see if a context item has any value associated with it
- For example, does the customer own any banking products?
- Check to see if a specific value exists for a context variable
- For example, does the customer own savings product ABC?
- Check to see if an entity has been mentioned
- For example, has the customer mentioned a specific product name in their question?
- Default (true) value
- The default response provided if the previous conditions haven’t been met.
Multiple conditioned responses can be a combination of the above conditions, they are not limited to only one scenario or condition type.
Implementing Multiple Conditioned Responses
Let’s create a conditioned response node to see how the process works.
To create conditioned response nodes, you will need to tell the system to change the behaviour of the node.
First, select the node you want to modify. Then click on the Customize option at the top of the node details.
The system will now open the customization window for the node. Note, this is not a global setting, this customization option is only for the node in which you select Customize.
At the bottom of the new window you will see a section titled Multiple conditioned responses. This is the option which will activate the feature for the node.
Simple click on the Off setting to change it to On, then click on the Apply button.
If you don’t click on Apply, the setting will not take effect and your node will remain as a simple single response node.
Now that you’ve applied the Multiple conditioned responses setting, your node will show a different display in the Then respond with: section. It now contains two columns/areas — If assistant recognizes and Respond with.
These options control how the system processes the conditions and what happens once the condition is met.
Now we come to the condition list — remember, the system processes the conditions in the order provided. The first condition is processed, followed by the second, then the third etc, until a condition is matched, or there aren’t any other conditions to check.
So, it’s simply a matter of adding a condition and its corresponding response. In this example we’ll use a context variable to check if the assistant knows the customer’s name. If you need more information about context variables, see the Dialog Runtime Context Variables page.
When you want to add another condition, click on the Add response plus sign (+).
In this case we will add a “true” condition to the node.
You should always include a default (“true”) condition at the end of the list. This will always trigger a response and ensures the customer receives an answer/acknowledgement.
We now have a multiple conditioned response node!
Customizing Conditioned Responses
If you ever find that you can’t see the full text of a conditional response, or you need to see the details for the response, simply click on the Customize response option beside it (the cogwheel next to the response).
This will expand the condition and allow you to specify whether you want to set a context value on the response, if you want variations of the response for the condition and, most importantly, what you would like the system to do once it has reached this condition — the And finally drop-down.
What this extremely useful option allows you to do is select whether the system performs the default action for that specific response (Default to node settings), or whether the system moves to another structure/node in the dialog tree (Jump to…).
With this option each conditional response can lead the customer to a different pathway, if desired.
For example, if we know the customer’s name, we might know more information, such as the products they own. In that case we can set the conditional response to jump to a node which discusses cross-selling a product.
With the ability to change the behaviour of the individual conditional responses, you can further personalize the conversation.
Multiple Conditioned Response Recommendations
When creating a conditioned response, you should consider the following aspects — some of which have been briefly discussed here:
- The requirement for the multiple conditioned response
- The scope of your conditions and their placement
- The response provided by the conditions
- The final behaviour of the condition
Multiple Conditioned Response Requirement
Consider whether a conditional response is the correct option for the intent. While they are useful, they’re not necessarily always required.
Sometimes a single, straight-forward answer can be just as, if not more, useful. With the ability to create variations on single responses, you can still provide an engaging interaction.
A rule of thumb should be whether the intent you have built consists of multiple questions or refers to multiple subjects which differ in their behaviours.
For example, an intent may be “#Product_Application” and the examples for that intent consist of “How do I apply for product ABC?”, “Where can I get Product XYZ?”, “Can I apply online for Product 123?”.
Here we can see the main topic for the intent (applying for a product) mentions three different products (Product ABC, Product XYZ and Product 123). Consider how a customer would apply for each of these products.
Does the customer use the same web page to apply for a product? If so, a single response is most useful.
Does each product have its own application process? If so, then conditional responses are most useful.
Condition Scope And Placement
When adding conditions to your conditional node, consider the order. Since the system processes the conditions from top to bottom, will one condition block another?
The best approach is to provide specific conditions higher up in the list, general conditions further down in the list and the default (true) condition as the final item in the list.
For example, we may want to check if the customer owns Product ABC and if they have owned it for more than 3 years. This is a specific condition — the number of people who meet this condition would be considered a sub-set of Product ABC owners.
Further down the list (or the next condition) would be a check to see if the customer owns Product ABC. This general condition addresses the wider group of Product ABC owners.
Then the final condition, the default (true) condition, is triggered if the previous conditions haven’t been triggered. In other words, we’ll provide an answer, but it won’t be specific to Product ABC.
Remember that with multiple conditioned response nodes, you need multiple responses (as the name suggests). There’s little point in having conditional responses if the response is going to be the same for all scenarios.
This is an important factor to consider. This aspect of multiple conditioned responses ties closely with the next (Response Behaviour), and typically both would be considered together.
For now, let’s only consider the responses provided. If the response is the same for all conditions of the intent, then you need a single response node.
If the responses are different for each condition of the intent, then you want to use conditional responses.
The next thing to consider is the wording of the response itself. Specific conditions should have specific answers — for example, owners of Product ABC who have owned it for 3 years or more, could receive a specific answer mentioning the product, the fact that they have owned it for 3 or more years and the answer to the intent.
General conditions should provide more generalised responses — for example, owners of Product ABC could receive an answer mentioning the product and answering the intent.
Finally, the default (true) condition would provide one of two possible responses:
- A general response to customers to address the intent, or,
- If the conditions are important to the response, ask the customer to clarify which product they want to discuss
This means the customer will always have their interaction addressed.
The default (true) condition should always be included in your condition response nodes. While we can create many conditions to try and personalize a response, there will be times when we forget about a specific condition, or the way we handle conditions changes, and we need a mechanism to ensure the assistant always responds.
Typically, a default (true) response indicates to the customer that the assistant has understood the question and addressed it. Not adding a default (true) response can lead to the customer not receiving a response at all. This makes the assistant seem like it didn’t understand the question, or worse, that it has broken down.
When considering the responses, you will also consider what happens after the response has been provided. You want your assistant to provide an answer to the intent, but you also want it to behave accordingly.
When deciding whether to use conditional responses, examine the need for the subsequent actions taken. Does the assistant need to move to a different part of the system to continue for each condition? Does it simply provide the response and wait?
If the response is the same for all interactions, but you need the assistant to perform different behaviours, you don’t need a condition response node. Likely you need a standard single response node with children nodes which handle traffic flow between your design structures.
If the behaviour differs for each condition and the response is different for each condition, then a multiple conditioned response node is the best option.
If you need different responses for each condition, but the subsequent behaviour is the same for all conditions, then a multiple conditioned response node is the best option.
Remember, the combination of the previous topic (Responses Provided) and this topic (Response Behaviour), typically work together when deciding to use a conditional response.
The above related areas can sometimes seem overwhelming, or confusing. Simply remember the following to identify the different aspects:
· Multiple conditioned response requirement — consider the intent and how it drives the response(s)
· Condition Scope And Placement — consider how the list of conditions will be processed
· Responses Provided : regardless of the intent, consider whether the responses rely on additional, possibly external criteria to change the response. For example, from “Good morning” to “Good evening”. Or the length of time the customer has owned a product might change a cross-selling response.
· Response Behaviour : consider the subsequent behaviour after the response has been provided
The lure of using conditional responses throughout the build is ever-present, but if you consider each of the aspects mentioned above, you will begin to easily identify when to use this feature.
Multiple conditioned responses provide a simple, but powerful, way to personalize your assistant’s interactions and introduce added intelligence to the assistant’s responses.