Running hot: why an 80%-full clinic waits, and a 95%-full one drowns
1. Before you start
Utilization is how full a resource is: the rate work arrives divided by the rate the resource can clear it. If patients arrive for a scanner at 4 an hour and the scanner can finish 5 an hour, utilization is 4 ÷ 5 = 0.8, or 80%. It sounds like “20% to spare, plenty of room.” The whole point of this course is that it is not.
The number that decides how long people wait is not utilization itself but how close it sits to 100%. A tiny worked example: at 80% full, the standard queueing intuition says a job waits about 0.8 ÷ (1 − 0.8) = 4 service-times before it starts. At 95% full it waits 0.95 ÷ (1 − 0.95) = 19. Utilization rose by 15 points; the wait grew almost five-fold. That non-linear jump is the concept.
Three honest statements before you start:
- This is a Decide course. You read a situation, learn the idea, and make a call. You do not write or run any code.
- The clinics below, Meridian Imaging and Harborview Urgent Care, are composite — invented from ordinary operations figures so the arithmetic is clean. No number is a claim about any real provider.
- This is not a certification. It proves, to you, that you can defend a capacity-and-wait call.
This is an operations lesson about queues and capacity — how full to run a line — not medical advice. Every scenario is about wait time and throughput, never about clinical care.
2. The Situation
Meridian Imaging runs one outpatient scanner. Referrals are climbing, and the operations lead wants to book it closer to full: “we’re only at 80% — push it to 95% and we squeeze far more scans out of the same machine.” The clinic manager has started hearing that patients now wait hours, and cannot say why a small booking change would do that.
You have to make the call on how hard to run the scanner. The trap is that utilization looks like money left on the table, while the wait it creates is invisible on the booking sheet until it suddenly is not — and which side wins turns on a single relationship neither of them has written down.
3. What you’ll be able to do
After this course you will be able to:
- Compute utilization as arrival rate ÷ capacity, and read it as “how full the server is.”
- Use the ρ ÷ (1 − ρ) relationship to say how the expected wait grows as load rises — and explain why 95% is not “a little worse” than 80% but several times worse.
- Decide when a clinic or line has too little slack, and name the utilization at which the wait crosses an acceptable line.
- Refuse the “we’re only at 90%, push to 98% for efficiency” argument, and say in numbers what it costs.
4. Prerequisites & time box
Prerequisites: arithmetic and division. Helpful but not required: the idea of an average rate (things per hour). No spreadsheet, no operations background, no calculus — the one formula is a single division. This is a read-and-decide course in the browser; there is no code setup.
Time box: about 20 minutes of reading (measured), plus your own thinking time on the call. That is under the 25-minute cap for a concept course.
Difficulty: 5 / 8 — a manager-level decision: several factors move at once and the naive reading points the wrong way, so you have to reason past it.
Free-tier honesty: no signup, no paid tools, requires_gpu: false.
5. The case & where the numbers come from
Meridian Imaging is a composite outpatient clinic: a single-scanner operation built from ordinary, realistic figures a small imaging center would recognise, chosen for clean arithmetic and not drawn from or claimed about any real provider. The definitions and the formulas — utilization, the single-server queue, the ρ ÷ (1 − ρ) wait relationship — are standard queueing theory and cited in section 11. Every figure below is an in-course assumption; every later number is computed from these.
| Item | Figure |
|---|---|
| Scanner capacity (service rate) | 5 patients / hour (one every 12 minutes) |
| Normal arrivals (arrival rate) | 4 patients / hour |
| Proposed “efficient” arrivals | 4.75 patients / hour |
| Acceptable queue wait target | 60 minutes |
A note on honesty about the model: a real clinic has scheduled slots, no-shows, variable scan lengths, and more than one queue. We use the single-server M/M/1 intuition — the simplest standard queue — because it captures the one thing that matters here: the wait rises as ρ ÷ (1 − ρ). Treat the minute figures as approximate, directional teaching numbers, not an exact prediction for any real scanner.
6. The Concepts
Utilization
Utilization (written ρ, “rho”) is the arrival rate divided by the service rate — how full the server is. At Meridian: patients arrive at 4 per hour, and the scanner can finish 5 per hour, so ρ = 4 ÷ 5 = 0.8. Eighty percent of the scanner’s time is busy; 20% is idle. The operations lead reads that 20% as waste. Hold that thought — the idle time is doing work you cannot see.
Two rules keep utilization honest. First, ρ must be below 1 for a stable queue: if arrivals match or beat capacity (ρ ≥ 1), the line grows without limit and the “wait” is not a number, it is a backlog that never clears. Second, ρ is a ratio of rates, not a headcount — “80% full” is about flow through time, not how many chairs are occupied right now.
Why the wait explodes near full capacity
Here is the relationship the booking sheet hides. For a single-server queue, the expected time a patient spends waiting before their scan starts is, in units of one service-time:
wait factor = ρ ÷ (1 − ρ)
The (1 − ρ) on the bottom is the idle fraction — the slack. As ρ climbs toward 1, that denominator shrinks toward zero, and dividing by a number near zero sends the wait toward infinity. It is not linear. Walk it up:
| Utilization ρ | Idle (1 − ρ) | Wait factor ρ ÷ (1 − ρ) | Queue wait at 12-min service |
|---|---|---|---|
| 0.50 | 0.50 | 1.0 | 12 min |
| 0.70 | 0.30 | 2.3 | 28 min |
| 0.80 | 0.20 | 4.0 | 48 min |
| 0.90 | 0.10 | 9.0 | 108 min |
| 0.95 | 0.05 | 19.0 | 228 min |
| 0.98 | 0.02 | 49.0 | 588 min |
At Meridian’s normal 0.8, the wait factor is 0.8 ÷ 0.2 = 4 — about 4 × 12 = 48 minutes, inside the 60-minute target. Push arrivals to 4.75 per hour and ρ = 4.75 ÷ 5 = 0.95; the factor is 0.95 ÷ 0.05 = 19, about 19 × 12 = 228 minutes — nearly four hours. The operations lead added 15 points of utilization and multiplied the wait by almost five. That is why “we’re only at 80%, push to 95%” is the exact trap: the last few points of utilization are the most expensive ones you will ever buy.
(An interactive calculator sits here — enter your own arrival rate, capacity, and wait target, and watch the decision flip from “load is fine” to “add capacity” as you push utilization up.)
Why some slack is efficient
The counter-intuitive lesson: that idle 20% is not waste — it is what keeps the wait sane. The slack absorbs the ordinary bunching of arrivals (three patients showing up in ten minutes) so the queue drains between bursts. Drive the slack toward zero and there is nothing left to absorb a burst, so it piles into a queue that takes hours to clear. A scanner run at 80% delivers scans in under an hour; the same scanner run at 98% delivers the same number of scans but makes people wait most of a day for them.
So the efficient operating point is not the fullest one. Above roughly 85-90% for a single server, each extra point of utilization buys a little more throughput and a lot more wait — a trade that is almost always a loss once patients (or callers, or trucks) can leave, complain, or clog the waiting room. The right call is usually to hold deliberate slack, and to add capacity before ρ creeps into the 90s, not after the waits arrive. “Some idle time is the price of short waits” is the sentence to take into the room.
7. Your Call
You have seen how utilization and the ρ ÷ (1 − ρ) relationship decide Meridian’s scanner call. Now a different one lands on your desk.
Harborview Urgent Care is a walk-in clinic — a different company and a different setting from Meridian’s imaging center. One nurse practitioner sees walk-ins, and can clear 3 patients per hour (about 20 minutes each). Walk-ins currently arrive at 2.7 per hour. The clinic director, chasing a productivity target, wants to route more walk-ins to that one provider to run “closer to 100% — we’re only at 90%, let’s get the efficiency.” Your job is to decide how hard to load the provider, and whether adding a second provider is worth it — under the constraint that the budget allows at most one extra hire.
How this differs from the taught case (the transfer): this is a different company and setting (a walk-in clinic, not the scanner), the figures are different so the arithmetic must be redone, there is an added constraint (a hiring cap of one), and it is a different kind of decision — you are finding the load ceiling and a go/no-go on capacity, not judging one fixed booking rate. The core concept is the same: utilization ρ and the ρ ÷ (1 − ρ) wait relationship decide the call.
8. Self-check
Before you write the memo, make sure you can say each of these in one line:
- Why is “we’re only at 90%, push to 98%” a much bigger move than the 8 points suggest?
- What single quantity in ρ ÷ (1 − ρ) is doing the damage as utilization rises — and why?
- How do you turn a wait-time target into a utilization ceiling, and then into a cap on arrivals?
If any is fuzzy, reread section 6 — utilization, the ρ ÷ (1 − ρ) wait relationship, and why slack is efficient are the whole course.
9. Stretch
Push the decision further on your own:
- Back at Meridian: solve for the exact utilization at which the queue wait crosses the 60-minute target, given the 12-minute service time. (Set ρ ÷ (1 − ρ) = 5 and solve for ρ; then back out the arrival rate.)
- At Harborview, arrivals are not steady — mornings spike to 3.5 per hour, afternoons drop to 1.8. If you average them to 2.65 and plan for that, why will the real waits be worse than your average-based plan predicts? (Hint: the curve is convex — the wait at the peak is not offset by the wait at the trough.)
- The genuinely harder one: two providers each at ρ = 0.9 give shorter waits than one provider at ρ = 0.9, even though both run at 90%. Why does pooling servers cut the wait, and what does that say about splitting one queue into two versus keeping a shared line?
10. Ship it — your decision memo
Write a one-page memo to Harborview’s director. State the call (do not push the single provider toward 98%; at ρ = 0.9 the wait factor is already 9, roughly 180 minutes, and 0.98 sends it to 49). Show the two-line arithmetic (ρ = 2.7 ÷ 3 = 0.9; wait factor 0.9 ÷ 0.1 = 9, versus 0.98 ÷ 0.02 = 49). Name the constraint (one extra hire allowed) and your recommendation — add the second provider to bring each server near ρ ≈ 0.45, or hold arrivals to about 2 per hour to meet a 40-minute target on one provider. Name what you rejected (“higher utilization is always more efficient”) and why. Name the one thing that would change your mind (arrivals so low that a single provider already sits well below the steep part of the curve). Keep it to a single page a director grasps in two minutes. This memo is your own argued claim — not a credential.
11. Sources
Meridian Imaging and Harborview Urgent Care, and every figure attached to them, are composite — constructed from ordinary operations figures for clean teaching arithmetic, not drawn from or claimed about any real provider. The queueing definitions and the ρ ÷ (1 − ρ) relationship used to reason about them are standard; references below.
| Concept / claim | Source (publisher) | URL | Accessed |
|---|---|---|---|
| Utilization ρ = arrival rate ÷ service rate; ρ < 1 for a stable queue | Wikipedia — M/M/1 queue | https://en.wikipedia.org/wiki/M/M/1_queue | 2026-07-20 |
| Expected queue wait scales with ρ ÷ (1 − ρ) (single-server intuition) | Wikipedia — M/M/1 queue | https://en.wikipedia.org/wiki/M/M/1_queue | 2026-07-20 |
| Queueing theory: waits, arrival and service rates, single-server model | Wikipedia — Queueing theory | https://en.wikipedia.org/wiki/Queueing_theory | 2026-07-20 |
Next up
Finished this call? Continue the Operations & Process track:
Is the process in control? Common-cause noise vs a real signal → · Browse all courses