Stop guessing ETAs: how to make wait times believable

If you have ever told customers “about 5 minutes” and watched it turn into 20, you know the uncomfortable truth:

The fastest way to lose trust is to look precise and be wrong.

This is why wait-time predictions are not just a data problem, but also an operations capability.

Done well, an ETA reduces anxiety and abandonment. Done poorly, it creates angry customers, repeat contacts (“Any update?”), and a brand tax you keep paying long after the queue is gone. Even worse: research shows that 40% of customers will abandon or go to a competitor if they perceive wait to be too long—and among those who leave early, 61% have actually begun waiting, meaning they have already committed time and emotional energy.

In our article on the psychology of control, we argued that customers don’t hate waiting—they hate uncertainty. This post turns that insight into an executive playbook: how to make wait times believable by building trust instead of chasing forecast accuracy.

Table of contents

• 1. The ETA paradox: accuracy is not enough
• 2. Why ETAs fail (even when your math is “right”)
  • 2.1 Point estimates create false certainty
  • 2.2 Volatile updates destroy credibility
  • 2.3 Your queue is not a spreadsheet: the hidden cost of variability
• 3. The business cost of unpredictable waits
• 4. The goal: believable ETAs, not perfect ETAs
• 5. A simple example: the naive ETA vs the believable ETA
• 6. Five rules for communicating wait times customers trust
• 7. What to measure: trust is observable
  • 7.1 Core credibility metrics
  • 7.2 Customer behavior metrics (the “truth serum”)
• 8. A pragmatic rollout plan
  • Phase 1 (days to weeks): make the UI honest
  • Phase 2 (weeks): segment and stabilize
  • Phase 3 (months): make it variability-aware
• Conclusion

1. The ETA paradox: accuracy is not enough

Most organizations treat ETAs like a forecasting exercise: build a model, show a number, move on.

But this misses the deeper insight. Customers don’t judge ETAs primarily on accuracy—they judge them on trust.

Specifically, customers evaluate ETAs on three dimensions—none of which is “how close did you get to the actual wait?”:

1. Calibration: When you say “10–15 minutes”, does reality usually fall inside that band? Do customers experience you as reliable?
2. Stability: Does the ETA evolve smoothly, or does it whipsaw every refresh? Do customers experience you as in control?
3. Fairness: Do similar customers experience similar waits, and are exceptions explained? Do customers experience you as just?

A queue can be statistically accurate on average and still fail all three. This is the ETA paradox: you can have high forecast accuracy and low customer trust simultaneously.

This point is critical, so let’s unpack what it means with an example.

Imagine your system shows a single ETA of 10 minutes. Over the course of a day, the average customer really does wait about 10 minutes, so the model looks “accurate” in aggregate. Unfortunately individual customers do not experience the average—they experience their own wait.

That is where trust breaks:

• Calibration failure: half your customers wait 4–6 minutes, while a meaningful minority waits 20–30 minutes (for example because of bursts, priority cases, or a few long-running tasks). The mean is still approximately 10 minutes, but many people experience the ETA as a broken promise. You showed them a number, and they didn’t hit it.
• Stability failure: the system updates the ETA on every small event, so customers see it bounce, e.g., 10, 14, 9, 17 and finally 13 minutes. Even if the final outcome is “about right”, the journey feels chaotic. Customers interpret this volatility as loss of control, not as transparency.
• Fairness failure: two customers join within seconds of each other, but one is routed to a slower service path (or lower priority) and waits twice as long—with no explanation. They do not care that the overall average was correct; they care that the process felt arbitrary.

In other words: an ETA can be accurate as a metric and still be untrustworthy as a product experience.

This distinction is everything.

2. Why ETAs fail (even when your math is “right”)

2.1 Point estimates create false certainty

A single number (“12 minutes”) sounds like a promise. It creates a hard mental contract: if you break it, customers feel misled. There is no wiggle room.

A range (“10–16 minutes”), on the other hand, sets expectations more honestly. It communicates that the system is managing uncertainty rather than pretending it doesn’t exist. It says we understand this is variable, and we are showing you the zone where you likely fall.

You do not need a PhD to produce those ranges. In practice, teams typically build them using one of these approaches:

1. Percentile bands from historical waits (e.g., show a range that covers the middle 70–80% of outcomes). If your 20th percentile is 8 min and your 80th percentile is 15 min, show “8–15 min”.
2. Rolling windows (last 15–60 minutes) to adapt quickly during peaks, while still having enough data to stay stable.
3. Confidence bands around an underlying estimate (for example, widening the range when variability is high and tightening it when the system is stable). This approach gives you a principled way to express uncertainty.

The key is to pick a coverage target you can reliably hit, then measure and recalibrate over time. A 90% coverage target means: “9 out of 10 customers experience a wait inside the displayed range.” That’s trust-building. A 50% coverage target is useless—you are expressing a wish, not making a promise.

2.2 Volatile updates destroy credibility

If your ETA changes from 12 to 18, then 11 and finally 22 within a few minutes, you are only alarming your customers rather than informing them.

This volatility often happens because systems update on every micro-event (one completion, one arrival) instead of on a stable cadence. Each new data point triggers a recalculation, and the UI shows every ripple.

There is another common culprit: small-sample noise. If you update your ETA from a tiny amount of recent data, a single new observation can swing the statistics wildly.

For example, if your “average service time” is based on one value (10), and the next job takes 4, the average instantly becomes $\frac{10+4}{2}=7$. But if your average is 10 across 100 jobs and you observe a 4, the updated average is $\frac{100\times 10 + 4}{101} \approx 9.94$ — barely a change.

When you push those unstable averages straight to the customer-facing ETA, you get jitter. Customers see the ETA as unreliable because it looks unreliable. They lose trust.

The fix is not complicated: update on a predictable cadence (every 30–60 seconds, not every event), require a minimum sample size (or time window) before updating, and smooth the estimate so it moves predictably instead of jumping around.

2.3 Your queue is not a spreadsheet: the hidden cost of variability

Queues are living systems, meaning that:

• arrivals are bursty,
• service times vary widely,
• priorities exist,
• and a single slow job can ripple through everyone else.

This last point is especially important when your service capacity is small — whether that capacity is backend servers, checkout lanes, or human agents. If you have only a handful of parallel workers, one long-running request can effectively “steal” a meaningful fraction of total capacity for a while — and everyone behind it feels the delay.

Heavy-tailed service times (where a few jobs take disproportionately long) are particularly damaging to trust. Recent academic research shows that in systems with small service capacity (5–10 parallel workers), a single outlier job taking 10× the average service time can stretch everyone’s wait by 50%+ for hours. Your ETA model’s mean might be accurate, but if 5% of jobs create 40% of the wait, you are showing customers an average that doesn’t match their experience. They see one person being served for 30 minutes while 50 others stack up behind them. The average wait is meaningless.

This is why we make the distinction: bursty arrivals create waves of congestion, but heavy-tailed service times create chronic delays that ripple through the system. In many real systems, long service times end up being the bigger trust-killer because they stretch the tail and make ETAs look unreliable.

In fact, in our virtual lobby experiments we found this rule of thumb repeatedly: when you separate the impact of arrival patterns from the impact of service variability, heavy-tailed distribution dominates. A system with steady arrivals but wildly variable service times looks less predictable (and less trustworthy) than a system with bursty arrivals but consistent service times.

If you have built or operated a retail or service system, you have likely seen this firsthand: the mean can look fine while the tail causes the pain. We go deeper into tails and variability in our virtual lobby performance evaluation series.

3. The business cost of unpredictable waits

Before diving into solutions, executives need to understand why this matters operationally and financially.

An untrustworthy ETA is not just a customer experience problem—it is a conversion and operational efficiency problem:

• Abandonment rises under uncertainty: customer satisfaction decreases 8–15% per additional 5 minutes of unexpected wait time in retail and service environments. For e-commerce, this compounds: every minute of unforeseen delay reduces repeat-visit likelihood by 1–3%. Worse, the damage is non-linear: a customer who waits 25 minutes when promised 10 doesn’t just have 50% less satisfaction than someone who waits 15 minutes as promised. The betrayal is categorical.

• Repeat-contact volume increases: when wait messaging is missing, jumpy, or feels arbitrary, customers create work by asking for updates. Those “Any update?” contacts add cost without moving the queue forward.

• Throughput suffers when flow feels chaotic: stable, legible queue experiences reduce friction and help demand distribute more smoothly. One global hypermarket chain implementing a single-queue system reported checkout productivity improvements with automatic customer routing.

• Trust takes time to rebuild: once customers experience confident ETAs that repeatedly slip, they discount future updates. Even after operational fixes, credibility lags.

This is why ETA credibility is not primarily a UX problem—it is a conversion and revenue problem. You are directly affecting whether customers complete transactions, whether they return, and whether they recommend you.

4. The goal: believable ETAs, not perfect ETAs

For executives and ops leaders, the goal is not to predict the future perfectly.

It is to build a system that customers experience as:

• Predictable (updates are consistent; customers can plan around them)
• Transparent (changes are explained; customers understand the why)
• Fair (rules are legible; customers see that similar situations are treated similarly)

This is what reduces abandonment, lowers support costs, and protects conversion.

In operational terms, what does “believable” actually look like?

The goal is not to be optimistic. It is to be consistently reliable—to deliver on what you promise.

A practical rule of thumb:

Customers forgive wide ETAs. They do not forgive confident ETAs that keep slipping.

Show them “10–20 min” consistently, and they trust you. Show them “12 min” and deliver 22 min half the time, and they hate you. The width doesn’t matter as much as the predictability.

5. A simple example: the naive ETA vs the believable ETA

Picture a support portal during a peak hour. The queue is clearly building: 500 customers are waiting, and your operation is processing around 50 requests per minute.

It is tempting to publish a clean, precise number:

ETA ≈ 500 / 50 = 10 minutes

On average, that might even be “right”. But it is not customer-safe. It silently assumes the system will behave like a spreadsheet: steady arrivals, steady service times, no priority classes, no outliers, no variability.

Real-world precedent: This naive approach is widespread—and it fails at companies with massive resources and sophisticated teams.

Uber’s highly publicized DeepETA system invested years of ML development to predict arrival times with high statistical accuracy. Yet riders consistently report 100%+ delays, where trips take twice as long as initially predicted. This creates a paradox: even the most sophisticated ETA systems fail at believability, not accuracy.

Apple’s Genius Bar system similarly overbooks appointments by ~40%, assuming no-show rates will balance the load. Customers report system errors deleting appointments and wait times stretching 1.5+ hours despite 45-minute estimates. The lesson here is that algorithm sophistication doesn’t fix trust if the underlying operation can’t deliver on the promise.

Better models help, but believability still comes from honest uncertainty, stable updates, and explicit handling of outliers.

Compare that to a transparent experience based on (1) honest communication about uncertainty, (2) stable update cadences, and (3) explicit handling of outliers:

• Estimated wait: 8–14 minutes
• Next update in: 60 seconds
• Status: “Traffic increased” (if it changes)

The difference is subtle but powerful. Customers stop treating the ETA as a brittle promise, and your operation gets room to absorb variability without triggering a trust collapse.

If the queue worsens and the range widens, widen it. Don’t cling to false precision. And when the range gets too wide to be reassuring, that’s when you offer alternatives: callback, reschedule, or a different channel.

6. Five rules for communicating wait times customers trust

These rules are deliberately practical. You can implement them without rewriting your whole stack. In fact, most of the gains come from changing how you communicate what is already there.

1. Prefer ranges to single numbers

A single number sounds like a promise. A range sounds like a system that understands uncertainty.

• Why it works: ranges absorb normal variability without forcing you to “break” the ETA every time reality deviates.
• How to do it: display a band derived from historical percentiles or confidence bands (e.g., “8–14 min”).
• Example: “Estimated wait: 8–14 minutes” tells customers what to expect and implies you are watching the boundaries.

2. Update on a predictable cadence

If customers do not know when the next update is coming, they will keep checking — and the experience feels unstable.

• Why it works: a stable rhythm reduces anxiety and prevents “stock ticker” behavior (obsessive checking).
• How to do it: update every 30–60 seconds (or at a fixed point in the journey), and show the next update time. Make the cadence visible: “Next update in 45 seconds.”
• Example: “Next update in 45 seconds” is often more reassuring than “live” updates that feel erratic.

3. Avoid whipsawing

Even when your estimate is improving, a jittery ETA reads as loss of control.

• Why it works: people interpret volatility as risk, not as transparency. A jumping number looks like panic.
• How to do it: smooth the estimate (e.g., moving averages), enforce minimum update intervals, and avoid updating the UI for tiny changes.
• Example: only change the displayed range if the midpoint moves by more than ~1 minute (or more than ~10%), otherwise keep the message stable. Absorb small fluctuations.

4. Explain the change in plain language

If you do not explain changes, customers invent their own explanation — and it is rarely flattering.

• Why it works: a short reason makes the system feel intentional, not arbitrary or broken.
• How to do it: use a small set of reason codes that are consistent across channels.
• Examples: “High demand”, “Extra verification”, “System is recovering”. Short, consistent messages beat detailed excuses.

5. Offer choices when uncertainty grows

When the range widens past what customers tolerate, the best move is not persuasion — it is options.

• Why it works: choice restores control (and control reduces abandonment). Give customers agency: let them decide whether to wait, reschedule, or try a different channel.
• How to do it: callback, reschedule, switch channel, or “come back at off-peak times”.
• Example: “We can notify you when it’s your turn” often outperforms shaving a minute off the ETA by giving customers control.

If you want to go deeper on “choice” and why it works psychologically, see the framework in designing virtual queues that don’t feel like waiting.

7. What to measure: trust is observable

If you can’t measure trust, you can’t improve it.

The good news: trust is not fuzzy. It shows up in measurable operational signals. Below are five metrics that map cleanly to credibility and fairness, plus how to interpret them and what targets to aim for.

7.1 Core credibility metrics

1. Late rate (“broken-promise” rate)

• Definition: the percent of customers whose actual wait exceeds your displayed upper bound.
• Why it matters: late is what customers remember. If your upper bound is frequently wrong, your ETA becomes a liability—customers feel misled.
• How to use it: treat it like an error budget. If late spikes during peaks, widen ranges and slow update cadence before you chase “accuracy.”
• Target: ≤5% of customers exceed the displayed upper bound. This means: 19 times out of 20, you deliver on what you promised.

2. Coverage (“range hit” rate)

• Definition: the percent of customers whose actual wait falls inside the displayed range.
• Why it matters: coverage is your calibration signal. It tells you whether your ranges are too loose or too tight.
• How to use it: pick a target (e.g., “85–90% of customers will fall inside the range”), then recalibrate the band as demand patterns change.
• Target: 85–90% coverage. If coverage is below 80%, your range is too tight (you are over-promising). If it is above 95%, your range is too loose (you are under-communicating).

3. Volatility (ETA jitter)

• Definition: average absolute change in displayed ETA per minute (or per update).
• Why it matters: even a correct ETA feels untrustworthy if it moves erratically. Volatility kills trust faster than width.
• How to use it: cap how often you update and ignore tiny changes; optimize for smoothness over accuracy.
• Target: Display ETA changes only when the midpoint moves >1 minute (or >10% of the current estimate). Absorb smaller fluctuations.

7.2 Customer behavior metrics (the “truth serum”)

4. Repeat-contact rate during waits

• Definition: chats/calls/tickets asking for updates while people are waiting.
• Why it matters: this is a direct proxy for uncertainty. When ETA messaging is stable and reason codes are visible, this metric often drops materially.
• How to use it: when it rises, treat it as a product signal: improve messaging, add next-update times, and offer options. Don’t blame customers for being impatient; they are telling you the system feels out of control.

5. Abandonment vs displayed range width

• Definition: abandonment rate as a function of the displayed range (and its width).
• Why it matters: this helps you find the sweet spot between honesty and reassurance. It’s a business constraint, not a technical problem.
• How to use it: if abandonment rises sharply past a certain range width, that is a signal that you need choices (callback/reschedule) or capacity changes, not a “better algorithm.”

Practical implementation tip: Compute these metrics per segment (channel, service class, priority tier). Otherwise, you will average away the very behavior you are trying to fix. A support channel serving both simple and complex issues will show averaged metrics that hide the fact that simple issues are trustworthy (90% coverage) while complex issues are not (60% coverage).

A useful rule of thumb:

It’s better to show a slightly wider range that you consistently hit than a tight ETA you regularly miss.

8. A pragmatic rollout plan

You do not need to boil the ocean. The biggest wins usually come from making the communication layer honest and stable first, then improving the underlying estimation.

This is counterintuitive—most teams want to start by “fixing” the algorithm. Resist that. In practice, Phase 1 often delivers most of the credibility gains with minimal risk and cost.

Before you start any phase, align on two decisions:

1. Coverage target: what does “good” mean for your range? (e.g., “our displayed range should contain 85–90% of outcomes.”)
2. Update contract: how often will you update, and when do you widen the range versus offering alternatives?

Phase 1 (days to weeks): make the UI honest

Goal: stop overpromising.

• Replace point estimates with ranges (and show the next update time).
• Add a stable cadence (e.g., every 30–60 seconds) rather than updating on every event.
• Add short reason codes for meaningful changes (“High demand”, “Extra verification”, “System is recovering”).

Success criteria:

• Late rate drops (or at least stops spiking) during peak periods.
• Volatility decreases (ETA feels calmer even if waits are still long).
• Repeat-contact rate during waits starts trending down.

Why this works: You haven’t changed the actual operation, but you have changed the promise. You are now communicating honestly about what customers will experience. This alone builds trust.

Phase 2 (weeks): segment and stabilize

Goal: stop mixing fundamentally different waits.

• Separate queues by service class (simple vs complex, standard vs premium, in-store vs online).
• Make priority rules legible (if there is triage, explain it clearly).
• Stabilize estimates with minimum sample sizes / rolling windows and smoothing to reduce noise.

Success criteria:

• Coverage improves within each segment (calibration becomes easier because each segment is more homogeneous).
• Fairness complaints drop (“Why did they go first?” becomes rarer).
• Abandonment becomes more predictable by segment (you can see where you need to offer choices).

Real-world example: A support system serving both password resets (2-min average) and account recoveries (30-min average) shows an aggregate “average” of 12 minutes. Customers see “ETA: 12 min” and then experience either a quick resolution (feels great) or a long wait (feels betrayed). Separating them into two queues with distinct ETAs (“Password reset: 2–4 min” vs “Account recovery: 25–35 min”) and allowing customers to self-select often reduces abandonment because expectations align with reality.

Phase 3 (months): make it variability-aware

Goal: explicitly handle outliers and heavy-tailed behavior.

• Forecast with distributions, not just means. Ranges that widen when variability is high and tighten when the system is stable.
• Detect and mitigate long jobs (timeouts, dedicated lanes, separate pools, escalation paths, priority overrides).
• Connect the queue to capacity levers (staffing, scheduling, autoscaling, admission control) so the system can protect itself under extreme load.

Success criteria:

• Tail behavior improves (fewer “mystery” 30-minute waits for what should be 10-minute tasks).
• Late rate stays controlled even when demand spikes.
• The organization can set an explicit trade-off between service levels and load protection.

This is where the real operational gains come from — and it brings us to the next post in this series, which dives deep into variability and outlier handling.

Conclusion

If you want customers to trust your waits, stop guessing.

Trust comes from calibration (ranges), stability (cadence), and legibility (plain reasons). When you prioritize these three operational levers over raw forecast accuracy, you do more than just improve a metric. You reduce abandonment, lower support costs, and protect conversion during your busiest hours.

That is not just “better UX”. It is predictable operations.

If you want help auditing your current ETA experience and designing a more predictable approach, we should talk.

📬 Get weekly queue insights

Not ready to talk? Stay in the loop with our weekly newsletter — The Queue Report, covering intelligent queue management, digital flow, and operational optimization.