A chatbot flow is a decision system, not a drawing of everything a customer might say. Its purpose is to complete one bounded job, preserve context, and hand off safely when the job exceeds automation.
After this lesson, you can turn a customer journey into states, transitions, data requirements, and tests that another operator can review.
Begin With One Job
Use this specification:
User: who is eligible to enter?
Trigger: what message, button, or event starts the flow?
Goal: what observable outcome should happen?
Inputs: which minimum facts are required?
Exits: completed, human handoff, opt-out, expired, or failed.
Owner: who resolves exceptions, and by when?
“Handle sales” is too large. “Collect service type, city, and preferred time, then create a human-owned quotation request” is testable.
Convert the Journey to States
Write states before messages:
| State | Required input | Valid next state | Audit event |
|---|---|---|---|
| welcome | language choice | qualify or human | language_selected |
| qualify | service and city | eligible, ineligible, human | qualification_completed |
| quote request | timing and contact confirmation | review | quote_requested |
| human queue | assignment | accepted or expired | handoff_created |
| closed | outcome code | none | case_closed |
Every state needs a repeat behavior, timeout behavior, back option, and human escape. Use reply buttons or lists when the current provider and message context support them, but accept typed equivalents too.
Minimize Collection
Ask only for information that changes the next decision. For a service quote, city and service type may be necessary; CNIC, date of birth, and household details usually are not. Tell the customer why an input is needed before requesting it.
Keep transaction state outside conversational text. The bot can collect an order reference, but the commerce system must retrieve the order. Never treat “paid” typed by a user as a payment event.
Worked Example
A Karachi home bakery wants custom-cake enquiries. The goal is not to price every design automatically. The flow collects event date, serving band, delivery/pickup area, dietary constraint, and reference-image permission. It then creates a quotation request.
WELCOME → language
DATE → reject past date; offer human for urgent order
SERVINGS → 10–15 / 16–25 / 26–40 / 40+
FULFILMENT → pickup / delivery area
DIETARY → none / stated constraint / speak to baker
SUMMARY → confirm / edit / human
QUEUE → assign Custom Orders with transcript and response time
The bot does not promise allergen safety or final availability. The baker verifies ingredients, capacity, design rights, delivery fee, total, deposit, and cancellation terms. Success means a complete request reaches the correct queue—not that the bot “closed” a sale.
Failure Cases to Diagnose
- Flow mirrors departments instead of customer goals: organize around the job the user came to complete.
- Dead end after an invalid answer: explain allowed choices and preserve prior inputs.
- Twenty questions before value: ask the minimum needed for the next decision.
- No edit step: show a summary and allow correction before submission.
- Unsupported promise generated from an answer: gate price, inventory, legal, health, and availability claims through authoritative review.
- Handoff loses context: attach collected fields, transcript link, reason, and urgency.
- No expiry rule: define what happens when the customer or agent goes quiet.
🇵🇰 Pakistan Angle
City and locality often affect serviceability, delivery fees, and timing. Use a controlled list where practical and an other / type area route that goes to human review. Do not promise nationwide delivery because a courier serves major cities; verify fragile, perishable, high-value, and remote-area constraints with the actual carrier.
Keep messages short for mobile screens and intermittent connectivity. A customer should be able to resume from a reference rather than restart. Show PKR amounts with separators, distinguish item total from delivery and tax, and confirm the final payable amount in one summary.
Hands-On Exercise
- Select one bounded customer job.
- Complete the user, trigger, goal, inputs, exits, and owner specification.
- Create a state table with transitions and audit events.
- Draw happy path, invalid input, back/edit, timeout, opt-out, and human escape.
- Test the paper flow with three people who did not design it.
Done means: a tester can complete, correct, abandon, or escalate the task without losing context or causing an unsupported business decision.
Completion Rubric
- The flow has one observable job and accountable owner.
- States and valid transitions are explicit.
- Only decision-relevant data is collected.
- Edit, timeout, opt-out, and handoff paths exist.
- Authoritative systems decide payments and inventory.
- Tests cover both happy and failure paths.
Sources
- WATI Help — Chatbots
- WATI Help — Question Box and flow guidance
- WhatsApp Business — Messaging policy
Key takeaway: design a chatbot as a small, auditable state machine that finishes one job and hands exceptions to a prepared human with context intact.