Why the clock measuring your wait starts later than you think

Measured waits and experienced waits are different quantities

Organisations that publish waiting times are generally telling the truth, and people who insist the published figure is nothing like their experience are also generally telling the truth. Both can hold, because the two are measuring different intervals.

Your wait begins when you decide you need something. The measured wait begins at a defined event in a system — a ticket issued, a call answered by the routing menu, a case allocated to a team, a form indexed. Everything before that defined event is invisible to the measurement, and it is often the larger part of the delay.

What counts as the start is a design decision

Choosing the start point is not arbitrary and it is not neutral either. It has to be an event the system can observe, which rules out most of the things a customer would nominate. Nobody can measure the moment you walked through the door unless something records your arrival, so arrival is recorded when you take a ticket, and time spent finding the ticket machine belongs to nobody.

The same is true on the telephone. A call is typically counted as answered when it reaches the system, not when it reaches a person, and time spent in a menu is a separate quantity from time spent in a queue. That is a defensible way to instrument a phone system. It also means an organisation can report answering calls quickly while callers spend a long time before speaking to anybody, and both statements can be entirely accurate.

Stopping the clock is the other half

End points are chosen with the same constraint, and they produce the same asymmetry. A case may be marked as handled when a first response is sent rather than when the matter is resolved. A queue position may count as served when you reach the counter rather than when you leave it.

This is where the familiar experience of the case that is closed but not finished comes from. Being told your matter has been dealt with while you are quite sure it has not usually means a defined end event occurred: a letter generated, a status changed, an item moved to a different team. The status is accurate about the thing it measures, and that thing is not what you meant.

What gets measured shapes what gets done

Any measurement applied to a queue starts influencing the queue, and this happens without anyone deciding to game it. If the target is time to first response, first responses get faster, because that is the number people can see improving. If the target is cases closed, cases get closed, sometimes by being reopened later under a fresh reference.

This is not usually cynicism. It is what happens when a team is given a single visible number and a great deal of invisible work, and it is one reason a service can improve on every published measure while feeling worse to use. The honest version of a target set is always several numbers that pull against each other, and several numbers are much harder to put on a poster.

Why nobody will tell you the total

End-to-end time is the figure everyone actually wants and almost nobody publishes, because it is genuinely hard to produce. It spans several systems, each with its own reference and its own clock, and the joins between them are exactly the places where items sit unmeasured. Assembling a true total means reconciling records that were never designed to be reconciled.

So organisations publish stage times, which are measurable, and the stage times sum to less than the experience because the gaps between stages are in nobody’s figure. That gap is not concealed so much as unowned, which is a distinction worth making and not much comfort while you are sitting in it.

Asking a question the system can answer

Given all that, the useful question is never how long this will take. It is which stage the item is at now, what event moves it to the next stage, and who owns it in the meantime. Those are things a system genuinely knows, and the person you are speaking to can usually read them off a screen.

The answers also tend to be more informative than a duration would be. An item waiting for allocation and an item allocated but not yet worked are in the same published bucket and in completely different situations, and only one of them is likely to move because somebody asked.