Latency is a trust metric

Speed gets discussed as an efficiency concern. Faster is cheaper, faster is more throughput, faster means we need fewer people.

All true, and all beside the point. The reason latency matters is psychological, and once you see it that way you measure it differently.

What waiting actually costs the customer

When a customer is waiting on you, they're carrying the request. They have to remember it exists. They have to decide whether it's time to follow up. They have to guess whether silence means progress or means they've been forgotten.

That cognitive load is the real cost of latency, and it scales nonlinearly. A two-hour wait costs almost nothing — they've forgotten they asked. A two-day wait costs a follow-up email and a small deposit of doubt. A two-week wait costs the relationship, not because two weeks is objectively unbearable but because by then they've constructed an explanation for the silence, and the explanation is never generous.

Which means the same latency has wildly different costs depending on one variable: whether they know what's happening.

The equation

A customer's tolerance for waiting is roughly:

tolerance = expectation ÷ uncertainty

Give someone a credible expectation — this takes about four days, and you'll hear from us Thursday — and four days is fine. Leave them uncertain and four days is an eternity, because they're paying attention the entire time.

This is why the status page beats the speed improvement more often than engineers expect. Cutting a process from six days to four is real work and delivers a 33% improvement in a number. Telling the customer it's a six-day process, and showing them where in the six days they are, often delivers more satisfaction for a tenth of the effort.

Both are worth doing. Only one of them is usually on the roadmap.

How to measure it properly

Three rules, learned the hard way.

Measure end to end, not per segment. Every team's individual latency can look excellent while the total is terrible, because the waiting happens at the seams. The customer experiences the total. Nobody internally is looking at it.

Measure from the customer's first ask. Not from when the ticket was created, or when it reached the right team, or when it was triaged. From the moment they asked. All the internal routing time is time they were waiting, and excluding it produces a number that flatters you and describes nobody's experience.

Watch P90 hardest. The median is the customer who had a normal experience and won't remember it. P90 is the customer who is composing a message about you right now. If you only get to publish one latency number, publish P90 — it's the one with information in it.

The gauge that's better than latency

If you can only build one thing, build time-to-first-signal: how long from a customer's request until they receive something real — a human acknowledgment, an ETA, a status change they can see.

It's usually cheap to move, often automatable, and it collapses the uncertainty term in the equation above. A customer who knows what's happening will wait a long time without resentment. A customer in the dark starts churning at hour six.

Same principle as everything else here. A visible process is tolerable at speeds an invisible one is not. The pipe doesn't have to be fast if it's clear — but if it's dark, it had better be instant, because uncertainty is the thing people can't stand.