Guide · Routing · For the owner with a support desk, a marketing tool and Meta's agent on one number

WhatsApp Conversation Routing: who answers when two systems share one business number

Many businesses end up with more than one system on the same WhatsApp number: a support desk, a marketing tool, an agency's software, now perhaps Meta's own AI agent. By default every one of them receives every customer message, and two of them can answer the same person. Meta's Conversation Routing fixes that by giving each conversation one owner, chosen by how the customer arrived. Here is how Meta decides who answers, what the others are allowed to see, and how a conversation is handed from one to another.

Published 1 October 2026 · Updated 6 October 2026

The problem, and when routing switches on

Meta's overview states the default plainly: every responder connected to a WhatsApp account receives every inbound message. That is fine with one system and breaks with two, for example one partner for customer service and another for marketing replies. Routing becomes active when two things are both true.

More than one responder: Two partners' systems, or one system alongside Meta Business Agent.
A routing configuration: Made in Meta Business Suite, mapping each way a customer can arrive to one responder. Meta says this is the business's decision, not the partner's. On an account with none, Meta can also create a starting configuration when the business onboards or assigns another partner; the routing setup guide lists every way one comes into being.

Until the business sets that configuration, nothing is filtered: every connected system keeps receiving every message, and none of them is a standby observer. Routing is also anchored to the account, with an optional override per phone number, so two numbers on one account can route differently.

Five ways a customer arrives

Meta calls them entry points. Each inbound message is given one, and each entry point has one responder the business chose as its primary.

Click to WhatsApp: The customer came from an ad that opens the chat. Decided first, whatever else happened recently.
Calls: The customer calls, or answers a call-permission request. Routed on its own and never changes who owns the message thread. Since Meta's 5 October 2026 update, the system set for calls also handles calls the business places, and it is the only system Meta lets place, answer, decline or end a call.
Marketing message response: The customer replies to a marketing template, by quoting it, tapping its button or choosing from its list, or the last thing the business sent in the previous 24 hours was a marketing template.
Utility response: The same, for a utility template: an order update, a reminder, a receipt.
Service: Everything else: a customer writing in with no qualifying template in the past 24 hours, or replying to an ordinary message. This is the default.

For the two template entry points the business can instead choose Route to Sender, so the reply goes back to whichever system sent that template. The template categories guide explains what makes a template marketing or utility.

Who owns a conversation, and for how long

Receiving the message makes you the owner: On a conversation with no owner, Meta delivers the customer's message to the primary for its entry point, and that responder owns the thread from that moment, before it has replied.
The owner keeps it: Once owned, every further message from the customer goes to the owner, whatever its entry point. Two exceptions: a new click on an ad, or a tap on a marketing or utility template's button, counts as a change of intent and re-routes the thread at once.
24 hours of silence resets it: After 24 hours without a message from the customer the thread goes idle, and their next message is routed afresh. Meta is careful to say this idle window and the 24-hour lookback that decides the entry point are two different clocks.
Templates ignore ownership: Any system on the account can send a marketing, utility or authentication template to the customer, whoever owns the thread, and doing so changes nothing. Only ordinary replies inside the window need ownership; from anyone else they are rejected.

What the other systems see

A system that does not own a thread can be granted standby visibility by the business. It then receives a copy of the customer's messages, of the owner's replies and of their delivery receipts, so it has the history if the thread is ever handed to it. Standby is off by default, appears only once the business has accepted Meta's terms, and comes with one rule in bold on Meta's page: a standby system must not reply to the customer.

Handing a conversation over

Meta's thread-control page gives the owner, and one special partner, three actions.

Pass: The owner hands the thread to a named role: customer service, marketing, utility, the ad-click responder, the AI agent, or the escalation partner. The receiving system is told who passed it and can be sent a short note with it.
Release: The owner lets go. The thread goes idle and the customer's next message is routed by entry point, as if new.
Take: Reserved for the account's one designated escalation partner, which may seize any thread at any time, explicitly or simply by replying to the customer. The previous owner is notified.

This is the mechanism behind the handoff described in the Meta Business Agent guide: the agent passes to a person's system, or a person's system passes to the agent, and at every moment exactly one of them owns the customer. The 24-hour window for free replies is unchanged by any of this; routing decides who may reply, the window decides whether a template is needed.

The note that travels with a handover

Meta's page on conversation context, updated 22 September 2026, adds a detail the owner will notice in practice. When a conversation is handed to a system that has not been watching it, Meta can attach a short machine-written summary of what was said so far, so the person picking up does not start cold. It arrives in three situations: a handover, the first message on a conversation that had gone idle, and a message that follows a promotion or notice sent by a different system mid-conversation. It is sent only when the receiving system would otherwise be missing the history, which means a standby observer never gets one, since it has the whole thread already; a business gets one of the two, never both. It is also tied to Meta Business Agent: the business must be in a region and line of work where the agent is offered and must have accepted its terms. Two things Meta says about the summary are worth knowing. Order numbers, reference codes and amounts are carried through word for word, so the receiving agent can act on them; and anything still open is written as unresolved, so a summary never implies a refund landed or a delivery slot was fixed when the conversation only shows it was asked for. Meta tells providers to treat the summary as optional and keep their own record; so should you.

When routing misbehaves

Meta's troubleshooting page for Conversation Routing, dated 25 September 2026, lists the faults providers report. Translated into what the owner sees:

A system receives nothing: It has not been made primary for any entry point and has no standby grant. The fix is in Meta Business Suite, and it is the business's to make: routing cannot be configured through any interface a provider controls.
Messages went to the other system: The other system is primary for the door the message came through, or already owned the thread. Check which entry point the message used before blaming the tool.
The same message arrives twice: A standby observer receives copies of activity on threads it does not own, alongside the messages on threads it does. A system that mistakes a standby copy for a live conversation will try to answer and fail.
The conversation reset on its own: 24 hours without a message from the customer, or a release by the owner, returns a thread to idle. An ad click or a button tap on a promotion also clears the owner, but the same message is routed again at once rather than left idle.
Nobody can tell who owns a thread: Meta is explicit that there is no way to ask. Each system has to keep its own record from the messages, handover events and standby copies it receives. A provider that claims to show live ownership is inferring it.
A phone call did not change anything: Correct. An incoming call is routed to the primary for the call entry point, but a call never creates, moves or clears ownership of the text thread.
Another system could not place or answer a call: Meta refuses calling actions from any system that is not set as the primary for calls, even one that is primary for messages. For a call the business places, Meta sends the call updates to that system only when it is also the primary for calls. Other systems on standby can receive copies of a customer's call events, but only to see them.

Faults a provider cannot explain go to Meta's Direct Support under the Conversation Routing question type, with the request reference from the failing call; that route, and who may use it, is in the support guide. Meta's page also notes that a pass can name the role it goes to, one of the six described above, provided the account has been enabled for passing to that role; a pass with no named role goes to the escalation partner.

Questions

Two of our tools both answered the same customer. Why?

Because no routing configuration exists, so Meta delivers every message to every connected system. Routing starts once a configuration exists in Meta Business Suite: the business can make one itself, and Meta can create one when another partner is assigned to the account.

Can our agency still send campaigns if the support system owns the chats?

Yes. Marketing, utility and authentication templates never need ownership and never change it. What the agency's system cannot do is send an ordinary reply inside a conversation another system owns.

If the customer replies to a promotion, who gets it?

The responder the business set as primary for marketing responses, or the system that sent the template if the business chose Route to Sender, provided the thread was idle or the reply was a button tap. A typed reply on a thread someone already owns stays with the owner.

Our chat system answers messages. Can it also make WhatsApp calls?

Only if it is also set as the primary for calls. Meta's routing pages, updated on 5 October 2026, say only that system may place, answer, decline or end a call, whichever system owns the text conversation.

Who can take a conversation away from another system?

Only the account's single escalation partner, which can take any thread, including by just replying. Every other system must be passed the thread by its owner or wait for it to go idle.

Sources

Meta's developer documentation: Conversation Routing overview, read 6 October 2026.
Meta's developer documentation: Entry points and routing, read 6 October 2026.
Meta's developer documentation: Standby partners, read 1 October 2026.
Meta's developer documentation: Thread control, read 1 October 2026.
Meta's developer documentation: Thread lifecycle, read 1 October 2026.
Meta's developer documentation: Conversation context, read 3 October 2026.
Meta's developer documentation: Conversation Routing troubleshooting, read 6 October 2026.

More plain-language notes like this one are on the guides page.

More than one system on your WhatsApp number, and nobody sure who answers?

We set up a business's WhatsApp number on a proper system that can be the primary for service, stand by for the rest, and take or pass a conversation cleanly, with every handoff recorded in one place the business owns. A short call is the easiest way to see whether it fits your business.

Book a demo