A common question that comes up is how to handle where the end user makes two utterances, but you only want to take action on one.

The most common being someone saying hello, versus saying hello with a question. You would want the question to take priority.

It’s very easy to do. You just do the following:

1. Create your first node with a condition of True and create your priority intents under this. Set your top node to jump to the first in that branch.
2. Create your second node which handles greetings.
3. Add a True node at the end of your important intents, and let it jump to greeting condition.

And that’s it! But that is the old style conversation way. Just before the new year a new version of conversation was released that makes this so much more simple.

The magic is in the first node.

Here we check to ensure that a greeting hasn’t been mentioned, then check each important intent.

With this method you don’t need any complex branches or jumping around. One important thing is to ensure that your less important intents do not have any training data that may cause it to pick it over the important intents.

Sample workspaces available.

There is one feature of Conversation that many people don’t even factor in when creating a conversational system. Let’s take the standard plan to spell it out.

• Unlimited API queries/month
• Up to 20 workspaces
• Up to 2000 intents
• Shared public cloud

Yep, you have 20 workspaces to play with! Most people starting off just use it for development, testing and production. But there is so much more. Putting it in context.

Functional Actions

For those new to Conversation, the first experience is normally the car demo. This is a good example of functional actions. In this case you know your application, and you want your end user to interact with it. So the user normally has prompts (conversational or visual) to allow them to refer to your user interface.

These offer the least resistance of building. The user is taught the names of the interfaces by using it, and are unlikely to deviate from that language. In fact if they do use non-Domain language, it is more likely a fault of your user interface.

Question & Answers

This is where you have collected questions from the end user, to determine what the answer/action that is needed to be taken.

Often the end user does not understand the domain language of the documentation or business. So training on their language helps making the system better for them.

Process Flows

This is where you need to converse with the user, to collect more information to drive to meeting their needs.

Multiple Workspaces

Most see this as just creating a workspace for development, testing and production. But using these as part of your overall architecture can dramatically increase the functionality and accuracy of the system.

Two main patterns that have been used are off-topic + drill down.

Off-Topic / Chit chat.

In this model we have a primary workspace which stores the main intents, as well as an intent for off-topic + chit-chat. Once one of these is detected, a second call is made out to the related workspace.

From a price point of view this works well if you are calling out to a subject matter that is asked infrequently. If the user will often ask these questions though, then the drill down method is a better solution.

Drill Down.

This model is where the user asks a question which has a more expanded field going forward. For example when you enter a bank you may ask the information desk about mortgages, who will direct you to another desk to go into more detail on your questions.

For this to work well, you need clear separation of what each workspace does. So that an off topic is triggered so as to pass back to the main workspace.

When planning your model look for common processes vs entities. The example above might not be good to separate by pets, as they will share common questions with a different entity. But you could separate between purchasing, accessories, etc.

As long as the conversation will not switch topics often then costs are kept down.

Multiple Workspace Calls.

This is not a recommended model as your costs go way up. It was originally used when there was a 500 intent limit per space (NLC).

If money is no object, then this model works where you may have more then 2000 intents, or a number of intents that share similar patterns but you need to distinguish between them.

You need to factor in if your conversation service is returning relative or absolute confidences. If relative, then responses are relative to their workspace and not to each other.

If you do have numerous intents, it may be easier and better to use a different solution, like Discovery Service for example.

While the cognitive ability of Conversation is what sets it apart from other chat bots, the skills in message shaping can even the odds. It is a common technique used in customer support when you need to give a hard message.

From a Conversation point of view, it allows you to dramatically reduce the level of work required to build and maintain. As well as improving customer satisfaction.

So let’s start with what is message shaping. Take this example: You own a pet store chat bot and the user says:

I wish to buy a pet.

You can start with “What kind of pet?”. Here you have left the users response too open. For a cognitive system, this on the face of it isn’t an issue as a well trained Conversation will handle this well.

But even if it does it still leaves you open to a lot of responses.

1. “What pets are there?” – Simple answer. Minimal work.
2. “What pet suits me?” – A process flow to determine this. Medium work.
3. “I want to buy a panda” – An endangered species. Again possible simple answer.
4. “I want to buy a puppy” – More details required. Medium work.
5. “I haven’t thought about it” – Could be simple or complex.
6. “A pet that is popular for millennials” – Now it starts getting crazy.

You will be driven to insanity trying to cater for every possible response coming back from the user. Even if you get a good response like “I want to buy a puppy” you may need to walk through to and fro, only to find that you don’t have that pet in the store to sell them.

So you can reduce complexity by taking control of the conversation. First you need to examine what the user hasn’t said. They haven’t said what kind of pet. This means they are unsure on what they want to get.

As a pet store owner, you know that certain pets are good for certain living conditions. So you can reduce and control the direction by saying something like:

I see you are maybe unsure about the pet you want. I can recommend a low maintenance pet, which are good for apartments or busy lifestyles. Or a high maintence pet which is good for families with a home.

Here you have given two options which dramatically narrow the scope of the next response from the user. It is still possible someone may go off script, but it is unlikely. If they do you can do a conversational repair to force them back into the script.

As the flow progresses, you can push the user to pets that you are trying to sell faster.

In doing so however it is important to understand that the end user must have free will, even if it is an illusion. For example if the person wants a puppy, it may be that a certain breed is not available. Rather then saying they can’t have that breed, offer other breeds.

If you give no options to the user, it leads to frustration. Even if given options which are not what the person wants, it is still better then no option. Actually if you shape your messages well you can give two options which lead to the same outcome, and the end user will still feel like they are in control.

Shaping through UI

Another advantage of message shaping is avoiding having to code complex language rules (Intents, Entities, Regex, etc).

For example:

Now you can see that the end user has not supplied all credit card information. You would need to code complex flows to cater for this. The information is clearly visible, and it could become a nightmare to parse to have it anonymised.

To solve all of this you can use the UI to force the user to structure their own data.

Watson Virtual Agent actually does this out of the box for a number of common areas.

Buttons are for apps, not for conversing.

For UI related prompts, try not to overdo it. For structured data it is fine. For buttons it can also be fine, but if you overdo it then it does not feel intelligent to the end user. As it starts to feel more like an application, the users have different expectations of the responses they get back.

Practise makes perfect

Don’t be fooled that this is easy to do. Most developers I have seen work with conversation fall back to looking for a technical solution, when only changing how you speak to the end user will suffice.

Even people working in support can take 6 months to a year to pick up the skills from no experience. Although it can be a bit harder having to do it on the fly versus creating a script.

For more reading on techniques, here is some stuff to get you started.

• The Customer Service Solution: Managing Emotions, Trust, and Control to Win Your Customer’s Business (Chapter 4:  Shaping your customer’s perceptions of control)
• The Leader’s Guide to Negotiation – Simon Horton
• Lateral Thinking – Edward de Bono
• Predictably Irrational – Dan Ariely

If you have gone into your conversation service since yesterday, you will find you have a new feature called System Entities. For the moment you only have number, percentage  and currency recognition.

For this introduction I am just going to use @sys-number entity to make Watson do simple math.

First let’s train Watson about the math terms we are going to use. For this we are going to use intents.

Why intents and not entities? Hands down Intents will mean very little training for it to understand similar terms. Also as system entities, are also entities they can interfere with any logic you put in. I use the number “42” so as to not bias the classification to a particular number.

Next we go to entities and switch on the @sys-number entity.

Now for dialog, first we want to make sure what the person has said is a valid math question, if not we say we don’t understand. We do it with the following conditional statement.

intents.size() >0 
AND intents[0].confidence < 0.30

This will ensure that the system only responds if it is confident to do so. Next we put another node in which checks to see if the system is unsure.

intents.size() >0 
AND intents[0].confidence < 0.60
AND entities.size() == 2

Now you will notice we are using entities.size(). This is because the numbers are entities, and @sys-number doesn’t have the size() method. We want to make sure that the end user typed in two numbers before continuing.

Now what we have done that, the procedure is more or less the same for each action, so here is just the addition.

The answer is <? @sys-number[0].numeric_value + @sys-number[1].numeric_value ?>

This takes the first and second numeric value and adds them. While conversation will recognise numbers from text and take action on them, it won’t always do this. So we have to use the numeric_value attribute.

While mostly fine, there are issues you won’t be able to easily cater for. For example the importance of the numbers location.

Take for the example the two questions which are the same, but will give very different answers.

• What is ten divided by two?
• Using the number two divide up the number ten.

One way to solve this is just to create a second division intent which knows the numbers are reversed, but more likely you can solve this with message shaping.

You will find a similar issue though when you start to use the other system entities. For example if you have @sys-percentage active, then “20%” is not only a percent, but it is also a number. This makes it tricker when trying to read the entity or @sys-number stack.

For what comes back from conversation, you will see that the entity structure has changed.

"entities":[{
    "entity":"sys-number",
    "location":[17,32],
    "value":"200",
    "metadata":{
        "numeric_value":200
    }
}

Now you have a metadata field which you can get the numeric value from.

As always, here is a sample conversation script.

When building a conversational system, how you handle off topics tends to swing one way or the other for people new to it.

They either totally forget about handling chit-chat/off topic. This leads to the system feeling stupid to the end user, even if it has a high accuracy. Or feeling like a search engine.

Or they go the other way and try to answer everything they can possibly think of, without realising the rabbit hole they are going down. Also they may only put in one response to the same type of question, making it feel like a computer program.

The correct way to handle off topics is: Answer the topic not the question, and drive the user back to the intended usage of the conversational system! 

To give an example:

User: Hey Watson, do you love Siri?
Watson: I have never really thought about other AI systems. I am too busy selling goods for pets.

User: Please tell me if you love Siri.
Watson: I would much prefer to help you in buying things for your pet, rather then talking about Artificial intelligences.

User: But do you love Siri?
Watson: Can we please get back to buying things for your pet.

The first response detects that the person is talking about an “AI” related item. But instead of trying to expend time on the nature of the question, you can deflect it with a broad response.

The second response is the same but a bit cooler, and pushing the user back to the topic.The last response stops playing with the user.

You can achieve this quite easily with the following advanced output.

{
  "output": {
    "text": {
      "values": [
       "I have never really thought about other AI systems. I am too busy selling goods for pets.",
       "I would much prefer to help you in buying things for your pet, rather then talking about Artificial intelligences.",
       "Can we please get back to buying things for your pet."
      ],
      "selection_policy": "sequential"
    }
  }
}

Someone playing with the system however will have it return to the first response on the 4th try. So you can set a counter that say after X number of off topic responses, then have it either redirect to a person, or stop responding completely.

The detection part is tricker. One way to approach this is to have a single intent that detects off topic, and then use a second workspace to drill down to the related off topic. This prevents polluting your main intents, and only requires further calls when needed. I may go into more detail on this later.

For more information on how to handle off topic/chit chat and much more, I strongly recommend doing the Designing Conversational Solutions (Watson Conversation Service) training.

In Watson Dialog the use of counters was pretty easy. In Conversation it is as well, but not as intuitive yet. Here I am going to explore three methods of building and using a counter.

First to create a counter, you need to go to advanced mode in your node. You can then type in something like the following.

{
  "output": {
    "text": "Keep saying T1"
  },
  "context": {
    "countdown": 3
  }
}

A common mistake that people make is to forget to add the comma after the output block. Conversation will normally make the editor window red, but doesn’t give any hints if you do this. Worse still, if you don’t notice the red block then Conversation will revert that node if you attempt to test or edit another node.

After this we create a node with the following output.

Counter is at: <? context.countdown-- ?>

This tells conversation to display the counter we made, then decrement it. Within the nodes condition we can check to ensure the counter is greater than 0, if not then move to the next node to tell them you are finished. For example:

Hiding the counter

Now you may not want the end user to be able to see the counter. In which case we need to mask the executing code from being rendered. To do this we create a node with the code to execute as follows:

<? context.countdown-- ?>

You then set this node to continue from another node, linking to the output (very important!). In the second node, you put the following into the advanced output window.

{
  "output": {
    "text": {
      "append": false,
      "values": [
        "Still counting down."
      ]
  }}}

What this does is generate output “Still counting down.”, but because “append” is false, it will erase the previous output. So the user only sees this message.

Do you really need a counter?

The simple solution can be to not use a counter at all. The following code for example will simulate the previous example by just cycling through custom responses.

{
  "output": {
    "text": {
      "values": [
        "Keep saying T3.",
        "Counting down 3",
        "Counting down 2",
        "Counting down 1",
        "Counting finished!"
      ],
      "selection_policy": "sequential"
    }
  }
}

Here is the sample conversation script you can play with.

Important reminder!

If you use the counter in your conversation flow, you should be responsible for it! It is good coding practice to declare it in the conversation.

Apart from being able to test, it allows you to see where the application layer would likely set the counter. Plus if something failed at the application layer you can trap easier.

Depending on the complexity of your conversational flow, you may sometimes want the application layer to handle modifying the counter. This is fine as well, but still initialize in conversation, even if the application overwrites that initialization.