Category Archives: Chatbots

Conditional fields using IBM Watson Conversation Slots

I’ve been playing a little more with the Slots feature in IBM Watson Conversations and hit a few issues that at first seemed like they could be a problem. One scenario in particular that took me a while to solve, was how to build conditional logic into a node with Slots.

Let’s say that we are walking the user through a process and in the middle of that process a decision needs to be made based on a value collected earlier in the process. This is a common feature of a workflow, it’s obvious how it is done using multiple nodes but how do we do it in a single node using Slots?

I’m going to stick with the example process (Open Account) I’ve used before and extend the completed workspace from this previous post (Read that post first for background). When you’ve worked through the steps in this post it should look something like this completed workspace.

The diagram below details the workflow we are going to follow to implement our process.

conditional_slot_flow

So our process is the same as in previous posts with the addition that if the @Subscription_Type is Annual we’re giving away a free t-shirt and need to collect the size. Our challenge is to be able to complete this process in a single node using slots so that we only ask for @TShirtSize when the @Subscription_Type equals Annual.

To perform this kind of condition slot we need to understand two things about the way slots work.

  1. Using the Slot editor on the slot we can use the JSON editor of the Found/Not Found conditions to update the context
  2. A slot is fulfilled when the context variable in the “save as” field has a value

With these insights in mind our solution will

  1. Update the definition of the @Subscription_Type slot so that it updates context with "TShirtSize": "NA"
  2. Add a slot with the “Check for” condition set to @TShirtSize and the “Save as” field set to TShirtSize

Start by adding an entity called @TShirtSize to the workspace and add values for Small, Medium and Large.

Next, select the #Open_Account node and click the Screen Shot 2017-06-26 at 16.35.27icon for the @SubscriptionType slot to open the editor.

Screen Shot 2017-07-31 at 14.01.09

Find the section that says “When user responds, if @Subscription_Type is…”, select the “Not found” option and add a condition for @Subscription_Type:Monthly.

Screen Shot 2017-07-31 at 12.00.28

Click the Screen Shot 2017-06-26 at 16.36.08 icon, select Open JSON editor and add a statement to set the context variable TShirtSize to “NA”.

Screen Shot 2017-07-31 at 12.03.14

Save the @Subscription_Type slot and add a new slot with a “Check for” value of @TShirtSize, “Save as” value of $TShirtSize and “Would you like a Small, Medium or Large t-shirt?” in the “If not present, ask” field as shown below.

Screen Shot 2017-07-31 at 13.54.36

To finish off our conditional slot we’ll add a conditional response to demonstrate that the final responses can also be tailored to our process and business rules. To do this, open the #Open_Account node, right at the bottom of that node you will see a section for “Then respond with:” which can have conditions attached to responses.

Click the add condition link above the current response and add a condition of $TShirtSize=="NA" then click “Add another response” and enter the text as “Okay, I’ll open your $Account_Type with $Subscription_Type payments and send your $TShirtSize t-shirt right now.”

Screen Shot 2017-07-31 at 14.17.15

Go ahead and test the workspace, in particular try out both Monthly and Annual subscription types to verify conditional t-shirt size question only gets asked when it should.

Using this approach you can build really quite complex decision trees without having to create trees at all, moreover your decision trees will allow users to provide information in a flexible manner, one at a time or all at once.

In my next post on using Slots in IBM Watson I will discuss how to add slots for non Entity conditions and how to deal with numbers where zero (0) is a valid entry.

Advertisements

Using Slots to collect data in IBM Watson Conversations

A new feature was released in IBM Watson Conversations earlier this month called “Slots”. This feature allows the collection of data from users to be configured in a more data driven and succinct manner than was previously possible.

In a previous post, I explained an approach for recursively collecting information that relied on configuring a flow with “Jump To” conditions or “Continue From” as they were called back then.

Using slots is pretty easy once you’ve done it a couple of times and the resulting node structure is very simple even in quite complex use cases. Let’s update my example from previous posts with this new approach.

Download the starter template which contains the basic structure and import it into a Watson Conversations Instance (see here for how to import). The workspace includes a couple of intents (Open and Close Accounts) and two entities (Account and Subscription Type). The basic idea is that we are building an assistant that will help us open an account for which two pieces of information are required.

Once imported use the “Add Node” button at the top of the dialog tab and set the node condition to #Open_Account” as shown below.

IBM Watson Conversation Slots 1

Next click on the customise link at the top of the right hand edit panel just above the #Open_Account condition. In the dialog that opens select the first checkbox to enable the Slots feature, ignore the “Prompt for everything” checkbox for now.

ICM Watson Conversations Slots 2

Clicking “Apply” will result in an update in the right hand edit panel and the addition of the Slot editor. Let’s add our first Slot, type @Account_Type into the “Check for” field of the first row and something like “You can open a Bronze, Silver or Gold account. Which option would you like?” to the “If not present, ask” field. The “save as” field will be defaulted for you and the default is fine for our purposes.

IBM Watson Conversation Slots 3

Next click the “Add slot” link and enter @Subscription_Type into the “Check for” field and something like “Would you like to pay monthly or annually?” into the “If not present, ask” field.

Finally we need to add the response that will be presented to the user when both account type and subscription type have been collected. In the section “Then respond with” add something like “Super. I’ll open your <? $Account_Type ?> account with <? $Subscription_Type ?> billing.”. The placeholders for $Account_Type and $Subscription_Type will be replaced with the values from context, you can see where this context is set by clicking on the cog iconScreen Shot 2017-06-26 at 16.35.27 to the right of the slot, then select the hamburger menu Screen Shot 2017-06-26 at 16.36.08 and select the “Open JSON editor” option.

Screen Shot 2017-06-26 at 16.36.17

The resulting flow should handle the possible variations of user input in a single dialog node rather than the 5 nodes we needed in my previous example. Try out the following variants:

  • I’d like to open and account
  • I’d like to open a bronze account
  • I’d like to open an account and pay monthly
  • I’d like to open a bronze account and pay monthly

Assuming our changes went well the above sentences will work and guide the user toward the endpoint regardless of what information they provide in the first utterance. The completed #Open_Account node should look like the below image, if you have any problems I have included a completed workspace that can be imported to double check against your own.

ICM Watson Conversations Slots 4

Although only a basic example I hope you can see just how powerful a feature Slots are within IBM Watson Conversations service. Extending this approach to 5, 6 or 7 pieces of information would be quick and easy to maintain, my only word or warning is that collecting a lot of information will quickly become a arduous task for users and is better handled with traditional forms.

 

Formula for cherry picking the right topics for your chatbot

Original Article Posted to LinkedIn on 22nd June 2017

So you’re building an AI powered chatbot to help customers on your website, but where do you start? Unless you’re in the position of knowing exactly what your customers will talk to your chatbot about, you’ll need to make some assumptions and pick your topics carefully.

A focus on domain specificity for your chatbot will benefit your customers and ensure you’re investing in the right thing.

This might sound obvious but, from my experience, too many companies are being tempted by the lure of “all knowing” chatbots and question answering systems that end up being all too generic and fall short of customer expectations.

As CTO at ICM Hub, I come at this subject from a particular perspective: we’re focused on AI automated customer service for airlines. Although our solution uses machine learning and natural language processing, delivered mostly in the form of a chatbot, our focus isn’t so much on the technology as it is on the impact we have on the final customer’s experience.

Getting specific is beneficial!

The technology needed to build chatbots and question answering systems is here, and there are businesses already investing in the development of these systems. However, one of the things I’ve seen a lot over the last fews years is a tendency to focus on the wrong thing: breadth. I think it is because people feel that knowing a little about a lot is better than knowing a lot about a little, but I’m not sure I agree. Lots of us will relate to taking the time to call a helpline, send an e-mail or start a web chat with a specific question or issue, only to be disappointed that the answer is too generic and doesn’t address our question at all.

General or domain agnostic solutions have their place, search engines are a great example: they cover massive amounts of content across every subject and can connect users with relevant information quickly and efficiently. They don’t, however, answer your question (yes, there are exceptions) or solve your problem, rather they help point you in the right direction. This approach is fine for a search engine, as our expectations are that they will do exactly that. On the other hand, when we take the time to engage with a company directly, we often expect more than simply being pointed in the right direction: we want personalised help.

Deciding what topics to cover

There’s a concept used within the world of question answering and information retrieval systems known as “the long tail graph”. I used it quite regularly during my time at IBM Watson to explain to businesses and development teams how to identify good topics to cover. The graph takes the form y = frequency and x = uniqueness and looks something like below.

The idea is that you focus the attention on topics that fall on the left hand side of the graph because they are the questions that occur most frequently and they are the easiest topics with which to train the machine learning. For question answering systems that focus on FAQs this is a good approach for the short tail, but the longer I’ve worked with businesses on conversational solutions (e.g. chatbots) for customer service the more I see that there is a need for an alternative perspective.

Consider value & complexity

Focusing so much on frequency and uniqueness leaves you at risk of spending time covering topics that offer the least value/cost or the highest complexity. This really isn’t how you want to get started: ideally you want to select the valuable topics that are most easily implemented. To deal with this, we find ourselves adding cost and complexity to our analysis to identify a number of candidate topics to cover.

Our approach is to analyse the domain using data from existing communication channels so we have a measure of frequency, cost, uniqueness and complexity. Cost represents the current cost of dealing with those topics while complexity is a discrete measure of how complex (1-10) the topic would be to automate. Visually the graph would look the same, but the topics that lie toward the top left can be quite different than those of other approaches.

y = frequency * cost | x = uniqueness * complexity

By following the above approach we ensure that we’re investing in the most frequently asked topics that carry highest value and are easiest to implement. The result is a reduction in the time needed to implement a solution capable of providing a return on investment and an increased chance at long term success. The idea is to get to a usable release and begin to get that valuable stream of data from the users as quickly as possible.

Don’t forget about breadth, just iterate

The idea that you’ll identify the most valuable topics to cover and only support those is the wrong mindset. Once you’ve released a chatbot, users will start to ask it questions; at this point, instead of guessing exactly what users will ask and how they’ll ask it, you’ll have real data to analyse.

My advice is to resist the temptation to start adding the topics that you THINK are needed and “let the data guide you”. You can then focus on the things your customers are actually asking that aren’t yet covered by looking again at the frequency, cost and complexity. As a result of this approach you will naturally begin to add the kind of breadth you were tempted to do from the beginning, but with greater confidence and a lower risk of wasting time.

What challenges have you faced selecting topics for a chatbot and how have you overcome them?