A fallback is not “Sorry, I didn’t understand” repeated forever. It is a recovery policy: preserve what is known, narrow the choice, limit retries, and transfer to an accountable human when confidence or authority is insufficient.
After this lesson, you can design fallback levels, protect high-risk intents, and measure where the flow needs repair.
Classify the Failure
Do not treat every mismatch as natural-language failure:
| Failure | Example | Correct response |
|---|---|---|
| invalid format | date entered as an unclear phrase | show accepted format and example |
| unsupported choice | city outside delivery list | offer Other/human review |
| ambiguous intent | “change it” with two editable fields | ask which field |
| missing authority | refund approval requested | transfer to authorized staff |
| system failure | order API unavailable | preserve reference, explain delay, alert owner |
| safety/privacy risk | user sends card or ID data | do not repeat it; follow deletion/escalation procedure |
The fallback should be specific to the state and avoid exposing internal errors, prompts, credentials, or stack traces.
Use a Three-Level Recovery
Level 1 — clarify: restate the current question and allowed response.
Please choose delivery: 1) Karachi, 2) Lahore, or 3) Other.
Level 2 — simplify: offer a smaller menu, back, or restart while retaining safe context.
I still cannot match that area. Reply AREA to type it again or HUMAN for help.
Level 3 — handoff: create a queue item with state, transcript, collected fields, failure reason, and response expectation.
I’ve sent this to our delivery team. Reference WA-1048.
They respond during listed support hours. Reply STOP to end messages.
Set the retry limit per state. One retry may be enough for payment, complaint, cancellation, health, legal, or identity-related questions. Automation should never improvise authority.
Create a Protected-Intent List
Immediately hand off or use an approved deterministic response for:
- payment disputed, duplicate, failed, or charged but unconfirmed;
- refund, cancellation, warranty, or complaint;
- threats, self-harm, abuse, or immediate safety concerns;
- legal demands or regulator contact;
- requests to access, correct, or delete personal data;
- suspected fraud, account takeover, leaked credentials, or unauthorized orders;
- any request outside the stated service scope.
Document the owner and service target. “Human” is not a route unless someone receives it.
Worked Example
A Peshawar electronics seller’s order-status flow asks for PK- plus six digits. The user types “paid kal, abhi tak nahi aya.” The bot must not hallucinate shipping status.
First it says: I can check an order using a reference such as PK-123456. Do not send card, PIN, OTP, or banking password. If no valid reference is supplied, it offers FIND ORDER and HUMAN. If the customer says the account was charged, the flow immediately creates a Payment Review case, preserves the message, provides a case reference, and stops promotional automation.
The team later counts fallback reasons. Thirty percent come from customers using local phone numbers instead of order IDs, so the interface adds a safe alternative lookup controlled by the commerce system. The bot is improved from evidence.
Failure Cases to Diagnose
- Infinite apology loop: cap retries and escalate.
- Restart deletes valid answers: retain safe state and show the editable summary.
- Bot guesses the nearest intent: confirm ambiguity before taking an action.
- API error shown as success: distinguish unavailable, pending, confirmed, and failed.
- Handoff lacks context: attach state, data, and reason.
- No queue owner: assign team, service target, and after-hours behavior.
- Fallback logs sensitive content forever: minimize, restrict, and apply retention rules.
🇵🇰 Pakistan Angle
Expect code-switching, voice notes, spelling variation, local area names, and mixed digit formats. If the system cannot safely process audio, state that limitation and offer text or human help. Normalize Pakistani phone formats only after showing the value back for confirmation; never guess a missing digit.
Payment disputes involving bank transfer, wallets, cards, or COD need different evidence and owners. The bot should collect only a transaction reference that the relevant system can verify, never a PIN or OTP. Give realistic support hours in Pakistan Standard Time and avoid “instant” promises during outages or holidays.
Hands-On Exercise
- List invalid, ambiguous, authority, system, and privacy failures for one flow.
- Write three recovery levels for two common states.
- Create the protected-intent list with owners and service targets.
- Test repeated invalid input, API outage, payment dispute, STOP, and human request.
- Create a fallback-reason report and one improvement rule.
Done means: every failed interaction either recovers safely or reaches a staffed queue with context and a truthful expectation.
Completion Rubric
- Failure types have different recovery behavior.
- Retries are capped and safe state is preserved.
- Protected intents cannot be improvised by AI.
- Handoffs have owners, context, and service targets.
- System failure is never presented as success.
- Fallback analytics drive documented changes.
Sources
- WATI Help — Setting up fallback messages
- WATI Help — Assign User and Assign Team nodes
- WhatsApp Business — Messaging policy
Key takeaway: a reliable fallback protects state and truth, limits retries, and transfers uncertainty or risk to a real owner instead of letting automation guess.