Running at 100%

• Why loading a system full blows up the wait
• Nimbus: one support engineer, an escalation queue, a 45-minute promise
• *Presenter note:* Say the honest line — teaching material, not a certification.

The case & the plan

• One engineer resolves 6 tickets/hr; escalations arrive at 4.8/hr; promise: reply in 45 min
• Head of support: "she's only 80% busy — route more, push to 100%" (arrivals up to 5.7/hr)
• *Presenter note:* Take the vote now — push to 95, hold at 80, or hire. Record the split; don't comment.

Utilization, plainly

• rho = arrivals / capacity = 4.8 / 6 = 0.80 — how full the server is
• rho must be below 1 or the queue grows forever; it's a ratio of rates, not a headcount
• The idle 20% looks like waste — hold that thought

Why the wait explodes

• wait factor = rho / (1 - rho); the bottom is the slack
• 0.80 -> factor 4 (~40 min) · 0.90 -> 9 · 0.95 -> 19 (~190 min) · 0.98 -> 49
• *Presenter note:* 15 points of utilization, almost 5x the wait. Not linear.

Your table's call

• Find today's rho -> test the push to 95% -> find the ceiling the promise sets -> make the call
• Name what each rejected option costs; one free move before hiring
• *Presenter note:* Circulate; ask "read the wait factor at 0.8 and at 0.95 — small change?"

Slack is not waste

• The idle fraction absorbs the bunching so the queue drains between bursts
• Same engineer, same tickets: 40 min at 0.8, over 3 hours at 0.95
• Past ~85-90% each extra point buys a sliver of output and a mountain of wait

A promise is a ceiling

• 45-min promise = wait factor ~4.5 = utilization ceiling ~0.82 = ~4.9 arrivals/hr on one engineer
• Add a second engineer -> each near rho 0.48 -> waits in minutes, with slack for bursts
• *Presenter note:* Tie back to the opening vote — the "small 15 points" was the trap.

Takeaway

• The last points of utilization are the most expensive you will ever buy
• The right target holds deliberate slack — don't chase 100%
• Further reading: the utilization-vs-wait Decide course