Split your contact volume into two separate skill queues, each staffed by dedicated agents, and you will always need more total headcount than if the same agents were cross-trained to handle both queues from a single pool. This is not a soft organisational benefit. It is a direct, calculable consequence of how queueing math works, and it is worth understanding in numbers rather than taking on faith.
Why splitting a queue costs you agents
Erlang C staffing has a built-in economy of scale: as a queue gets bigger, the agents needed per unit of volume gets smaller, because a larger pool absorbs random spikes and lulls more efficiently than a small one. Split one large queue into two smaller ones and you lose that efficiency twice over, once in each smaller queue, without gaining anything back. Two independent queues have independent peaks and troughs. A pooled queue sums the volume but not the variability in the same way, so the combined stream is proportionally steadier than either queue was on its own, and steadier demand needs less staffing buffer to hit the same service level.
The actual numbers
Take two identical skill queues, same volume, same AHT, same target service level. Staff them separately, then staff the same combined volume as one pooled multi-skill queue:
| Volume per queue | Separate total | Pooled | Agents saved | % reduction |
|---|---|---|---|---|
| 100 x 2 | 42 | 39 | 3 | 7.1% |
| 150 x 2 | 60 | 57 | 3 | 5.0% |
| 200 x 2 | 78 | 74 | 4 | 5.1% |
| 300 x 2 | 114 | 108 | 6 | 5.3% |
| 400 x 2 | 148 | 142 | 6 | 4.1% |
| 600 x 2 | 216 | 210 | 6 | 2.8% |
This lines up with what queueing research generally finds in practice: pooling produces roughly a 5 to 15% staffing reduction depending on queue size and variability, sometimes more. Notice the pattern here too, the percentage saving is largest for smaller queues and shrinks as each individual queue gets larger, since a big single-skill queue already captures some economy of scale on its own before you pool it with anything else. Pooling helps most exactly where you'd expect: smaller, more volatile skill queues that are currently staffed in isolation.
You don't need every agent cross-trained to get most of the benefit
This is the part that surprises people running the numbers for the first time. Capturing most of the pooling benefit does not require full cross-training across your entire floor. Research on this consistently finds that a modest amount of cross-training, often cited around 20 to 30% of agents skilled across two queues, captures most of the available gain, because those flexible agents can be deployed wherever the variance actually shows up that day. Full cross-training past that point adds cost (training time, skill currency maintenance, coordination overhead) for a shrinking marginal return.
Where this breaks down
Pooling assumes agents can genuinely handle either queue at an acceptable quality level. If "cross-trained" means an agent technically has the skill flagged in the system but rarely gets routed to it and never builds real proficiency, you get the training cost without the pooling benefit, and you have quietly recreated two single-skill queues with extra overhead attached. The efficiency gain only materialises if cross-trained agents genuinely flow to wherever demand is highest in real time, which is an intraday management and routing configuration problem as much as a training one.
What to actually do with this
Before combining any two skill queues into a shared pool, quantify the expected gain rather than assuming it. Run each queue's required staffing separately through the Erlang C Staffing Calculator, then run the combined volume as a single pooled queue, and compare. If your queues are small and volatile, expect a meaningful reduction. If they are already large and stable, the pooling benefit will be modest, and the cross-training cost needs to be judged against that smaller number, not against the bigger savings you'd see on a smaller queue. Feed whichever number you land on into your Capacity Planning Calculator headcount model so the pooling benefit shows up in your plan, not just in a one-off calculation nobody revisits.