Queue pooling calculator
Small queues are expensive: each needs its own slack to absorb random arrivals. Pool them and the slack is shared. Enter up to five queues in the same interval and the calculator runs Erlang C on each and on the pool, so you can see the agents multi-skilling saves before you argue about whether it is possible.
Same service level target, one queue instead of several.
- Agents as separate queues
- 49
- Agents as one pooled queue
- 40
- Saving
- 18.4%
- Pooled occupancy
- 85.0%
- Total workload
- 34.0 erlangs
Show the working
- Queue 1: 13.3 erlangs needs 18 agents on its own at 74.1% occupancy.
- Queue 2: 10.0 erlangs needs 14 agents on its own at 71.4% occupancy.
- Queue 3: 8.0 erlangs needs 12 agents on its own at 66.7% occupancy.
- Queue 4: 2.7 erlangs needs 5 agents on its own at 53.3% occupancy.
- Separately: 49 agents in total.
- Pooled: 34.0 erlangs at a volume-weighted handle time of 306 s needs 40 agents at 85.0% occupancy.
- Why it saves anything: agents above the workload scale with its square root. Separate queues buy that slack 4 times over, which predicts a saving of about 5.6 agents against the 9 found exactly. It is why the saving shrinks as queues grow: a big queue already pools with itself.
- Saving: 9 agents, 18.4% of the separate requirement, for the same service level in every queue.
Doing this for every interval of the week? Pebble WFM computes the requirement from your forecast and builds the roster. Free month, no card needed.
How the pooling benefit is calculated
Each queue runs Erlang C on its own: its contacts and handle time give its erlangs, and the smallest agent count meeting the target is found. Summing those is the cost of keeping the queues separate.
The pool is the same contacts as one queue, with a handle time weighted by volume. Erlang C on the pool needs fewer agents than the sum, because random peaks in one queue land in the slack of another. The saving is largest when the queues are small and similar, and it shrinks as queues grow, because a large queue already pools with itself.
The calculation assumes every agent can take every contact. Real multi-skilling is partial: some agents take two queues, and which queues they are joined to matters as much as how many people are trained. No formula covers that, so the saving here is the ceiling that perfect skilling would reach. The cross-training simulator on this site works out how much of that ceiling a real skill design reaches.
Frequently asked questions
- Why does pooling save agents?
- Slack. A queue needs agents above its workload to keep waits short, and the smaller the queue the larger that slack is as a share. Four queues of ten erlangs each need 56 agents in total; one queue of forty needs 46. The ten agents were all absorbing peaks that, pooled, cancel each other out.
- Does pooling hurt service level in any queue?
- Not in the model, which staffs the pool to the same target. In practice a queue with a much longer handle time can crowd out short-handle queues unless routing gives them priority, which is why blended queues need priority rules as well as skills.
- What about languages or regulated skills that cannot be pooled?
- Then they are separate queues, and the calculator tells you what that separation costs. That cost is the business case for cross-training, and it is usually larger than people expect for small language queues.
Embed this calculator on your site
Paste this where you want the calculator. It stays free and ad-free, updates when we improve it, and the line under it credits the source.
Stop doing this one interval at a time
Pebble WFM forecasts your demand, computes the staffing requirement for every interval, builds the roster and publishes it, with self-service for agents and a copilot that can do what a planner can. Explore a sample organisation on day one.