Module 02 · Chatbot Design
Mapping a Customer Journey Into a Chatbot Flow
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 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.
// concept
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.
// concept
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.
// concept
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
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 timeThe 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
Failure Cases to Diagnose
7 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
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
Hands-On Exercise
5 steps
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.
// completion_rubric
Completion Rubric
6 checks — tick as you verify
// sources
Sources
2 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: “Dead end after an invalid answer.” What does the lesson tell you to do about it?