Zendesk Requester Wait Time Report: Measure and Reduce Customer Wait

Requester wait time measures the total time a customer spends waiting for your team to act on their ticket. Unlike first reply time, which only captures the gap before the initial response, requester wait time accumulates across every status where the customer is waiting — New, Open, and On-hold. It’s the metric that best reflects how your customer experiences your support speed.

This guide covers how to build a requester wait time report in Zendesk, what the numbers tell you, and how to reduce wait without adding headcount.

What requester wait time actually measures

Requester wait time is the combined duration a ticket spends in statuses where the customer is waiting for the support team:

A ticket can cycle through these statuses multiple times. Requester wait time adds up every interval where the ball is in your court, giving you a full picture of how long the customer waited for resolution — not just the first touch.

For the formal definition, see the requester wait time glossary entry.

How to build the report in Zendesk Explore

Prerequisites

• Zendesk Explore Professional or Enterprise
• Editor or Admin permissions in Explore

Step-by-step

1. Open Explore and create a new report — Use the Support: Tickets dataset.

2. Add the metric — Select Requester wait time (hrs) from the Ticket metrics. This is a native duration metric Zendesk calculates automatically. Choose business hours or calendar hours based on your team’s schedule (business hours recommended for teams that don’t work 24/7).

3. Set your aggregation — Median is more reliable than average here. A few tickets stuck in On-hold for days will distort an average. Median gives you the typical customer experience.

4. Add a time dimension — Use Ticket created date by week or month to track trends over time.

5. Add breakdowns — The power of this report is in the segmentation:

6. By group — Which team keeps customers waiting longest?
7. By priority — Are high-priority tickets actually getting faster treatment?
8. By channel — Do email tickets have longer wait than chat?

9. By status — How much wait accumulates in New vs Open vs On-hold?

10. Save to your dashboard — Add this alongside first reply time and resolution time in your support metrics dashboard so you can compare all three in your weekly review.

Sample Explore formula

If you want to create a calculated metric for requester wait time as a percentage of total ticket lifetime:

(Requester wait time (hrs)) / (Full resolution time (hrs)) * 100

This ratio tells you what fraction of the ticket’s life the customer spent waiting. A healthy target: under 70%. If it’s above 85%, most of the ticket lifetime is dead time from the customer’s perspective.

Business hours vs calendar hours

This choice matters even more for requester wait time than for first reply time, because requester wait time accumulates across the entire ticket lifecycle.

• Calendar hours count nights, weekends, and holidays. A ticket created Friday at 5 PM and resolved Monday at 9 AM shows ~64 hours of requester wait time — even if your team worked on it first thing Monday.
• Business hours only count scheduled work time, giving you a metric that reflects your team’s actual responsiveness.

If your team operates on a fixed schedule, use business hours. Configure your schedule in Zendesk Admin Center under Business rules → Schedules, and make sure Explore reports reference it.

What high requester wait time tells you

Requester wait time is a compound metric — it absorbs delays from multiple causes. When it’s high, investigate these common culprits:

1. Slow initial assignment

If tickets sit in New status for hours, you have an assignment problem, not a speed problem. Check your assignment time report to confirm. Fixes: auto-assign via round-robin, reduce group routing hops, or tighten trigger conditions.

2. On-hold abuse

Some teams use On-hold as a parking lot for tickets they’re unsure about. Since On-hold counts as requester wait time, this inflates the metric. Audit how your team uses On-hold — it should mean “waiting on an internal dependency,” not “I’ll get to this later.”

3. Ping-pong reassignment

Every reassignment adds dead time while the new assignee reads context and decides on an approach. If tickets average more than one reassignment, the handoff delay is baked into your requester wait time. See the hidden cost of ticket reassignment.

4. Pending → Open cycles

When a customer replies to a Pending ticket, it moves to Open. If agents don’t respond promptly to these re-opened conversations, wait time spikes. Track next reply time separately to catch this.

Reducing requester wait time without adding headcount

You don’t always need more agents. Start with workflow improvements:

• Automate assignment — Use omnichannel routing or skills-based triggers so tickets reach the right agent in minutes, not hours.
• Set On-hold expectations — Create an internal SLA for On-hold tickets: if you haven’t gotten the internal answer in 4 hours, escalate or update the customer.
• Reduce reassignments — Better initial routing means fewer handoffs. Review your triggers audit to catch routing rules that bounce tickets between groups.
• Prioritize re-opened conversations — When a Pending ticket comes back as Open, it should jump the queue. The customer already waited once.
• Staff to volume — Use your ticket volume forecast and capacity plan to match coverage to demand.

Requester wait time vs other time metrics

Requester wait time sits between first reply time and resolution time in scope. It strips out time where the customer isn’t waiting (Pending status) and focuses purely on the experience gap.

FAQ

How is requester wait time different from first reply time? First reply time only measures the gap before the first agent response. Requester wait time measures all cumulative time the customer spends waiting — before the first reply, between subsequent replies, and during On-hold periods.

Should I track requester wait time in my SLA? Yes, if you want your SLA to reflect the full customer experience. Many teams set SLAs on first reply time and total resolution time, but adding a requester wait time target catches the “slow middle” — tickets where the first reply was fast but the customer still waited days for resolution.

What’s a good requester wait time target? It depends on your ticket complexity and support hours. As a starting point: if your median first reply time is under 2 hours and your median resolution time is under 8 hours, aim for median requester wait time under 5 hours. Review the metric in your weekly ops review and tighten targets as you improve.

Does requester wait time include time in custom statuses? If you use custom ticket statuses in Zendesk, requester wait time counts time in statuses mapped to the New, Open, and On-hold categories. Statuses mapped to Pending are excluded. Check your status category mappings in Admin Center.

See your requester wait time without building Explore reports — start free