Internal WhatsApp routing rules: which area each reason goes to and how long it should take to come back

When a business handles WhatsApp with several people, the question that comes up most often is not "what do I answer?" but "is this mine or someone else's?". Without a written rule, each agent decides differently: some escalate too much, others keep a complaint they can't resolve, and the customer waits while the message bounces between areas. This page is the table that solves that: an escalation policy with the reason, the destination area, the priority, the minimum data that must be attached, and the deadline by which the area has to return an answer.

It's not a table of made-up reasons for one industry. It's the template for each business to fill in with its own, plus the method to set deadlines with your own data instead of by guesswork. The deadline column isn't filled in with what you'd wish for: it's filled in with what the team can sustain.

How to read this table

Each row is a type of conversation that arrives in the inbox and can't be closed by whoever receives it. The columns are always the same six: reason, area that resolves it, priority, minimum data attached when escalating, expected response deadline, and what the agent does if the deadline passes. The row is read from left to right: the agent recognizes the reason, looks at the area, calculates the priority, attaches the data, and starts the clock.

The important thing isn't the row: it's that the row exists before the message arrives. A written rule is discussed once; an implicit rule is discussed on every escalation, with the customer waiting on the other side.

Reference table: reasons, area, priority, data, and deadline

How to set deadlines with your own numbers, not the ones you'd like

The most common mistake when building this table is writing down the desired deadline. If the logistics area has only one person who reviews those cases twice a day, a deadline of "2 hours" will never be met and the table loses authority. The deadline is calculated with three pieces of data the business already has: how many cases of that reason arrive per day, how many people in the area can handle them, and how long each case takes to resolve.

The formula is simple: daily capacity of the area = people × cases per person per day. If more cases arrive than the capacity, the deadline stretches or cases are prioritized. An example with made-up numbers to show the mechanism: if the after-sales area has two people who can resolve ten cases each per day, its capacity is twenty cases per day. If thirty complaints arrive per day, no deadline can hold up: you have to add capacity or define what is answered automatically while the case waits.

With those five pieces of data, a deadline that can be sustained is defined. And if demand exceeds capacity in a structural way, that is not fixed with a longer deadline: it is fixed with automatic responses that inform the status while the case waits, or by adding people. A deadline that is missed every day is worse than having no deadline, because it teaches the team to ignore the table.

What minimum data each referral must carry

A referral without data comes back. The area receives "a customer is complaining about their order" and has to ask for the number, the date, and the address before it can do anything. That adds a round trip that is paid for in hours. The rule is that the agent making the referral attaches, in the same internal message, everything the area needs to start without asking again.

• Identification: customer name and phone number, even if the area sees it in the conversation.
• The reason in one line: not the full story, the category.
• The hard data of the case: order number, receipt, date, amount, branch, whatever applies.
• What the customer has already said they want: a complaint asking for a refund is not the same as one asking for a replacement.
• The attachment if it exists: photo, screenshot, receipt.
• The date and time the customer first wrote about this topic.

What the full circuit looks like, step by step

1. 1The agent reads the message and classifies it by reason, using the first column of the table.
2. 2If the reason is in the table, it identifies the area and the priority.
3. 3It attaches the minimum data from that row. If any is missing, it asks the customer for it before forwarding.
4. 4It forwards with an internal message that includes the reason, data and expected deadline.
5. 5It lets the customer know that their inquiry is now in the hands of the corresponding area and gives them a reference (case number or similar).
6. 6The area responds within the deadline. If it does, the case continues its normal course.
7. 7If the deadline passes, the agent applies the last column of the table: it does not leave the customer without a response.
8. 8When the case is closed, the closing time is recorded so the actual deadline can be measured.

The step that gets skipped the most is the fifth one: letting the customer know. A customer who doesn't know their message was forwarded writes again, and that second inquiry enters the same queue, doubling the load. Letting them know costs one message and saves two.

What to do when the area doesn't answer: the escalation ladder

No rule works if it doesn't say what happens when the deadline passes. The ladder has three rungs and each one has a different recipient. Insisting to the same person is not the same as notifying their manager. The ladder is defined once and always applied the same way, so it doesn't depend on who is on duty.

The third rung is the most uncomfortable and the most important. Leaving the customer waiting without a response because the internal area doesn't answer is the worst option of all: the customer doesn't know there's an internal problem and interprets it as abandonment. Responding with what is available, even if partial, keeps the conversation alive.

Common mistakes when building this table

• Setting deadlines the area cannot meet. The table discredits itself in the first week.
• Forwarding without minimum data. The area asks again and the time the forwarding was meant to save is lost.
• Not telling the customer their case was forwarded. It generates duplicate messages and distrust.
• Defining priorities without criteria: if everything is high priority, nothing is.
• Not recording the real resolution time. Without that data, the table can never be corrected.
• Leaving the escalation ladder unwritten. Every agent improvises and the circuit breaks.
• Confusing forwarding with closing: forwarding is not resolving, it is passing the ball to someone who can resolve it.
• Building the table once and never reviewing it. Reasons and workloads change with the business.

How to know if the circuit works

The table is measured with four simple indicators, all calculable with what is already recorded in the inbox. No new tool is needed: it is enough to note, for each forwarded case, when it was forwarded and when it was closed. With those two data points, everything else is calculated.

• Percentage of cases that come back within the deadline: the central indicator. If it drops, the deadline is poorly calibrated or there is a lack of capacity.
• Average resolution time per area: it allows comparing areas with each other and seeing where the circuit gets stuck.
• Percentage of forwardings that come back due to incomplete data: it measures whether agents are attaching what the table requires.
• Percentage of cases that escalated to the third step: if it is high, there is an area that cannot handle its workload.

The table is reviewed with these numbers in view, not with opinions. A deadline that is almost always met is well set; one that is met half the time is poorly set, even if the team swears it works well. The adjustment is to raise the deadline or lower the workload, and that decision belongs to whoever coordinates, not to the agent who handles the case.

How this fits into an inbox with AI suggestions

When the inbox has AI suggestions, the agent still decides: the AI proposes and the person approves. The forwarding table is precisely the criteria the person applies when approving or discarding. The AI can suggest a response, but it does not know whether that specific complaint goes to logistics or to administration: that is defined by the table the business built, and the agent applies it. Over time, the team's real responses are what feed the suggestions, so a clear table also improves what the tool proposes. Wando uses Meta's official WhatsApp API and learns from the business's real responses, but the decision of which area each case goes to is still up to the team.

Frequently asked questions

The most common questions when putting together the forwarding rules are answered below. If your case isn't here, the answer is usually in the time limit formula: measure the area's actual workload before writing the number.