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.