INTRODUCTION TO CHATBOTS
INTRODUCTION TO CHATBOTS
Welcome to How to Build Chatbots. My name is Antonio Cangiano
and I’m a Software Developer and Artificial Intelligence Evangelist at IBM.
Over 50,000 people took the first edition of this course on chatbot building and the reviews have been amazing so far.
This motivated me to create an even better version of the course
that uses the latest user interface and incorporates some exciting new
features that weren’t available when the first edition of the course came out in 2017
In this course I’ll teach you all that you realistically need to know about chatbots,
the business opportunity they provide,
and how to start building useful chatbots for yourself, your company, or your clients.
No coding skills are required so anyone can take this course and learn how to create and deploy chatbots.
Together we’ll build a chatbot for a fictitious florist chain of stores.
A chatbot that provides information and assistance to prospective customers.
We’ll then deploy it on a WordPress site.
Don’t worry if you don’t have your own WordPress site, as one will be provided for you in the course.
Alright, let’s find out what chatbots are and how they can help us by discussing a common scenario.
“Your call is important to us.
Due to unusually high call volume, you may experience a greater hold time than usual.”
Many of us are going to be familiar with this greeting on the phone
when trying to reach the customer support line of a company.
The prompt varies but the gist of it is always the same.
It would seem that the call volume is always unusually high, no matter when we call.
Another common prompt you might be familiar with is,
“Your call may be recorded for quality and training purposes.”
I must confess that at times I question how much these conversations are actually being used for training purposes,
as opposed to liability purposes.
As we’ll see in this course, with chatbots we can actually use the conversations with customers
to train and make our chatbot smarter and more useful.
At any rate, we are on the line, waiting for what seems to be an eternity, and we finally get to talk to a person. And they tell us…
and we finally get to talk to a person. And they tell us…
“Have you tried turning it off and on again?”
Now, this is frustrating regardless of whether it fixes our problem.
If it doesn’t, we feel insulted by such a simple suggestion
after 20 minutes of patiently waiting on the line.
And if it fixes our problem, as it often actually does,
we’ll be happier but still frustrated from having wasted so much time on something we should have thought of ourselves
or found as a suggestion on the company website.
I’m not picking on companies providing customer care here.
The truth is that customer support is hard.
It’s not hard because the questions are very hard.
In most cases, it’s a matter of providing simple answers to simple questions.
It’s hard because customer care powered by humans is not very scalable.
If your business is doing well, you’ll have an increasingly large amount of customers who need your help.
So you’ll need to hire more and more people and that takes money.
You’ll also need to spend the time and energy to train them properly, managing them, and so on.
Chatbots are not meant to replace humans entirely.
But they can help us address a large number of simple inquiries from our customers.
They can scale indefinitely, unlike human teams, and are available 24/7 every day of the year.
unlike human teams, and are available 24/7 every day of the year.
In other words, they can act as a first line of defense for your customer care team,
allowing you to inexpensively scale your customer support operations
and provide a better service by having immediate answers around the clock for common enquires.
a hotel might drastically cut down on the number of calls its reception desk receives
simply by having a chatbot that replies to the most common enquires
such as restaurant hours or checkout times,
setting an alarm call, or figuring out how to connect to the Wi-Fi.
This leaves the hotel staff with a greater degree of time and energy to tackle more elaborate requests,
such as changing rooms because one of their customers found crickets in their room.
That actually happened to me, but that’s a story for another day.
We had this customer care scaling problem ourselves
when Cognitive Class started to become more popular.
We were ecstatic to have one million enrolled learners,
but that posed a serious problem for our small team.
So we created a student advisor chatbot
that could advise students on which course to take and other common questions.
As simple as it is,
it reduced the number of support tickets from our students to about half of the number we were getting prior to the introduction of our chatbot.
half of the number we were getting prior to the introduction of our chatbot.
And unlike our team, who has a habit of going to sleep most nights,
the chatbot is there available 24/7 for our users.
That’s our story.
Here is another one: Allan from Dollar Tea Club,
a subscription service for tea lovers, is a one man shop.
He has to do everything by himself.
Prior to introducing a chatbot
he was spending a lot of his time answering the same questions over and over.
Do you ship to Canada? How much is shipping?
How does it work? What kind of teas do you have? And so on.
Again, simple questions that still take time to answer
if a human is on the receiving end.
So he took the first version of this chatbot course
and built a chatbot that is saving him many hours a week.
According to Allan the moment the chatbot went live,
it was like turning off a switch in terms of support tickets received.
The chatbot he created is allowing him to regain some of his time which he can use to actually grow his business.
which he can use to actually grow his business.
It’s worth noting that Allan is a businessman not a programmer,
but he was able to create his own chatbot and by the end of this course so will you.
Another example I wanted to give you is Oscar,
the chatbot from the airline company Air New Zealand.
I recently visited their wonderful country and on my way there I had a question about protein powder.
You know how import regulations can be quite strict,
so I got a little paranoid that I might be breaking some rules.
Not wanting to be the Pablo Escobar of Whey Protein Isolate,
I asked the staff on board and they had no idea.
Thankfully, I had Wi-Fi on the plane and was able to use their chatbot
which had an answer to my protein powder question and all other questions I had.
I was really impressed by how useful it was especially at 35,000 feet in the air.
As you can see, chatbots are universally useful,
regardless of whether you’re a one-person operation
or a fortune 500 company.
Throughout this course we’ll learn how to create chatbots that serve practical business purposes,
rather than just being amusing gimmicks.
But first, what is a chatbot?
It’s a software agent capable of conversing with users through some kind of chat interface.
Typically, the chatbot will greet the user and invite them to take some action like asking it a question.
When the user replies, the chatbot will parse the input and figure out the intention of the user’s question.
Finally, it will respond in a consequential manner,
either providing information or asking for further details before ultimately answering the question.
Great chatbots can keep up this back and forth in a natural way,
within the scope of what the chatbot is designed to do.
They make the user feel understood and helped.
They create rapport with the user, without pretending to be human.
The most common chatbots are textual chatbots.
The kind you’d interact with in a chat pop up window on a web site
or through a messaging app like Facebook Messenger, Whatsapp or Slack.
However, you can interact with some chatbots through your voice.
Apple Siri and Amazon Alexa are two examples of audio-based virtual assistants.
Before we proceed further, it’s worth noting
that sometimes you might hear the word “bot” instead of chatbot in this course or elsewhere online.
Depending on the context, it’s acceptable to use bot in lieu of chatbot to mean the same thing.
Nevertheless, the term bot is more generic
and there are software programs that independently perform a certain operation on our behalf
without being chatbots.
For example, a trader bot might monitor the market for certain conditions
and then perform automated stock trading transactions based on that information.
That’s not a chatbot, as no chatting is taking place.
The conversational element is what makes a bot a chatbot.
There are many other terms that refer to chatbots,
such as chatterbot,
talkbot, virtual assistant,
Conversational Agent, embodied agent,
and even Artificial Conversational Entity
or its acronym ACE.
And believe it or not this list is not even exhaustive.
I like to keep things simple, though, so I will generally stick with chatbot and occasionally bot in this course.
and occasionally bot in this course.
CHATBOTS ARE TRENDING.
In this video we’ll discuss why and give you your first assignment.
Chatbots are really trending.
Everybody seem to be talking about them
and everyday there is a new headline about how they are going to be big.
If you cut through the hype, you’ll notice that there is genuine interest and businesses, small and big,
are paying very close attention to them.
This creates a great business opportunities for those with the right skills.
Chatbots have been around since the late sixties.
The first chatbot, Eliza,
was rudimentary but it proved the potential of chatbots even back then.
So why are chatbots suddenly so in demand now,
over half a century later?
Two key developments have allowed chatbots to become a viable business tool
and such an in-demand skill.
The first one is the emergence of messenger applications.
Whatsapp, WeChat, Facebook Messenger,
and even Slack have become incredibly popular.
Collectively, they are used by billions of people around the world.
That’s “B”, not “M”.
In fact, messenger platforms are even more popular than social media sites.
Messenger apps might have been the catalyst for the emergence of chatbots,
but they are certainly not the only platform.
Chatbots are now appearing on sites and as mobile apps as well.
It’s not so much the platform on which they are delivered on,
but rather the conversational nature of the interface.
People simply love textual chat and prefer it over virtually every other form of digital conversion.
The second key component that allowed chatbots to really take off,
is the emergence of Artificial Intelligence.
Chatbots wouldn’t be very useful if they weren’t able to understand what the user wants and respond accordingly.
Over the past few years, machine learning,
natural language processing,
and artificial intelligence in general,
have all progressed quite rapidly.
You might be familiar with IBM Watson
who, several years ago, defeated the best Jeopardy players in the world.
More recently, IBM showcased Project Debater, an AI capable of debating humans on complex topics.
an AI capable of debating humans on complex topics.
The math behind many of these innovations and achievements is quite complex.
And by the end of this course you will fully understand these formulas.
Well, not really.
You see, AI is becoming smarter
but it’s also becoming more readily available to everyone.
AI is no longer accessible solely to researchers with PhDs in Computer Science.
Such cognitive capabilities are now easily available via libraries
and through services provided by companies like IBM.
Today, the many AI capabilities of Watson
are readily provided as services and APIs
that are available to anyone with a IBM Cloud account.
In this course, we’ll in fact use one such a service.
Specifically, I’m talking about Watson Assistant.
This will enable us to develop a chatbot with NLP or natural language processing capabilities.
In other words, a chatbot that understands our users
and can provide useful answers within the scope we define for it.
It’s now your turn.
In the next section of this module, you’ll find a lab that will instruct you to register for a free IBM Cloud account
and to create a Watson Assistant service.
Follow the step-by-step instructions I provided
and the process should not take much time or effort.
In this course, we’ll use the Watson Assistant service hosted on the IBM Cloud platform. As a result, before we progress further, we’ll need to ensure that you are set up with an account. Follow the instructions below to get your own instance of Watson Assistant and start building chatbots.
Exercise 1: Register with IBM Cloud
- Registerfor Watson Assistant on IBM Cloud by clicking on this link.
- You’ll be asked to log in if you already have an account with IBM.com. If you do, log in. If you don’t, click on Create an accountand proceed with the creation of an account with your professional email address. (If you don’t have access to a business email, feel free to use your personal email, however.)
- If you created an account in the previous step, you’ll be asked to verify your email. Check your inbox for the verification email (and for good measure, be sure to check your spam folder as well if you don’t see the email after a few minutes).
- Upon successful verification of your email, you’ll see a Log InClick on it and accept the privacy notices. At this point, you’ll be logged in with your IBM ID.
IMPORTANT: If you’re prompted to create a Watson Assistant service on a page similar to the image below, you are all set and can skip steps 5-9. Close that browser tab and jump straight to Exercise 2 below.
- If you weren’t redirected to the service creation page above automatically, you’ll be prompted to create an IBM Cloud account instead. Click on the Sign Upbutton presented to you on the page to do so. (If the Sign Up button doesn’t work, log out and log back in before trying this step again.)
- You’ll see a registration form for IBM Cloud. Considering you likely just entered your information to register for an IBM ID, this extra step might feel tedious. Thankfully, you can just enter your email address and the rest of the form will disappear, allowing you to create an IBM Cloud account by simply clicking on the Create Account
- Check your email once again click on the Confirm Accountbutton provided in the confirmation email.
- You registered and activated your IBM Cloud account. Our last step for this task is to log in using the provided button on the success page you were redirected to.
- You’re now logged in and should see your (empty) dashboard.
Exercise 2: Create a Watson Assistant Service
Now that you have an IBM Cloud account, it’s time to create an instance of IBM Watson Assistant. Visit your IBM Cloud dashboard and then follow these simple steps:
- Click on the Create resourcebutton on your dashboard.
- Search for Watson Assistantin the search field or find it in the AI category of the catalog and then click on that tile.
- You should see a Watson Assistant creation page similar to the image I showed you above. You can leave everything to default, or customize the service instance name to your liking (e.g., Watson Assistant Flower Shop). If you are not in the USA or Canada, you might want to switch the region/location for optimal performance. It may take up to a minute before the UI will allow you to select a different data center. Give it a moment to finish loading the page if you don’t see the option.
- Take note of the differences between the free Lite plan (which you’ll be using) and the other plans available, towards the end of the page.
- With the Lite plan selected, click on the Createbutton at the bottom to create your instance.
- You’ll be redirected to the launch page for the service you just created. Click on the Launch toolbutton to access the web application that will allow you to create chatbots. You’ll land on an informative page. Feel free to read it, watch the videos on it, and when you are ready, follow the final step of this exercise.
- Click on the Skillsmenu at the top of the page, as it’s where we’ll teach our chatbot how to chat in the next modules of this course. For quick access in future labs, bookmark this Skills
Note that you can always create new services (Watson Assistant or any other service available in the IBM Cloud catalog) by clicking on the Create resource button on your dashboard.
Your dashboard is accessible at any time by logging in on the IBM site, but it takes a few clicks to get there, so I highly recommend that you just bookmark the dashboard page now instead.
It will give you quick access to seeing and managing all the resources you created inside of your IBM Cloud account. If you go there after completing this second exercise, you should see the Watson Assistant service you just created.
Welcome to the second module of How to Build Chatbots.
- In this module we’ll discuss one of the three components of a chatbot.
- Namely, intents.
- Conceptually, this is how a chatbot works.
- The user enters some text, the chatbot thinks really hard,
- and then a response is issued to the user.
- Now, that’s very, very high level and doesn’t tell us much, of course.
- So let’s see more in detail how this works.
- The chatbot will use three main components
- to determine how to interpret the user input and how to respond to it.
- Intents, the subject of this module,
- Entities, which we’ll cover in the next module,
- and finally the dialog which we’ll cover in module 4.
- When you create a chatbot in Watson Assistant, the first think you do is create a Dialog Skill which will contain these three components.
- the first think you do is create a Dialog Skill which will contain these three components.
- which will contain these three components.
- Intents are the most important component
- because they try to determine what the user wants. What are they asking for? In other words, they capture the intent or goal of the user.
- What are they asking for?
- In other words, they capture the intent or goal of the user.
- For example, we could define a #greetings intent
- and train Watson with some examples of what a greeting looks like.
- We might provide Hello, Hey, Hi, Good morning,
- and for our friends from New Zealand, Kia Ora.
- It’s a good practice to provide at least 5 examples per intent
- in order to fully train Watson on the intent.
- But the more the merrier applies here.
- Once Watson is trained on the intents we defined,
- it will look at the user input
- and try to determine if any of the intents match the user request.
- For example, if the user were to say ”Aloha”,
- Watson would recognize that it’s a greeting akin to the ones we trained it on.
- Note that Aloha was not one of the examples we gave it.
- This is where Watson’s Artificial Intelligence capabilities really kick in.
- We train it with some examples,
- and Watson will be able to recognize an intent in the user utterance
- even when the user phrases it very differently from the examples we provided.
- As mentioned in the previous module,
- in this course, we’ll create a simple chatbot for a fictitious chain of Flower Shops.
- So let’s consider for a moment a domain-specific intent,
- as opposed to simple chit chat intents.
- Users may want to find out about our hours of operation,
- so we could define a #hours_info intent.
- Note, however, that intents cannot have spaces.
- So we’ll simply use an underscore instead of a space.
- And here are some examples that we might provide to train Watson on the hours info intent.
- “What time are you open until?”,
- “What are your hours of operation?”,
- “Are you open on Saturdays?” and so on.
- These are all realistic ways in which users might express the same request for hours of operation information.
- It’s important to train Watson with realistic examples,
- to the point that you’ll even want to leave in typos you might accidentally make
- as you type out the examples.
- After all, if you made that typo, your users might as well.
- Now when the user asks,
- “When is your Toronto store open?”
- Watson will recognize our #hours_info intent
- even though, again, this particular phrasing was not part of our examples.
- Watson was smart enough to figure out what the user wanted
- now that it understands what hours info represents.
- Intent examples can be entered manually in Watson Assistant
- but they can also be imported from CSV files.
- This simplifies collaboration.
- For instance, you could receive the examples from a colleague in your customer care team
- who doesn’t know anything about building chatbots.
- To help you out, Watson Assistant also comes with a Content Catalog
- which provides collections of intents relevant to various industries,
- such as banking, insurance, and ecommerce.
- It’s not a premade chatbot by any means,
- but you can use it as a starting point to build upon.
- It’s worth noting that in this course we’ll build our chatbot in English,
- but several other languages are available as well.
- So if you wish to create a chatbot in Italian or Japanese,
- you’ll simply create a dialog skill in that language
- and then train Watson with relevant examples in the same language.
- That’s it for the theory around Intents.
- In the rest of the module,
- you’ll go through the labs that will guide you through the process of
- creating, importing, and testing intents.
Welcome to the third module of How to Build Chatbots.
- In the previous module we mastered intents.
- This module is entirely dedicated to entities,
- the second key component of our dialog skill.
- As you know by now, intents capture the user goal.
- Entities allow us to capture specific values within the user utterance.
- You might recall this example from the previous module.
- You’ll notice how the chatbot is correctly detecting the intent
- but completely ignoring the specifics of the question.
- In other words, “When is your Toronto store open?”
- and “When is your Vancouver store open?”
- are the same as far as our chatbot is concerned.
- That’s because we haven’t defined an entity to capture that specific bit of information,
- namely the location of the store.
- So what we could do is create a location entity.
- Notice how we use an @ symbol
- rather than a # symbol for entities.
- We can then define multiple values for our entity,
- such as Toronto, Montreal, Vancouver, et cetera.
- One value for each store location that we have.
- You’ll notice that we can also define synonyms for a given entity value.
- These can be dictionary synonyms
- but are often synonyms in the sense that the user might refer to the entity value in that way.
- Imagine for example our Toronto store is located on Warden Avenue.
- People might ask about hours of operation of our Toronto store,
- or they might phrase it as,
- “What are the hours of operation of your Warden Ave store?”.
- Either should lead our chatbot to detect the same entity value.
- Synonyms are optional,
- but are a useful feature and worth defining when applicable.
- With our location entity defined,
- we can now detect the intent and the specific location.
- With these two pieces of information
- we can provide an appropriate and specific answer to the user.
- Note that although entities values can have spaces in them,
- we need a special syntax to represent them.
- If the entity value has a space in it,
- we simply wrap it in parentheses to refer to it
- when, later on, we’ll define the rules of our dialog.
- Much like intents, we can also import entities from CSV.
- In fact, in the labs for this module
- you’ll import them in this way
- and learn how to export them to CSV as well.
- Other than entering them manually in Watson Assistant
- and importing them from CSV,
- there is also a third way to add entities to your chatbot.
- In fact, there are some predefined system entities that you can enable
- if needed by your chatbot.
- As you can see there are quite a few options.
- @sys-currency allows us to detect mentions of currencies within the user input.
- @sys-date mentions of dates.
- For example, the user might reply to a question with “next Monday”
- and @sys-date will allow us to capture that piece of information
- as an actual specific date.
- @sys-person allows us to detect common names,
- an easy way to collect people’s names to make your chatbot more personable,
- as you’ll see later on in the course.
- System entities are quite handy
- and they are constantly being improved upon.
- Make sure you check the system entities available in your dialog skill
- before you jump right to implementing your own entities.
- Alright, now it’s your turn.
- By now you should know the drill.
- In the rest of this module, you’ll find a series of guided exercises that will teach you how to work with entities. You’ll also find some graded quizzes.
- You’ll also find some graded quizzes.
- In the next module, we’ll see how to put the intents and entities we defined to good use
- to provide accurate and specific responses to the user.
PUTTING IT ALL TOGETHER
Welcome to the fourth module of How to Build Chatbots.
- In this module we’ll finally address the third component of our dialog skill.
- Namely, the dialog itself.
- The dialog component allow us to issue a response to the user
- based on the basis of their intent and the specifics of their request
- which we captured through entities we defined.
- It’s great that our chatbot can detect and classify the user input.
- However, so far, we haven’t really replied to the user at all.
- We must be able to act on that correct classification
- by issuing an appropriate response.
- When a user greets us, for example,
- we may want to reply back with,
- “Hi there. How can I help you?”.
- The same is true for more complex queries.
- We must be able to use the fine-tuned classification
- that intents and entities enable us to do,
- to provide an appropriate and accurate response to the user.
- In this case, they enquired about our Toronto store hours,
- and the response would reflect that
- and contain the information the user is looking for.
- A dialog is simply a tree of nodes,
- and each node will typically handle one particular scenario.
- For example, here we have three nodes.
- The first one is Welcome which handles the chatbot prompt.
- In other words, our greeting when the user first arrives.
- Then we have a Greetings node to respond to the user greeting us.
- And finally we have a special fall back node
- that will notify the user that the chatbot wasn’t quite sure about what the user was asking.
- Welcome and Anything else
- are two default nodes created for you when you first create the dialog for your chatbot.
- Any node you’ll define will sit in between these two.
- But let’s take a quick look at what a node might look like.
- You’ll want to give each node a name.
- Watson doesn’t really care about the node name,
- but it’s useful to us, the chatbot designers,
- so that we can more easily organize and work with our nodes.
- Next, we have a condition that determines when the node should be executed.
- In this case, the node will be executed if the #greetings intent
- is detected in the user input.
- The condition can be as simple as this or complex logical expression.
- In most cases it will test against an intent,
- entity, or a combination of them.
- Then we have the response block,
- where we finally get to decide what to reply back to the user.
- In this case, a simple,
- ”Hi there. How can I help you?” will suffice.
- This response block has many, many options.
- In fact, the response doesn’t even have to be text
- (it could be an image or some options for the user to choose from).
- We can provide multiple response variations,
- and then decide if they should be issued in the order they appear
- every time this node is executed,
- or randomly, from the list we provide.
- We can even have multiple responses where we attach a condition
- to each individual response within the same node.
- This is a great feature and we’ll definitely take advantage of it in the labs of this course.
- Finally, we get to specify what happens after we issued a response.
- Typically, we just wait for the user to say something else,
- and that’s why that’s the default action.
- However, other options are available,
- including the ability to jump to other nodes within the dialog.
- This is a feature that will be useful in more complex chatbots,
- but can lead to chatbots that are difficult to reason about if you abuse it.
- The execution is evaluated from the top to the bottom of the dialog.
- So when the user submits their utterance,
- the first node will be evaluated for execution.
- If the condition is not met, we’ll move down to the second node.
- If this one doesn’t meet the criteria either,
- we’ll consider the third node, and so on.
- Essentially, we continue to evaluate nodes in the order they appear
- while the conditions of these nodes are false.
- We stop at the first node whose condition matches the user input.
- This is why it’s important to have that Anything else fallback node at the very bottom.
- That node has a special condition that is always true
- whenever all the nodes above it failed to execute.
- It ensures that we have a reply for the user,
- even if it’s a simple, “I don’t understand, could you try rephrasing?”.
- Likewise, this is why we have the Welcome node greeting the user at the very top.
- That node has a special welcome condition that is only true at the beginning of the conversation with the user.
- By placing it up top,
- we ensure that it’s executed prior to any other node being considered.
- The fact that the condition is only true once,
- ensures that we don’t keep greeting the user every time we evaluate their input.
- Nodes can also have children nodes
- and there are situations in complex chatbots
- where employing this feature enables us to create a more nuanced chatbot.
- Children nodes are considered for execution
- only after the parent node has been executed,
- unless some other node in the dialog explicitly jumped to a given child node.
- Children nodes are then also executed top to bottom
- and we stop executing at the first child node that meets the condition.
- Watson Assistant
- introduced many cool new features that actually allows us to rely less on children nodes,
- greatly simplifying our dialog design.
- By the end of this course you’ll become familiar with both children nodes
- and the simpler alternatives you can commonly use in many scenarios.
BUILDING USER FRIENDLY CHAT BOTS
Welcome to the second video of this fourth module.
- The labs within this course will teach you everything you need to know
- about how to work with chatbots.
- However, before we get into the nitty gritty details,
- I wanted to quickly mention a couple of guiding principles for building user-friendly chatbots.
- Whenever you design a chatbot
- you should consider the tone and personality of your chatbot.
- Consider the audience and purpose of the chatbot
- and then adjust the chatbot accordingly.
- If you are targeting a younger demographic,
- vanilla jokes and emojis might be appropriate.
- If your chatbot is for a funeral home,
- perhaps avoid jokes and using slang.
- Much like you would if you were to train a human customer service agent,
- you want to ensure the chatbots issues responses
- that are appropriate for the circumstances,
- whether a formal or informal tone is in order.
- Consider the default chatbot prompt.
- “Hello. How can I help you?”.
- It’s a default value when we first create the dialog
- so it has to be generic by design,
- but it’s not very good and it’s the first thing I like to change in a chatbot.
- Let’s see how we can improve upon it.
- In our case, we might change it to say something like,
- “Hello. My name is Florence
- and I’m a chatbot here to assist you with your questions
- about store hours,
- and flower recommendations.”
- This is a much more user friendly prompt for the user.
- Let’s see why.
- We start by giving the chatbot a bit of personality
- by giving it a name.
- It’s no longer a random software in the ether.
- It’s Florence.
- Next, we come clean to the fact that we are a chatbot.
- This is important because
- it sets the right
- expectation with the user.
- We want our chatbot to be human-like
- but we don’t want to falsely pretend that it’s actually a human,
- as this will lead to disappointment for the user.
- Finally, we define the scope of the chatbot
- by guiding the user on what they might be able to ask.
- The worst thing a chatbot can say is a wide open,
- “What can I do for you?”.
- It’s okay as a reply later on in the conversation,
- after you already declared the chatbot’s scope.
- But a “Hello, What can I do for you?”
- off the bat
- is an invitation to ask the chatbot anything,
- and that will inevitably lead to disappointments.
- No matter how thorough of a job we do with our chatbot,
- we are not going to make it capable of answering every question it will receive.
- Heck, we wouldn’t even be able to make such a claim if we were training a human customer care agent either.
- But doubly so for a chatbot.
- On top of the considerations we discussed so far,
- I’d like to leave you with three important rules of chatbot design.
- The first one
- is that you should avoid including Yes and No
- in your answer.
- If you include them
- it’s very easy to give the wrong answer to the user
- or come across as less human-like that we’d want.
- For example, consider this question.
- We might have a #free_delivery intent
- and we might be tempted to answer with,
- “Yes, it is”.
- When the question is phrased like this, the reply works.
- However, if the user phrases the question differently,
- the same intent will be detected
- and the response will be issued.
- Only this time,
- “Yes, it is” is a pretty bad answer to the question,
- “Do I have to pay for deliveries?”.
- A much better answer is one that avoids a straight yes or no.
- By responding with “Deliveries are free” for example, we correctly respond to a question expressing a request for delivery pricing information no matter how it’s phrased.
- “Deliveries are free” for example,
- we correctly respond to a question
- expressing a request for delivery pricing information
- no matter how it’s phrased.
- Related to this first rule,
- whenever possible try to incorporate part of the user’s question
- in your response.
- The user will feel more understood
- and the chatbot will be perceived as more intelligent as a result.
- For example, the user might ask us
- if we have a store in a given city.
- “We have stores in Toronto, Montreal, Calgary, and Vancouver.”
- is an okay response as it answers the question.
- However, we could improve it
- by incorporating a bit of empathy
- and information provided by the user in our response.
- If we reply, “Unfortunately, we don’t have a store in Seattle.
- ☹️ To date, we have stores in Toronto,
- Montreal, Calgary, and Vancouver.”
- we are still conveying the same information,
- but this time we come across are more empathetic with the user
- and all we had to do is incorporate part of the user input in our response.
- Along with ensuring that the answer we provide to the user is correct,
- we should also consider its length.
- Nobody likes to read walls of text.
- Instead, people prefer to read answers that are
- one or two short paragraphs long at the most.
- If you need to convey a lot of information in your reply,
- you are better off linking to a page on your site
- where the user can learn more about the topic.
- Imagine a financial chatbot trying to respond to the user
- with the entire terms and conditions
- for a credit card application directly in chat.
- It would be comical.
- Linking to the right page would be more appropriate.
- And since we can embed HTML in our responses
- we can make such links clickable,
- making it more convenient for the end user.
- Okay, now it’s your turn.
- By the end of this module
- you should have a much better understanding of how intents,
- entities, and dialog work together
- to allow chatbots to provide useful answers to the end user.
- In the next module we’ll discuss deployment,
- and finally in the last two modules,
- we’ll look into more advanced features
- that enable us to create
- smarter and more useful chatbots.
With intents and entities under our belts, we can finally look at the third component: the dialog.
In fact, at this point, our chatbot can understand some intents and detect a few specific pieces of information thanks to entities. What we are missing is using this information to formulate appropriate responses to the user. Will do so in this module to create a simple, but useful chatbot. In this lab, we’ll start by defining chit chat responses.
Exercise 1: Create a Dialog and improve the prompt
Let’s kick things off by creating a dialog and a good prompt for our chatbot.
- Click on the Dialog sectionof your skill.
- It’s empty at the moment. Go ahead and click the Createbutton.
- Take a moment to investigate the default Welcome and Anything elsenodes that were generated, by clicking on them.
- Open the Try it outpanel and click on the Clear link at the top to start testing the chatbot from scratch. Notice anything different this time around?
- Yes, we have a prompt! Unfortunately, the default phrasing is not very user-friendly. Let’s change it.Select the Welcome node and edit the response to say My name is Florence and I’m a chatbot here to assist you with your questions about store hours, locations, and flower recommendations. Change the name from Florence, to whatever flower-inspired name you prefer, to make it yours.
- Click on the Clearlink in the Try it out panel once again to see the change take effect.
Great. We added a bit of anthropomorphization, set the expectations right by coming clean about our robotic nature, and offered some guidance to the user in terms of the scope offered by our chatbot.
- Now try replying helloin the Try it out What happens? Watson recognized the right intent (i.e., #greetings) but doesn’t have a node to handle greetings, so the fallback node Anything else was executed. We’ll remedy this in the next exercise.
It’s worth noting that if you enter a greeting (or anything at this point) multiple times, you’ll get a different response each time. The reason for this is that the Anything else node has three response variations by default. Furthermore, these are set in sequential mode. So every time we hit this node, the next response variation is provided to us, as shown below.
If we didn’t care about the specific order, we could set this to random and a random variation would be provided each time.
The reason why we want variation is that we don’t want to robotically say to the user, I don’t understand every time the chatbot fails to handle the user input with an appropriate node. It gets old fast and makes our chatbot come across as dumber that it could be.
For nodes that are unlikely to be hit multiple times within a conversation, it’s okay to have a single response with no variations. In every other case, variations are good to have.
You might wonder whether you should prefer sequential or random for your variations. Sequential works well when you plan to leverage your knowledge that the node was hit multiple times to provide a better response to the user. Random when the variation that is given to the user, doesn’t matter.
Go ahead and add a fourth variation to the Anything else node, with the following text: It looks like we are not quite getting each other today. Would you like to talk to a human agent instead? If so, please contact us at 555-123-4567 or email us at support\@example.org. The \ before the @ is needed to display the special character (something programmers call, “escaping”).
Because we have this set in sequential mode, we ensure that this escalation of the sort is only given as an option after we failed to understand the user four times in the same conversation. If this was set to random, we’d risk escalating the very first time we don’t understand the user, which is typically not what we want.
Exercise 2: Add Chit chat nodes
We have three chit chat intents, #greetings, #thank_you, and #goodbyes. We now need to have nodes that specify what response we want to give the user when such intents are detected.
We have a couple of strategies possible here. We could create three nodes, one for each of these intents. This is the most common and simple approach. The other option would be to create a single node for chit chat that uses multiple responses (essentially, conditional responses), attaching a condition to each response.
I would recommend that you stick to the traditional way as it’s more flexible. It allows us to add more chit chat nodes down the line, as well as making the chit chat logic more complex if needed.
We want to keep things organized, separating small talk from domain-specific nodes. So we’ll create a folder for chit chat, and we’ll create three nodes in it for now. The picture below shows the end result. At any time, you’ll be able to collapse or expand the folder by clicking on the blue folder icon.
Follow these steps to add it to your chatbot:
- Select the Welcomenode and then click the Add folder button. This will create a folder underneath the selected node (i.e., Welcome).
- Name the folder Chitchat. You don’t need to specify a condition for the folder, as the conditions of the children nodes will suffice.
- With the Chitchatfolder selected, click the Add child node button. This will create an empty child node within the folder.
- Name this node Greetings. We want it to be executed when the #greetingsintent is detected, so under If bot recognizes: enter the #greetings intent. Autocomplete will help you find the intent (not that useful here, but quite handy in complex chatbots with many intents).
It’s worth noting that you can make the condition of a node as complex or as simple as you’d like. You can use ||(or its alias OR) and && (or its alias AND) to make the condition more complex. We don’t want this here, but if you wanted to execute a node if the intent detected was either #greetings or #goodbyes we could simply type #greetings OR #goodbyes in the node condition.
- Enter a few appropriate responses. The scenario we are handling here is one in which we already greeted the user with our prompt, and they replied with a greeting. So we should greet them back without repeating the prompt verbatim.
Enter a few responses to offer some variation if we get a greeting-happy user. Examples could be Hi there. How can I help you?, Hello. How may I assist you today?, Hi. What can I help you with?
Normally, I would advise against open-ended questions such as how can I help you, but since we already qualified the scope of the chatbot in our prompt, we can get away with it here.
- You can leave the response variations set to sequential or set them to random if you prefer. The third option, multiline is not applicable here, as it would provide a response over multiple lines using each response you wrote as its own line, de facto asking the user what is essentially the same question three times at once. ?
This is what the node will look like.
- The And finallysection at the bottom of the node defines what happens after this node has been executed and a response was given to the user. In the case of this node, after we responded to the user, we expect them to enter some more questions, so you can also leave Wait for user input as the final action for this node.
- Open the Try it outpanel (if you closed it) and click the Clear link to start a new conversation. Try to reply hi to the chatbot prompt. Congratulations, you just had your first conversation with our chatbot. It’s not a complex interaction, but it’s a start. You can now close this panel.
- With the Greetingsnode selected, click on the Add node button. This will create an empty peer node below Greetings.
The order of these chit chat nodes is not that important because they are all simple nodes with independent intents. However, the order can matter in more complex scenarios (as we’ll see in a moment) and it makes sense to place them in a logical manner that is roughly equivalent to how a conversation would go. Greetings first, thank yous in the middle, and goodbyes at the end.
Go ahead and make this node handle the #thank_you intent. For the responses, you’ll likely want something like:
You’re welcome. Please let me know if you need anything else.
No problem. Let me know if there is anything else I can help with.
You could get chicky, and add:
I aim to please. ?
depending on how much personality you’d like to inject in your chatbot. BTW, yes, emojis are supported. Set the response variation to Random by clicking on the Random link.
- With the Thank younode selected,add a Goodbyes node which will handle the #goodbyes You can use standard polite goodbye responses such as Nice talking to you today., Have a nice day., and Goodbye.
- Start a new conversation in the Try it outpanel and test all three intentsto ensure you get an appropriate response in each case.
Exercise 1: Respond to hours of operation
Chit chat interactions are necessary to make our chatbot more pleasant and human-like. However, what makes the chatbot actually useful is its ability to answer domain-specific questions. That is business-related questions.
We defined intents for people inquiring about hours of operation and addresses of our fictional florist chain and even created an entity to be able to provide location-specific answers. However, much like the chit chat intents, intents alone don’t offer responses to customers. We’ll need to create nodes to handle these two business-specific intents.
Create the parent node
We’ll start by creating a node for hours of operation. Follow these steps:
- Select the Welcomenode and click on Add node. This will create an empty node just below the first node in the dialog.
- Set the node name to Hours of Operationand use #hours_info for the node condition. This will ensure that the node will be executed when the user is inquiring about shop hours.
- In the response, enter:
Our hours of operations are listed on <a href=”https://example.org/hours/”>our Hours page</a>.
Notice how HTML code is allowed in responses, enabling us to provide more interactive and useful textual answers.
Next, head over to the Try it outpanel and test that it works by asking:
When is your Vancouver store open?
as shown in the image below.
This works and it provides a somewhat useful answer to the user (assuming we are pointing them to a page with the right information listed). However, it feels… not very smart.
After all, the user asked us about a specific location. We even detected it with the @location entity (as well as the system entity) and then proceeded to ignore it, opting instead for a generic answer. We can do better than that. (Close the Try it out panel to gain some breathing room as we work on the dialog.)
In order to handle this case properly, we’ll have to consider three possible scenarios. One in which a location is specified and it’s one of our locations, a second one in which the city is specified but we don’t have a location, and a third one in which the user just asks about hours of operation in general without indicating a city.
This is a classic use case for child nodes. We’ll use our current node to capture the hours of operation request, and then jump to the child nodes to decide how to handle the request on the basis of the specific location information that was or wasn’t provided.
By the way, as the complexity of your dialog grows, you might have a hard time finding which node executed the response you’re seeing during troubleshooting. To help you out, you can click on the map pin icon next to the response, and the current node will be highlighted for you.
Create the Our Locations child node
- Delete the response from our Hours of Operationnode by clicking on the trash bin icon in the Then respond with: section. We do that because we don’t want this parent node to provide the answer. We’ll let the child nodes decide what’s the right response.
- With the Hours of Operationnode selected, click on Add child node. This creates the first child node. We’ll use it for the case of the user providing us a city for which we have a flower shop. So go ahead and name it Our Locations.
- Set the condition to @location, as we want to execute this node only if the user is inquiring about hours of operation for one of our locations.
As a reminder, a child node is only executed if the parent node’s condition is true or if it’s jumped to from elsewhere. This means that if we are executing this child node, two conditions will actually be true as far as the user input is concerned: 1) The intent will be #hours_info; 2) The input will contain the @location Knowing this allows us to provide very specific responses.
- We need a way to offer a different response for each city, so we need to enable Multiple conditioned responses. To do so, click on the Customizelink within our child node. Switch on Multiple conditioned responses and click Apply. You’ll notice that now we have the ability to attach a condition to each response, as shown below.
- Go ahead and create a series of responses, one for each city. In the IF ASSISTANT RECOGNIZEScolumn you’ll want to enter the specific city (e.g., @location:Toronto) and in the RESPOND WITH the hours of our fictional flower shop location (e.g., Our Toronto store is open Monday to Saturday from 9 am until 6 pm, except statutory holidays.)
Use Add response to add additional entries for each location we have. Feel free to come up with fictional hours of operation, as it is, after all, a fictional retail chain. The end result should be similar to the image below.
It’s worth noting that if the hours of operations where the same for all locations, we could have saved the trouble of switching to multiple responses and simply included @location in our response. (e.g., Our @location store is open Monday to Saturday from 9 am until 6 pm, except statutory holidays.)
This would automatically output the detected entity value back to the user in the response. So when enquiring about Calgary, the user would receive the response Our Calgary store is open Monday to Saturday from 9 am until 6 pm, except statutory holidays. Of course, if stores have different hours of operation, we need to opt for the multiple response approach like we did here.
Create the No Such Location child node
Now that we have a child node capable of handling hours of operation for our particular locations, we can focus on the case in which a user provides a city (detected through @sys-location), but we don’t have a store in that city.
- With the Our Locationsnode selected, click the Add node button to add a peer/sibling node below it.
- Call this node No Such Locationand add @sys-location as the condition.
- In the text response, enter:
Unfortunately, we don’t have a store in @sys-location.? To date, we have stores in Toronto, Montreal, Calgary, and Vancouver.
Notice that @sys-location will also detect our own locations, however, this node will never be executed for our own locations, because it comes after the Our Locations node. The execution of the dialog always goes top to bottom and stops at the first node for which the condition is true.
This is one instance were the order of the nodes matter. If we placed No Such Location above Our Locations, the very generic @sys-location condition would be true even for cities in which we do have a store, and therefore the execution would stop at this node, overshadowing Our Locations.
As a general rule, when organizing your dialog, always place nodes with specific conditions at the top and ones with more generic conditions at the bottom.
(If you are wondering why we bother with @location at all and not just use @sys-location even for our own locations, revisit Module 3 where we discussed the tradeoffs of @sys-location.)
Create the Location Not Provided child node
We now have two child nodes to handle users asking about hours of operation for a specific location (whether we have a store there or not). However, we also need a child node to handle the case in which the user didn’t specify a location.
- With the No Such Locationnode selected, click the Add node button to add a peer/sibling node below it.
- Call this node Location Not Provided.Set the condition to true.
Here is why. When the user asks What are your hours of operation? the #hours_info intent is detected, so we enter the parent node Hours of Operation.
The Our Location child node is then first evaluated. We fail its condition because the user didn’t specify any location, so the next child node is considered for execution. We fail that condition as well because no @sys-location is detected either. So we finally consider this third child node.
Since the condition is set to true it will automatically be executed. This is exactly what we want to happen since at this point we know the user wants to know the hours of operation but no location was provided. (If we left the condition empty, we’d get an error because no child node was able to match the user request.)
- We need a generic answer for when no location is specified, so go ahead and reuse the message we had originally.Our hours of operations are listed on <a href=”https://example.org/hours/”>our Hours page</a>.
- Before we can test it all out, we need to make sure that the parent node (i.e., Hours of Operation) hands off control to the child nodes.
Select the parent node, and you’ll notice that the And finallysection is set to Wait for user input. This is not what we want. The user has already provided us with the question and we haven’t responded yet. Change this section of Hours of Operation to Skip user input. This will hand off the execution to the two child nodes we just created.
- Click on the Try itbutton and try the following inputs (one at a time):
What are you hours of operation in Toronto?
What are your hours in Calgary?
What are your hours in Seattle?
What are your hours of operation?
You should see a proper response for each of these inputs.
Exercise 2: Respond to address requests
Our little chatbot is getting more useful by the minute. We now need to handle location address requests. And guess what? It’s no different in terms of how this works. We’ll have a parent node and three children to distinguish each scenario. By the way, at any time, you can click on the arrow next to the Hours of Operationnode to collapse or expand its children. Collapse its child nodes now to gain some breathing room.
In the new parent and child nodes to handle address request will need to change one condition (#location_info instead of #hours_info) and change the responses from hours of operation to actual addresses. Overall though, the structure is identical. So we could redo the process in Exercise 1 above, step by step, or we can be more efficient and simply duplicate Hours of Operation and change this copy to our needs.
We’ll opt for this more efficient route:
- Click on the three vertical dot icon to the right of the Hours of Operationnode and select Duplicate to make a copy of Hours of Operation and its children.
- Select the Hours of Operation – copy1node that was generated. Change its name to Location Information and its condition to #location_info. Its name will allow us to distinguish it from its remarkably similar sibling Hours of Operation, and the condition will ensure that Watson will only execute the node when the user asks for an address not hours of operation.
- Next, we’ll need to change the responses in two child nodes within the Location Informationtree.
We don’t need to change the No Such Location response because the one we have applies to both requests for hours of operation and for address requests from the user (i.e., Unfortunately, we don’t have a store in @sys-location. ? To date, we have stores in Toronto, Montreal, Calgary, and Vancouver.)
Feel free to get creative but here is the type of response you should assign to each city in Location Information > Our Locations:
Our Toronto store is located at 123 Warden Avenue.
Add fictitious address for all the cities in that node.
Likewise, in the more generic Location Information > Location Not Provided change the response to:
Our store locations are listed on our site on the <a href=”https://example.org/stores”>stores page</a>.
- Open the Try it outpanel, press Clear to start a new conversation, and test out a full conversation a user might have with our chatbot. Enter in succession the following input.
where are you stores located?
what are your hours of operations in Montreal?
If you followed the instructions so far, you should have a pretty neat conversation. We can, of course, flesh out our chatbot much more, but if you got to this point, you have mastered the fundamentals of what you need to know to create something useful that cuts down of many common inquiries from your customers.
We’ll soon see how to deploy the chatbot, and then tackle more advanced topics in the process of improving the chatbot’s usefulness and apparent degree of intelligence.
Are child nodes really necessary here?
Technically speaking we don’t need child nodes to handle the two scenarios we implemented above. We could simply add multiple conditional responses to the parent nodes, and add responses for each of the cities, @sys-location, and the catch-all true case, all from within the same node.
However, I wanted to show you how to work with child nodes, the importance of their ordering, and their flexibility. If the logic was more complex than just a generic response, having a dedicated child node to handle it would likely be a good idea, anyway. In some complex chatbots, you might even have child nodes that have their own child nodes.
Later in the course, we’ll get rid of child nodes in favor of something called Slots. For now, please keep the three child nodes below both Hours of Operation and Location Information, as you defined them in this lab.
The small chatbot we built so far works well enough from the Try it out panel. That’s great and all but our customers won’t have access to it unless we deploy it somewhere. Let’s see how to accomplish that.
Exercise 1 – Create an Assistant and link it to your skill
So far we created a dialog skill, which is the core engine of our chatbot. However, in order to deploy it, we’ll need to create an Assistant and link it to our skill. You can think of an assistant as a container of one or more skills. When you deploy a chatbot on a site, you’re a deploying the assistant.
- Click on IBM Watson Assistantat the top of the page. This will bring you back to your Skills
- From here, click on the Assistantstab at the top and then the Create new button.
- You’ll be asked to give it a name (e.g., Florence Chatbot) an optional description, and whether or not you want a preview link.
Definitely keep the preview enabled so that you’ll be able to show a preview of your chatbot to other people by simply giving them a link. It’s a great tool to let other people try your chatbot before you actually deploy it on your site.
Finally, click on the Create button to generate the assistant.
- You’ll be prompted to add a dialog skill to the assistant you just created. Since we already worked on one, we’ll click Add Dialog Skilland then select Add existing skill. Next, select the Flower Shop Skill by clicking on it. You should see that the Florence Chatbot assistant now has the Flower Shop Skill linked to it.
- Your chatbot assistant is now ready to be deployed. You can see a preview of it by clicking on the Preview Linkbutton in the Integrations A page containing the actual link will open up. Click on that link to see your chatbot in action.
This preview link can be shared with friends and colleagues who’d like to try out your chatbot. Do bear in mind that every time someone sends a message to the chatbot, one API call is made and it counts towards your free allowance (10,000 API calls per month in the Lite plan).
- When you deploy your assistant in the next steps, you’ll be asked to provide your chatbot credentials. Click on the three vertical dots icon and then on the View API Detailslink in the top right of your Florence Chatbot assistant page.
You’ll need to know the Assistant URL, Username and the Password in order to successfully deploy your chatbot later on. Make note of them now and then click on the X to close the API credentials page.
Exercise 2 – Generate a WordPress website
You followed along and now have a simple Flower Shop chatbot running in your Watson Assistant service. That’s great, but how do we place it on an actual site?
WordPress is a content management system that allows anyone to quickly have a website up and running. This platform has a lot of features out of the box, and many more can be added through plugins.
We developed one such a plugin for Watson Assistant to make it extremely easy to place a chatbot on a WordPress site.
We’ll discuss the plugin in the next lab. But first, we need to create a WordPress site.
Click on the Generate Site button at the bottom of this page to create a WordPress site. You’ll be given details about your site, similarly to the ones shown in the figure below.
Please make note of the credentials you’ll be given upon generating the site, you’ll need them to log into the site in Lab 2. In particular, write down somewhere your generated WordPress Dashboard URL (where you’ll log in), your username, and your password. (Note that these are WordPress credentials and therefore different from the API ones you wrote down earlier in this lab).
If you lose them, you can always come back to this lab and click the button at the bottom to display the credentials again.
Click on Go to SITE green button or visit the Instance URL to verify that your site has been created correctly. You should see a flower shop site.
GENERATE A WORDPRESS SITE (EXTERNAL RESOURCE)
This course uses a third-party tool, Generate a WordPress site, to enhance your learning experience. The tool will reference basic information like your username, email and user ID.
WORKING WITH CONTEXT VARIABLE AND SLOTS
Welcome to the sixth module of How to Build Chatbots.
- Now that you know the fundamentals of chatbot building
- and how to deploy your chatbot to a WordPress site,
- it is time to look at more advanced features.
- We’ll do so in this and the next module of the course.
- In this module, we’ll focus on two important concepts
- that can really take your chatbot to the next level.
- Namely, context variables and slots.
- Consider the following interaction.
- The user asks the chatbot about hours of operation for a specific location.
- The chatbot replies correctly.
- Then the user asks for the address of the store
- and the chatbot replies with a generic list of all stores, i
- nstead of the specific information.
- A human answering the same question would understand from the context
- that the user is asking about the location they already mentioned.
- But our current chatbot does not.
- The reason why this happens is that entities are captured and exist only during the current user input.
- There is no memory of them once the user enters new questions.
- So, even though the Toronto store was mentioned before,
- we have no recollection when the user asks us for its address.
- The only way this would work as expected,
- would be if the user were to repeat Toronto again in their request for an address.
- Unfortunately, we can’t control how people choose to phrase their questions
- and it would be uncommon for the average user to repeat Toronto again
- when it’s obvious from the context of the conversation.
- This is the problem that context variables allow us to solve.
- At any time, in any node of our dialog,
- we can store values we collected from the user for later use.
- Unlike entities, context variable remain available for the entire duration of the conversation with the user,
- so we can refer back to them at any time.
- We could, for example, store the location entity value in a $city context variable
- in the node that handles hours of operation.
- Then when we hit the location info node
- we can look into the $city context variable
- to see if a value has been set.
- If it has, we can use it to provide a specific address to the user.
- There are a few ways to set context variables,
- but one of the most convenient ways is using slots.
- We could for example add an optional slot to our node,
- and check for a @location entity.
- If one is found in the user input,
- the value will then be stored in the $city context variable.
- It is optional because we don’t force the user to give us a city.
- We simply assign it if one is provided.
- So when the user asks a generic hours of operation question without specifying a location,
- no context variable is set
- and we can reply with a link to a page that includes all our locations and hours of operations.
- But if a location is specified,
- we store it in the $city context variable through the slot
- and then use it in our multiple responses within the same node
- to provide the specific hours of operation for the given location,
- in this case Vancouver.
- We can make the slot required,
- by adding a question that the chatbot will ask
- whenever no @location is provided by the user.
- When the user asks,
- “What are your hours of operation?” without mentioning a city,
- our chatbot will then reply with “For which city?”.
- The slot will not give up asking the question until a valid answer is provided.
- Once the user provides the specific city,
- it will get stored in the context variable as usual
- and the multiple responses in the node will handle the specific response for the city at hand.
- It’s also worth noting
- that you can have multiple slots within the same node.
- In fact, this is the most valuable aspects of using slots.
- They are great at collecting information from the user,
- especially when multiple follow up questions need to be asked.
- For example, consider the case of a restaurant chatbots booking a reservation for a customer.
- The chatbot will ask how many guests and then store the number in an appropriate context variable.
- Then it might ask the date, then the time,
- and finally which name the reservation should be made under.
- Each of these question is one slot within this hypothetical reservation node.
- Once the information has been collected and stored in the context,
- the restaurant will have access to the data needed to book the reservation in.
- This could be done manually (by checking the logs)
- or through a bit of programming,
- by making the node make a call to an API service to schedule the reservation in whatever table system the restaurant adopts.
- to schedule the reservation in whatever table system the restaurant adopts.
- I wanted to give you a decent theoretical understanding of what problems context variables and slots solve.
- However, as it’s often the case,
- the only way to truly master these concepts is for you to practice them.
- The labs in this module will get you to improve your chatbot by employing some of the techniques discussed here.
EXPLORE CONTEXT VARIABLES
By now you know the essentials of Chabot building. There are however some more advanced concepts that will enable you to create better and smarter Chabot.
I could list them all here at once, but I think it makes more sense to organically introduce them as their need arises in the process of improving our Chabot.
Keep in mind that some of these concepts are tougher to get, particularly if you have no prior programming experience. So don’t be discouraged if you don’t fully get everything right away.
You can try things, test to see if they work, and if they don’t, try something else. That’s why the Try it out panel is so useful. It allows you to build Chabot one feature at the time. Stick with it, and if you practice, you’ll quickly become familiar with the advanced concepts.
Exercise 1: Remember the city with context variables
Whenever a user enters a new input, the intent and entities that are detected don’t stick around for the rest of the conversation. They exist at the moment, for the current input, and are forgotten once the user types more questions.
This is generally fine, but it limits the Chabot ability to appear smarter and remembering the context of the conversation so far. For example, consider the following interaction.
A human customer agent responding to the second question would have inferred that the user is asking about the hours of operation for the city they just inquired about in the previous question (i.e., Calgary). However, the entity detected in the first input only lives for the duration of that input, so our chatbot has no memory of it when the user enters a second question.
How can we store this information so it’s available for the duration of the conversation? Enter the concept of context variables, which allows us to do just that. As we go about collecting information from the user, we can store them in the Context and then reuse it when it makes sense.
One way to achieve this is to create a passthrough node that checks for the @location entity and sets it to the $city context variable if one is detected. It then hands off the execution to the rest of the nodes as if this node didn’t exist.
Keep in mind that this is not necessarily the best approach, but it allows us to demonstrate a couple of things:
- The passthrough node technique which can come in handy in complex chatbots;
- How context variables work.
So let’s see how this would work in practice.
- In the Dialogsection of your skill, select the Welcome node and then click Add node to create a sibling node underneath (as a reminder, all nodes must be contained between the Welcome and the Anything else node).
- Call the node Assign Cityor something similar. Set the condition to @location. Delete the response by clicking on the trash can icon in the response area, as we don’t want this node to issue the response, only to set the variable in the context.
- Next click on the three dots to the right of Then respond with:and select Open context editor.
- You’ll be offered the ability to set one or more context variables whenever this node is executed. Enter $cityfor the variable name, and @location for the value.
In the And finally section we don’t want to wait for the user input (they already gave us input to process) we just want to jump to the rest of the nodes as if nothing happened. To do so select Jump to from the drop-down list. You’ll be asked to specify which node to jump to. Select the first node just below the current one (i.e., Hours of Operation).
You’ll then be asked to specify what to do after the jump. Wait for the user input? No. Jumping to the response directly? No. Select is If assistant recognizes (condition) so that this node can be evaluated as it normally would.
To recap, our node detects if there is a @location specified in the input. If there is we execute the node which does nothing but set the context variable $city to the entity value (e.g., Vancouver). Then we jump to evaluating the condition of the first node beneath us so that the flow is the same as if this context variable assigning node wasn’t there. If that node’s condition is successful it will be executed. If not, the nodes beneath will be evaluated in their order of appearance. If none of the nodes satisfy the current input, we hit the fallback Anything else node as usual.
Your Assign City node should look like shown in the image below.
- Head over to the Try it outpanel and ask What are your hours of operation?. Click on Manage Context at the top of the panel to see the content of the Context (i.e., its variables).
The $timezone variable will already be set for you automatically, but because we didn’t specify a location, the Assign City node was not executed, and therefore no $city context variable was set.
- Close the context and now try entering What are your hours of operation in Montreal?in input. Next, click on Manage Context You’ll notice that this time the $city context variable has been set to the entity value (i.e., the string “Montreal”). We’ll have access to this variable for the entire duration of the conversation with the user (or until we set its value to something else). It’s worth noting that pressing Clear in the panel starts a new conversation, and so context variables are cleared as well. Go head and close the context manager again.
- We want to make sure that $cityvariable is set whether it was specified along with a request for hours information (as we already did) or for location addresses. So as a sanity check, try where is your Calgary store?. You should see that the city in the context now changes to the string “Calgary”.
- Alright, we now store city in our trusty $citycontext variable. To make use of it, we’ll need to change our Our Locations child nodes under the Hours of Operation and Location Information parent nodes.
There is an easy way to do this. Simply replace @location with $city for every occurrence in the two Our Locations child nodes as I did in the image below.
Make sure you repeat this process for both Our Locations child nodes.
- Next, test the original interaction again. As a reminder, you can save time by recalling previous input through the Up key on your keyboard, instead of retyping the same questions in. Enter,
what’s the address of your store in Calgary?
ok, what are the hours?
You should now see a smarter response as shown in the image below!
The chatbot definitely comes across as smarter and it’s more useful to the end user.
- But wait… now that we have the $cityvariable, can we use it to help our business even further? It would be a nice touch to tell the user we hope they’ll visit our store when they wave us goodbye.
Simply change the Goodbyes node responses to include the $city variable. If it’s set to a specific city, it will be shown. If it’s not set, it will not be displayed. So go ahead and change the first response for that node to:
Nice talking to you today. We hope you visit our $city store.
If the $city is set to, say, Calgary, the response to the user will be Nice talking to you today. We hope you visit our Calgary store. If no city is set, simply Nice talking to you today. We hope you visit our store. A small, but still nice touch that invites our customers to shop with us.
Go ahead and test that it works in the Try it out panel. Next, click on the Clear link at the top to clear your variables and try typing bye with no context variable set. You should see that the response still makes sense. (As a general rule, always clear the context whenever you are running a new test.)
Context variables are quite useful, as I hope this small example allowed to illustrate.
Exercise 2: Collect the user name with <? input.text ?>
Sometimes you’ll see chatbots asking for the user name, so as to make the interaction more personable. We know that we’d want to store it in a context variable once we acquire it, so that we can refer to it throughout the conversation to sound more friendly. However, how would we go about collecting the name?
- Since we are dealing with names, let’s start by enabling the @sys-person entityfrom the System entities Watson will start training (as expected).
- Back in the Dialog, select the Welcome We need to change the prompt so that it asks for a name. Enter,
Hello. My name is Florence and I’m a chatbot. What name can I call you by?
- We need a child node to actually collect the name(the answer to our question, in other words). So go ahead and create a child node under Welcome. Call it Collect Name. For the condition, we want to detect that a @sys-person name was provided.
- Click on the three dots icon in the response section and open the context editor. Set the context variable $nameto the value @sys-person.
- Next, we want to reply to the user from this node, so add the following response,
Nice to meet you, $name. How can I help you? You can ask me about our store hours, locations, or flower recommendations.
Use the Try it out panel to test out the interaction, as shown below. (Click Clear to start a brand new conversation and see the new prompt.)
Nice! We are all set, right?
We have a problem
Well, not so fast. You might have spotted the problem if you tested it with your own name (depending on how common it is). We live in a beautiful and diverse world, and people have a variety of names. If you try it with the name, Reyansh it won’t detect it. Heck, if you try antonio with a lowercase a, it won’t detect the name either. I fully believe this latter limitation will be lifted in the future, but the former is much harder to address.
So we have something that sort of works, provided the name is common enough and properly capitalized. If that’s not the case, the experience we provide is… poor at best, ending up with I didn’t understand type of responses to the user’s own name (the sweetest sound to their ears).
We have three possible approaches. All valid.
- Forget about collecting the name. We simply revert to the previous prompt, get rid of the child node, and that might be good enough for our chatbot.
- Collect the name in the node we created, if one is detected, as we currently have. Add a second node that simply doesn’t set the context variable and replies with a generic Hello, without a name.
- Collect the name in the node we created, if the name is detected. Add a second node that collects what the user enters verbatim. In other words, we are collecting whatever answer the user provides and storing it exactly as stated.
We’ll take this third route as it’s the most refined of the three and it’s the one that allows me to teach you the most concepts.
The only downside to this is that the user might say, I don’t want to tell you and we’ll end up saying, Nice to meet you I don’t want to tell you. Which is amusing, but an argument could be made that the user asked for it. ?
Technically, we could implement even more sophisticated logic to detect such responses (with an intent) and not store the name if we get a flippant reply from the user, but it might be overkill or a refinement for a much later version of our chatbot.
Fixing the problem
As I mentioned, we’ll take the third approach to fix this problem. If for no other reason than collecting the user’s input exactly as provided is a useful notion you might need in future chatbots.
The current Collect Name node works well for names detected by the system entity. However, we should rename the node to something like Collect Sys-Person Name to make it more descriptive.
Next, add a peer/sibling node below it to handle the common case where the user reply is not detected as a valid name. We’ll want this second node to be executed every time the first child node (i.e., Collect Sys-Person Name) fails its condition, so set the condition for this node to true (it’s essentially our fallback node in the Welcome tree). You can call this node Collect Other Names or something equally descriptive.
Watson stores the current user input in input.text. So open the context editor for this node and set the $name context variable to <? input.text ?>. The reason why we need the special syntax is that we don’t want to say Nice to meet you input.text. but rather we are asking Watson to give us the actual value.
Doing so will collect the user input and assign it to the name. For the response, you can use the same response as the node above:
Nice to meet you, $name. How can I help you? You can ask me about our store hours, locations, or flower recommendations.
If you want to always capitalize the name, so that antonio is stored as Antonio, you can use a bit of code and replace <? input.text ?> with:
<? input.text.substring(0, 1).toUpperCase() + input.text.substring(1) ?>
This will capitalize the first letter of the user reply for you.
If you are not a programmer, don’t worry too about the details. Simply know that it capitalizes the input text and you can copy and paste it whenever you have such a need in your chatbots.
The image below shows what the node should look like.
As usual, use the Try it out panel to test that it works, whether you use a name recognized by the system entity or not. As a reminder, click Clear between each test to clear the context.
Using the user name in the Dialog
Now that you’ve collected the name, we can start using it in our responses in order to make our chatbot more personable. All you have to do is add $name to the appropriate responses. Great candidates would be the three chit chat nodes. For example, we could revisit the response in Goodbyes to say:
Nice talking to you today, $name. We hope you visit our $city store.
Likewise, incorporate $name in the responses for the Greetings and Thank you nodes like I do in the sample image below.
Finally, test out a complete conversation with the chatbot:
(enter your name after the prompt)
What are you hours of operation of your Toronto store?
Where is it?
Pretty neat, right?
Help! It didn’t work.
If the conversation above didn’t work well for your chatbot, it’s likely because some mistake (or happy little accidents as Bob Ross would have called them) was made in the process of following the instructions.
If that’s the case, no worries, you can import this JSON file with the current chatbot we built so far. You can then click on Assistants in your Watson Assistant instance, then click on your assistant (e.g., Florence Chatbot). There you’ll find your skill. Click on the three dots and then select Swap Skill.
This enables you to replace the current skill with a different one. As you click that, a new page will appear allowing you to create a new skill, use an existing one, or importing a skill. Select the Import Skill tab, upload the JSON file you just downloaded (by clicking on Choose JSON File) and then click Import. You want to import everything as you need the dialog as well.
Once the import is done, you’ll have the skill we developed so far linked to your assistant. A successful notification will appear. Try the conversation again and this time it should work for you.
Exercise 1: Follow-up questions and slots
What we just did, beside learning about <? input.text ?> is handle a follow-up question in a child node. This is a common pattern in which a parent node asks for information or clarification from the user and then one of its child nodes handles the response to the user.
If multiple follow up questions that are dependent on each other have to be asked by the chatbot, you’ll end up with a cascade of children nodes, each asking the next question in the chain and having their child process it. This works but it’s not ideal in terms of reasoning about or structuring your chatbot dialog flow.
Another shortcoming of this approach is that if the user asks a side question or just says, wait a second, instead of replying to what we asked, we’ll end up losing our “position” in the dialog cascade and therefore end up treating the delayed answer as a brand new input, failing (most likely) to provide an appropriate response or collect the information we wanted.
There is a much better tool to help us collect information from the user and store it in context variables. Namely, I’m talking about Slots.
Let’s see a practical example of how they work.
- From the Skills tab of your instance,define an intent called #flower_recommendations with at least 5 examples of ways people might ask for flower suggestions (e.g, Flower recommendations, flowers suggestions for my girlfriend, Which flowers for Valentine’s Day?, etc.). Watson will train on it as usual.
- Create a node called Flower Recommendationsbelow the Welcome node (as a peer node, not a child). Set the condition to #flower_recommendations. This is the node that will handle our flower recommendations.
- Click on the Customizelink in the node and turn on the Slots feature. Leave Prompt for everything unchecked, as this option is only useful if you have multiple slots/questions for the user and you want to ask them all at once, rather than one at the time. Not a common scenario. Finally, click on the Apply
- This will automatically add one empty slot to our node. We use slots to collect information from the user and store it in a context variable.
The three key components of a slot are CHECK FOR(often an entity), SAVE IT AS (a context variable), and IF NOT PRESENT, ASK (an optional question to explicitly request the information if not provided). Enter @occasion, $occasion, and What occasion are the flowers for? You’ll notice that the slot type changes from Optional to Required the moment we add a question.
This node will be executed when its condition #flower_recommendations is true. In other words, when the user is asking for flower suggestions. However we want to know for which occasion the flowers are meant, so as to have an appropriate response for different occasions.
The slot will automatically assign @occasion to the $occasion context variable if the user provided an entity value in their original question (e.g., flowers suggestions for Valentine’s Day) and not ask the question in that case.
If the @occasion entity is not detected, because the user simply asked, I’d like some flower recommendations without specifying a particular occasion, then the slot will ask What occasion are the flowers for? until the user replies with a relevant @occasion. The slot is like a dog with a bone and will keep asking the question until the user enters a valid occasion. So if the user enters an irrelevant reply, the slot will ask the question again.
By the way, a node can have multiple slots (through that Add slot button), if multiple pieces of information need to be collected.
- After the slot does its job of clarifying with the user which occasion are we talking about, it will store it in the $occasioncontext variable. So we can use it directly in the response section of the same node, without the need to create a child node. We want to provide a different answer for each occasion, so we’ll want to enable Multiple conditional responses for the node from the Customize link as well.
- Now you can add different answers leveraging the content of the context variable $occasion, as shown in the image below. Go ahead and replicate it in your Flower Recommendations node, handling at least a few occasions from @occasion. If you don’t implement them all, make sure you add a truefallback response for the occasions you don’t handle otherwise the user will receive no response at all (a cardinal sin of chatbot design).
For the generic response, you might recommend a mixed bouquet that is versatile enough for different occasions. (Admittedly I know much more about chatbots than flowers.)
The slot sets the context variable $occasion for you. Make sure you use $occasion not @occasion in your multiple responses.
- Once you’ve added a few, open the Try it out panel, press the Clearlink if needed, and test that this is actually working. For example, for your turns, try entering:
I’d like flower suggestions
You should get the response you specified (provided you added one for the condition $occasion == “Mother’s Day”). Something similar to the conversation shown in the image below.
Note that we can normally use the : shorthand when working with entity values that have no spaces. So $occasion:Birthday is equivalent to explicitly saying $occasion == “Birthday” which means the value stored in $occasion is Birthday. However, if the entity value contains a space, as it’s the case for @occasion:(Mother’s Day), you’ll want to use the explicit form with the equal equal symbols (e.g., $occasion == “Mother’s Day”).
Using a slot saved us from having to implement the collection of the $occasion somewhere (e.g., in a passthrough node like we did for Assign City), handling everything neatly in one node. With a required slot (so one for which you defined a question to collect information from the user), we can count on $occasion existing as we formulate our responses.
Note that if you don’t specify a question, the slot becomes optional, which means that the entity value will be stored in the context variable of your choice if detected in the user input, but the user won’t be asked explicitly for it (since you didn’t provide a question).
If you add two slots to a node, then the node will ask the first question, store the information in your first context variable, then proceed with asking the second question and storing that answer in the second context variable you specified. In our case, we could have used the second slot to ask for the @relationship. Knowing both occasion and relationship would then allow us to come up with really fine-tuned answers. In the responses, we would be able to combine the two through logical AND and OR logical operators (e.g., $occasion:Birthday AND $relationship:wife).
The classic example of multiple slots in a node is a chatbot that makes a restaurant reservation. Let’s say that the information it needs to collect is the name, phone number, date and time, and party size. The node can define a slot for each of these values with their respective questions. This greatly simplifies the dialog flow, as it reduces what would require several nodes, to a single node that does all the work. It also ensures that the answers are collected before the conversation proceeds further which is crucial in a scenario where, say, you are making a reservation.
To handle complex logic you can use both slots and children nodes. Slots to collect the info, children node to do the processing of that information according to your logic/preferences.
And since slots collect the information in context variables, we can refer to their values throughout the conversation with the user. So in the example of the reservation, we might be able to provide a confirmation of the reservation as we wave the user goodbye.
Exercise 2: Reimplement hours and locations
Now that we know how to work with slots, we can greatly simplify our Hours of Operation (and eventually the Location Information) node.
- Get rid of the Assign Citynode by clicking on the three dots icon on that node, and then selecting Delete.
- Define a slot with the condition @locationinside of Hours of Operation. Assign the value to $city. Make the slot required, that is, explicitly ask the user For which city?, if they didn’t specify it in their original question.
- Enable Multiple conditional responsesfor the node. Then move the response information from the Our Locations child nodes into these responses within Hours of Operation, as shown in the image below.
- Since Hours of Operationnow does issue a response, we need to change the And finally action to Wait for user
- Copy the responses for the system location and no location child nodes somewhere (e.g., in Notepad) and then delete Hours of Operation‘s child nodes (all three of them).
At this point, you will have the basic scenario for our locations handled by the combination of the slot and the multiple responses. If you test it with what are your hours of operation the chatbot will ask your For which city? and if you reply with one of our cities such as Vancouver, you’ll get the right response. Great.
Since we made the slot required with a question, we don’t even need to worry about the fallback case (for now), but we should be able to handle the @sys-location case. Right now the slot will demand @location and ignore @sys-location. Try replying Kelowna or lsdfjlfkj when asked for which city. The chatbot will ignore us entirely and ask us for the city again. Not good!
We can approach this issue in a few ways, including reverting to a dedicated node that handles non @locationcases or configuring a Not Found response in the slot to inform the user of which locations we have. We’ll cover Not Found in the next module, so for now, we’ll take the easiest route here and just make the slot optional. This way we’ll be able to handle all three scenarios from a single node.
Let’s see this in action.
- Remove the question from the slotwithin Hours of Operation to make the slot optional.
- In the response section, add a response with the condition @sys-locationand the response:
Unfortunately, we don’t have a store in @sys-location. ? To date, we have stores in Toronto, Montreal, Calgary, and Vancouver.
- Add a final response with the condition true,and the response:
Our hours of operations are listed on <a href=”https://example.org/hours/”>our Hours page</a>.
The resulting node’s slot and response section will look as shown in the image below.
- Test that the node is working as expected. Try the following conversations (clicking Clearin between each test):
(Enter your name)
hours of operation
(Enter your name)
hours of operation in Kelowna
(Enter your name)
hours of operation for Vancouver
All three scenarios should work as you expect.
- Repeat the whole process for the Location Informationnode adjusting the responses accordingly.
- Test the Location Information node with the following text (again, click Clearin between each test):
(Enter your name)
list of locations
(Enter your name)
what’s the address of your Kelowna store
(Enter your name)
what’s the address of your Vancouver store
All three scenarios should also work as expected.
The image below shows what the dialog will look like after all the changes have been correctly implemented.
If you are lost or encountered problems when testing the chatbot, you can download the JSON file for the dialog skill we developed so far.
Welcome to the seventh module of How to Build Chatbots.
- At this point you should have a solid understanding of what context variables and slots bring to the table.
- There is still one problem we’re facing that we don’t have a solution for yet.
- Consider the following interaction.
- The user asks the chatbot for some flower recommendations.
- The slot will ask for what occasion.
- Instead of replying with an occasion, the user decides to ask about hours of operation.
- The slot will continue to pester the user, asking for the occasion
- and ignoring other questions from the user,
- even though technically the chatbot knows how to answer such questions.
- The problem is that required slots won’t quit asking their question
- until an acceptable answer has been provided and stored in a context variable.
- One option we have to make the interaction less obnoxious
- is to configure the Not Found section of a slot.
- Found and Not Found sections allow us to specify what the slot will say to the end user
- when they reply with an acceptable answer and when they don’t, respectively.
- Typically, you’ll use the Found section to thank the user for answering your question
- or just leave it blank as it is by default.
- More interestingly, however,
- we can use the Not Found section to make asking the same question again less awkward.
- In other words, we can soften the blow of ignoring their second question by apologizing for having to ask the question again.
- by apologizing for having to ask the question again.
- Here is a practical example of how configuring the Not Found section of a slot
- can make the interaction a little smoother.
- You’ll notice that when the user asks us an unrelated question
- while the slot is asking for the specific occasion,
- we don’t just repeat the question verbatim.
- In this case, we’d say something like,
- “Sorry to ask again, but what occasion would you like flower recommendations for?”.
- It comes across as significantly more empathetic
- and less robotic even though technically we are still asking the same question.
- This is an improvement,
- but wouldn’t it be great to be able to answer the aside question we received from the user,
- and then come back to the original question?
- That’s what a human agent would do in most circumstances.
- It turns out this is possible thanks to digressions.
- We can allow a slot to jump to a different node
- after having asked the mandatory question,
- and we can specify that other nodes can return back to an originating slot
- after answering the user’s aside question.
- Let’s see a practical example of how this would work.
- When the user ignores our request for a specific occasion,
- asking our chatbot to provide store hours instead,
- digressions allow us to jump to the node that handles hours of operations.
- Since that node has a slot too,
- that slot will ask its own question about which city are the store hours for.
- Once the user replies with Toronto,
- the node will provide the information to the user and return to the original node where the slot will ask about the occasion once again.
- This is a workflow that works quite well
- and makes our chatbot come across as smarter and friendlier.
- In some instances, you might not want to return but instead continue the conversation from the node you jumped to.
- With digressions, you’ll have a chance to specify the desired behavior,
- including which slots can digress to other nodes,
- which nodes can accept digressions,
- and whether a return is required.
- It’s a powerful and genuinely useful feature.
- So where exactly do we specify the Found and Not Found text for a slot? And where do we configure digressions?
- And where do we configure digressions?
- The nitty gritty details are, as you probably guessed,
- in the labs for this module.
- You’ll get to play with these new features that will make our simple chatbot more useful and user friendly.
- Keep in mind that these features are somewhat advanced.
- I know plenty of people who built great chatbots without understanding or relying on them.
- Still, having a precursory understanding of the advanced concepts presented in this and the previous module
- will really pay off once you start building your own chatbots,
- whether for yourself, your company, or paying clients.
Exercise 1: Handling user digressions
Slots are awesome. However, their stubborn nature (for required slots that specify a question) can come across as rude if we are not careful. They keep the user to the task, which is fine if the user enters something irrelevant. It’s less okay if the user is asking a legitimate side question, however.
Consider the following interaction.
That’s not great. It looks like we completely ignored the user’s legitimate question. Notice also that the chatbot understood what the user wanted (i.e., #hours_info was detected) but we were still somewhat rude to them by not addressing their digression.
Configuring Found and Not Found responses
A first course of action we have is to use the Slot’s Found and Not Found responses. These are issued to the user before the node’s own responses (in our case the actual flower suggestions for the given occasion), so they allow us to interject a message before the node replies to the user.
Let’s see them in action.
- Select the Flower Recommendationsnode and click on the gear icon next to Required in our node’s slot.
- Configure the slot by adding a Thank you, $name.response in the Found
- Add a Not Foundresponse that says, Sorry to ask again, $name, but what occasion are the flowers for? as shown in the image below. Then click Save. (Variations are also possible to make the chatbot less repetitive.)
Now, when we try the interaction again, we get a slightly more friendly interaction.
That’s better, maybe even good enough. We are apologizing when we have to ask again, and we are thanking the user when they provide the answer we need. Since we have their name, we sweetened the deal by including it in our messages.
But… we are still not answering the user’s legitimate side question about hours of operation. To properly actually handle that, we’ll need Digressions.
Digressions are a feature that enables nodes to pass control to a different node while they are processing a slot. What this means is that they allow the dialog to respond to a user’s side question, while they are in the middle of answering a slot.
Let’s see them in action.
- The first thing we need to do is ensure that the node containing the slot allows digressing away from it. Select the Flower Recommendationsnode again and click on Customize, and then its Digressions Here you’ll want to expand Digressions cannot go away from this node by clicking on the > next to it and turn on the option to allow digressions away from this node. Make sure you click Apply.
With the digression away enabled in our node, we’ll now be able to ask other questions in the middle of answering the slot’s question and get a proper response for them. Technically, the nodes we digress into need to allow the digression, but that’s the default setting so we don’t have to worry about it. (Should you ever need to prevent a node from being digressed into, you can disable the Digressions can come into this node for that node.)
Let’s see how this altered our interaction.
Awesome. We fixed our original problem. However, you might notice that we don’t come back to the original question about flower recommendations. This may or may not be what we want, depending on our chatbot. If we’d like to return, we’ll need to explicitly set Return after digression in the nodes we might digress to. Go ahead and set the option for all three nodes with slots (i.e., Hours of Operation, Location Information, and Flower Recommendations) as shown below.
Don’t forget to click on Apply, and then test the interaction again, as shown in the image below.
That’s quite nice! Our chatbot interacts like a polite human would in such a conversation.
- Technically, neither Hours of Operationnor Location Information have required slots, so we don’t need digressions. But in the future, we might decide to make their slots mandatory, so as an exercise, there is no harm in enabling the digression for both nodes now. Go ahead and enable Allow digressions away for both nodes.
- Test a few conversations with your chatbot from the WordPress site you deployed to earlier in the course.
Found and Not Found responses, along with Digressions, are useful tools to add further polish to our chatbot and make it appear more human-like in its interactions with our users.
We didn’t need it in our chatbot, but sometimes we might want to execute certain actions if the user responds to a slot in a certain way. For example, if we detect that the user is trying to cancel a reservation, we want to escape/exit the slot rather than continue to pester the user for details until they get frustrated and just leave the chat.
Found and Not Found do not allow us to attach any condition to the responses, and they don’t really allow us to exit the slot either.
To have conditions and skip a slot, you’ll need Handlers, accessible via the Manage Handlers link. Handlers are evaluated even before the Not Found response is issued.
This is what a Handler‘s response might be configured to escape the slot when the user cancels a reservation.
Again, this is not relevant to our chatbot, but I wanted you to know about their existence and why they might be useful at times.
Congratulations on getting so far into the course. We’re almost done. Meanwhile, if you need it you can download and import a JSON file of the dialog skill we created so far.