Key takeaway
A queue can grow sharply before utilisation reaches 100%. State the arrival and service assumptions, measure the same case population and keep average waiting time separate from a deadline.
The reviewer is faster than arrivals, yet cases wait
A team reports that its reviewer can finish more cases per day than arrive on average. It then promises that every new data-package review will start immediately. The capacity comparison does not support that promise: uneven arrivals and service durations can create a queue even when average service capacity exceeds average demand.
MIT’s basic queueing notes describe an M/M/1 model with Poisson arrivals, independent exponential service times and one server. Its steady-state formulas require arrival rate below service rate. Those are substantive model assumptions, not properties established by counting staff or looking at a weekly average.
Columbia’s notes explain Little’s Law: with the relevant finite long-run averages, average number in the system equals arrival rate multiplied by average time in the system. Little’s Law has broader conditions than the M/M/1 waiting-time formula. Do not claim it independently proves that an operational queue has Poisson arrivals or exponential service.
A two-scenario model with the same reviewer
Hypothetical example: model one continuously available reviewer with mean service rate μ = 8 cases per model day. Mean service time is 1/8 day. A model day is a continuous time unit here; it does not represent a staffed eight-hour workday with overnight closures.
In the first scenario, assume arrival rate λ = 6 cases per day. Utilisation is λ/μ = 0.75. The M/M/1 mean time in the system is W = 1/(μ − λ) = 0.5 day. Subtract the mean service time to obtain mean queue waiting time 0.375 day. Little’s Law then gives an average three cases in the system.
Raise arrivals to 7.5 per day while preserving the same service assumptions. Mean time in the system becomes two days and mean queue wait 1.875 days. The modelled average number in the system rises to fifteen. The service time has not changed; total system time has quadrupled as spare capacity narrows.
| Model quantity | 6 arrivals/day | 7.5 arrivals/day |
|---|---|---|
| Utilisation, λ/μ | 0.75 | 0.9375 |
| Mean service time, 1/μ | 0.125 day | 0.125 day |
| Mean time in system, 1/(μ−λ) | 0.5 day | 2 days |
| Mean queue wait, W−1/μ | 0.375 day | 1.875 days |
| Average cases in system, λW | 3 | 15 |
Define the case and the clock before estimating
For a real review queue, choose an entry event and an exit event that describe the same population. A new submission, a resubmitted correction and a request waiting on its owner are different operational states. Decide how each enters the calculation and keep that decision stable.
A useful event record might contain case identity, ready-for-review time, service-start time, service-completion time and any return-to-owner transition. Preserve the observation window and the treatment of open cases. Counting completed fast cases alone can understate the waiting experience of work still unfinished.
Inspect whether arrivals cluster after batch imports, whether service depends on package complexity and whether staff are actually available during the chosen clock. A queue with working-hour closures, priority classes, multiple reviewers or correlated service durations may need another model. Do not apply the displayed formula merely because its inputs are easy to obtain.
Use the result to change a process, not invent a deadline
The example exposes a capacity risk worth measuring. It does not predict an actual VOID queue, establish a service percentile or promise a two-day turnaround. An average includes shorter and longer cases; a service-level commitment needs its own definition and evidence.
Before accepting more simultaneous work, compare measured arrival patterns with actual staffed capacity, correction loops and any intake limit. Consider whether staggering batches or separating incomplete submissions changes the process. Treat those as interventions to evaluate, not benefits proven by this hypothetical calculation.
Use readiness to collect a coherent package before the queue begins and introduction brief to identify the responsible review owner. A named reviewer and a capacity spreadsheet remain distinct from a measured queue model and an agreed response commitment.