Measuring Waiting Time: Which Metrics Actually Matter?

Queue management systems are usually judged by an "average waiting time" report. That single number reassures the manager but hides the truth: behind the average sits a distribution in which a few customers waited a very long time. This article covers which metrics actually support decisions, and how to turn the data into action.

Why the average misleads

If 90 out of 100 customers waited 3 minutes and 10 waited 25 minutes, the average comes out at roughly 5 minutes. A manager looking at that number concludes there is no problem. Yet the 10 people who waited 25 minutes are the group who left dissatisfied and told others about it.

The average hides the worst part of the experience. That is why the distribution has to be read alongside it: what proportion of waits exceeded an acceptable threshold?

Waiting times follow a right-skewed distribution: most customers wait briefly and a minority waits a long time. In such a distribution the mean sits above the median (p50), and the gap between the two shows how heavy the tail is. The mean, the median and the percentiles therefore need to be read together.

Set the target as a percentile, not an average

An "average wait under 5 minutes" target renders the ten people who waited 30 minutes invisible. Set a percentile target instead, such as "90% of customers served within 10 minutes". A p90 target protects the typical experience and the tail at the same time.

Derive the threshold from your own service type rather than from an outside source: an urgent service point and a routine transaction desk cannot target the same wait. What matters is not that the number is ambitious, but that it is defined and stays fixed over time.

The metrics worth measuring

The decision-supporting metrics that can be derived from queue data are:

• Average waiting time. The interval between taking a ticket and being called. A core indicator, but not sufficient on its own.
• p90 / p95 waiting time. The time below which 90% (or 95%) of waits fall. It makes the worst experience visible.
• Average service time. The interval between the transaction starting and finishing. Looked at per counter, it shows which transactions take longest.
• Service-time variability. How widely service times scatter; this affects queue length independently of the mean.
• Queue length (instantaneous). The number of people in the waiting area. Needed for capacity planning.
• Abandonment rate. The proportion of customers who left before being served.
• Demand distribution. The demand curve by hour and day; the foundation of staffing plans.
• Counter load. How many transactions each counter handled. Exposes uneven load distribution.

Abandonment rate: the most critical and most ignored metric

The abandonment rate measures the customer who gave up waiting and left. That customer leaves without complaining: they do not fill in the survey, leave no feedback, and often never come back. So they never appear in satisfaction surveys. A customer who abandons never fills in a survey, so they stay invisible in satisfaction results; the two should be read together. We covered the metric choice on the survey side (the difference between NPS, CSAT and CES) in a separate article.

• If abandonment is low but waiting times are long: the system is congested but customers are tolerating it. Risk is accumulating.
• If abandonment is high: service capacity does not match demand. That is directly lost business.

This is why abandonment rate is a more important signal than average waiting time.

How is abandonment measured in practice?

Abandonment is the most critical metric and also the hardest to measure, because a customer who leaves leaves no trace in the system. There are three approaches, and none of them is perfect on its own:

• Tickets that were called but never served. The queue system knows this group exactly. But a significant share of them are not abandonments at all, they are no-shows: the customer missed the number, stepped outside briefly, or completed the transaction through another channel. It is still useful as an upper bound.
• Tickets issued minus transactions completed. Over a period, subtracting completed transactions from issued tickets leaves a difference made up of cancellations, duplicate tickets and abandonments. Crude, but it is a signal you can track continuously.
• Door counting. Comparing footfall at the entrance with completed transactions lets you estimate abandonment from the difference between the two counts. This is the most reliable approach, and it requires extra hardware plus a privacy assessment.

Whichever method you choose, write the definition down and do not change it between periods. Otherwise you cannot tell whether a fall in abandonment is a real improvement or simply a changed definition.

How the measurement is made

In queue management systems, measurement comes from timestamps across the ticket's lifecycle:

1. Ticket issued — the customer took a number at the kiosk.
2. Called — the number appeared on screen and was announced.
3. Service started — the customer reached the counter.
4. Service ended — the transaction was completed.

From these four timestamps, waiting time (1→3), response-to-call time (2→3) and service time (3→4) can be calculated separately. Without that separation you cannot tell which step is congested.

For example, if response-to-call time is long, the problem may not be staff but announcement and wayfinding: the customer is not hearing the number or not seeing the screen.

Two technical details in this timestamp-based measurement change the result directly. The first is how "service started" is defined: when the customer reached the counter, when the agent acknowledged the call, or when the first record was opened in the system? The three definitions produce different numbers, so the definition must stay fixed if you intend to compare periods. The second is clock consistency: if branches or devices drift apart in time, you get nonsensical negative durations, most visibly on short transactions.

Utilisation and waiting do not rise linearly

The most common capacity-planning mistake is aiming for counter utilisation close to 100%. In queueing mathematics, waiting does not grow linearly with utilisation: it accelerates. In a simple single-counter model, going from 80% to 90% utilisation more than doubles the average wait, and at 95% it grows disproportionately again.

The practical meaning is this: running staff at full capacity is not efficiency, it is fragility. An unexpected surge, one unusually long transaction or a brief absence immediately inflates the queue when there is no reserve capacity. The goal is therefore not maximum utilisation but the lowest staffing level that still holds the wait within its target.

Service-time variability and the pooled queue

Waiting time is driven not only by transaction volume but by how variable service times are. Of two branches with the same average service time, the one where transactions take similar durations produces a shorter queue. The reason is simple: a single very long transaction delays everyone behind it. Standardising transaction types, collecting paperwork in advance and routing complex work to a separate queue therefore deliver measurable improvement.

The second lever is pooling the queue. When all counters draw from one shared queue instead of each having its own, the situation where one counter sits idle while another is blocked disappears. With the same number of counters and the same staff, a pooled queue almost always delivers a shorter average wait and a lower p90. At setup time this is the choice between "a queue per service group" and "a shared queue" — and the choice should be settled by measurement, not assumption.

Little's law: a practical way to sanity-check your numbers

There is a simple way to judge whether your reported figures hold together. In queueing theory, Little's law states that the average number of people in the system equals the arrival rate multiplied by the average time spent in the system. Applied to queue management:

Average number of people in the waiting area ≈ customers arriving per hour × average waiting time in hours.

This relationship requires no distributional assumptions; it holds for any stable queue. It is useful in two ways. First, it lets you compare the reported waiting time against an independent observation to check whether the measurement is plausible. Second, if all you have is an entrance count, it lets you estimate waiting time. For example, if 120 customers arrive per hour (2 per minute) and the waiting area holds an average of 10 people, the average wait is about 5 minutes. If the report is far from that, either the definition or the count is wrong.

From data to action: the point of measuring

Producing a report is not measurement; measurement is what turns into action. Three typical uses of the data: Which system you take these measurements from is itself a selection question; we collected the criteria for choosing a queue management system in a separate article.

• Staff planning. The demand distribution shows how many counters should be open at which hours. Planning against demand rather than fixed shifts.
• Counter allocation. If counter load is uneven, the distribution of service groups across counters is redesigned.
• Measuring the effect of a change. When a new practice goes live (priority queue, appointments, an extra counter), its effect is confirmed by comparing with the previous period.

The third is the most commonly skipped: a change is made but not measured, so whether it worked is never known.

Comparing the effect of a change

When you measure the effect of a change, compare similar demand, not matching calendar periods. Monday and Saturday are not the same, and neither are the start and the end of a month; holidays and campaign periods distort the demand curve. The right comparison uses the same day type and a similar customer volume.

If you cannot control volume, normalise the metric against demand: look at wait per transaction rather than total wait. Otherwise you will read a seasonal fluctuation as an improvement, and a real improvement as a fluctuation.

A measurement plan: what, at which threshold, how often

To turn measurement into a routine, put the following in writing:

• Definitions: how waiting, service and abandonment times are defined, and that they will stay fixed.
• Thresholds: the acceptable limit for each metric, ideally expressed as a percentile.
• Owner: who follows which metric.
• Action mapping: who does what when a threshold is breached.
• Reference period: keep the baseline data you intend to compare against.

With these in place, reports get read and debate rests on data. Without them, even the best report stays in a folder.

How often should this be reported?

• Daily: only for anomalies (a spike in abandonment, a counter going offline).
• Weekly: demand distribution and staff planning.
• Monthly: trend tracking and management review.

If a report does not trigger a decision, reducing its frequency is the right move. An unread report weakens measurement discipline.

Frequently Asked Questions

Why is average waiting time not enough on its own?

Waiting times follow a right-skewed distribution: most customers wait briefly, a minority waits a very long time. The average hides that long tail. Reading a percentile such as p90 alongside the average makes the worst experience visible.

How is abandonment rate actually measured?

The system knows only the tickets that were called and did not appear; some of those are no-shows rather than abandonments. Subtracting completed transactions from issued tickets gives a crude but continuously trackable indicator. The most reliable approach is comparing an entrance count with the number of completed transactions.

How should a waiting-time target be set?

Defining the target as a percentile rather than a single average is more sound: for example, 90 percent of customers served within a given time. That target protects the typical experience and the tail at the same time. The threshold itself is set by the organisation according to its service type; what matters is that the definition stays fixed.

How can I tell whether the measured figures are consistent?

Little's law provides a simple check: the average number of people in the waiting area should be close to the arrival rate per hour multiplied by the average waiting time in hours. This relationship requires no distributional assumptions. If the reported figure is far from that calculation, either the time definition or the counting is wrong.

Conclusion

Good measurement has three layers: distribution and percentiles alongside the average, abandonment rate, and the demand curve. Read together, queue management stops being guesswork and capacity decisions rest on data.

Two practical rules hold the framework up: tie the target to a percentile rather than to an average, and test the number you measure against an independent check such as Little's law. The report then becomes a self-verifying indicator.

For measurement and reporting capabilities see Queue Management System; to find which product matches your requirement, see our product selection guide.