How To Write User-Friendly Error Messages

Those of you who have ever written a chatbot have probably encountered several error messages such as, “Sorry, I don’t understand your questions” answered by the chatbot. Maybe you have even experienced that your own developed chatbot is receiving extremely random questions from users who are clearly just testing the chatbots boundaries. These irrelevant requests are also called conversational divergences, which cannot be prevented.

Generally, a chatbot is created to solve a specific use case or to provide a particular value. Therefore it is clearly not able to answer all possible questions. So if the chatbot sends out a so called error message (also known as fallback response or default response), it basically indicates that it was not able to process the request and to match it to a fitting intent. If you keep in mind how new the technology is and how fast AI is still going to evolve, this is definitely not a criteria to shut a bot down. In fact, if you know how to deal with the user in such situations, there is a high chance of ensuring a positive user experience within the communication. On the other side there is also the risk of harming the user experience by sending poorly thought through error messages. It is one of the main tasks of the chatbot to keep the user engaged in the communication without leading him/her into dead ends as a worst scenario.

In this blog post you will learn how you can write user friendly error messages by demonstrating bad and good examples and describing a standard framework on how to design error messages in order to avoid losing users again in the conversation.

So How Does Error Handling Actually Work?

How to not do it:

The examples above demonstrate very well how error messages should never be handled.

• The conversation on the left with “The Weather Channel” has not implemented a user-friendly response because it simply refers to an error without giving details of the cause. Also, asking the user “to try again” is not really helpful since he/she doesn’t know what exactly went wrong and how to do better next time.
• The chat with “Dallas Mavericks” in the middle actually shows many improvements. There are definitely more possibilities to communicate than asking the user to use cryptic commands. However, what stands out is the negative undertone of “Hmm, sorry I don’t quite understand that,” Like it doesn’t matter. This error message just simply gives the user the impression that the chatbot is not putting much effort into pleasing or helping him.
• The last example on the right clearly failed in phrasing a helpful default message. It is obvious that the user will leave the chat due to the fact that the chatbot is not even working since it’s always sending out the same response. Speaking of, in case you have already written user-friendly error messages it is still essential to implement variations of it! The chance of misunderstanding requests more than once in a communication is very high. So you don’t want to annoy your users with sending out the same messages.

Let’s Take A Look At Experts: Poncho’s Case

The developers of the most popular chatbot Poncho, which can send out weather forecasts, have also realized how important it is to write well, thought out fallback responses. For example, in the beginning they have implemented the following error message:

„Sorry, I was trying to charge my phone. What were you trying to say?“

So what exactly went wrong? In this message the chatbot is apparently overplaying the fact that he did not understand the request. This unfortunately only leads to a never ending cycle since the user will repeat his question which will be followed by an error message. The person has no clue on how to further deal with the chatbot and will leave the conversation soon. So the developers of Poncho came up with a better response:

“So, I’m good at talking about the weather. Other stuff, not so good. If you need help just enter ‘help.”

In this version the chatbot is straightforward. He explains that his only purpose is to talk about weather and that the user should not expect him to know more. He also mentions the help area to provide even more context. The people behind Poncho recognized that this was a way better strategy to approach users in these situations. In order to even perfect error messages, we will outline a framework below.

A Framework For Error Handling

1. Clarifying the misunderstanding

The first step is to clarify the misunderstanding. It is essential to be very transparent, honest, and modest in regards to the abilities of the chatbot. Do not overplay the mistake. If the chatbot is not able to understand the request, you should let it come clean.

2. Reminding the user of the chatbots abilities

In the second step, it makes sense to explain to the user again which information the chatbot can intake. So if you remind the user of the bot’s knowledge, function, and abilities, he/she will be prepared to come up with the right questions.

3. Call to Action!

Call to actions are the right way to guide the user. You can either suggest him/her to use buttons, to ask his/her question in a different way or to enter a keyword such as “help” to read the documentation again. Also, it might be useful to offer the user a handover to a human to ensure satisfaction or sometimes to even restart the whole conversation. There are multiple options to keep the user engaged to decrease exit rates.

Good Examples

Above you can find better versions of default responses. In the Porsche chat on the left the user received clear call to actions of either asking for a real employee or to use the buttons below. Same case with “ShoeDazzle”. The chatbot is being clear about its abilities and is trying to guide the user out of the this little dead end.

To summarize this post, it is extremely important to focus on the critical parts of a conversation to prevent losing the user. Error messages are such crucial events. If you keep the mentioned framework in mind during the conversational design of a chatbot, you will ensure a great user experience. To close this off consider the following:

Rule no.1: The user is never wrong and it’s never his/her fault! ;-)