Define your use cases – not too little and not too much

Many businesses struggle to identify the use cases where a bot can replace a human interaction. This is usually a result of the relatively poor experiences that today's bots provide.

Poor automated experience is a consequence of either:

  • The "too little" scenario, where a bot offers very little and therefore has no value for the end user
  • The "too much" scenario, where a bot sets high hopes for what it can do, but then fails to meet those expectations

In both cases, the bot is unsuccessful in fulfilling its purpose. Due to technology limitations, or bad design, it has failed to offer a fast and scalable service to the customer and failed to reduce the business' costs. Finding the minimum viable product (MVP) is crucial for the success of any chat/voice application, but be aware of "burning" users by offering a limited product that does not provide value. You can start with simpler types of features, but then you should develop a second level of features that provides the user with a richer experience. By offering a full-service application, you make sure that users continue to use the conversational application and don't fall back to the website, the mobile app, or the call center, or, even worse, you lose them.

As presented in the previous chapter, building a conversational design is a challenging task. While trying to simplify it, bot-development frameworks offer an easy and intuitive platform to build chatbots, with no development skills needed. In some cases, those bots have no NLU capabilities and are very limited in the understanding level of an interaction. In such cases, the user will have to ask a specific question in a certain way to get a response. If the user fails to ask the question as was preconfigured, the bot will not be able to provide the user with an answer. Understanding that this can be very limiting, some bot-development frameworks took on the menu-based structure, which eliminates the user's conversational interactions and simply offers a selection of capabilities that the user can choose from.

In such cases, the user is led in the conversation and can't ask for anything that isn't on the menu. This is clearly the most obvious form of transition that bot developers are making from GUI to CUI.

In the following example, the bot didn't understand my request, even though I selected it from the menu. After the "speak to an advisor" button was offered to me, I wrote that I want to talk with someone. However, the bot didn't understand my request:

Define your use cases – not too little and not too much

Figure 2: A failed interaction with the EatOut Facebook Messenger chatbot

I then tried to use the exact same wording to ask for "Cuisines," but once again the system failed to understand my request:

Define your use cases – not too little and not too much

Figure 3: A failed exact-matching request using the EatOut Facebook Messenger bot

On the Expedia chatbot, the experience was better. I wrote, I'm looking for hotel. The system was quick to understand me and continued the conversation, asking me in what city:

Define your use cases – not too little and not too much

Figure 4: Successful understanding of the Expedia Facebook Messenger bot with a contextual sequence

However, I got a different result with this wording: I need a place to sleep.

Define your use cases – not too little and not too much

Figure 5: Lack of samples of sentences makes it hard for the NLU to understand a request in the Expedia Facebook Messenger bot

The system didn't understand my intent and asked me to rephrase my request.

To sum it up, the preceding examples demonstrate why use cases that are offered on various chatbots are somehow limited and in many cases also not very valuable. The information offered on these bots can be easily found on the website/app, so it can be a good start, but it symbolizes the too little functionality that continues to disappoint.

On the other hand, although we envision a "know-it-all intelligent assistant" in our future, for now, a bot that doesn't limit the user to some extent will also fail very quickly. There must be a balance between the amount of use cases and the number of supported samples. It's a width and depth challenge. The user should be informed what they can ask and what the automated solution can offer him/her and then, when the system fails, it can transfer the conversation to a real human.

In the Expedia example, we were limited to a certain scope and this is perfectly fine because, after all, even a human agent can't answer everything. However, what this chatbot failed to do was to allow us to interact freely within the scope of the offering, failing to understand our intent the moment we chose a different set of words.