Best practices

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.

Handling errors

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.

Missed utterances

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:

Failed utterances

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.

External APIs

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";
}

Errors in your code

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.

Tone of voice

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.

Identifying suitable use cases

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.

Designing the information for the delivery method

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.