Module 02 · Chatbot Design
Handling Fallbacks When the Bot Doesn't Understand
Open lesson + course map
On this lesson
Course outline
Module 1 · WhatsApp Business Foundations
Module 2 · Chatbot Design
Module 3 · Lead Handling
Module 4 · Sales Automation
Module 5 · Scaling Your WhatsApp Channel
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.
// concept
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.
// concept
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.
// concept
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
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
Failure Cases to Diagnose
7 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
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
Hands-On Exercise
5 steps
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.
// completion_rubric
Completion Rubric
6 checks — tick as you verify
// sources
Sources
3 official sources — check every claim yourself
// check_yourself
Check yourself
4 questions · answers and options are taken word-for-word from this course
1 / 4 · diagnose
Your work shows this failure mode: “Infinite apology loop.” What does the lesson tell you to do about it?