This workflow is a consent and state pipeline, not a cold-outreach machine. It captures an authorized enquiry, validates/minimizes it, creates one CRM draft, routes a human, and sends only a permitted WhatsApp response under current policy.

// concept

Define the States

// prompt — copy me4 lines

RECEIVED → VALIDATED → CRM_DRAFTED → ASSIGNED
                                      ↓
                              RESPONSE_APPROVED → SENT
REJECTED | OPTED_OUT | HUMAN_REVIEW | FAILED

Record source event ID, consent purpose/evidence/time, customer reference, CRM record ID, assigned owner, last user message, service-window expiry, template if required, and effect IDs.

// concept

Build With Gates

// prompt — copy me10 lines

authenticated form/webhook
→ schema + abuse controls
→ consent ledger lookup/write
→ event deduplication
→ CRM upsert/draft with idempotency
→ qualification from explicit facts
→ human assignment
→ permitted response check
→ WhatsApp send with message effect ID
→ outcome metrics

Service response permission is not marketing opt-in. Outside the WhatsApp customer-service window, use only an appropriate approved template and valid permission. Honor STOP everywhere.

Before each send, re-read current consent, case status, and service window rather than trusting values captured when the workflow began. Long queues and retries make cached permission dangerous. The send record should atomically claim the logical message so two workers cannot both dispatch it.

// worked_example

Worked Example

A Lahore solar-cleaning page receives an enquiry for service coverage. The form states that the business may reply about this request; marketing is unchecked. One CRM draft is created from the form event ID. City and service determine the team, not inferred income.

An agent approves a service acknowledgement. If the form webhook retries, CRM and message IDs prevent duplicates. If the user opts out, suppression updates before any later send. No “nurture campaign” begins without separate marketing consent.

// failure_cases

Failure Cases to Diagnose

6 cases to diagnose

Imported contacts treated as leads
require authorized source and purpose.
CRM duplicate on retry
upsert/idempotency by source event.
Qualification infers sensitive/value traits
use minimal stated facts.
Bot sends after STOP
centralize suppression.
Marketing template relabelled utility
verify current category/purpose.
No human response target
assign queue and timeout.

// pakistan_angle

Pakistan Angle

Use explicit English/Roman Urdu preference and honest PKT support hours. Normalize city/service area for fulfillment only. Do not infer language or ability to pay from phone/name.

Never request OTP, PIN, banking password, or unnecessary CNIC in lead capture. Keep the client’s CRM and WhatsApp Business ownership under company accounts.

// hands_on

Hands-On Exercise

5 steps

Draw states and authoritative fields.
build synthetic form → CRM draft.
add consent/window/template/suppression gates.
test duplicate, STOP, after-hours, expired window, CRM outage.
measure queue and delivery outcomes.

// completion_rubric

Completion Rubric

6 checks — tick as you verify

0/6

// 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

0/4

1 / 4 · diagnose
Your work shows this failure mode: “Imported contacts treated as leads.” What does the lesson tell you to do about it?