Use a short WhatsApp menu as the default, with an optional AI conversation for requests that do not fit. For a plumber taking urgent calls, this hybrid is a sensible starting design: predictable routing at the entrance, flexible information collection afterwards, and a human dispatcher responsible for urgency, safety-related judgement and dispatch. It is a proposed design, not evidence that either channel will perform better for your business.
The useful comparison is not which bot sounds more natural. It is which route gets the customer to an accountable person with enough reliable information, without delaying a potentially urgent request.
1. Choose the route by request clarity, not enthusiasm for AI
Choose a menu when customers can recognise their request quickly; add AI when fixed choices leave too much unexplained. Keep human contact available in both designs.
A proposed opening menu could offer “Urgent service request”, “Routine booking”, “Existing job” and “Speak to a person”. Include a plain-text alternative so the customer can type their problem instead of navigating choices. Confirm what your chosen WhatsApp setup supports before specifying interactive controls.
A menu constrains the route but does not remove ambiguity. A customer may choose routine booking and then describe water entering a ceiling. An AI conversation can collect that description, but it may also misunderstand it or ask unnecessary questions.
Use this distinction when discussing AI chatbots: the menu selects a path; the conversation prepares a handover. Neither should act as a remote plumbing diagnosis.
If requests are mostly straightforward, start with the menu. If customers frequently describe several problems together, compare a hybrid against that baseline. Do not assume a fully conversational entrance is automatically easier.
2. Make urgent human escalation available before collecting details
Expose the human route immediately, rather than making customers complete an intake form first. A customer reporting urgency should not have to prove it to the bot.
A proposed opening message is: “This chat collects service requests. A dispatcher must confirm availability and attendance. If you need urgent help, choose urgent service or call our published service number. You can ask for a person at any time.” The business must insert its real number and accurate operating hours.
The Source: WhatsApp Business messaging policy, updated on 23 September 2026, permits automated replies within the customer service window but requires prompt, clear and direct escalation paths. That requirement supports a visible handover route, not a claim that your proposed workflow is safe.
Have a qualified person approve wording for reports of immediate danger and any direction towards appropriate emergency services. Do not let the bot decide that a property is safe, advise electrical handling or downgrade a customer's concern.
Define an after-hours route separately. If nobody is available, say so honestly. A queue acknowledgement must never imply that help is on the way.
3. Collect a small handover record, not a diagnostic interview
Collect only what the dispatcher needs to contact the customer and understand the request. Allow missing fields instead of inventing answers or blocking escalation.
The proposed record contains a request reference, contact number, customer-provided location, original problem description, customer-reported urgency, existing job reference if available, missing information and ownership status. Keep the original wording beside any AI summary so the dispatcher can check what changed.
Distinguish “not supplied” from “customer says no”. An absent report of electrical involvement is not confirmation that none exists. Similarly, “water everywhere” is not a precise description of the source or severity.
If you use schema-based extraction, Source: OpenAI's structured outputs documentation describes output constrained to a supplied schema. A correctly shaped record still needs factual checking against the message. Include explicit unknown values and a route for refusals or incomplete responses.
Ask for location in ordinary terms, such as suburb and street address. Do not infer it from a phone number. If the customer cannot provide it, escalate with the gap visible rather than sending repeated questions.
4. Keep record preparation separate from dispatch authority
Let automation prepare a request and notify staff, while a dispatcher controls operational commitments. This separation matters more than whether the customer entered through a menu or an AI conversation.
Source: OpenAI's function calling guide explains that the model requests a function call and the application executes the associated code. A model request is therefore not permission to send a technician, change a booking or make a promise.
A proposed integration could allow draft creation and handover alerts, but require human approval for confirmed attendance, arrival estimates, charges and changes to an existing job. Validate inputs in application code and restrict which records each operation can access.
If using n8n, its Source: human review documentation describes pausing selected tool calls for approval or denial. That is one implementation option, not a native feature of every WhatsApp chatbot.
The dispatcher should see the source message, proposed action and missing details before approving. If approval is denied or expires, keep the request unresolved and tell the customer accurately. Do not translate silence into approval.
5. Design ownership, duplicates and failures before launch
Give each escalated request an owner, and handle technical failure as an operational exception. Sending a notification is not the same as a person accepting responsibility.
A proposed state sequence is received, awaiting human ownership, human reviewing, attendance confirmed and closed. Record who accepted the request and when. Set a proposed acknowledgement deadline based on actual staffing, with a backup person alerted if the request remains unowned. Do not publish a response promise until the team can support it.
Separate delivery retries from suspected duplicate jobs. Application code should avoid processing the same message identifier twice. Two different messages describing the same leak need human checking before their requests are merged. A shared household phone number is not enough to establish that the jobs are identical.
For model errors, unavailable integrations or unreadable attachments, preserve the message and route it to staff. Offer a working contact alternative instead of leaving the customer in a loop.
The AI CRM integration glossary provides context for connecting conversation records to customer systems. In this workflow, that connection should preserve uncertainty rather than turn a partial chat into a confirmed job.
6. Check messaging permissions and information handling
Check the messaging rules and privacy arrangements before building follow-ups. An incoming service request should not become permission for unrelated marketing.
The WhatsApp policy requires relevant permissions, respect for opt-outs and appropriate notices for collecting and sharing information. For the Business Platform, replies without templates are allowed within the 24-hour customer service window; outside it, approved message templates are required. Have a responsible person review the intended messages and applicable South African legal obligations.
Collect service information, not unnecessary identity or payment details. Avoid asking for full payment card numbers, financial account numbers or personal identity numbers. Decide who can access addresses, photos and conversation history, and have appropriate human review of retention and security arrangements.
Show the dispatcher only what they need, and restrict access to the wider record. Do not copy customer chats into broadly accessible staff groups by default.
For broader channel planning, the WhatsApp AI agents for business guide is a useful companion. Keep this decision narrower: how urgent plumbing intake reaches a person, not how many communications you can automate.
7. Compare both routes on complete handovers
Evaluate the menu and hybrid using the same scenarios, then choose the simplest route that meets your proposed operating requirements. Bot reply speed alone is a poor decision measure.
Use fictional requests covering routine work, customer-reported urgency, missing addresses, conflicting descriptions, unsupported languages, voice notes, existing jobs and duplicate messages. Have a dispatcher define the expected handling before reviewing the outputs.
Measure elapsed time to human ownership, customer interactions before handover, missing essential fields, summary corrections, abandoned conversations and unapproved commitments. Count a handover as complete only when a person has accepted it, not when an alert was generated.
Proposed acceptance rules should include no automated safety conclusions or dispatch promises, visible unknown information and successful access to human help from every route. Any failure on these points should trigger redesign and further evaluation. Passing a small rehearsal does not establish safety or production reliability.
The customer service AI agents guide can help frame the wider service process. Here, keep the comparison focused on intake and exceptions, rather than sales conversations or appointment reminders.
Reusable channel design and exception checklist
Use this proposed checklist to agree the design before configuration. Replace role labels with named staff and approve the customer-facing wording.
| Situation | Proposed channel behaviour | Human responsibility |
|---|---|---|
| Clear routine request | Menu collects contact, location and description | Dispatcher checks details and offers availability |
| Customer reports urgency | Show direct contact route and alert staff without requiring complete fields | Named dispatcher accepts ownership and assesses next steps |
| Description does not fit menu | Offer free text or optional AI collection | Review original wording beside summary |
| Missing address or contact detail | Ask a focused clarification; keep unknown fields visible | Follow up without blocking urgent review |
| Conflicting information | Preserve both statements; do not resolve by guessing | Clarify with customer |
| Possible duplicate job | Link candidate records without merging automatically | Confirm whether requests concern the same incident |
| Request for a person | Stop automated questioning and expose human route | Accept handover or state availability accurately |
| Tool failure or unreadable attachment | Preserve message, show fallback and alert staff | Recover request and verify missing content |
| Attendance, arrival time or charge | Prepare proposal only | Authorised person approves commitment |
| After-hours request | Display approved availability and contact wording | Follow agreed cover procedure |
Before release, confirm a working fallback, named owner, backup owner, permission review, access controls and rehearsed exception paths. No checklist entry authorises automated safety decisions.
Worked walkthrough: a normal request and unresolved exceptions
A normal request should produce a reviewable record; an exception should reach a person with the uncertainty intact. These examples are entirely hypothetical.
A customer chooses routine booking and writes: “Kitchen tap dripping at a house in Claremont. Tomorrow afternoon would suit.” They provide a street address and callback number. The menu collects the fields and presents a summary for correction. The proposed status is awaiting human ownership, not booked. A dispatcher checks service coverage and actual availability, then offers a slot. AI adds little value if the menu already captures everything needed.
Another customer writes: “Water coming through the ceiling, same problem as yesterday, come now.” No address or job reference is supplied. The hybrid preserves that wording, records customer-reported urgency and alerts the dispatcher immediately. It may ask for the address while the handover proceeds, but must not classify the situation as safe or promise attendance.
A further message arrives from the same number: “My tenant already contacted you.” The system marks a possible duplicate rather than creating another dispatch or silently merging records. The dispatcher checks the existing incident and asks whether this is the same property. If confirmed, they link the messages and retain any new information. If not confirmed, both requests remain visible. The customer's repeated contact never closes the first unresolved request automatically.
FAQs
Should the urgent menu option automatically move a plumbing request to the front?
It can trigger a proposed urgent-review alert, but it should not settle priority relative to other incidents. A dispatcher must review the report and available resources. Keep urgency labelled as customer-reported until a person assesses it. Also review free-text messages on other routes, because a customer may choose routine booking while describing a concern that needs prompt human attention.
What should happen when a customer sends only a voice note or photo?
Preserve the attachment and show whether its content has actually been reviewed. If transcription or image interpretation is available in the chosen setup, treat it as a draft aid, not a reliable diagnosis. Do not require another attachment before escalating an urgent report. Where content cannot be read, tell the customer and route the original to a person through an approved, access-controlled process.
Can the AI confirm that a plumber will arrive soon?
Only after an authorised person has confirmed the actual commitment should the system relay it. A draft request, successful tool call or staff notification does not establish attendance. Distinguish “request received” from “dispatcher reviewing” and “attendance confirmed”. If the team cannot confirm availability, say that plainly. Arrival estimates and charges should follow the business's approved human decision process.
Choose the smallest workable design
Start with the menu plus direct human access, and add AI only where comparison shows a useful role in collecting difficult descriptions. Retain dispatcher control even if the conversational route appears quicker.
If your business needs help defining these boundaries, Symaxx's AI automation service can support the design discussion. Bring your opening message, dispatcher responsibilities and fictional exception cases, then get in touch to explore the appropriate scope.