LatentEval

TOOL | Propagation & containment

How many reviewers your human gate needs to hold the wait target

Enter the reviewed share, handling time and shift size. The calculator returns the wait, the backlog, the service level against your target, and the minimum staffing to hold it.

Enter your reviewed share from the review threshold optimizer, a handling time and a reviewer count. The page returns whether the queue holds. The human gate exists to catch confident wrong answers that pass every structural check. Of the five production reliability levers, it scales worst: its cost is throughput and latency. The threshold optimizer picks the cutoff. This page sizes the people behind it.

What reaches the gate

The population the gate sees before the reviewed share is applied. Change the period if you count by the hour.

Check this value.

Everything downstream is computed per hour; this converts once.

Check this value.

The share of items a human has to look at. This is the complement of coverage from the review threshold optimizer: if that page automates 82%, enter 18%. It comes from the threshold decision, not from a guess.

Check this value.

When you have a measured sample, enter the count and the page derives the rate with an interval.

Check this value.

The numerator of the measured reviewed share.

Check this value.

The denominator. A larger sample tightens the staffing range.

Check this value.

The shift

Average minutes one reviewer spends on one item, start to finish. Include reading, checking and recording the decision, not the wait before the reviewer starts.

Check this value.

Concurrent reviewers right now, not headcount on the payroll. A person on two shifts is one reviewer at a time.

Check this value.

Set to 24 for round-the-clock cover. Below 24 the page also reports what piles up overnight.

Check this value.

The target, and what a reviewer-hour costs

The maximum time an item should spend waiting before a reviewer picks it up. This is not total turnaround; handling time is added separately.

Check this value.

The share of items that must be picked up within the wait target. 80% and 90% are common service-level targets. Enter whatever your team uses.

Check this value.

Optional. Leave blank to suppress every money figure. Use whatever currency unit you used on the review threshold optimizer. The cost per reviewed item that appears here is the number to type back into that page's "Review cost per item" field.

Check this value.

Structural backlog

+120/day

240 of 360 items clear during the 8-hour shift. The queue grows by 120 items per day.

Staffing sweep from 2 reviewers.

ReviewersUtilizationWaits at allAverage waitService levelClears in windowDaily reviewer cost
2 75.0% 64.3% 7.7 min 94.7% does not clear not priced
3 50.0% 23.7% 0.9 min >99.9% does not clear not priced
4 37.5% 7.5% 0.2 min >99.9% does not clear not priced
5 30.0% 2.0% <0.1 min >99.9% 6 h 51 min not priced
6 25.0% 0.5% <0.1 min >99.9% 5 h 20 min not priced
7 21.4% 0.1% <0.1 min >99.9% 4 h 22 min not priced
8 18.8% <0.1% <0.1 min 100.0% 3 h 42 min not priced
Offered load (erlangs) Reviewer-hours of work arriving per hour. When this equals or exceeds the reviewer count, the queue is unstable.
1.5
Opening wait The wait the first item of the day sees when a backlog has accumulated overnight. The steady-state average understates this figure.
8 h
Reviewer-hours per day Total reviewer-hours of work arriving in 24 hours, independent of how the shift is staffed.
36
Average wait Time an item spends in the queue before a reviewer picks it up, not total turnaround.
–
Average time to decision Wait plus handling time: the total time the agent's task stalls at the gate.
–
Probability of waiting Share of items that wait at all before a reviewer is free.
–
Service level Share of items picked up within the wait target.
–
Minimum reviewers to hold the target The minimum is the smallest staffing that both clears the day's work inside the window and holds the wait target.
5
Staffing gap How many reviewers the entered shift is above or below the minimum. Negative means the shift has room.
+2
Reviewer utilization Share of a reviewer's time spent on items, once the queue has reached steady state. At or above 100% the queue grows without bound.
–
Average queue length Mean number of items waiting, not a maximum.
–
Overnight backlog Items waiting when the shift opens, from arrivals during unstaffed hours.
240
Time to clear the overnight backlog Hours from shift open to an empty queue, with new arrivals still coming in.
16 hours
Daily staffing cost Reviewers times coverage hours times the entered hourly rate.
–
Cost per reviewed item Daily staffing cost divided by the items the shift reviews that day. This is the number to type into the review threshold optimizer's "Review cost per item" field.
–
Reviewed share interval 95% Wilson interval on the measured reviewed share.
–
Staffing range Minimum reviewers at the low and high bound of the reviewed share interval.
–
Wait range Average wait at the low and high bound of the reviewed share interval, at the entered reviewer count.
–

The overnight figures model the backlog that builds while the queue is unstaffed.

The prefilled figures are a worked illustration. Replace every field with your own numbers.

Export

average wait = C(c, a) · h / (c − a)How?

How this is calculated

The page models the human queue as an M/M/c system: Poisson arrivals, exponential handling times, c interchangeable reviewers, and an unlimited queue with no abandonment. Every figure below follows from that model and the inputs you enter.

Arrivals. The volume you enter is converted to an hourly rate, lambda, and spread across all 24 hours regardless of the coverage window. Multiplying by the reviewed share gives the arrival rate into the human queue. This rate governs both the in-window steady state and the overnight pile-up.

Offered load. The arrival rate times the handling time gives the offered load in erlangs, the reviewer-hours of work arriving per hour. Dividing by the reviewer count gives the utilization. When utilization reaches or exceeds 100%, the queue is unstable and grows without bound; every wait and queue-length figure below requires utilization strictly below 100%.

The Erlang C probability. The probability that an arriving item waits at all is Erlang C, computed through an Erlang B recursion: B(0, a) = 1, then B(k, a) = a · B(k-1, a) / (k + a · B(k-1, a)) for each server from 1 to c. The recursion is exact in floating point and stable where the closed-form factorial overflows above roughly 170 servers. Erlang C itself is B(c, a) / (1 - rho · (1 - B(c, a))), where rho is the utilization.

Wait, queue length and service level. Average wait is C(c, a) · h / (c - a), where h is the handling time in hours. Average time to decision adds one handling time. Average queue length follows from Little's law: lambda times the average wait. The service level, the share of items picked up within the wait target, is 1 - C(c, a) · exp(-(c - a) · t / h), where t is the target expressed in the same unit as h.

Minimum staffing. The page scans reviewer counts upward from the first stable value, floor(a) + 1, until the service level meets the target. Service level is monotone increasing in the reviewer count for a fixed offered load, so the first hit is the service-level count. The scan caps at 1,000 reviewers; past that the target is reported as unreachable at these inputs. A second condition applies when the coverage window is shorter than 24 hours: the smallest whole number of reviewers whose shift clears the day's reviewed items. The minimum is the larger of the two.

The overnight pile-up. When the coverage window is shorter than 24 hours, items still arrive during unstaffed hours and accumulate. The backlog when the shift opens is the arrival rate times the unstaffed hours. Drain time, the hours from shift open to an empty queue with new arrivals still coming in, is the backlog divided by the surplus service capacity. If drain time exceeds the coverage window, the shift ends with a bigger queue than it started: a structural backlog that does not resolve without wider coverage or more reviewers.

Intervals on the reviewed share. When you enter a measured sample rather than a typed rate, the page puts a 95% Wilson interval on the rate and re-runs the whole model at both bounds. The staffing answer becomes a range, not a point. A larger sample tightens the range; a small sample may not pin the headcount at all, and the page says so.

What the model assumes. Arrivals are Poisson (no bursts or batches). Handling times follow an exponential distribution (some items are quick, some are slow, with no fixed duration). Reviewers are interchangeable and always available during the coverage window. No reviewer gives up and no item is withdrawn. The queue is unlimited. Bursty arrivals make the real wait longer than the figure here; reviewers who batch or abandon make it shorter. The model sizes a shift. It does not schedule one.

Formula: average wait = C(c, a) · h / (c − a)

Questions

Where does the reviewed share come from?

The reviewed share is the complement of the coverage from the review threshold optimizer: if that page automates 82% of your sample, your reviewed share is 18%. If you have not run that page yet, measure the rate directly by counting how many items a human had to review over a known window and enter it as a measured sample. To put an interval on a measured rate before typing it in, use the pass-rate confidence interval calculator.

Can I use this page without the review threshold optimizer?

Yes. Type a rate directly. The page computes the same queue regardless of where the number came from. The threshold optimizer gives you a rate grounded in your own data and costs; a typed rate is a planning assumption until you measure it.

My shift is 8 hours. Does the page account for what happens overnight?

When the coverage window is less than 24 hours, items keep arriving while nobody is on shift. The page reports the overnight backlog and how long the shift takes to clear it. If the drain time exceeds the coverage window, the queue never catches up, and the page says so. Set coverage to 24 to see the numbers without the overnight block.

What is the difference between wait and time to decision?

Wait is the time an item sits in the queue before a reviewer picks it up. Time to decision adds the handling time: the total time the agent's task is stalled. The service level target applies to the wait, because handling time is the reviewer's job, not the queue's.

The page says the queue is unstable. What do I do?

The queue is unstable when work arrives faster than the shift can clear it, which happens when the offered load in erlangs equals or exceeds the reviewer count. Add reviewers until the count exceeds the load, or reduce the arrival rate by raising the confidence threshold on the review threshold optimizer so fewer items reach a human. The queue-bounding mechanism is a form of backpressure: the gate holds items until a reviewer is free, rather than dropping them.

How does this page relate to the agent action risk matrix?

The agent action risk matrix decides which actions get a human gate. This page sizes the people behind a gate that already exists. A C3 or C4 row on the matrix means a person is in the path; this page says how many people that takes.

Does the page price the delay?

No. The page computes the latency and stops. What the delay costs in risk terms depends on the action, the customer and the contract, and no formula on this site prices that. The daily staffing cost and the cost per reviewed item are reported when you enter an hourly rate, and the cost per reviewed item is the number to carry back to the review threshold optimizer.

What does the gate's wait add to the machine-side latency?

The gate's wait is one term in the whole deadline the agent's task has to meet. The machine-side half, the time each model call takes and the timeout each layer should hold, is what the latency budget calculator computes. That page's utilization is chain time over deadline, a different quantity from this page's reviewer utilization.

How does this page relate to the rate-limit backoff planner?

Both pages compute a wait. This page's wait is a person's queue: items waiting for a reviewer. The rate-limit backoff planner computes a different wait: a caller waiting for a rate limiter to open. The two waits add to the same deadline from different sides.

Sources

  1. Solution of Some Problems in the Theory of Probabilities of Significance in Automatic Telephone Exchanges (the delay formula for c servers under Poisson arrivals and exponential service)A. K. Erlang, Post Office Electrical Engineers' Journal 10, 189-197 (1917) Retrieved
  2. A Proof for the Queuing Formula: L = lambda W (the identity the average queue length is read from)J. D. C. Little, Operations Research 9(3), 383-387 (1961) Retrieved