Visitors are unpredictable. They always find a way to ask what you didn’t expect. Or ask the wrong question at the wrong time. But your chatbot should never be caught completely off guard. A bot able to recover from unexpected inputs is more likely to increase customer engagement, while a stubborn bot replying “Sorry I didn’t get it” over and over will make them fly away. This is what fallbacks are for. Defining good fallbacks is a key element when creating bots.
Today we take a look at the different options to define meaningful fallbacks in your chatbot, and how you can leverage Xatkit to do it easily and efficiently.
What is a Fallback?
Most bot solutions embed an event-driven execution logic. Simply put, a bot application is defined as a set of intent / reaction pairs. When the bot receives an intent it executes a piece of code, for example, to post a reply, or search some information in a database.
A fallback is the reaction of the bot when it receives an unexpected intent. In the example below the bot expects a number from the user, but receives a city name. Since the bot cannot continue the conversation it triggers a fallback and asks the user to rephrase.
[Bot] Hi! Let's play a game, can you pick a number between 1 and 10?
[User] Barcelona
[Bot] Sorry I didn't get it, can you try again?
Default vs. Local Fallbacks
A default fallback is the generic error reaction executed by the bot, such as the Sorry I didn't get it answer above. They are defined once for the entire application and triggered every time an error occurs. Default fallbacks are usually not that helpful for the end-user because as they don’t lack enough contextual information from the current conversation state to provide a helpful answer. A default fallback needs to be generic enough to work at every possible failure point. Their main goal is to make sure visitors are aware the bot didn’t get their question instead of silently failing.
Local fallbacks are the opposite: they are defined at a specific failure point in your bot’s conversation flow, and have access to contextual information. A local fallback can use this additional information to provide better feedback to the user (e.g. reply I am expecting a number here in the example above), print some examples of valid inputs, or even access a knowledge base to find a possible answer.
???? While local fallbacks are the most adapted for customized feedback, it’s usually a good practice to define a default fallback as a safety net for uncaught errors.
Fallbacks in Xatkit
Xatkit’s DSL provides out of the box constructs to define local and default fallbacks. A Xatkit bot is a state machine containing states representing bot reactions, linked with transitions representing user intents.
The Xatkit state machine contains a mandatory defaultFallback state, that is executed when an unexpected intent is received and the current state does not define a local fallback:
Note that this fallback state does not contain any transition. The Xatkit engine will automatically return to the previous valid state once the fallback has been executed.
Xatkit local fallbacks are directly defined inside their containing state. The DSL provides the optional fallback construct after the transition definition, which accepts a context parameter containing all the contextual information of the current conversation.
Conclusion
Good fallbacks are one of the keys to build an engaging conversation with your chatbot. Default fallbacks are easy to configure and can be used as a safety net to handle unexpected intents, but they aren’t very flexible. Local fallbacks can be used to improve specific failure points with fine-grained reactions based on contextual information.
The Xatkit DSL provides constructs for both types of fallbacks. With them, you can create arbitrarily complex fallback reactions by orchestrating the different platforms and services natively available in Xatkit.
Featured image from francebleu.fr
