Why Do Queues Form? Planning Capacity With Data

When a queue appears at a bank, a clinic or a public service desk, the first reaction is usually "poor management". In reality a queue is rarely the result of neglect: it is the predictable meeting point of two curves, incoming demand and service capacity. This article breaks a queue down into three components, shows why utilisation does not behave linearly, and covers which data to use when planning capacity.

A queue is not a failure, it is the result of a balance

Eliminating queues is not an achievable goal. No waiting at all means capacity exceeds demand at every moment, which in turn means most resources sit idle. The real goal is to manage the tail of the queue: not the average experience, but the worst ones.

That distinction drives management decisions directly. "Average wait is 4 minutes" is reassuring, but if a small share of customers wait 25 minutes, the complaints come from that minority. A capacity plan should be built on the tail of the distribution, not on the average.

Three sources: demand, capacity and variability

Every queue arises from the interaction of three components:

1. Demand. How many people arrive within an hour. What matters is not only the total but how arrivals are distributed over time.

1. Capacity. How many transactions can be completed within an hour. This is the number of counters multiplied by the speed per counter.

1. Variability. The irregularity of both arrivals and service times. As variability grows, the queue lengthens even with the same average demand and capacity.

The first two components are easy to measure, which is why they dominate the discussion. The third is usually overlooked, yet it is often what makes a queue grow the most.

Why is utilisation not linear?

Utilisation is incoming demand divided by capacity. Intuition suggests that as utilisation rises, waiting should rise in step. The actual behaviour is not linear but hyperbolic.

In the simple single-server queue model, the average number of people in the system is ρ / (1 - ρ), where ρ is utilisation. That expression produces the following result: at 80% utilisation there are on average 4 people in the system; at 90% utilisation the number rises to 9. Capacity was increased by only 12.5%, yet the queue grew by more than double.

The practical meaning is this: high utilisation is not efficiency, it is fragility. Pushing utilisation to 95% looks efficient on paper, but at that point a small demand increase or a single slow transaction will blow the queue up. A capacity plan requires deliberately holding target utilisation somewhat below the maximum.

Peak hour: what the average hides

Average daily arrivals are a misleading basis for capacity planning. Demand during the day is not a straight line; there are concentration points such as lunch, end of business or school dismissal.

A service point staffed to the average is idle for most of the day and short-staffed at peak. Planning should be based on peak-hour arrival rate rather than the average. If the peak is not a full hour, the busiest 15 or 30 minute slice can be used instead; what matters is that the chosen unit is defined consistently.

Pooled and separate queues

When there are several counters for the same service, two arrangements are possible: each counter with its own queue, or a single shared queue for all customers.

• A pooled queue reduces the time counters sit idle; a customer waiting behind a slow counter is directed to a counter that frees up.
• Separate queues make sense when the services differ; each counter is faster within its own specialisation.
• The deciding criterion is the similarity of service times: when times are close, pooling pays off; when they differ, separate queues are more accurate.

Pooling also improves perceived fairness: the customer does not experience the feeling of "I picked the wrong queue".

Reducing service-time variability

Adding capacity is expensive; reducing variability is usually cheap. Why does service time vary?

The most common reason is something missing at the start of the transaction: the customer did not know which document to bring, the form is incomplete, or they were sent to the wrong desk. Such cases both lengthen that transaction and grow the queue behind it.

The first step in process improvement is therefore usually information: clearly listing the required documents before the visit, letting the form be completed while waiting, and redirecting a customer sent to the wrong desk early. These measures do not increase service speed, but they make the duration predictable and reduce variability.

The order of capacity interventions

A queue reduction programme delivers more with fewer resources if it follows an order:

1. Reduce variability. Remove document and form uncertainty; bring service times closer together.

1. Smooth demand. Spread the concentration over time using appointments, staggered calling or communication.

1. Add capacity at the bottleneck. Strengthen not every counter, but the point that determines the queue.

1. Manage perception last. Make the remaining wait more tolerable through information and visible progress.

The logic of the order is this: the first two steps genuinely lower the measured duration, the third step is expensive, and the fourth only multiplies the effect. Perception work does not substitute for a wait that has not been shortened.

Which data should you collect?

A capacity plan is only as good as the data behind it. At minimum, four records are needed:

• Arrival time. The moment a ticket is taken or a customer joins the queue; for hourly and 15-minute distributions.
• Completion time. For the service-time distribution and the rate per counter.
• Abandonment. The number of customers who leave the queue; the most direct indicator of insufficient capacity.
• Queue length. The number of people waiting, sampled at intervals through the day; to verify the calculations above.

Read together, these four records move the capacity discussion out of guesswork and onto measurement.

How do you calculate the capacity you need?

A simple calculation makes the plan concrete. Suppose 180 customers arrive in the peak hour and target utilisation is 70%. The total service rate required is demand divided by utilisation: 180 / 0.70 ≈ 257 transactions per hour.

Assume one counter completes 40 transactions per hour. The number of counters required is 257 / 40 ≈ 6.4, that is 7 counters. Opening six would push utilisation to 75% and bring the hyperbolic relationship above into play.

This calculation is deliberately simplified: in real systems arrivals and service times are random and there is more than one service type. Its value is still that it moves the discussion away from "a bit more staff" and ties it to a measurable target. The assumptions are written down explicitly and updated with measurement.

How often should the plan be updated?

A capacity plan is not a document written once and filed away; the demand curve changes with season and campaign.

• Monthly: the trend in arrival and abandonment data. A slow shift becomes visible early.
• Seasonally: holidays, term starts and campaign periods must be handled separately; a yearly average hides them.
• After every change: when capacity or process changes, the effect must be measured; otherwise the plan reverts to an assumption.

A capacity decision taken without measurement leads to the same argument being repeated the following year.

Frequently Asked Questions

Can queues be eliminated entirely?

No, and that should not be the goal. No waiting at all means capacity exceeds demand at every moment, which means most resources sit idle. The realistic goal is not to zero the average but to shorten the tail of the distribution: to reduce the wait of the worst-off customer.

How many counters should we open, based on average arrivals?

The average is a misleading basis. A service point planned to the daily average is idle for most of the day and short at peak. The calculation should use peak-hour arrival rate and target utilisation, because waiting grows hyperbolically rather than linearly as utilisation rises.

Is a pooled queue always better?

Not always. When service times are close to each other, pooling pays off because it reduces counter idle time. When service types differ substantially, separate queues provide specialisation and faster results. The decision should be made by looking at the similarity of the service-time distributions.

Does an appointment system solve the queue?

Appointments spread demand over time and reduce peak concentration, but they introduce a new source of variability: no-shows and late arrivals. Appointments therefore complement a capacity plan rather than replacing it. How scheduled and walk-in flows share capacity must be defined separately.

Conclusion

A queue is born where demand meets capacity, and its size is set by variability. That is why two wrong answers are given to queue problems: "more staff" and "no queue at all".

The right approach has three steps: accept that utilisation is not linear and deliberately cap target utilisation; plan capacity against peak demand rather than the average; and reduce process variability before moving to the most expensive step. For the measurement and perception sides, see our separate articles: measuring waiting time and wait perception.