Agent Wait Time vs Requester Wait Time: Which Delay Should Support Ops Fix First?
When ticket lifetime gets too long, support teams usually reach for one big number: resolution time. The trouble is that resolution time bundles together two very different kinds of delay.
- time the customer spends waiting on support
- time the support team spends waiting on the customer or another dependency
That is the difference between requester wait time and agent wait time. They sound similar, but they answer opposite questions. One tells you how slow support feels to the customer. The other tells you how much of the delay is outside the agent’s control.
If you confuse them, you will fix the wrong problem.
The quick difference
| Metric | What it measures | Best use |
|---|---|---|
| Requester wait time | Time the customer waits on your team | Customer experience and queue responsiveness |
| Agent wait time | Time the team waits on the customer or an external dependency | Workflow diagnosis and dependency analysis |
That table is simple, but the operational consequence is huge.
When requester wait time should lead
Requester wait time is the metric to prioritize when you want to know whether support feels fast.
A high requester wait time usually means one of four things:
- tickets sit too long before first assignment
- agents reply slowly between touches
- tickets get reassigned and lose momentum
- internal work sits in Open or On-hold without clear ownership
This is the metric most likely to match what angry customers describe. If customers say support is slow, requester wait time usually explains why better than almost any other number. See Zendesk Requester Wait Time Report.
When agent wait time should lead
Agent wait time becomes more useful when your goal is diagnosis rather than experience.
If overall ticket lifetime is high but requester wait time looks reasonable, agent wait time helps explain the remaining delay. Common causes include:
- customers take days to provide logs or screenshots
- a vendor or engineering team is blocking progress
- the team uses Pending heavily for verification workflows
- the issue naturally requires a long back-and-forth
In those cases, the ticket may be slow without the support team actually being slow. See Zendesk Agent Wait Time Report.
The common reporting mistake
The mistake is treating all old tickets as evidence of poor support.
Imagine two tickets that both took five days to solve:
- Ticket A waited four of those days for the support team to respond.
- Ticket B waited four of those days for the customer to confirm a fix.
The total resolution time is identical. The operational meaning is not.
Ticket A points to a queue problem. Ticket B points to a dependency pattern. Only wait-time segmentation tells you which is which.
Which one should you fix first?
In most cases, fix requester wait time first.
Why? Because it is the delay your team controls most directly, and it is the one customers feel most clearly. Faster assignment, better ownership, and quicker follow-up will usually improve customer experience faster than any change to agent wait time.
But there are three situations where agent wait time deserves immediate attention:
1. Customers are confused about next steps
If agents keep sending vague requests for more information, tickets drift into Pending and stay there. That is technically agent wait time, but it is still a workflow quality problem you can fix.
2. External escalations dominate specific queues
If one workflow depends on engineering or compliance every time, you need tighter internal SLAs and better escalation design.
3. The team is being judged unfairly
If leadership sees long total resolution time and assumes the team is slow, agent wait time provides the missing context.
The best way to use both metrics together
A strong ops review asks these questions in order:
- How long is the customer waiting on us? Use requester wait time.
- How much ticket lifetime sits outside direct support control? Use agent wait time.
- How long does the ticket take overall? Use resolution time.
- Are we trading speed for poor quality? Check reopen rate and first contact resolution.
That sequence keeps the conversation grounded in customer impact first and diagnosis second.
Where teams go wrong in practice
- They review only total resolution time.
- They use Pending as a hiding place for neglected tickets.
- They never separate customer-caused delay from support-caused delay.
- They coach agents on speed without looking at dependency-heavy ticket types.
When that happens, operations reviews become arguments instead of analysis.
What a healthy dashboard looks like
For most small teams, the core time stack is:
That set shows how quickly you start work, how consistently you continue it, how long the customer waits, how much delay is external, and how long the whole issue lasts.
Key takeaway
Requester wait time tells you whether support feels slow. Agent wait time tells you why some tickets stay open even when the team may not be the bottleneck. You need both, but they should not carry the same decision weight.
If customers are unhappy with speed, start with requester wait time. If ticket lifetime still looks long after that, use agent wait time to find the dependencies and workflow design problems underneath.
See customer wait and dependency wait side by side - start free