Two Stage Fallback Policy SMS/Voice

We are trying to use the two stage fallback policy in a bot that uses SMS and voice as channels.

It seems that you can not do this on either SMS or call - there are no buttions that we can use

The problem we are hitting is that the user has to specify the Intent Name to move forward, either or <deny_suggestion_intent_name> rather than a user being able to just pass a yes or a no (or hitting the affirm/deny intents)

Is there a way of configuring this policy to work for SMS

Hi,

we are having similar issues. The “original” implementation of this policy actually allowed you to do this as it had both a deny and confirm intent, see following commit:

However, later, the confirm/affirm intent was removed. I see two possible paths to solve your issue, although I’m stuck with both. It would be good to get a developers view on this.

  1. Find another way than “buttons” to bypass the NLU or map your affirmintent back to the original intent as you can with the payload. I don’t have enough knowlege about how/where the payload is handled to know if you can have an easy text based version.

  2. Overwrite the ActionRevertFallbackEvents action. Here, you can add more UserUtterenaceReverted events (as was in the original implementation) that would help you. However, currently, there is a very confusing issue with this. The original ActionRevertFallbackEvents action is defined in rasa.core and uses the DialogueStateTracker, if you overwrite it and use it on the action server, you will be using the rasa_sdk tracker, which is different. In fact, you cannot even put the current implementation of the action on your action server. This seems a bit like a bug to me.

Hope somebody can clarify which of both paths can be fixed easily, or what the best solution is.

However, later, the confirm/affirm intent was removed. I see two possible paths to solve your issue, although I’m stuck with both. It would be good to get a developers view on this.

The buttons are not required, they are just the easiest way to make sure that the new intent is correctly recognised. You could also do something like Please type "Hello" if you wanted to greet the bot

the original ActionRevertFallbackEvents action is defined in rasa.core and uses the DialogueStateTracker, if you overwrite it and use it on the action server, you will be using the rasa_sdk tracker, which is different

they are indeed different classes, we actually are thinking about adding a note to the docs to make that behavior more obvious

The proposed solution (Please type “Hello” if you wanted to greet the bot) is indeed a good solution on the short term for bots that are not too complex. However, whereas type “Hello” is quite elegant, this method will become very cumbersome when dealing with more complex intents, where you need to ask the customer to retype a full sentence that is for sure recognized by the bot.

I still feel that from customer experience pov, asking a yes-no question is much better (buttons are probably the best though if possible) and I’d definitely still be interested in a solution.

Mhm, if you can’t use buttons and want to have yes / now answers then you might need to implement a custom policy for that.