The Pooling Principle
The pooling principle is the workforce-management rule that combining several separate queues or agent groups into one larger pooled group lets you handle the same workload with fewer staff — or, for the same staff, deliver a better service level.
It's one of the most powerful — and most misunderstood — ideas in contact centre planning.
The effect comes from economies of scale in queueing: a bigger pool smooths out the random peaks and troughs of arriving contacts, so agents spend less time idle waiting and more time helping.
But the principle has firm limits, and pushing it too far causes real damage.
This guide explains how pooling works, why it saves staff, how it relates to service level and Erlang calculations, and where over-pooling tips from smart to self-defeating.
What it is
Combining separate queues or agent groups into one pooled group, which handles the same workload with fewer staff thanks to economies of scale.
Why it's powerful
Larger pools smooth out random demand peaks, so the same staff deliver a better service level — or the same service needs fewer staff.
What this guide covers
How pooling works, why it saves staff, its link to service level and Erlang, and the point where over-pooling destroys expertise.
What is the Pooling Principle?
In plain English
Imagine two separate teams, each with its own queue. Some of the time one team is slammed while the other has agents sitting idle — but because the queues are separate, the idle agents can't help the busy ones.
Now merge them into one pool answering one combined queue: every agent can take any call, so the quiet capacity in one area soaks up the busy spikes in another.
The result is that a single larger group handles the same total work with fewer people, or gives faster answers with the same people.
It works because contact arrivals are random and bursty.
The bigger the pool, the more those random peaks and troughs cancel each other out — the maths calls this an economy of scale, and it's the same reason large contact centres can hit a tough service level more efficiently than several small ones can.
What it is
A queueing principle: merging separate queues or skill groups into one larger pool to gain efficiency from smoothing random demand.
What it isn't
It is not a licence to make everyone do everything. Pooling assumes agents can genuinely handle the pooled work — ignore that and the "saving" is an illusion.
Why It Matters
The pooling principle is one of the highest-leverage ideas in WFM because it changes the staffing maths itself — not just how you schedule the staff you have.
📐 For WFM & planners
Pooling explains why two queues of five agents are far less efficient than one queue of ten. Understanding it stops you over-staffing fragmented teams and helps you design queue structure deliberately.
🎧 For contact centre leaders
It reframes the "more channels, more teams" sprawl: every new specialist queue you carve out has a hidden staffing cost. Pooling is the lens for weighing that trade-off.
💷 For finance & the business
Because pooling reduces the staff needed for a given service level, it's a direct lever on the single biggest cost in most contact centres — labour — without cutting service.
How Pooling Saves Staff
The benefit comes from four linked effects. Together they explain why a bigger pool does more with proportionally less.
Smoothing random peaks
Contacts arrive unpredictably. In a larger pool, a spike in one area is offset by a lull in another, so the combined demand is far steadier than any single queue's.
Less idle capacity
Separate small queues each need spare agents "just in case". Pooled, that buffer is shared, so far less capacity sits idle waiting for a peak that may not come — which lifts occupancy without burning agents out.
Economies of scale
The efficiency gain grows with size: the bigger the pool, the lower the proportion of staff needed for the same service level. This is the core economy of scale.
Better service for the same cost
You can bank the gain two ways — keep service level the same and cut staff, or keep staff the same and lift service level. Either is a real win.
See it in the Erlang maths
The effect is easy to demonstrate with an Erlang C calculator. Model two queues of, say, 100 calls an hour each, staffing each to your service level target — then model one pooled queue of 200 calls an hour to the same target.
The pooled queue needs fewer agents than the two separate queues combined. That gap is the pooling principle, in numbers.
How to Apply the Pooling Principle
Pooling is a design decision, not a switch you flip. The goal is to capture the scale benefit without breaking the things that make specialist teams good.
Pool where skills overlap
The biggest, safest gains come from combining queues whose agents already share the skills to handle each other's work. Where the work is genuinely interchangeable, pool freely.
Use skills-based routing for the rest
Where work differs, you don't have to choose between fully separate or fully pooled.
Skills-based routing lets one workforce flex across overlapping queues — a partial pool that captures much of the benefit while protecting expertise.
Model before you merge
Always quantify the gain before restructuring. Use an Erlang model to compare the separate-queue staffing with the pooled-queue staffing at your service level target — and remember to layer in shrinkage, since the headcount you actually roster is always higher than the raw Erlang figure.
If the saving is small but the skills risk is large, the pool isn't worth it — the maths and the operational reality both have to agree.
Common Pitfalls
Pooling fails when planners treat the efficiency gain as free and forget that it assumes agents can actually do the pooled work.
Over-pooling and losing expertise
Merge too many distinct skills into one generalist pool and quality, first-contact resolution and handle time all suffer. Agents become jacks-of-all-trades, mastering none — and customers feel it on complex calls.
Assuming the saving with no skills check
The Erlang saving only materialises if every pooled agent can genuinely handle every pooled call. Pool on paper without training to match, and calls get transferred, repeated and escalated — wiping out the gain.
⚠️ Pooling is powerful, but over-pooling destroys expertise
This is ACXPA's position: pooling is one of the best tools in WFM, but it is not a goal in itself.
The efficiency curve flattens as pools grow, while the cost to expertise keeps rising — so beyond a point you're trading away quality for an ever-smaller staffing saving.
Treat the trade-off between scale and specialisation as a deliberate design choice, not a default toward "one big pool".
💡 Most of the gain comes early
The efficiency benefit of pooling is largest when you combine the first few small queues, and shrinks as the pool gets bigger.
That means you can usually capture most of the upside with moderate, skills-aware pooling — and rarely need to flatten everyone into a single mega-queue to get there.
If you'd rather have specialists model and route it for you, the ACXPA Supplier Directory lists Workforce Optimisation providers who do exactly this.
Frequently Asked Questions About the Pooling Principle
What is the pooling principle?
The pooling principle is the workforce-management rule that combining several separate queues or agent groups into one larger pool lets you handle the same workload with fewer staff, or deliver a better service level with the same staff. The gain comes from economies of scale: a bigger pool smooths out the random peaks and troughs of arriving contacts.
Why does pooling save staff?
Because contacts arrive randomly and unevenly. With separate queues, one team can be overwhelmed while another sits idle, and the idle agents can't help. Pool them and every agent can take any call, so quiet capacity in one area absorbs busy spikes in another. The combined demand is steadier, so proportionally fewer agents are needed to hit the same service level.
How does pooling relate to service level?
Pooling directly improves the staffing-to-service-level equation. For a given number of staff, a larger pool achieves a higher service level; for a given service level target, it needs fewer staff. You can bank the benefit either way. The relationship is non-linear, which is why an Erlang calculator is the right tool to quantify it.
Can I see the effect in an Erlang calculator?
Yes — it's the clearest way to prove it. Model two separate queues, each staffed to your service level target, and note the total agents. Then model one pooled queue carrying the combined volume to the same target. The pooled queue needs fewer agents than the two separate ones added together, and that difference is the pooling principle in numbers.
What are the limits of pooling?
Pooling assumes agents can genuinely handle all the pooled work. When you combine queues that need very different skills, you either force agents to become generalists — hurting quality and resolution — or the saving evaporates as calls get transferred and escalated. Complexity, training cost and the value of specialisation all cap how far pooling should go.
Should I pool everything into one big queue?
No — and this is ACXPA's clear position. The efficiency gain is largest when you combine the first few small queues and shrinks as the pool grows, while the cost to expertise keeps rising. Over-pooling trades quality for an ever-smaller staffing saving. Capture most of the benefit with moderate, skills-aware pooling, and use skills-based routing rather than flattening everyone into one generalist mega-queue.
How is pooling different from skills-based routing?
They work together. Pooling is the principle that bigger combined groups are more efficient; skills-based routing is a practical way to capture much of that benefit without fully merging teams. Routing lets one workforce flex across overlapping queues based on who can handle what — effectively a partial pool that protects expertise while still smoothing demand.
Where to Next
Summary: The Pooling Principle
The pooling principle says that combining separate queues or agent groups into one larger pool handles the same workload with fewer staff — or delivers a better service level for the same staff — because a bigger pool smooths out the random peaks and troughs of arriving contacts.
It's an economy of scale you can prove in any Erlang calculator: a pooled queue needs fewer agents than the separate queues it replaces.
The effect is real and valuable, but it isn't free. It only holds while pooled agents can genuinely handle the pooled work, and the efficiency gain shrinks as the pool grows while the cost to expertise keeps rising.
ACXPA's position is that pooling is powerful but over-pooling destroys expertise.
Capture most of the benefit with moderate, skills-aware pooling and skills-based routing — and treat the trade-off between scale and specialisation as a deliberate design choice, never a default march toward one giant generalist queue.
