Getting Started with Watson Assistant: Bring Your Assistant to Life!

You’ll learn how to build an assistant that handles topics faster and more concisely than any alternative (2/5)

Blake McGregor
IBM watsonx Assistant
15 min readApr 8, 2021

--

Photo by NeONBRAND on Unsplash

Now that you’ve planned your assistant, it’s time for the fun part: have it do stuff! Before we get started, be sure that you’ve taken the guided tours so that you’re familiar with the core Assistant concepts:

  • What is an Intent (and how to set one up)
  • What is an Entity (and how to set one up)
  • What a dialog node represents
  • How to link your intents and entities to dialog nodes

To find the guided tours, head to the “learning center” in the top right of the Watson Assistant console.

Screen shot of the Watson Assistant console and the dropdown menu showing the learning center.
Watson Assistant Guided tours within the Learning center

Once you’ve learned the basics in the “getting started” section of the guided tours, keep reading to learn about the core principles and prominent patterns of dialog design.

A reminder of where you are in the overall build, test, and launch journey:

First-Assistant Getting Started Steps

  1. Plan it — a few hours (you already did this!)
  2. Build it — half of a day (you are here)
  3. Complete it — a few hours
  4. Test and improve it — half of a day
  5. Launch it — a few hours

Start with Your Frequent Topics

We’ll start with the decisions you made in step 3 of the planning process (below). Remember those? We sure hope so!

You’re going to start by building the dialog for the top three to five most frequent topics that your customer service reps hate handling. That’s what this post is all about. Once you’ve done that, the next post will show you how to set up your assistant to search against existing content, handle greetings and other chit chat, and configure how your assistant can escalate conversations to human agents.

Also, everything in this post can be done by anyone — yes, anyone. You don’t need to be a developer to build an assistant worth launching (but if you are a developer, we love you too). And finally, before we start, some conversation design best practices to internalize:

Best Practice 1: Focus on Concise Answers

Let’s be honest, everyone hates reading long paragraphs of text to hunt for the information they need. Focus on building topics where you can ask a few clarification questions up front that ultimately lead to clear and concise answers (not huge paragraphs of text).

Best Practice 2: Save Simple FAQs for the Search Skill

Make sure that each topic leads to multiple clarification steps before ultimately providing a concise response. If you have questions that lead to short responses with absolutely no clarification needed (aka FAQs), we can handle those easily in the search skill. There’s no need to configure FAQs within the dialog skill.

Best Practice 3: Try It, Try It, Try It

As you start building stuff (in the subsequent sections of this post), keep going back to the “try it” panel to test what you built. This will let you experience what your users will experience and reduce the total testing time after once you’re ready to launch.

Screen shot of Watson Assistant’s “try it” tool for testing a skill.
Try out interactions in the Watson Assistant try it panel

Choose a Conversation Pattern Per Topic

Now think about each of your topics for a moment. Specifically think about the overall flow someone would need to go through to get that job done.

Now, we’d like you to align each of those flows to one of five of the most common conversation patterns documented below. If you don’t see a pattern that aligns, it might be worthwhile choosing a different topic (just so you can get through this as quickly as possible).

Here are the 5 patterns, all of which revolve around a fictional fruit stand.

Pattern 1: Basic Question and Conditional Response

Many of our customers’ initial topics fall into this bucket. Almost as simple as an FAQ (ask question, always get same answer), but allows you to provide a more concise response based on specific info (e.g., a type of fruit).

Pattern 2: Information Gathering with Conditional Response

This pattern adds to the previous one, where the assistant will explicitly ask for the information it needs to get to a concise answer. In this case, it’s asking for the day of the week and provides the specific hours of operation for that day.

Pattern 3: Information Gathering with Warm Agent Handoff

This is like pattern 2 but instead of the assistant providing a final response, it does a warm handoff to a human agent so that they can finish the job.

As you can see below, the agent (in this case in Zendesk) has context of what they need to do and can carry on the conversation where the assistant left off.

Pattern 4: Step-by-Step Instructions

This pattern is like a process walkthrough. It could involve actual questions and answers, or, as in this case, it could just be a series of steps with a confirmation after each one.

Pattern 5: Recommendations and Troubleshooting

This pattern asks a variety of questions where each subsequent question shown is dependent on the answer to the previous question. And in some cases, even the applicable answers to the subsequent questions vary based on previous answers.

Troubleshooting and recommendation scenarios (like fruit recommendation flow below) both fall into this category.

You’ll notice that as the conversation continues through a series of follow up questions, the assistant begins to hone in on a final recommendation (in this case, pomegranates).

Start with a Sample

For each of your topics, we’d like you to build off of the patterns you saw above. And the good news for you is that you don’t have to do it from scratch! We’re going to build off of the fruit stand skill we built for the sample patterns above.

  1. Start by downloading this sample skill (download button top right)

2. Find the assistant that was created for you when you signed up with Watson Assistant. Swap out the dialog skill with the one you just downloaded.

3. Once you’ve clicked “Swap skill,” just go to “Upload skill” in the menu and find the “.json” file on your computer.

4. Once you’ve done that, your assistant should look like this:

5. Now open the web chat integration already attached to your assistant:

6. Start testing the interaction patterns above (so that you can get a feel for how it all works). Here’s a cheat sheet of what the assistant can do:

Pattern 1: Do you have _____ in stock?

Pattern 1: What sweet fruits do you have?

Pattern 2: What are your hours?

Pattern 3: I’d like to buy a fruit

Pattern 4: Refund a fruit purchase

Pattern 5: Which fruit do you recommend

7. Once you build up enough familiarity with what the assistant can do, open the fruit stand sample and take a look around. If you navigate to the dialog page, you’ll notice the five patterns in order, along with some useful chit chat!

8. Now it’s actually time for the fun part! Choose one of your topics with the simplest pattern (1 is the simplest, 5 is the most complex), and then choose the corresponding folder and duplicate it (so that you always have something clean to refer back to).

9. Give your new folder an intuitive name so you don’t forget what it represents later on.

10. From here, create your own intents and entities and build something relatively similar to the pattern in this sample skill using your best judgment. You’ll slowly start to evolve this fruit stand skill into your own skill.

Yes, just dive in head first and start experimenting! And remember, you’ve got a lot of assistant-building knowledge already from the guided tours you took and from all of the things you’ve learned in this guide. We believe in you!

Photo by Oliver Sjöström on Unsplash

Pro tip: Building an assistant is a truly creative process with a lot of trial and error. You will NOT get things perfect the first time, so just keep playing around and keep trying!

Pro tip 2: You will have noticed by now that this guide covers the dialog skill, but not the new “Actions skill” which is still in beta. This is because there is still some critical functionality we need to add in to the actions skill before we remove the beta tag and launch it fully. Once that happens, rest assured that you will be able to use both your existing dialog and any new actions you build together!

The remainder of this post contains even more detailed best practices on intents, entities, and dialog, which you are welcome to read (or not read). When you’re satisfied with the 3–5 topics you’ve built into your dialog, move on to the next post.

➡️ Next Up: Complete it (3/5) ➡️

Craft Amazing Intents (Optional Read)

Intents represent the distinct things that your users want to get done. A general best practice is that you create an intent for the action being taken (aka a verb) and entities for the objects upon which those actions are taken (nouns).

For example, if you were building a fruit-only shopping assistant, creating one intent for #buying_apples and another for #buying_oranges would lead to an unnecessary overlap. Instead, you would want to create an intent for #buying_fruit and an entity for the objects (fruits) themselves (apple, orange, etc.).

For each intent you create, you need to train the system with example sentences that represent various ways a user might ask for this (in natural language — not a bunch of keywords). The cool thing here is that you don’t need a ton of example sentences per intent—the AI underpinning Watson Assistant can do a good job identifying intents with only five to ten examples.

Pro tip: Your assistant can catch misspellings too, so don’t worry about adding training sentences with intentionally misspelled words.

While we’re at it, you don’t need to gather data looking for historical conversation logs with example sentences (we can do this later), just come up with some different phrasings yourself. And when you do this, don’t simply change one word around with every new sentence! The system needs some natural language variety to really figure out what people are asking for.

Here are two examples of intents, one good and one bad:

Bad Intent (#buying_fruit)

Example 1: I want to buy an orange

Example 2: I want to buy an apple

Example 3: I would like to buy an apple

Good Intent (#buying_fruit)

Example 1: I want to buy an orange

Example 2: Give me an apple

Example 3: Can I have that apple please?

In the bad intent, the structure of the sentence is the same in all three cases, but with a few individual words replaced. Doing this doesn’t really help the system get better at understanding requests (it’s smart enough to pick up on apple vs orange and want vs would like).

In the good intent, you’ll notice that the examples are fairly distinct. Again, the system performs a lot better with this kind of variety in example sentence structure.

Check for Intent Conflicts

Once you’ve built the three to five intents, run a quick check to see that there aren’t glaring overlaps between the examples (which would confuse the system when it is running). To do this, go to the intents page, and check for conflicts (see the conflicts column in the image below).

If there are conflicts, the number of sentences in conflict will display within the column. If the column is entirely blank, hooray, no conflicts! If you do have conflicts, open up the intent in question and identify the specific examples that need resolution. Click “resolve conflicts” to open up the resolution screen:

In this case, I have a pretty obvious conflict: The wrong example went into the deductible intent. To resolve, simply select the example in the wrong spot, and decide what to do with it (move or delete). Confusion averted! Easy.

Note that the intent conflict resolution feature is only available in the Plus plan or above. The good news is that you can start a free trial of the Plus plan for 30 days to get access. Just hit upgrade in the top of the screen and select Plus.

Build the Right Entities (Optional Read)

Entities are used to collect bits of information (typically nouns) within a given flow.

For example, if you were building a banking bot and the intent was “#check_balance,” an entity, or clarification, may be “@account_type” with values set to “checking” and “savings.” The ultimate flow might look something like:

User: What’s the balance in my account?

Assistant: Which type of account?

User: My checking account please

Assistant: Your balance is…

Again, as a general rule, think of the intent as the up-front action the user wants to initiate and the entities as the bits of information you need to collect in the flow to get the user to the ultimate resolution.

To decide which entities you need to associate with your top three to five intents, start with just one of those intents. Write out some example scenarios and identify which clarifications are needed to reach the end of the flow. For each of those clarifications, think about the type of the information you need to gather.

Some potential entity types are:

  • Options with explicit values (e.g., “Which type of account, checking or savings?”)
  • Date/time (e.g., “When do you want to come in?”)
  • Number (e.g., “How many people are in your party?”)
  • Currency (e.g., “How much money do you want to send?”)
  • Percentage (e.g., “What portion of your bill do you want to pay today?”)
  • Something else in a format that can be validated (e.g., email address, phone number, etc.).

Based on the type of entities you need, the setup will look a little different:

Options with explicit values

This is the most common entity type and allows you to build out a dictionary with separate values of a given object (think product names, account types, locations, etc.).

If we go back to our fruit-only shopping assistant example, here’s an entity for fruit and the values for the fruits that we sell:

You’ll notice (in our very limited fruit selection) that synonyms are added for each of the values — this is useful when your users use words other than the exact value name to refer to that value. So, for example, someone might ask to purchase a granny smith instead of asking for an apple. Instead of having the assistant respond asking the user to correct an invalid input, synonyms allow your assistant to catch multiple ways of saying the same thing.

Pro tip: You can also use the synonym recommendations provided by the system to speed up the process of adding them!

Another pro tip: The entities you build automatically make your intents smarter. Meaning, if you have a “#buying_fruit” intent where some of the examples use the word “apple” (e.g. “I want to buy an apple”), you don’t need to add similar examples for every value of the fruit entity (e.g. “I want to buy a banana”).

System entities (date, time, number, currency, percentage)

Watson can automatically identify dates, times, and numbers for you, regardless of how they’re phrased or written! If you plan to use any of these, just head to the system entities page and enable them.

We’ll work with these entities later on, so just enable them for now if you need them.

Pattern entities (email, phone number, etc…)

For bits of information that follow a specific pattern that can be validated with regex (like an email, phone number, etc…), you’ll want to use a pattern entity.

To do this, just set up an entity as you normally would, but when you’re entering a value, select “pattern” for the value instead of “synonyms.” The pattern field is expecting regex to tell the system how to properly identify this specific value.

If you’re not a developer and have no idea what regex is, never fear! Regex (aka regular expression) is simply an expression you can write to tell a system how to identify and validate text/numbers. You don’t need to learn how to write these out to set up a simple pattern either. Just copy/paste some of the common patterns (like email or phone number) off of this site or, honestly, just Google the specific pattern you’re looking for.

Learn Dialog Design Principles (Optional Read)

Principle 1: Bring it to life!

You want your customers to have fun interacting with your assistant. This helps increase engagement and retention for your business. But before you write any content, come up with a persona for your assistant. Is it a “cool dude,” a “caring helper,” or a “formal fancy-pants”? Give your assistant a name that aligns with the persona too!

You can begin building this persona in the content for the top topics. Eventually you’ll be able to take the persona further with greetings, pleasantries, and other chit chat—but let’s focus on your top topics for now.

Principle 2: Don’t leave your users hanging

Your users are here because they need help getting something done that they likely couldn’t accomplish on their own. They’re looking for your assistant to guide them, but this doesn’t stop at just guiding them through a multi-step process—it also includes guiding them through the conversation itself. Meaning, you should always give users an idea of what they should be saying next, or how to phrase their input so they aren’t just guessing and having to retry.

For example, if you’re looking for an email address, show your users an example. If you’re going to ask them which fruit they want to buy, give them some examples of what fruit is available.

The same goes when they complete a task. Don’t just give your users an answer and end there, always leave them with a question like “Is there anything else I can help you with?”

Principle 3: Don’t get too cute with your conversation

Don’t go overboard on human-like conversation flows. There’s a balance between a natural conversation and self-service functionality on a website (e.g., a web form).

For example, have you ever tried to apply for a mortgage purely over the phone, answering 20 questions one by one when you could have easily filled out a form in half the time? It’s much faster to use natural language up front to launch into the right action, but guiding someone through a process can be much faster using buttons, images, and other interactive elements in a digital channel like web chat to get the job done.

Pro tip: Your goal is to make your assistant feel natural to your users while also getting them to the end of the job as fast as possible. Use natural language up front to identify what the user wants to do followed by more guided and interactive experiences to finish the task.

In summary, it’s important to find the right balance of guided process and natural language input. Don’t just build human-like, conversational interactions for the sake of it! We can’t say this enough.

--

--

Blake McGregor
IBM watsonx Assistant

I love to ski, eat, travel, and eat. And in my spare time, I work in the natural language/AI space as the product management lead on IBM Watson Assistant.