Decision matrix: when to merge two support queues into one and when to keep them separate
Merging two support queues is cheap to decide and expensive to undo. When two inboxes, two numbers or two teams are unified, you gain coverage and lose context: the agent who previously knew that everything coming in through the after-sales number was a complaint now receives sales inquiries, billing requests and messages from a customer who has already written three times through another channel. The decision is not made by intuition or by 'we're bigger now.' It is made with four numbers: how many messages per hour come in through each queue, how many agents are available in each time slot, how long a response takes in each queue and how many conversations are left without an owner during peaks.
This page is a decision matrix. It does not recommend a tool or a brand. It organizes the criteria so that the support manager can check off their situation and come away with an answer: merge, keep separate or partially merge (a shared queue with an origin tag that survives). The load calculation is done with your own data; here are the formulas and the table to apply them.
What exactly does 'merging two queues' mean
Merging two queues can mean three different things, and it is worth naming them before deciding, because each one has a different operational cost. The first is merging the channel: two WhatsApp numbers that become one. The second is merging the inbox: two numbers continue to exist, but a single team sees all messages in a shared view. The third is merging the team: agents who previously handled only one queue now handle both, with or without a shared inbox.
Channel merging is the most costly to reverse. Inbox merging is the cheapest to test.
| Type of merge | What changes | What is gained | What is lost | Can it be undone |
|---|---|---|---|---|
| Channel (two numbers → one) | The customer writes to a single number | Duplication of contacts and history is eliminated | Separation by origin is lost; migrating contacts and notifying customers takes time | Difficult: the second number has to be published again and customers notified again |
| Inbox (two numbers, one view) | Agents see everything together | Coverage during peaks; a single person can handle both queues | The agent loses the context of 'this is after-sales' and mixes priorities | Easy: the view is separated again by tag or by number |
| Team (same agents for everything) | Agents are no longer assigned to a single queue | Shift flexibility; fewer idle people during off-peak | Learning curve; the specialist stops being a specialist | Medium: people are reassigned, but the knowledge is already mixed |
The four numbers you need before deciding
Without these four data points, any decision is an opinion. They are calculated with the message history from the period you want to analyze. Important: for the analysis by time slot, you must use the message timestamp (the one set by the messaging platform), not the date the record was inserted into the database. If the insertion date is used, any import of old history will show that everything happened on the same day and at the same time, and the distribution of time slots will be false.
- Messages per hour per queue: count incoming messages for each queue, grouped by hour of the day and by day of the week. At least four weeks are needed so that a peak is not an isolated case.
- Operators available per time slot: how many people are connected in each hour, in each queue. If a queue has only one person from 13:00 to 15:00, that is the critical time slot, not the daily average.
- Time to first response per queue: median, not average. The median says what the typical customer experiences; the average is distorted by a single message that went unanswered for eight hours.
- Unassigned conversations during peaks: how many messages were left unassigned or unanswered when the queue exceeded its capacity. This is the number that justifies or does not justify the merge.
The load formula per queue
The load of a queue is estimated by dividing the messages that come in during the peak hour by the response capacity of one operator in that same hour. Capacity is not a fixed number: it depends on the type of inquiry and on whether there are suggested replies or templates that speed up writing. It is measured, not assumed.
Step 5 is the deciding one: if the merge frees up at least one operator during the peak hour, there is a strong argument. If it frees up no one, the merge only adds mix.
| Step | What is calculated | Formula | Example with your own numbers |
|---|---|---|---|
| 1 | Messages during peak hour per queue | Count incoming messages during the highest-volume hour of the last 4 weeks | Queue A: 48 messages/hour. Queue B: 12 messages/hour |
| 2 | Capacity per operator per hour | Messages that one operator can answer well in one hour (measure during a real hour, do not estimate) | 20 messages/hour per operator |
| 3 | Operators needed per queue | Messages during peak hour ÷ capacity per operator | Queue A: 48 ÷ 20 = 2.4 → 3 operators. Queue B: 12 ÷ 20 = 0.6 → 1 operator |
| 4 | Operators needed when merging | (Messages A + Messages B) ÷ capacity per operator | (48 + 12) ÷ 20 = 3 operators |
| 5 | Savings or cost of the merge | Separate operators − merged operators | (3 + 1) − 3 = 1 operator difference during the peak hour |
The matrix: nine situations and what to do in each one
Each row combines the relative volume of the two queues with the specialization of the team. The right-hand column is the operational recommendation, not an absolute rule: it serves to check off your own situation and discuss the specific case.
Situations 3, 7, and 9 allow partial merges: it is not all or nothing.
| Situation | Volume queue A vs. B | Team specialization | Main risk | What should be done |
|---|---|---|---|---|
| 1 | One queue concentrates more than 80% of the volume | Both queues are handled by the same person or the same group | None relevant: they are already merged in practice | Formally merge the inbox and keep an origin label |
| 2 | Similar volumes (between 40% and 60% each) | Different teams, with specific knowledge of each topic | The specialist loses focus and quality drops | Keep them separate, but with a backup channel for peaks |
| 3 | One queue has strong peaks and the other is stable | Same operators rotating | During the peak, the stable queue goes unattended | Merge the inbox only during the peak window, not all day |
| 4 | Both queues have peaks in the same window | Different teams | No one can cover the other's peak because both spike at the same time | Keep them separate and reinforce each one during that window |
| 5 | Low volume in both (fewer than 10 messages/hour each) | A single person handles both | Overload of one person | Merge everything: channel, inbox and team |
| 6 | One queue is sales and the other is post-sale | Different teams with different metrics | Objectives get mixed: sales wants to respond quickly to close, post-sale needs to investigate | Keep them separate; if the inbox is merged, separate by label and by metric |
| 7 | One queue receives messages outside business hours and the other does not | Same operators during business hours, on-call for the other | The person on call receives messages they do not know how to resolve | Merge only the auto-reply by schedule, not the entire inbox |
| 8 | Both queues use the same number but a different label | Same operators | None: the merge already exists at the channel level | Organize labels and statistics; no need to merge anything else |
| 9 | One queue has a single operator and that person gets sick | No backup | The queue goes dead | Merge the inbox as a backup, even if the team remains separate |
When to keep them separate even if merging seems obvious
There are three cases in which keeping the queues separate performs better, even if the load calculation suggests that merging frees up an operator. The first is when both queues have different record-keeping obligations: if a conversation from one queue must be documented in one way and the other in another way, merging the inbox transfers that problem to the operator. The second is when first response time is a metric committed to a client or an internal agreement for only one of the queues: mixing them dilutes the measurement. The third is when one queue receives messages that require validating identity or sensitive data and the other does not: the friction of a different protocol in the same inbox generates errors.
- Different record-keeping obligation per queue: keep the record separate even if the view is shared.
- Response time metric committed in only one queue: if merged, it must still be measurable by origin.
- Different identification protocol: if one queue asks for data that the other does not, the shared inbox invites skipping it.
- Specialization that took time to build: if training an operator in one queue took weeks, merging dilutes that investment.
How to do a partial merge (the option almost nobody considers)
A partial merge solves most cases without losing context. It consists of keeping the two numbers or the two origin queues, but sharing a single view with a label that identifies where each conversation comes from. The operator sees everything, but knows what they are looking at. Statistics can still be separated by label. If the experience does not work, you go back to the separate view without having migrated contacts or notified clients.
- 1Define one label per origin queue (for example, the name of the number or the area) and apply it automatically to each incoming conversation.
- 2Configure the shared view so that the label is visible in the list and in the conversation header.
- 3Define a priority rule: which queue is handled first when there are messages in both. Without this rule, the operator improvises and the lower-volume queue gets postponed.
- 4Measure first response time by label for two weeks. If the lower-volume queue gets worse, the partial merge is not working.
- 5Check whether the team still uses the label or ignores it. If they ignore it, the partial merge has become a de facto full merge.
Common mistakes when merging queues
None of these errors gets fixed in a set amount of time: it depends on how many customers are used to the old number and how much knowledge the team has. If, after correcting course, unanswered conversations keep rising, you need to escalate to whoever manages the account or the messaging platform.
| Error | Why it happens | How it's detected | What to do |
|---|---|---|---|
| Merging the channel before merging the inbox | People believe a single number simplifies everything | Customers keep writing to the old number and nobody sees it | Keep the old number redirected or with an auto-reply announcing the change before deactivating it |
| Merging without a priority rule | People assume the operator will know what to handle first | The lower-volume queue accumulates unanswered messages | Write the priority rule before opening the shared view |
| Measuring response time with the average instead of the median | The average is easier to calculate | One message left unanswered for eight hours distorts the entire metric | Recalculate with the median and reassess the decision |
| Merging teams without training them on the new queue | People assume that handling is handling | Incomplete or forwarded responses to another area increase | Train before merging, or merge only the inbox, not the team |
| Not keeping a record of the origin | The tag is applied at the start and then lost | You can't reconstruct which queue had more load when the merge was decided | Tag automatically on entry, not by hand |
| Merging because of a seasonal peak | One month of high volume looks like the new normal | The following month there's excess capacity and the team gets bored | Merge only the peak time slot, not the entire operation |
| Deactivating the second number without warning | People assume customers will migrate on their own | Lost messages and complaints about the change | Announce it on the old channel for a period and leave an auto-reply redirecting |
What to review after merging (or after deciding not to merge)
The decision doesn't end when you press the button. You need to review four signals during the first few weeks. If they get worse, you roll back whatever can be rolled back: merging the inbox is reversible, merging the channel is not. If they were kept separate, the review helps you know whether the decision is still correct or whether the volume changed.
- Time to first response by origin queue: if the lower-volume queue got worse than acceptable, the merge is costing you.
- Unanswered conversations at the end of the day: if they increased, the shared view wasn't enough to cover the peaks.
- Complaints about responses that don't match the topic: a sign that the operator isn't reading the queue's context.
- Actual use of the origin tag: if nobody uses it, the partial merge became a full one without anyone deciding it.
- Load per operator during peak hour: if an operator went from handling 20 to handling 35 messages per hour, the merge didn't free up capacity, it moved it.
How this relates to the tool you use
The decision to merge or not is operational and is made before choosing the tool. That said, some features make a partial merge viable without friction: a shared inbox with visible tags, auto-replies by schedule, and statistics that can be separated by origin. Wando, for example, has an inbox with AI suggestions, tags on contacts, auto-replies by schedule, and message statistics, which lets you test a partial merge without migrating the number. The underlying decision remains the same: if the load calculation doesn't free up capacity during peak hour, no tool justifies merging.
Frequently asked questions
Answers to the most common questions when deciding whether two queues should be merged or kept separate.
Frequently asked questions
How many messages per hour justify merging two queues?+
There is no universal number. The merge is justified when the sum of both queues at peak hour requires fewer operators than the sum of operators needed separately. With the formula on this page: if queue A needs 3 operators and queue B needs 1, and merged they need 3, there is an argument. If merged they still need 4, the merge does not free up capacity.
Can the inbox be merged but the numbers kept separate?+
Yes, and it is the cheapest merge to test and to revert. Both numbers keep existing, a single team sees all messages in a shared view and an origin tag allows measuring per queue. If it does not work, you go back to the separate view without having migrated contacts or notified customers.
What happens if I merge and then regret it?+
It depends on the type of merge. The inbox merge is easy to revert: the view is separated again by tag or by number. The team merge is reverted by reassigning people, although the knowledge is already mixed. The channel merge is the hardest: you have to republish the second number and notify customers again.
How do I measure first response time if I merged the queues?+
With the origin tag applied automatically when each conversation comes in. If the tool allows statistics separable by tag, you can keep measuring each queue even if the inbox is shared. If it does not allow it, the inbox merge erases the metric and it is better not to do it.
Is it worth merging if one queue is sales and the other is after-sales?+
Generally no, because the two areas have different objectives: sales prioritizes responding quickly to close, after-sales needs to investigate before answering. If the inbox is merged, you have to separate by tag and by metric, and define an explicit priority rule. Without that rule, the after-sales queue is postponed because its responses take longer.
How often should the decision to merge or not be reviewed?+
Every time the volume changes sustainably, not because of a seasonal peak. A month of high activity is not the new normal. The review should be done with at least four weeks of data and comparing median response times, not averages.
Does merging queues affect WhatsApp template approval?+
No. Template approval depends on Meta, not on how the business organizes its queues. The only deadline that can be stated is that the review may take up to 48 hours. Any other deadline or approval criterion should be verified in Meta's official documentation, because the rules change.
Answer WhatsApp with AI
Try Wando free. No credit card required.