When I first started consulting in Dialogflow, I noticed a pattern. A lot of clients who came to me had made a complete mess of their chatbots, and all of them were using the slot filling (required parameters) feature.
When you use required parameters in Dialogflow, you are telling Dialogflow – “please ensure that this parameter is actually collected from the user”. When you mark a parameter as required, it will trigger slot filling – and Dialogflow will keep prompting the user until they provide the input. As of this writing (Feb 2020), there isn’t any way to limit the maximum number of retries.
What about Dialogflow CX? Dialogflow CX was introduced only in September 2020, and this article was written before that. CX introduces the concept of retry handling during slot filling, meaning you can now restrict the number of retry attempts. This guide refers ONLY to the earlier version of Dialogflow (i.e. ES), and not to Dialogflow CX.
I don’t recommend that people use slot filling in their Dialogflow chatbots. It makes your bot brittle, unpredictable and hard to reason about.
It is quite possible there is a little bit of a self-selection bias going on here. Nearly all my clients find me via my website by doing an online search for some Dialogflow related question. This means they were already working on a chatbot which couldn’t be properly built with slot filling. Since this self-selecting group might have been a large portion of my clients, I may be biased on this topic.
Earlier, I had written many articles on my website about this topic. In this guide, I have consolidated them into a single article.
An overview of slot filling
This video provides an overview of slot filling.
Notice how the contexts are auto-generated by Dialogflow ES (discussed around the 10:00 minute mark), which gives you a hint of how hard it is to use slot filling and still have a reliable bot.
Why I avoid slot filling
This is a somewhat opinionated view, but it is based on my experience using slot filling as well as helping my clients get unstuck by moving them away from slot filling.
In my view, slot filling makes four implicit assumptions:
- perfect entity recognition
- complete entity definition
- perfect spelling
- full cooperation from user
Let me explain these one by one.
Perfect entity recognition
If you have used Dialogflow for a while, you already know it struggles with non-English names – specifically the @sys.given-name entity. The @sys.person entity works better. If you make one of your slots a @sys.given-name, odds are it will repeatedly fail for many different names which you would expect it to handle.
Complete entity definition
So you realize you cannot get Dialogflow to identify all the non-English names. So you decide to augment it by adding some names you want it to handle – for e.g. the name of the employees in your organization.
But there is a limit to how far you can go with this system – because soon the chatbot creator needs to take responsibility of defining every possible entity value.
You will run into this issue even if you have a developer defined entity. For example, a list of names in your organization is likely to be fluid, and you will now need to put a process in place for keeping your entity up to date.
It is a bit ironic, but the rise of chatbots is supposed to be the result of the increasing use of messaging apps. So what else resulted from the increasing use of messaging apps? Typos!
Unfortunately, Dialogflow isn’t very good at handling typos in its entity recognition either, although it is quite good for regular words.
Full cooperation from the user
So the user needs to type out a required parameter and they get stuck in the loop. How are they supposed to come out of the loop?
Apparently, by typing Cancel or some other code word. Which is OK, but how do you let the user know after they entered the loop? Dialogflow could have made it easier by either a) allowing a maximum number of retries before quitting the loop or b) having a fallback message after N retries which explains to the user that they can come out of the loop by typing Cancel or Stop.
But don’t these problems happen anyway in Dialogflow?
You might ask: Other than the last one (getting stuck in a loop), aren’t the others already issues with Dialogflow anyway?
Yes, but if you don’t use slot-filling, you have a lot more options to handle these things gracefully. You can
- choose to do a fallback where you reprompt once, and then you quit that particular input if there is a second fallback
- with a more complex UI, you can choose to show a list of options the user can select from after the first fallback
- with a complex UI, when there are typos, you can choose to show a list of options with spelling similar to the typo
Slot filling doesn’t cause the issues I mentioned (except the last one), but it makes it very hard to recover from them.
Do you actually need slot filling (required parameters) for your bot?
The only thing worse than using slot filling is to use it for a use case where it doesn’t even make sense.
Motivation for slot filling
The real reason you want to use slot filling is because the user’s question/message is posed in a specific format.
First, let us look at an example of a user wanting to book a flight.
They might say any of the following:
I would like to book a flight
I would like to book a flight from Seattle to New York
I would like to book a flight for 4
I would like to book a flight leaving from Seattle tomorrow
Notice that the intent is specified in bold text, and the entities are specified in italics.
Now imagine a conversation like this where the user starts by providing the number of people travelling:
User: I would like to book a flight for 4 people
Bot: OK, for how many people?
Now, that would make your chatbot look really stupid because the user is thinking “What? I just said it is for 4 people”.
Slot filling is very handy in such circumstances, because it infers that the user has already provided one of the pieces of information (slot) needed to book the flight and only prompts for the rest.
In addition, slot filling is smart enough to handle multiple slots provided in the same sentence, and also smart enough to understand that the user could specify the first slot(s) in any order. (Like the example above).
So let us first start with some terminology:
Opening sentence – the first message that the user says to your chatbot
Slot – one of the pieces of information you need to collect for completing the task
Entity – Dialogflow’s terminology for the name of the slot
Intent – The task at hand (again, in Dialogflow terminology. In this case it would be “booking a flight”)
Your website contact form
Now let us take the example of your website contact form.
Suppose you provide marketing services. As part of filling out your contact form, the prospect has to fill out their website URL, their company Twitter handle, and their Facebook page URL, and also the company name and their estimated budget.
Since you decided to use a Dialogflow bot for collecting this information, you also looked at Google’s demo and decided you will just use a bunch of slots (required parameters) for getting this information.
Is that a good idea?
A checklist to decide for yourself
I have put together a small checklist you can use to decide for yourself whether what you are doing is actually slot filling.
1 Could the opening sentence include ANY of the slots?
Take an example of flight booking. It is quite natural to say:
“I would like to book a flight for 4” or “I would like to book a flight leaving tomorrow”.
In other words, it is natural to use any of the slots in the opening sentence.
What about your contact form?
“I would like to know more about your marketing services and my budget is $50000”
“I would like to know more about your marketing services and my Twitter handle is @examplecom”
Almost no one talks like that!
2 Could the opening sentence include ALL of the slots?
Now with the flight booking example, someone might include all the slots in their opening sentence:
“I would like to book a flight from Seattle to New York for 4 people leaving tomorrow and returning next Monday”.
It is quite a lot to say, but it isn’t unnatural.
Imagine if your prospect said the following:
“I would like to know more about your marketing services and my website is at http://www.example.com and my Twitter handle is @examplecom and my Facebook page is at facebook.com/example and my company name is Example and the budget is $50000”.
3 Could the slots be specified in any order?
In the flight booking example, it is quite possible that the slots are specified in any order (maybe not quite all combinations, but there are many possible combinations):
“I would like to book a flight from Seattle to New York for 4 people leaving tomorrow and returning next Monday”
could just as well be:
“I would like to book a flight for 4 people from Seattle to New York leaving tomorrow and returning next Monday”
I leave it as an exercise for you to imagine if this would work for your specific use case.
4 Are all the slots ACTUALLY required?
Does your prospect actually need to provide you with all this information before you can accept them as clients? Probably not. You could probably get just their contact info (e.g. email address) and ask the rest later.
In theory, you could also do the same with the flight booking (i.e. have a travel agent call the customer later), but that would defeat the purpose of having the chatbot in the first place.
5 Is it possible a slot may not exist?
Is it possible your prospect doesn’t have a website?
While it is unlikely, it is possible.
Can you still have them as a client even if they don’t have a website? For sure, in fact you could be the one who actually sets up their website for the first time!
Is it possible to book a flight without knowing the destination?
6 Do the slots change dynamically?
Here is a comment someone left me recently:
In case you are wondering why my answer seems so blunt, it is because the user left this comment under one of my original articles explaining why I avoid using slot filling.
But it perfectly illustrates the overall point of my article. If all you know is slot filling, everything looks like a required parameter 🙂
3 scenarios where you should avoid using slot filling in Dialogflow
The slot filling feature is hands down one of the coolest features in Dialogflow.
Not only that, it is often the centerpiece of many demos given by the Dialogflow team.
So why am I asking you to avoid slot filling? Because there are three common scenarios which the existing slot filling implementation cannot handle well.
Do you need to ask user to confirm their input?
As it happens, in real world chatbots, we need to ask the user to reconfirm their input. It becomes especially important in transactional scenarios where the reconfirmation is our last chance to implement a conversational “rollback”.
With slot filling, you cannot ask for reconfirmation of an input right away. And if you do it outside the slot filling, then you might end up re-creating the slot filling.
Do you need to get entities which Dialogflow does not identify consistently?
As it turns out, there are a lot of valid entity inputs which Dialogflow cannot identify. The most common example is the user’s first name – Dialogflow doesn’t do a great job at identifying non-English names when you use the @sys.given-name entity.
Do you need to ask for a list selection?
For example, there are scenarios where the user can input one of only a handful of values. This is best served by using a list selection user interface (e.g. the list selector in Google Assistant). You cannot mix the list selector input with your existing slot filling intent. So you would need to separately get input for that particular value alone if you want to give the user the benefit of selection-based input.
Slot filling vs follow up intents
I got this question from a reader:
i didn’t understand difference between slot filling vs follow up intents as slot filling can be achieved by followup as well with extra validations right?
We can better understand this by looking at our bigger goal: we wish to collect a mandatory set of inputs from the user (that is, all are required values).
The order in which user provides input
Slot filling is orderless
The first difference between slot filling and follow up intents is that slot filling doesn’t expect the user to go in a certain order.
You can set up a single slot filling intent which can handle either of these inputs:
 “I would like to book a flight leaving tomorrow and coming back this Friday”
 “I would like to book a flight from Seattle to New York”
 “I would like to book a flight for two”
In the first case, the intent will be able to extract the departure date and return date, and needs to get the remaining inputs, i.e. slots – from, to, and number of passengers.
In the second case, the intent will be able to extract the from and to locations and will prompt the user to get the other values such as departure date, return date and number of passenger.
In the last case, the intent can only extract the number of passengers and needs to prompt the user to get the other four values.
Follow up intents impose an implicit order
In the case of follow up intents, as you can imagine, you will collect the inputs in a specific order.
User: I would like to book a flight
Bot: When is the departure date?
User: <provides departure date>
Bot: When is the return date?
User: <provides return date>
Number of values collected from a single user message
Slot filling can “fill” multiple slots in one message
In message , we can infer both the departure date and return date from a single user message, while we can only infer one parameter (number of passengers) from message .
That is, we can extract multiple values in a single user message, especially the first message from the user which triggers the slot filling.
Follow up intents can extract one value per user message
While in theory you CAN design follow up intents to extract multiple values, in practice it is much more intuitive for the user if you collect only a single value per user message.
Slot filling gives the user a second chance to get their input right
If user makes a simple typo, for example, slot filling will re-prompt them for the input value. So it gives the user a chance to recover from input error. In theory, the bot can “keep asking till the user gets it right”. In practice, it actually goes into an unrecoverable loop (see next point).
Follow up intents do not automatically give the user second chances
In the case of follow up intents, if the user’s input is not recognized, it will trigger the fallback intent and there isn’t any way to recover and go back to the previous state in the conversation.
And a third, fourth, fifth, sixth…..
But slot filling does unlimited reprompts
Slot filling actually goes into an infinite loop of asking the user to provide some information if they don’t provide the value it expects. (one reason I suggest you avoid using it).
Here is what happens with slot filling when using the @sys.given-name with a name that it cannot identify.
Bot: What is your first name?
Bot: Sorry, can you tell me your first name?
User: I said Aravind
Bot: I don’t think I got that. Can you tell me your first name again?
User: Its Aravind
Bot: Sorry, something went wrong. Can you…..
Followup intents don’t go into a loop
Using followup intents, you don’t (automatically) give the user a second chance to get their input right. In addition, there is really no way to “keep asking until the user gets it right” with followup intents.
Generally, that isn’t a bad thing.
Can the slot filling feature be replicated using followup intents? No.
Can the eventual goal of slot filling (collecting a set of requited/mandatory parameters) be achieved using followup intents? Yes.
Slot filling via REST API
I got this question on my post about using the PHP Client library for API v2.
I think there is some confusion among my readers about using the REST API when it comes to using and managing contexts.
Clearly, I don’t recommend using slot filling.
But if you wish to use slot filling via the REST API, you need to understand the role that the sessionID plays in REST API calls. I have discussed this in my post on tips for Dialogflow REST API users.
Here is a video which summarizes my views on this topic.
What is slot filling using webhooks?
I recently got a question which suggested that people are getting confused about the meaning of “slot filling using webhooks”.
I have mentioned in different places in my blog and my courses that I don’t encourage people do slot filling using webhooks.
What does it mean?
But what does it actually mean?
Suppose you have a chatbot which needs to collect four values for booking a flight – starting city, destination city, number of passengers and date of travel. Let us also suppose you use slot filling to get all the parameters.
You have 4 slots to fill
Now by marking all these parameters as required, you expect the user to “fill” all these 4 slots before they can finish the intent.
Now, it turns out that if the user were to travel from Dallas, the only destination your airline has is Houston (just as an example).
So once the user types in Dallas as the starting city, you could simply use Houston as the destination. To do this, you could use “Use webhook for slot filling” option at the bottom of the intent.
The actual implementation is complex, non-intuitive and not recommended.
As I tell all my clients, the only thing worse than using slot filling is to use the “Enable webhook call for slot filling” feature.
What non-programmers should know about slot filling
If you are not a programmer, there are some very specific reasons why you should avoid using slot filling.
Now, you cannot really build your Dialogflow bot without hiring a developer.
And a developer who suggests that you use slot filling in your chatbot (usually) also knows how to fix the problems caused by the slot filling feature.
Unfortunately, this becomes a little bit of a conflict of interest problem – the developer will be required every time you need to update and improve your bot, and the developer knows this 🙂
There is also a second problem – there are a lot of things you can learn in Dialogflow without writing code, which means it is possible to develop a lot of your bot logic inside the conversation layer itself. By using slot filling, you are moving more of your chatbot logic into the webhook/fulfillment layer which means you need to rely on your developer more.
Third, if you are working with a developer that you cannot easily reach (say you work in different time zones), and you want to update something quickly in an intent which uses slot filling, you will be forced to wait for the developer to come online.
Fourth, it is my opinion that even as a non-programmer, you can reason about a lot of things in your bot’s logic if you use simple input and output contexts. I am very certain of this, because I have quite a few clients who are technical non-programmers who can reason about the behavior of their Dialogflow bots almost completely, all the way until the “last mile” – the place where you hand off control to your developer.
Lastly, because of the nature of the slot filling feature, you will start handling all the exceptions/edge cases in your webhook layer, and sometimes end up creating a mini-Dialogflow in your webhook code, and sometimes it becomes too complex for even the developer to fix. This happened to one of my clients. He finally fired the developer and started over, after wasting upwards of four figures in dollars.
Do you still think slot filling is a mess? (updated Feb 2020)
I got this question a while back, asking me what I think of slot filling today.
Yes, I still think it is a mess. That’s because the underlying implementation of slot filling hasn’t really changed.
Here are some questions you can ask yourself to decide:
1 Do you want to build multi-turn conversation dialogs which are also flexible?
2 Would you like to actually understand what is going on under the hood in your bot?
3 Would you prefer a bot which is more maintainable over the long run?
If you answered Yes to all these questions, I suggest you don’t use the slot filling feature.
This website contains affiliate links. See the disclosure page for more details.
"The magic key I needed as a non-programmer" The custom payload generator was the magic key I needed (as a non-programmer) to build a good demo with rich responses in DialogFlow Messenger. I've only used it for 30 minutes and am thrilled. I've spent hours trying to figure out some of the intricacies of DialogFlow on my own. Over and over, I kept coming back to Aravind's tutorials available on-line. I trust the other functionalities I learn to use in the app will save me additional time and heartburn. - Kathleen R Cofounder, gathrHealth