What Are Good or Bad Use Cases for Chatbots?

There are good use cases for chatbots and bad use cases but how can you tell a good use case from a bad use case?

Before you say whether the use case is good or bad, you need to consider the type of chatbot being considered and the alternatives to using a chatbot.

The first point is that a chatbot is an interface to software. Therefore it can only be a good use case for a chatbot if the job to be done can’t be done better using an alternative interface such as a graphical user interface.

Like every software interface, the goal of the chatbot is to deliver a new level of convenience to the end user.

Of course, there is an economic constraint here. Companies can only provide convenience that is economically viable, otherwise, they would allocate a customer service representative to every customer. In assessing the convenience that a chatbot delivers, an important consideration is therefore how much it will cost to deliver the required level of convenience and how this delivered convenience will pay for itself and provide a return on investment.

The cost of added convenience is determined in large part by the technological advancement of the chatbot development tools. A tool that requires the input and categorization of tens of thousands of customer service chats will be vastly more expensive than a tool that allows a developer to develop a similar use case in three days. The question is what is the difference in quality achieved and what is the direct and indirect economic impact of this difference.

Even if we can make some generalizations about what would be considered a good use case for chatbots, every situation is different so some judgement is required to figure out whether the use case being considered is a good use case or not.

‍

A common Use Case: Form filling

Let’s first discuss the use cases for text-driven chatbots and consider the common use cases of information gathering, specifically form filling.

We see many use cases where users want to use a chatbot to fill in a form. I cannot say whether form filling per se is a good or bad use case, but if we look deeper into this use case we can determine whether the exact use case being considered is a good fit for a chatbot or not.

Let’s say the end user needs to fill in a conventional form either on their mobile device of a desktop. The form fields are similar no matter what the user inputs are i.e. they fields don’t change much based on the user input.

In this case, filling in a form would seem to be a bad use case for a chatbot. A graphical interface would allow the user to easily scan what’s required and easily edit previous fields if they made a mistake. Revising previous fields can be difficult on a chatbot because the chatbot flows in one linear direction.

In this classic form filling use case, there are ways a chatbot can potentially improve the user experience. For example, the user could initially engage with the chatbot and the chatbot could guide them to and open the required form. The chatbot could also be on standby for any unexpected questions that arise when answering the form. Note I said “unexpected” questions. It’s more efficient to display information regarding expected questions as graphical pop-ups next to the relevant fields.

The chatbot can also take control after the form is completed and guide them to the next form or action, assuming there are multiple steps in the user journey. This can be more effective than passive instructions written on a web page that the user needs to remember and follow. In summary, the chatbot can be used as a workflow manager that can deal with unexpected questions, but will leave the form filling action to an appropriate graphical interface.

Where the form is short, the chatbot may be the best interface. This is because it may not be worth the effort of opening up a graphical interface if there are just a few questions that can be asked inside the chatbot. The chatbot still has a limitation that it will need to ask at the end whether any answers need to be changed and have a mechanism to allow users to change the answers, but if the form is short it is less likely that users have made mistakes and it is also easier to elegantly allow the user to change previous answers from within the chatbot.

This argument to use a chatbot is even stronger if the chatbot is used to guide the users to the forms. If the user is already in the chat interface, the questions can be quickly asked without disrupting the flow. This argument is even more powerful when the user is using a chatbot through a chat application such as Whatsapp. If the company has the user’s phone number, an application such as Whatsapp is a great way to reach the customer and ask them some quick questions. Delivery companies for example should always be using this kind of technology to schedule drop-offs.

Another case where it may be better to use a chatbot for a from is where an answer on a form determines what the next question will be. Essentially this type of form takes the user through a decision tree. This can be a good use case for a chatbot as it is harder to get this type of form right in a graphical interface. It’s still the case however that a mechanism to change previous answers needs to be built in and therefore the pros and cons need to be evaluated carefully.

‍

‍Scripted vs Intelligent bots

The form filling use case is a good one to examine because it demonstrates some of the advantages and disadvantages of using chatbots. It should be mentioned that in the above use cases we have been describing scripted chatbots, i.e. chatbots that simply navigate a decision tree deterministically, i.e. they have no intelligence (except in question answering).

We should also mention that it is often best to use a scripted chatbot for a given use case rather than an open-ended intelligent chatbot. For the use cases mentioned above where the scope of what the user needs to do is well understood, the scripted chatbot provides an efficient and simple experience. Not only that, it is vastly cheaper to put this functionality in a chatbot rather than having a web page for each action.

The other kind of chatbot we want to discuss is the intelligent kind. These chatbots can recognize the meaning in a user phrase and extract parameters from the phrase. For example, if the user says “I want to book a flight to Paris”, the chatbot can recognize the intent of “Flight Booking” and also extract the destination city as Paris.

A good use case for this kind of chatbot is a use case where the user is highly likely to use the types of phrases that the chatbot understands. This means that the user needs to be aware that they are using the chatbot for a very narrow task.

It should also be the case that the number of alternatives open to the user is fairly large, i.e. it is not more efficient to list the alternatives in a scripted bot.

The chatbot can be programmed to recognize many different phrases. If the chatbot can’t understand what the user has said, the user experience can quickly turn bad. It is generally good practice, therefore, to have the intelligent chatbots backed up by customer service agents. Any misunderstood questions can be escalated to the customer service agent who can answer the question (and make the chatbot smarter at the same time).

Not having the service backed up by customer service agents means that in the event it doesn’t understand something, the bot has to explicitly state to the user the things it can understand in terms of topics or for the user to select from and ask the user to select one. This means the bot becomes a scripted bot from that point onwards. This is however problematic if there are a huge number of alternatives which are too numerous to list.

The other approach is for the chatbot to raise a ticket in a support system on behalf of a customer which the human agent can respond to asynchronously. This is of course not an ideal customer experience.

The “optimal” virtual assistant

It should be mentioned that voice will be a game-changer here and that the killer use case for chatbots will be voice-driven bots.

While there are already many popular voice devices out there, voice has not yet reached the point where it is a perfect experience. Too many mistakes are made by the software and users need to speak to the devices in effectively SQL statements. These chatbots essentially only support one off commands or questions and the tasks they typically carry out are too granular to produce a great product-market fit.

A perfect chatbot would be like a human assistant, only better. You would be able to give the minimum high-level instruction for a task and that task would be carried out based on prior knowledge of the assistant. This means that the assistant would not ask you to confirm the things it should already know.

For example, if you say “Book me an Uber” and you had just been talking about a destination, it would not ask you where you are going or at the very least state where it was booking the Uber to.

A rule of thumb for the best chatbot use cases is to ask yourself what you might say to a human assistant at that point. While the technology is not perfect yet, it is progressing rapidly, and human-like interactions will soon be the standard (within increasingly large knowledge domains).