WhatsApp Business bots: menus, fields and human handover

A well-designed WhatsApp Business bot does not try to do everything: it covers a precise scope, order or support, guides the customer through short menus, collects structured fields and knows when to hand over to an agent at the right moment. Here you will find a complete design method: tree structure, input rules, error handling, refusal cases and the bot-stop mechanism, with an original commented example from end to end.

Bounding the bot: order or support, not both

The first decision is editorial, not technical: what scope does the WhatsApp assistant cover? A bounded bot states what it does and, above all, what it does not do. An order bot handles a limited catalogue, a simple basket and confirmation. A support bot handles order status, frequent questions and qualification before handover. Mixing the two produces endless menus and dead ends.

This boundary also serves human handover: when the agent receives the conversation, they must see at a glance which journey it is and which data has already been collected. A bot that "does everything" hands over a fuzzy context. To go further on structuring inbound requests, see our guide on WhatsApp AI agents and organising customer requests.

Finally, a bounded scope makes compliance easier: you collect less data, you document fewer flows, and you can justify every field requested. The 24-hour customer service window of the WhatsApp Business Platform, reopened by each user message, and the requirement for approved templates beyond it are constraints to build in from the design stage, not afterwards.

Numbered menus rather than open-ended understanding

For a bounded bot, short numbered menus beat free-text interpretation in almost every case useful to an SME. Three options per menu, four at most, with a visible exit option: "3. Talk to an agent". The customer replies "1", "2" or "3"; the bot has nothing to guess.

Free input remains necessary in a few places: order number, delivery address, problem description. The design rule is simple: one free field at a time, with a closed question and an example of the expected format. "What is your order number? It starts with ORD, for example ORD-1042."

Do not assume every rich component is available in your integration: depending on the solution chosen, interactive lists, structured forms or catalogues are not always accessible. A numbered text menu works everywhere, including via the plain app, and is easy to test. If you are designing an appointment-booking journey, our article on the appointment chatbot and a customer journey without dead ends details the same principles applied to scheduling.

Collecting structured fields, not paragraphs

Every piece of data requested must have an identified recipient and use. A free "additional information" field attracts everything and anything; three targeted fields — order number, nature of the problem, urgency — produce an actionable ticket.

Concretely, define for each field: the expected format, the validation, and the behaviour on failure. An order number is validated with a simple pattern (prefix plus digits). A postal code is validated by length and numeric content. A problem description stays free but bounded: ask "in one sentence, what happened?" rather than an unlimited field where the customer recounts the whole story from the beginning.

These structured fields are what the agent will see at handover. A handover saying "unhappy customer" is useless; a handover saying "order ORD-1042, parcel not received, customer available before noon" enables immediate handling. Data protection applies here too: only request what is necessary for processing, in line with the core data protection principles set out by the CNIL.

Handling errors without infinite loops

The most common WhatsApp bot failure is the loop: "I didn't understand" repeated until abandonment. Set an explicit rule: after two validation failures on the same field, the bot changes strategy — it reformulates with a more precise example, or it offers the exit to a human.

Second rule: every menu must have an exit. A customer who lands by mistake in a support journey must be able to return to the main menu or type "stop" at any time. One memorable global shortcut is worth more than ten hidden commands.

Third rule: distinguish input errors from journey errors. A non-existent order number is not a typo to correct indefinitely; after a check, the bot offers either a reformulation or the handover. Our guide on handover to an agent in a customer service chatbot details these exit points.

Refusal cases and outside-hours messages

A bounded bot must refuse cleanly what it cannot do. These "refusal cases" are prepared responses for out-of-scope requests: pricing complaints, legal requests, safety emergencies, topics you do not handle. A refusal is not a failure: it is an honest answer that redirects. "I cannot process refund requests above our threshold. I am putting you in touch with an agent who can review your case."

Outside-hours messages follow the same logic. If your customer service closes at 6 pm, the bot must say so, state the reopening time, and offer an asynchronous option: "Your request is recorded, an agent will handle it from 9 am tomorrow. Would you like to leave a message?" Mind the platform mechanics: the 24-hour service window opens on the user's message; if the bot replies within that delay, no approved template is needed. By contrast, a scheduled reminder the next day beyond the window will require an approved template, with a cost per delivered message that varies by category and market under Meta's pricing for the WhatsApp Business Platform. All the scheduling scenarios presented here are hypothetical design examples, not commitments.

Preparing the context handed to the agent

Human handover succeeds or fails on a single element: the summary. Before transferring, the bot must restate in a few lines what it knows: declared identity, order number, nature of the problem, actions already attempted, customer availability. The agent should never have to ask a question that has already been answered.

This summary also serves as the bot's stop: when handover is triggered, the bot clearly steps aside — "I am passing you to an agent, you will now continue with Marie" — to prevent the bot and the human from answering the same message in turn. Define who owns the conversation: once the bot has stopped, only the human replies until the conversation is closed.

Finally, plan for the absent agent: an explicit queue, a realistic promised response time, and an outside-hours message if the handover arrives after closing. A handover ending in silence is worse than a bot that owns its limits.

Decision table: when the bot continues, when it stops

Situation	Bot's decision	Why
Valid menu answer	Continue the journey	The customer is on the intended path
Two validation failures on a field	Reformulate with an example, then offer the human	Avoid the error loop
Out-of-scope request	Refusal case pointing to the human or the exact information	An honest refusal prevents frustration
Order number not found after checking	Offer reformulation or handover	Do not make the customer pay for the error
Message received outside opening hours	Acknowledge, state reopening, offer recording	Manage the wait explicitly
Keyword "agent" or "stop"	Immediate bot stop and handover	Honour the requested exit
Handover triggered, agent unavailable	Queue with an announced delay	Silence after handover breaks trust

Six-step design procedure

1. Write the scope in one sentence. "This bot handles order status requests and delivery problems." Anything outside that sentence gets a refusal case.
2. Draw the tree on paper. Every menu, every field, every exit. Count the dead ends: a node without an exit to the main menu or to a human is a defect.
3. Define the fields and their validations. Format, example of a correct answer, behaviour after two failures.
4. Write the refusal and outside-hours messages. Each one states what is possible and what happens next.
5. Specify the handover summary. Which lines, in which order, with which data.
6. Test error paths before happy paths. A bot that handles the nominal case well but errors poorly will produce silent abandonment. Our article on testing a conversational AI agent offers a test-set method that fits.

Main example: a commented tree for a delivery support bot

Here is a hypothetical example, deliberately minimal, for a fictional delivery support bot.

``` Home: "Hello! I am the DeliveryPlus assistant (fictional example). I can help you with: 1. Track my order 2. Report a delivery problem 3. Talk to an agent"

[1] Track my order: "What is your order number? It starts with ORD, example: ORD-1042." → Valid: reply with status, then "Anything else? 1 / 2 / 3" → Invalid (twice): "I cannot find that number. Would you like to talk to an agent? (yes / no)"

[2] Report a problem: "Sorry about this. In one sentence, what happened?" → Bounded free field, then: "When are you available for an exchange? 1. This morning 2. This afternoon 3. Tomorrow" → If the answer falls outside service hours (after 6 pm, fictional example): "Our team is closed until 9 am tomorrow. Your report is recorded and will be handled first thing on reopening."

[3] Talk to an agent: "Here is a summary of your situation: order ORD-1042, parcel not received, contact preference this morning. I am passing you to an agent." → Bot stops, summary is handed over.

Refusal case (any other request): "I can only handle order tracking and delivery problems. For anything else, type 3 to talk to an agent."

Global shortcut: "stop" at any time stops the bot and offers the human handover. ```

What this example shows: every field announces its format, every failure has an outcome, the refusal case redirects without humiliating, and the handover summary contains exactly what the agent needs. No message promises what the bot cannot deliver.

What a bounded bot cannot decide for you

A WhatsApp Business bot executes the rules you wrote; it does not decide your commercial policy or your refund thresholds. Ambiguous cases — a customer who is both angry and out of scope, a mixed order-plus-invoicing request — need either an explicit rule from you or the default handover. Prefer the handover: an agent receiving three off-topic conversations a day costs less than a lost customer.

Also keep the channel's limits in mind: the customer can leave the conversation, change numbers, or write from a shared account. Check the terms of use of the WhatsApp Business Platform and obtain consent before any message you initiate; our article on WhatsApp Business automation, consent and templates details that framework.

If you would like to scope a WhatsApp bot design mission for your SME, visit our agent offers.

Frequently asked questions

Should the opening message be a menu or free input?

A short menu from the start, without exception. Free input as the first message forces the bot to interpret, and therefore to get it wrong. The menu steers in one reply, and the "agent" shortcut covers the cases the menu does not anticipate.

How do you stop the bot without closing the conversation?

Provide a single global keyword, for example "stop" or "agent", recognised at any step. It triggers the bot stop and the handover without closing the thread: the agent takes over the same conversation, with the context.

What should happen when a customer writes outside opening hours?

The bot acknowledges, states the reopening time and offers to record the request. If you then want to send a message beyond the 24-hour window, you will need an approved template, billed by category and market.

How many structured fields should you ask before a handover?

The minimum needed for processing: typically three to five fields, including an identifier (an order number, for instance) and an availability slot. Every extra field must be justified by a real use on the agent's side.

Can one assistant handle both orders and support?

Possible but not advisable in a first version: menus grow longer, refusal cases multiply and the handover summary becomes confusing. Start bounded on one scope, then extend only once the exit points work.