Home / DialogFlow / Conversation Design / Reader Question: Do I need a contextual fallback intent for every single context?
Conversation Design | DialogFlow

Reader Question: Do I need a contextual fallback intent for every single context?

I got this question on my YouTube channel:

Hi, I’m new to DF and really appreciate your videos. I totally agree with keeping the context lifespan to 1, as otherwise it makes the conversation really messy. I guess the only situation I have found that this falls down is here, where the default fallback intent then effectively deletes the context, causing re-prompting to fail. I have a complex conversation, and I want a general fallback intent that reprompts the user and maintains the context. Is there any way of creating that, as otherwise I am going to need a fallback for every single one of my (many) contexts.

This is a very good question, and the answer is the usual one: it depends. 🙂

First, make sure you understand how contextual fallback intents differ from regular ones. The reader is asking if they need to add a contextual fallback intent for every single context.

When you are in this situation, it helps to remember the following:

If you are very clear on the candidate intents at each step of your conversation, you can choose context lifespans higher than 1.

Let me explain.

Context Lifespan of 1: Pros and Cons

Let us take a step back.

The biggest issue with using the default context lifespan of 5 is that it spawns too many candidate intents over a multi-step conversation. As a result, the chance that the user’s utterance could be mapped to the wrong intent increases.

Using a context lifespan of 1 avoids this problem (of wrong intent mapping), but it also enforces a lot of discipline into the conversation design. It might be a bit too much effort in some cases, like the one in question.

Default Context Lifespan: Pros and Cons

On the other end of the spectrum, the default context lifespan value is 5.

This requires much less work up front, but you will likely spend a lot of time debugging issues in your Dialogflow bot.

Intermediate lifespan values: Pros and Cons

But we don’t have to choose either extremes (1 or 5).

For the specific scenario described by the reader, you can try incrementally adding to the context lifespan.

Say you raise the lifespan to 2 in all your output contexts.

If you had a tool to analyze the candidate intents [1] at each step in the conversation, you will see that

a) this allows you to use a single fallback intent (i.e. it is the default fallback intent which doesn’t have any input context)

b) you will probably run into occasional intent mapping issues because there will always be some surplus intents in your conversation design

If you are very clear about your candidate intents, and you are willing to tolerate these surplus intents, then using a context lifespan of 2 is likely to be a good tradeoff in this situation.

Additional considerations

While the specific number you use for the context lifespan can be higher than 1 if you have carefully analyzed the candidate intents in your conversation, it helps to remember a few things before you make that choice.

Second fallback

Even when you use the context lifespan of 2, remember that your conversation will break if the user triggers a second fallback (because by then the context lifespan would have reduced to 0).

So is the answer to increase the lifespan to an even higher value of 3?

No!

And I hope you have been following along and see why that is a bad idea! 🙂

If this happens, it is probably because of the verbiage you use in your default fallback intent’s response. See if you can improve it.

Bottlenecks

You should also take care that the default fallback intent doesn’t turn into a bottleneck.

For example, suppose you want to add different verbiage to the fallback intent response depending on the previous step in the conversation.

Since the Default Fallback Intent is now trying to be a conduit to the next step in the conversation, you might need to add a response which looks like this:

“If you were trying to book a flight, please try and use only alphanumeric characters.

If you were trying to cancel a reservation, please enter the date in the format YYYY-MM-DD.

If you were trying to ask about credit card points, make sure you provide the card issuer name (e.g. AMEX, Visa).”

You can see that by trying to use a single default fallback, you have turned it into a sort of a bottleneck where you need to add custom error responses according to the context which is active. This could become unsustainable.

Path specific behavior

Sometimes you will run into another issue.

Depending on which intent was mapped previously, you might have set some parameter inside that intent. Because you don’t know which context was active when the default fallback was triggered, if your conversation recovers into a surplus intent, your variables may not be available. (This is a bit hard to explain without a good example, I will try and add one later).

Wildcard entities

When you have wildcard entities in your training phrases, they will try and aggressively capture everything. Surplus intents which also contain wildcard entities can be especially problematic. If you have a training phrase that is entirely a wildcard entity (which is required when collecting free form text inputs), this problem becomes more severe.

Fallbacks can be precursors to new intents

Sometimes you want to handle the user input in a more elegant way than just allowing it to go to the default fallback. For example, it might be an important followup question you haven’t considered adding as an intent.

So keep analyzing what user utterances get mapped to the fallback intents when you use a lifespan of 2, and see if some of them can be converted into intents.

Reduce the context lifespan down to 1 iteratively

Even if you start with an output context lifespan of 2, you can still selectively update it back to 1 if you find that the fallback is rarely triggered for that context. This will make your intent mapping more predictable in the long run by removing surplus intents from your conversation design.

[1] I am building such a tool right now as part of my BotFlo web app. If you are interested in using such a tool, leave a comment below. If I get at least 5 comments, I will prioritize the development of this candidate explorer tool.

Related Posts