WhatsApp AI agents: organise customer requests

A customer writes on WhatsApp: an order enquiry, a complaint, a question about an invoice. Without structure, these messages pile up in a shared inbox and follow-up depends on your team's memory. A well-designed WhatsApp AI agent does not replace your advisors: it turns a stream of messages into a queue of requests that are identifiable, categorised, timestamped and transferable. This page explains how to organise that queue, from capturing identity to proving that a request was handled.

Why structuring the queue changes everything

A raw WhatsApp message rarely contains everything needed to act: who is writing, what exactly it is about, since when, and how urgent. A WhatsApp assistant that merely replies leaves that interpretation work to your team, message after message.

Structuring the queue means deciding at design time which pieces of information every request must carry before it reaches a human. The goal is not to automate everything, but to ensure no request stays vague: every item in the queue has an identity, a category, a status and an owner. That discipline is what makes human handover reliable and proof of handling possible.

WhatsApp app or WhatsApp Business Platform: a decision to make early

Before discussing the request queue, you must choose the technical channel. The standard WhatsApp Business app, used on a phone, suits artisanal usage: one number, a few quick replies, no serious automation. The WhatsApp Business Platform, built on Meta's API, lets you build an AI agent that reads, qualifies and routes messages programmatically.

The difference is not cosmetic. On the Platform, the 24-hour service window is reopened by each user message: as long as the customer has written within the last 24 hours, your agent can reply freely. Beyond that, only templates approved by Meta can be sent. This framework directly shapes your queue design: a request open for three days cannot be followed up with a free-form message — an approved template is required. Compliance, permissions and the conditions for leaving the channel are set out in WhatsApp Business's official policy, and Platform pricing works per delivered message, by category and by market — not all messages are chargeable, notably replies within the service window. Do not build your business case on a fixed rate: check the categories that apply to your markets.

One more warning: a QR code or a connection link does not prove you are using the official Business Platform. Many tools connect numbers without going through the API, which risks suspension. Likewise, do not assume a business can freely run a Business app and a Platform on the same number, nor that features like Flows or a catalogue are available in every case: verify number by number.

Company-specific assistant or general-purpose assistant

A second choice shapes your agent: is it a general-purpose assistant that answers everything, or a company-specific assistant limited to your scope? For organising a request queue, the company-specific assistant is almost always the right starting point.

A general-purpose assistant must improvise on topics it does not master; a company assistant knows its categories, its handover rules and its limits. When a customer asks something out of scope, it does not fabricate a plausible answer: it tags the request as "off topic" and routes it. That explicit boundary is what makes the queue usable. You can read our guide on the WhatsApp AI assistant for customer support to explore this distinction, and our article on AI agent permissions to frame what the agent may do on its own.

Capturing identity without blocking the conversation

The first piece of data in any request is who is writing. On WhatsApp you already have the phone number, but a number does not tell you who is speaking: one phone may serve several people, and a customer may change numbers.

A robust design asks for light identification early in the conversation: a name, a customer or order reference, depending on your business. The classic mistake is demanding full identification before any reply, which frustrates people and drives abandonment. Better: reply usefully first, then ask for identity when it becomes necessary — for example before looking up a file or handing over to an advisor.

Design points to remember:

• Never treat the phone number as sufficient proof of identity for sensitive actions.
• Ask for identity in one short step, not five successive questions.
• Store the declared identity with the original message, not in a separate note.

Detecting and handling language

If your customers write in several languages, language must be a data attribute of the queue, not an improvisation by the model. A WhatsApp AI agent can detect the language of the first message and attach it to the request: every reply, every handover and every follow-up template then aligns on that language.

Two precautions. First, automatic detection fails on short messages: "ok", "hello", an emoji. When in doubt, ask the user to confirm the language rather than guessing. Second, human handover must account for language: routing a request in Wolof to an advisor who does not speak it creates a break worse than a delay. If you serve customers between Paris and Dakar, language and time zone go together — on 20 October 2026, 10 a.m. in Paris is 8 a.m. in Dakar, but on 3 November 2026, 10 a.m. in Paris is 9 a.m. in Dakar: a poorly calibrated reminder schedule will wake your customers at dawn.

Categorising requests: few categories, well defined

Categorisation is the heart of the queue. A frequent mistake is multiplying fine-grained categories ("international delivery problem", "domestic delivery problem") until neither the agent nor the teams can navigate them.

Three to six categories are usually enough to start, with written definitions and examples. For a fictional after-sales service — call it "Atelier Noro", a home appliance retailer — the queue could rest on four categories:

Category	Example message	Indicative priority	Destination
Order tracking	"Where is my order?"	Low	Automated reply with status
Breakdown / after-sales	"My washing machine is leaking"	High	Advisor handover + ticket creation
Billing	"I was charged twice"	High	Advisor handover
Off topic	"Do you sell bikes?"	Low	Short reply, no ticket

Each category also defines what the agent may do on its own: reply, request a document, or hand over. This decision matrix avoids the opposite trap — an agent that hands everything over — as well as an agent answering beyond its scope. Our guide on WhatsApp Business bots, menus and journeys details how to structure these journeys without trapping the user in a rigid menu.

Giving every request a status

A request without a status is a lost request. At minimum, every queue item carries one of these statuses: new, being qualified, awaiting customer, handed to a human, resolved, closed. Moving from one status to another must be triggered by specific events, not by an impression.

For example, a request moves to "awaiting customer" when the agent has asked a blocking question, and back to "new" when the customer replies. It moves to "handed over" when an advisor accepts it, not when the notification is sent. This event discipline is what makes the queue auditable: at any moment you can say how many requests are waiting for a human and for how long.

Human handover: a rule, not an exception

Handover to an advisor is the most fragile moment in the chain. A successful handover passes on three things: context (identity, language, category, conversation history), status (what the agent has already done or promised), and the reason for the handover. An advisor who receives "handover from the bot" with no context starts from scratch, and the customer must repeat everything — the most frequent and most avoidable failure.

Design handover as an explicit rule: which categories always transfer (a complaint, for example), which signals trigger an immediate handover (a customer expressing strong dissatisfaction, the same request repeated three times — a fictional example, to calibrate for your business), and what happens when no advisor is available. Our article on human handover in customer service chatbots covers this in depth, including conversation resumption when the advisor closes.

Proof of handling: what you must be able to show

Proof of handling answers a simple question: when was a request seen, by whom, and what was done? This is not administrative formalism; it is what lets you answer a customer who says "nobody replied to me", and honestly analyse where the queue jams.

Concretely, every request should allow you to reconstruct:

• the timestamp of the customer's first message and of the agent's first reply;
• the declared identity and the detected or confirmed language;
• the assigned category and, if it changed, the reason for the change;
• status transitions with their timestamps;
• any handover: recipient, acceptance, closure.

One point of caution: these elements form an activity trail, not automatic compliance. Retaining customer data follows data protection principles you must frame yourself — duration, purpose, access. The design recommendations above are engineering choices, not legal obligations and not proof of compliance.

Procedure: setting up the queue in five steps

1. Choose the channel. Decide app versus Business Platform. If you want an AI agent that qualifies and routes, the Platform is required; prepare the number connection using our guide to creating a WhatsApp chatbot and connecting the number, and check consent and templates before any outbound send.
2. Write the matrix. List your categories; for each one: example message, destination, what the agent does alone, what transfers. Four to six rows are enough to start.
3. Define statuses and their triggers. For each transition, write the event that causes it. If a transition depends on human judgement, note it: that will be a friction point.
4. Design the handover. Context passed on, acceptance rule, behaviour when unavailable. Test it with a real request before going live.
5. Check the proof. Take a past request and reconstruct its timeline from your trail. If a data point is missing, that is a design gap, not a one-off oversight.

Main commented example: Atelier Noro's after-sales service

Entirely fictional scenario. Tuesday 2:05 p.m., a customer writes: "Hello, my fridge bought last month is making a strange noise and the door no longer closes properly." The agent detects French, tags the request as "Breakdown / after-sales" and replies: a brief apology, a request for the order reference, and a note that an advisor will take over. The customer replies at 2:09 p.m. with the reference. The agent moves the request to "being qualified", attaches the declared identity, and hands over to the after-sales team with full context.

At 2:22 p.m., an advisor accepts: the request moves to "handed over". The advisor proposes a visit slot; the customer says Thursday would be best. The request moves to "awaiting customer" while this is confirmed, then the advisor confirms and closes. The following Thursday, the agent sends an approved template — the 24-hour window is long gone — asking whether the visit solved the problem.

This scenario illustrates three decisions. One, the agent did not try to diagnose the fault: its matrix states that breakdowns always transfer, because bad advice would damage the relationship. Two, the "awaiting customer" status prevented the team from chasing the request while the customer chose a slot. Three, the post-visit follow-up went through an approved template, not a free message, because the service window had closed. Every step leaves a trace: at the end, Atelier Noro can show who saw the request, when, and what was done.

Limits and frequent mistakes

Three traps come up again and again. The first: believing the AI agent "understands" requests when it is applying a matrix you wrote. If your categories are vague, the queue will be too. The second: overlooking the Platform's per-delivered-message pricing. Poorly calibrated follow-ups sent outside the service window via templates cost money per message — in a fictional scenario, an SME following up a thousand customers a month without checking its pricing categories could see its bill double with no change in service quality. The third: treating proof of handling as a monthly export rather than structured data captured from the start.

Finally, remember that channel compliance — consent, approved templates, terms of use — is verified in WhatsApp Business's official policy, and nothing on this page replaces that check.

Frequently asked questions

Should you use a WhatsApp chatbot with menus, or a free-language AI agent?

The two approaches combine. Menus suit predictable journeys (choosing a category, confirming a slot); free language suits initial qualification, where the customer describes the problem in their own words. What matters is that the result feeds the same structured queue, whichever entry mode is used.

How do you handle a customer who switches language mid-conversation?

Treat the switch as an event: the agent confirms the new language, updates the request, and subsequent replies align with it. If a human handover is under way, tell the advisor rather than silently changing the language.

What happens when no advisor is available for a handover?

Design for this case from the start: the request stays in the queue with an explicit status ("awaiting advisor"), the customer receives an honest reply about the delay, and a follow-up via an approved template can be scheduled if the service window closes. Never let a handover fail silently.

Is the customer's WhatsApp number enough as an identifier?

No. The number identifies a conversation, not a person. For any action that reads or modifies a customer file, ask for light identity confirmation and store it with the request. This is a design rule, not a legal obligation.

Can you start without the WhatsApp Business Platform?

Yes, to test simple journeys with the Business app, but without reliable automation or a system-side structured queue. As soon as you want to qualify, route and trace, the Platform becomes necessary — and with it, checking consent, templates and per-delivered-message pricing.

If you would like to define a mission to structure your WhatsApp request queue, you can browse our agent offers at edeverse.com/en#agent-offers.