To create successful chatbots using Alexa or Lex, you first need to understand the components that make up a chatbot. These parts can then be used to create conversation diagrams and flow diagrams, helping visualize the user's path through the conversation. Being able to have this map for the user's conversation makes building chatbots far easier and quicker.

Toward the end of the chapter, we will also introduce Alexa and Lex and have a look at their similarities and differences. We'll also have a quick look at some of the use cases for each of them.

The chapter will explain the following topics:

• Introducing chatbots
• Designing conversation flow diagrams
• Best practices
• Amazon Alexa and Amazon Lex

Chatbots are a new way to interact with a user in a more human way, through conversation. This is vastly different from existing methods, which provide minimal interaction or personalization.

Chatbots can be either voice or text-based interactions, allowing them to be integrated into existing websites and apps or used in phone calls and virtual assistants.

They have recently been put in the spotlight with products such as Amazon Echo and Google Home, as well as an enormous number of Facebook Messenger chatbots. These advances in technology allow you to check the weather or order a pizza without looking at a screen, or get personalized information without having to wait to talk to a call center.

A chatbot is very different in the way that it interacts with a user, and therefore how it works is also very different. There are three main components of a chatbot: intents, slots, and utterances.

Intents are the most important part of a chatbot. They are the tasks or conversations that the chatbot can process. They are called intents because they are the things that the user intends to do.

Intents can vary in complexity from very simple to extremely complicated. A basic intent may just be SayHello, which just says "Hi" to the user. A more complex intent may be booking a holiday, choosing and buying a pair of shoes, or ordering a pizza. They can be designed to be as elaborate as your imagination allows.

They are started or triggered when the user says one of the sample utterances. The sample utterances are a list of words or phrases that the user might say when they are trying to start an intent. Each intent can have lots of sample utterances. In the SayHello example, they might be "Hello chatbot", "Hey there chatbot", or just "Hi".

To allow the chatbot to be really useful, it has to be able to gather details about what the user is asking for. If you are wanting to order a pizza, the chatbot needs to know what toppings you want, what style of base you want, and where you want it delivered to. This information is collected and stored in slots.

Slots are designed to only accept certain types of information. If you were trying to find out whether they wanted a large, medium, or small pizza, it wouldn't be very useful if they could enter any random information. Defining the information that can be stored in a certain slot is called creating a slot type.

To make use of the information gathered in the slots, they can be accessed in the next stage of the chatbot logic. This could be as simple as saying "You have ordered a large Hawaiian pizza", where the size and topping are exactly what the user previously ordered.

An utterance is a word or phrase that has been said. This is key to chatbots as this is how a user interacts with the chatbot.

These utterances can trigger which intent the user is trying to access and they can also be used to get the exact information needed to fill the slots.

Now that we understand the components that make up a chatbot, we can start to design the conversations that we want our chatbot to handle. Designing conversations now makes it a lot easier to visualize how the chatbot will work, making it easier and quicker to build. Designing conversations in this way makes them easy to understand, making it a great tool for creating chatbots with people who can't code.

This design method will work for voice or text chatbots; just imagine the textboxes as speech bubbles.

Everything has to start somewhere, so it may as well be perfect. The aim of this stage is to have a basic conversation diagram that we will later expand into a detailed flow diagram.

To do this, you need to think about what the perfect conversation with your user would be. Start by writing down what the user will say and how the bot will respond. This is an example of ordering a pizza:

This can be done in lots of ways: with flow diagram software, using two phones or two messaging accounts, or simply with pen and paper. The aim is just to understand how the chatbot is going to be interacting with the user and what utterances the user is likely to say.

Now that you have a basic conversation diagram, we need to make it into a flow diagram. A flow diagram is different from a conversation diagram in a few key ways:

• Each part of a flow diagram has its own symbol, making it easy to understand what is happening at each stage.
• A flow diagram contain more than just the conversation. It also describes the logic, information, and processes that take place behind the scenes.
• Flow diagrams aren't linear. This means that they can describe lots of conversations where the user says different things.

To properly describe our chatbots, we need to have a symbol for each of the parts of the conversation. To start with, we are going to be using six, but we can add more symbols later on:

To create our flow diagrams, we'll be using flow diagram software. There are a couple of reasons we want to use flow diagram software instead of a normal document or even creating them by hand:

• They are easily editable. We are going to be changing the stages of the conversational flow and the text of utterances and replies as we work through this book. Having to redraw the diagram every time you make a change would be very time-consuming.
• It's the easiest way to make flow diagrams. The symbols snap into place and are easy to edit and modify. Doing flow diagrams in Word would be far more time-consuming.

In all of the examples throughout this book, we'll be using www.draw.io, but if you have a different flow diagram software that you prefer then that will work too. We use draw.io as it's free, online, and is very easy to use.

Now that we know the parts of a conversation flow diagram, let's create one. We'll use the same pizza order conversation that we used earlier.

Start at the very beginning of the conversation. Create a symbol for the user's first utterance. This first message from the user is a really important one as it will trigger an intent:

Now that the OrderPizza intent has been triggered, our chatbot can start asking the user about the pizza they want to order. We'll start by asking what topping they want and they reply with "Hawaiian":

Later on, we want to remember that they chose Hawaiian as their topping so we need to store this as a slot. We store the information against a slot name, so in this case, it will be topping = Hawaiian. As well as storing the slot, we need to carry on the conversation, asking them what size of pizza they want:

With the response from the user, we store the size in a slot and proceed to the next stage. We repeat the question, answer, slot process for the size of pizza the user wants.

Now that we have all of the information that we need, we need to tell the pizzeria that someone has ordered a medium Hawaiian pizza. For this, we'll use the action symbol and make sure to include the slots that are required. When we include slot information into anything, it is normal to write it as the slot name wrapped in curly braces.

As well as telling the pizzeria about the order, we need to let the user know that their order has been placed and tell them when to collect it. Again, we use the slot name wrapped in curly braces to customize the message with slot information:

User stories are a vital tool in the design and testing of chatbots. They are stories about fictional users, what they want, and how they will interact with your bot. When we create a user story, it needs to be as close to a real user as possible. They should be based on a real user or the type of user that would be using your chatbot. If you have existing customers that you are wanting to target your chatbot toward then you can create data-driven user stories.

To create a user story, start by describing the user and why they are talking with your bot. Examples of the pizza ordering bot might be the following:

• Chris, a 23-year-old joiner. Wants to order a pizza on his phone so he can pick it up on the way home from work.
• Claire, a 35-year-old bank manager. Ordering a pizza using Alexa while she watches TV.

The user descriptions don't have to be very long or complicated, but they have to represent the kind of users the bot will get.

For each user, go through the flow diagram pretending that the bot is talking to that user. The aim of this is to test your flow diagram before we start building the bot. If you find that the conversation doesn't work for a certain part of the flow diagram, changing it now will save you time later on.

For simple examples like this pizza order, there won't be a big difference between all of the conversations, but user stories will become more important as we create more complicated flow diagrams.

Anyone can make a chatbot. With a bit of practice, you can build a simple bot in a few hours. The problem with building bots like this is that, as they grow in scope and complexity, they can very easily become unmanageable. Simple changes can result in hours or even days of bug fixing and it can ruin the joy you get when you finally get the chatbot working.

To avoid the horror of working with a disorganized and complex chatbot, there are a few best practices. Following these will reduce your headache later on and allow you to quickly and easily add new features.

Throughout a user's conversation with a chatbot, there are a lot of points where errors can occur. Errors can occur when an utterance isn't understood, an API returns an error or when there is a mistake in the developer's code. Each of these needs to be caught and dealt with properly. We'll cover how to use try/catch and the to() method to catch these errors in Chapter 4, Connecting Your Alexa Skill to External APIs.

The most common error will be when utterances aren't understood or aren't what the chatbot expected. This can be because the user typed something incorrectly, misspelled a word, or just typed a response you hadn't thought of. Alexa and Lex both use natural language understanding (NLU) to try to reduce the errors from misspelling and varied responses but they aren't perfect.

Because not understanding the user's utterance is such a common error, both Lex and Alexa also have systems to handle them. This involves a failure phrase that can be sent to the user when the chatbot doesn't understand what the user just said. Make sure that this is set up properly and that you are asking the user to try again or to choose a different option:

Alexa and Lex also have a feature that stores all of the times that it couldn't understand an utterance. Using this list, you can add more sample utterances to help the chatbot understand more. Doing this regularly can give a massive boost to your user satisfaction, as well as helping you understand how your users interact with your bot.

Every time you deal with anything outside of your code, there is a risk that it will error. This might be a third-party API, your own API, or simply a query to a database. You should always write these requests so that if the request returns an error, you fully deal with it. This means logging what the error was and where it took place and making sure that the chatbot still works when an error occurs.

Making sure that the chatbot still works when an error occurs is really important as no one wants to talk to a chatbot that just stops talking to you halfway through the conversation. To make sure this doesn't happen, you have three options: create error messages for every external call you make, let all errors flow down to a very low-level error handler that sends a generic We had an error message, or a combination of the two. The idea would be using custom messages for every error that could happen but as your chatbot becomes larger and more complicated, that can become very time-consuming.

An effective method for dealing with the errors is to create a low-level error handler that passes a generic error message unless a specific error message is provided. This gives you the flexibility to let the user know exactly what went wrong when it matters but saves you having to create lots of similar error messages:

try {
    let result = AccessPeopleAPI();
    if (result === null || typeof result !== 'number'){
        throw 'I've failed to get the number of people';
    }
    return 'We have ' + result + ' people in the building';
} catch (error) {
    console.log(error || 'The system has had an error');
    return error || "Unfortunately I've had an error";
}

No developer wants to admit there are bugs in their code, but if you create more than a simple chatbot, there probably will be. There are different ways to approach this problem, from writing tests for every function, to thorough end-to-end testing, to wrapping everything in a try/catch. This book will let you decide how you want to deal with these errors, but expecting your code to be error-free is a very dangerous path.

No matter how you want to stop errors getting into your code, you need to deal with them when you get them. This is where having a low-level error handler can also be of use. You can use that to catch errors that have occurred in your code the same way that you deal with errors from external APIs.

One of the best things about chatbots is the fact that they are conversational and feel more human. Because of this, you need to give your bot a personality and you need to tailor that personality to suit the purpose of the chatbot and the users who will be interacting with it.

Having a banking chatbot that uses slang might make the users trust the chatbot less, whereas having a clothing sales chatbot that uses lots of very formal or old-fashioned language might be just as off-putting.

Try to design the language that the chatbot uses to be in line with your brand persona. If you don't have a brand persona then you can build one by interviewing your staff and customers. Use these interviews to create a persona (similar to a user story) that relates closely to your customers.

Chatbots are awesome! Being able to create a new way for users to interact is such a great feeling that you want to make a chatbot for everything. Unfortunately, chatbots aren't suited to every situation and some things need to be carefully thought through before being implemented. You need to think about whether users would want to talk about certain things with a chatbot, as well as how the chatbot will be communicating back.

Thinking about the way that the bot will be communicating is particularly important for voice-based chatbots, as everything that the chatbot says will be sent through speakers for everyone around to hear. This could end badly for a chatbot that accesses your bank information, reads your emails, or deals with any other personal information. When designing your Alexa conversations, ask yourself whether you'd want Alexa telling all of your friends and colleagues about your results from your doctor's appointment or reading out an email from your partner about what they had planned for that evening.

As the method of information delivery is very different from existing methods (emails, websites, and printed media), you also need to think about what it will be like for the user. For example, when creating a newspaper chatbot, having Alexa read the whole paper for 15 minutes or Lex send a huge chunk of text might not be very user-friendly. Instead, you could break down the information into smaller chunks, or give a brief overview of the information.

There can be a fine line between a chatbot that provides the user with great information and one that talks too much. Make sure that the amount of information is designed in a way that is suited to the end delivery method.

Alexa and Lex are a pair of tools built by Amazon to change the way that users interact with technology. They are platforms that allow developers to create immensely powerful conversational interfaces without having to study deep learning, natural language processing, or speech recognition.

They are part of the Amazon Web Services (AWS) group and therefore work brilliantly alongside the rest of the services, making the development process smoother and more consistent.

The main difference between Alexa and Lex is that the Alexa platform allows developers to create skills for Alexa-enabled devices, whereas Lex allows developers to create generic text or voice-based chatbots.

Amazon Alexa is a voice-based chatbot that is the brains behind the Echo family of products from Amazon. Users can customize their Echo experience by adding skills to their Alexa account in a similar way to how you add apps onto a smartphone. These skills can be downloaded from the Alexa Skills Store and there are thousands to choose from.

Similar to apps, each of these skills has been designed to perform a single task, whether that's to talk you through a recipe to cook, guide you through your morning workout, or just to tell you jokes.

Alexa was released in November 2014 and has become increasingly popular. By the end of 2017, Amazon had sold tens of millions of Alexa-connected devices. This has resulted in Alexa devices securing 55% of the market for virtual assistants by February 2018.

Amazon Lex is a chatbot service that allows developers to create either text- or voice-based chatbots, utilizing the incredible power of the deep learning, natural language understanding, and speech recognition that Amazon has developed. Lex differs from Alexa in that it can be integrated into different devices and services.

Lex is most commonly used as a text-based chatbot. There are loads of different ways that users interact with text-based chats, and Lex can integrate with a lot of them. Developers can create Facebook Messenger bots, Slack bots, Kik bots, and Twilio texting bots through integrations built into the Lex platform.

Lex can also be triggered through the AWS-SDK, meaning that it can be put behind an endpoint. This means that developers can set up a system where they post messages to an API and get back the response from Lex. This gives you the flexibility to send messages to Lex from almost any system. This can be used to create a chat window inside a website, create a chatbot on almost any messaging service, or integrate it with any system that can connect with the internet.

Using Amazon Transcribe for speech recognition, you could create a system very similar to Alexa. This has been used very effectively in call centers, allowing a customer to talk to a virtual service representative instead of just waiting until a human service representative is available. This means that a lot of callers can get the information that they need without talking to a human. This has the dual effect of reducing the time to get an answer if the bot can solve your problem, and reducing the number of people going through to the call center, reducing call wait times.

In this chapter, we've learned about the components of chatbots—intents, slots, and utterances—and the role that each of them plays.

Next, we learned how to design conversation flows, starting with an ideal conversation and converting it into a conversation flow diagram. Using flowchart software, we created conversation flow diagrams to help visualize how our chatbot will interact with the users.

We talked about the best practices for creating a chatbot, from handling errors to designing your conversations to work well on chatbots, from the tone of voice to good chatbot use cases.

The last part of this chapter introduced Amazon Alexa and Amazon Lex. We learned about the similarities and differences between the two types of chatbot as well as a bit of background into them both.

1. What are the three main components of a chatbot?
2. Name two things that Alexa and Amazon Lex have in common.
3. Name two differences between Alexa and Amazon Lex.
4. When designing a conversation flow, where should you start?
5. What does tone of voice mean?
6. What are the three main types of errors that can occur in chatbots?