Count arrivals and acceptable completions in the same unit and period. An email inbox and a customer-resolution queue are different systems: one customer issue may generate several emails.
Follow a simple backlog bridge
A fictional support team starts Monday with 40 unresolved requests. It receives 60 requests per day and completes 50 per day. Assume no reopened, abandoned or duplicated requests in this teaching model.
| Day | Opening backlog | Arrivals | Completions | Closing backlog |
|---|---|---|---|---|
| Monday | 40 | 60 | 50 | 50 |
| Tuesday | 50 | 60 | 50 | 60 |
| Wednesday | 60 | 60 | 50 | 70 |
The identity is opening backlog + arrivals − completions = closing backlog. At those rates, the queue grows by ten requests each day. Asking the team to reply sooner could improve a response-time metric without raising completed resolutions.
In a real system, add separate lines for reopened requests, cancellations and reclassification. Otherwise a changed definition can look like improved service.
Matching arrivals does not clear the past
Suppose the team increases acceptable completions to 60 per day. New daily work no longer adds to the backlog, but the existing 70 requests remain in this constant-rate model. To drain the backlog, completions must exceed arrivals for a period.
At 70 completions and 60 arrivals per day, ten requests are removed from the backlog daily. Clearing 70 would take seven such days if those rates hold. That is a deterministic illustration, not a prediction for a queue with changing demand or case complexity.
A queue is a clue, not a diagnosis
Work may wait because of missing data, batching, an approval schedule or a capacity limit. Inspect a sample of delayed cases. Which part of the elapsed time was useful work, and which part was waiting for a decision or resource?
The workflow mapping guide helps distinguish those paths. If investigation is the limiting stage, adding people to intake can increase the pile faster. Test that hypothesis with the bottleneck tool.
Averages can hide peaks
A team may receive 100 requests in the morning and very few later. Its daily total capacity might be adequate while customers still wait through the morning peak. Case difficulty can also vary: ten password resets are not ten complex refund investigations.
Segment the queue by arrival time and work type. Measure age as well as count, because a stable backlog can conceal a few requests that never move. Also watch quality: declaring unfinished requests complete is not a capacity improvement.
Choose a response you can test
First identify the source of delay. Then test one response: clearer intake information, less batching, a changed staffing window or more capacity at the relevant stage. Measure completed customer outcomes and the age of the queue, alongside errors and reopenings.
Before hiring, use the hiring-capacity test. If the proposal changes several things at once, write down which outcome it is intended to improve and how you will know whether it worked.
Sources and limits
ASQ's process analysis tools support mapping and measurement of work. The backlog bridge and support numbers are original HBW arithmetic. No stochastic waiting-time formula, staffing guarantee or service-level prediction is implied.