One Barge-In Switch Doesn't Cover Both Channels

Amazon Connect's documentation states that barge-in is disabled by default in a call flow, and you have to set the x-amz-lex:allow-interrupt session attribute directly on the Get Customer Input block to turn it on per intent or per slot. The same page is explicit that this attribute only controls voice barge-in — interrupting a playing prompt with speech — and has no effect on DTMF barge-in, the keypad channel. Teams that flip on voice barge-in and assume DTMF comes along for free end up with an awkward lag: a caller presses a key mid-prompt, and the system still plays the whole sentence out before it registers the input.

Silence and a Mismatch Are Two Different Retry Counters

Google Cloud's Dialogflow CX documentation separates a caller saying nothing (a no-input event) from a caller speaking but not matching any intent (a no-match event), each with its own handler. The no-input timeout defaults to 5 seconds and can go up to 60, and audio playback is split into a no-barge-in phase followed by a barge-in phase. The same documentation recommends capping no-match and no-input retries at 3 per page, escalating to a human agent past that — and that cap is exactly the line that should decide when to offer DTMF instead.

Roadmap: Building a Callbot's Voice-to-DTMF Fallback Channel

At the planning stage, pin down both when to steer callers toward DTMF and what completion rate that fallback needs to hit. If no-match or no-input fires twice in a row at the same step, add a "you can also press a key" prompt starting on the third attempt, staying inside the Dialogflow CX-recommended 3-retry cap and letting the caller choose between a human agent and DTMF. Reasonable deployment bars: 80%+ task completion after a DTMF fallback is offered, no-input timeouts split by channel — 4 seconds for call-center flows, 6 for casual chat — and a DTMF-specific no-input timeout shorter than voice's, around 3 seconds.

The most common failure is turning on voice barge-in and forgetting DTMF barge-in entirely. If the system ignores a keypress mid-prompt and plays the sentence out anyway, callers assume the button is broken and hang up. The fix is treating voice and DTMF barge-in as a pair on every deployment checklist — change one, verify both in the same release.

A second pattern is folding no-input and no-match into a single retry counter. Repeating the same reprompt ("could you say that again?") for a caller who said nothing and a caller who said something unmatched leaves them with no idea what went wrong, so they repeat the same failure. The fix is separate counters for each event, paired with distinct prompts — "I didn't catch that" for no-input, "I didn't understand that request, you can also press a key" for no-match.

A third pattern is offering DTMF as a fallback while the keypad parser inherits the voice session's timeout and valid-input set wholesale, so even button presses get dropped. The fix is a dedicated grammar and a shorter no-input timeout for DTMF input, instead of carrying the voice channel's settings over unchanged.

Pre-launch, the checklist should reproduce four scenarios — silence, background noise, misrecognition, and a prompt cancelled mid-DTMF-entry — and verify both whether the fallback fires and how long it takes. Log fields should include cumulative no-input and no-match counts, the fallback trigger reason, and the raw DTMF value entered, with account and card numbers masked before they hit the log.

Run improvement work weekly, splitting fallback-trigger rate and post-fallback completion rate by channel, and checking whether no-input or no-match hits the retry cap more often so reprompt wording and timeouts can be tuned separately for each. Keep configuration-change logs separate from call-flow structure logs, or the next regression takes twice as long to trace.

Quick-Reference Checklist

A callbot's fallback design isn't finished with one barge-in switch and one retry counter. Treat voice and DTMF as separate channels, count silence and mismatches on separate retry axes, and offer the fallback within a 3-attempt cap so callers understand why before they take the next step.

References

AWS Amazon Connect Administrator Guide – Get customer input flow block

Google Cloud – Dialogflow CX Voice agent design best practices