Why Chatbot and Callbot Loops Break on Reprompts
No-input (the user says nothing) and no-match (the user speaks but recognition or understanding fails) have different root causes, yet most loops replay the exact same reprompt sentence for both. Google's conversation design guidance treats them separately and caps the combined count at three consecutive no-input/no-match events. Re-entering the same loop past that cap means users hang up or close the chat before a fourth attempt.
Reprompts Are a Ladder: Open → Constrained → Handoff
The first reprompt should never repeat the original question verbatim — it should ask only for the missing piece, briefly. The second narrows an open question into a constrained choice or a button/DTMF-paired prompt, structurally lowering the odds of another failure. If the third also fails, the loop must close — either a human handoff or a graceful exit. Skipping straight to a human on attempt one drags down automated-resolution rate; repeating the same open question through attempt three drags up abandonment.
Counter Scope: Per Slot or Per Session?
Binding the retry counter to the whole session means a user who mis-hears a name-confirmation prompt twice hits the cap on a single order-number miss later. Keeping a separate counter per slot, reset only when that slot is filled successfully, cuts false-positive escalations. Still, if the session-wide total grows too large even while no single slot breaches its cap — six or more combined events, for instance — a session-level ceiling should force a full exit to prevent an unbounded loop.
From Design to Operations: A Reprompt-Ladder Checklist
Fix the target numbers before writing any prompt copy. A reasonable starting bar: a per-slot cap of 3 combined no-input/no-match events, a reprompt recovery rate (valid input obtained after the first reprompt) of 60% or higher, handoff time under 5 seconds once a session exceeds the cap, and a 0% rate of verbatim repeats across attempts one through three. If recovery rate falls short, revisit the ladder's first-tier copy first.
Four failure patterns recur: replaying the identical sentence across all three attempts; binding the counter to the whole session so one slot's mistake pulls other slots toward the cap; applying the same no-input timeout to voice and DTMF channels, leaving too little time for button entry; and re-entering the same loop with no exit condition once the cap is already exceeded.
Recovery branches follow the ladder tier by tier. Attempt one asks only for the missing piece, never repeating the original prompt. Attempt two narrows the open question into a constrained choice or button input, structurally reducing failure odds. If attempt three also fails, force the loop closed — human handoff or a graceful exit — and pass the handoff reason (no-input or no-match, and which tier was reached) to the agent screen so the same question isn't asked twice.
Pre-deploy scenario tests must cover three consecutive no-input events, three no-match events, and a mixed no-input/no-match sequence of three. Logs need retry_count, error_type (no-input/no-match), reprompt_tier, and outcome (recovered/handoff/closed) fields, and any name or phone number that could appear in reprompt copy must be masked before it's written to storage.
Run the improvement loop weekly: review abandonment and recovery rate by tier, and A/B-test the copy for any tier whose recovery rate lags. For sessions that hit the cap and escalated, tally the offending slot separately so the next improvement cycle knows which slot's question design to revise first.
Takeaways at a Glance
Separate no-input from no-match, cap the combined count at three per slot, and design reprompts as a three-tier ladder — open, constrained, handoff — instead of repeating the original question. Declare the counter scope and recovery-rate target in code first, and the same ladder carries over cleanly the next time a slot is added.