← Notes

The fallback flow needs the same guarantees as the main one

Continuing to collect data while nobody is available is a defensible product decision, and it turns against the visitor if the collection asks again for what they already gave.

When nobody is available, continuing the conversation by collecting what the agent will need later is a defensible decision: it turns empty waiting into preparation and raises the chance the conversation resumes usefully.

The decision only works under one condition: the collection has to know what it already has. That is exactly where the standard implementation fails. The Dialogflow CX parameter documentation states that "If the end-user provides multiple parameter values in a single conversation turn during form filling, usually only one form parameter is set" — the visitor who sends everything at once has most of what they sent ignored.

The result is worse than not having continued. An honest unavailability notice followed by silence is frustrating and coherent. An honest notice followed by questions about what was already answered communicates something else: that nobody is reading. The attempt to improve the wait ends up signing the impression it meant to avoid.

The test that separates the two cases is cheap and specific: walk the fallback flow sending every field in the first message, and check whether the next question accounts for what arrived. A fallback flow never walked that way is live without having been tested on the case that matters most — the visitor who cooperates.