Skills-based routing & pooling

Deep-dive lesson · about 10 minutes · short quiz at the end

ccPlanning academy · advanced

Skills-based routing & pooling

Why two small teams need more people than one big one.

The big idea

Splitting a pool costs efficiency.

Take 40 agents handling one queue and split them into two specialist teams of 20. To hold the same service, you’ll now need more than 40 people total. Skills-based routing is useful and often necessary — but every split has a hidden staffing tax. Understanding why is core advanced planning.

The pooling principle

Big pools absorb randomness; small ones don’t.

Contacts arrive randomly. In a big pool, a lull in one moment is covered by the many agents free; the bumps average out. In a small pool, the same random bump has nowhere to hide — everyone’s busy and a queue forms. Smaller pools are more volatile, so they need more slack.

The scale effect

The penalty is worst for small pools.

Splitting a huge pool barely hurts — both halves are still big enough to absorb randomness. Splitting a small pool hurts a lot. So a niche skill with low volume is the most expensive thing to isolate: a dedicated team of three for a rare language can sit idle yet still miss service when two contacts arrive at once.

Why we split anyway

Specialisation buys quality and speed.

Routing isn’t a mistake — a specialist resolves faster and better than a generalist. The art is weighing that genuine benefit against the pooling tax. Sometimes a slightly slower generalist pool beats a fragmented set of experts who are collectively under-utilised.

The middle path

Overlapping skills, not rigid silos.

The fix for fragmentation is universal or cross-skilled agents who can flex between queues. A pool where most agents handle two or three skills recovers much of the pooling benefit while keeping useful specialisation. Skill overlap is the lever that buys back efficiency.

Routing design matters

How you route changes the maths.

Priority rules, overflow thresholds, “most-idle-agent” vs “best-skill” selection — these routing choices materially change service and efficiency. Two operations with identical headcount and skills can perform very differently purely on routing design.

Why Erlang can’t do this

This is simulation territory.

You can’t Erlang a skills-based environment accurately — the interactions between overlapping pools and routing rules have no neat formula. To size and tune SBR properly, you simulate (the previous lesson) or rely on WFM tooling that simulates under the hood.

The planner’s instinct

Resist needless fragmentation.

Every new skill, queue or priority someone requests is a little more pooling tax. A good planner pushes back on splits that don’t earn their keep, and champions cross-skilling — because consolidation, where quality allows, is one of the cheapest efficiency gains available.

Feel the tax

40 in one pool vs 20+20

One pool of 40 hits 80/20 comfortably. Split it into two specialist teams of 20 and each small pool is more exposed to random bumps — so to hold the same service you now need ~23 and ~23: about 46 people for the work 40 used to do.

That six-head gap is the split tax, and it’s worst for tiny pools — a dedicated team of three for a rare language can sit idle and miss service when two contacts land at once. Cross-skill to buy it back.

The takeaway

Every split has a tax; overlap buys it back.

Pooling makes big groups efficient and small ones fragile, so fragmenting agents into specialist silos costs headcount — worst for low-volume skills. Specialise where quality demands it, cross-skill to recover efficiency, and reach for simulation to size it. Resist splits that don’t pay.

Now test yourself ↓

1 / 10

Slides done? Here’s the same idea in a bit more depth — the part worth keeping.

In depth: why two small teams need more people than one big one

Take 40 agents handling one queue and split them into two specialist teams of 20, and to hold the same service you’ll now need more than 40 people total. Skills-based routing is useful and often necessary, but every split carries a hidden staffing tax, and understanding why is core advanced planning. The cause is pooling: contacts arrive randomly, and in a big pool a momentary lull is covered by the many free agents so the bumps average out, whereas in a small pool the same random bump has nowhere to hide — everyone’s busy and a queue forms. Smaller pools are more volatile, so they need more slack.

The penalty is worst where volume is lowest

Splitting a huge pool barely hurts, because both halves stay big enough to absorb randomness; splitting a small pool hurts a lot. So a niche skill with low volume is the most expensive thing to isolate — a dedicated team of three for a rare language can sit idle and still miss service when two contacts arrive at once. That said, routing isn’t a mistake: a specialist resolves faster and better than a generalist, and the art is weighing that genuine quality benefit against the pooling tax. Sometimes a slightly slower generalist pool beats a fragmented set of experts who are collectively under-utilised.

Overlap, routing, and the planner’s instinct

The fix for fragmentation is skill overlap: a pool where most agents handle two or three skills recovers much of the pooling benefit while keeping useful specialisation. How you route matters too — priority rules, overflow thresholds, “most-idle-agent” versus “best-skill” selection materially change service and efficiency, so two operations with identical headcount can perform very differently on routing design alone. None of this is Erlang-able; the interactions between overlapping pools and routing rules have no neat formula, so you simulate or use WFM tooling that simulates under the hood. And the standing instinct is to resist needless fragmentation: every new skill, queue or priority is a little more pooling tax, so a good planner pushes back on splits that don’t earn their keep and champions cross-skilling.

The principle to remember: every split has a tax; overlap buys it back. Pooling makes big groups efficient and small ones fragile, so specialise where quality demands it, cross-skill to recover efficiency, simulate to size it — and resist splits that don’t pay.

Skills-based routing & pooling