Zendesk Agent Wait Time Report: Separate Customer Delays from Team Delays

Agent wait time measures the time your team spends waiting on a customer or an outside dependency after the ticket is already in motion. It is the mirror image of requester wait time: requester wait time shows when the customer is waiting on you; agent wait time shows when you are waiting on someone else.

That distinction matters. If your resolution time is long, you need to know whether the delay came from slow internal follow-up or from a ticket that sat in Pending for three days while the customer gathered screenshots. This guide shows how to build an agent wait time report in Zendesk, segment it, and use it in your support metrics dashboard.

What agent wait time actually measures

Agent wait time is the cumulative time a ticket spends in states where the next move belongs to the customer or an outside party.

Typical examples:

  • Pending customer response - The agent asked a question and is waiting for a reply.
  • Waiting on a vendor or engineering - The support team already did its part and is blocked by another team.
  • Verification holds - The customer needs to confirm a fix before the ticket can be solved.

That means high agent wait time is not automatically bad. In some queues, it is expected. What matters is whether it is explained by your workflow, ticket mix, and customer journey.

Why this report matters

Without an agent wait time view, teams often make the wrong diagnosis:

  • A long full resolution time gets blamed on agents when the real delay is customer follow-up.
  • A low first reply time looks healthy even though tickets drag for days after the first answer.
  • A backlog review treats all old tickets as equally risky, even though some are genuinely waiting on the requester.

Agent wait time gives you a clean way to separate throughput issues from dependency issues.

How to build the report in Zendesk Explore

Start with the right question

Build this report around one operational question: “How much of our total ticket lifetime is outside the agent’s control?”

That framing helps you avoid using the metric as a blunt performance score.

Report setup

  1. Open Zendesk Explore and create a report from the Support: Tickets dataset.
  2. Look for a waiting-time metric that captures time spent waiting on the customer. Depending on your Zendesk setup, this may be available directly or may require a calculated metric based on ticket status history.
  3. Choose median before average. A few tickets that sit in Pending for a week will distort the average. Median shows the typical case.
  4. Add a date dimension such as Ticket created - Date or Ticket solved - Date by week.
  5. Break the report down by the dimensions that explain delay:
  6. Group - Which teams have the most dependency-heavy tickets?
  7. Priority - Are urgent tickets still stalling outside the agent’s control?
  8. Channel - Email queues usually produce more wait time than chat.
  9. Ticket form or tag - Which workflows create the longest external waits?
  10. Pair it with companion metrics on the same dashboard: requester wait time, reply time, and resolution time.

If Zendesk does not expose the metric cleanly

Many teams need an approximation. A practical fallback is to calculate time spent in Pending or in custom statuses mapped to waiting-on-customer states. If you route external dependency work through a dedicated status or tag, segment that separately so customer wait and third-party wait do not get blended together.

Business hours vs calendar hours

Agent wait time is one of the clearest examples of why business hours vs calendar hours matters.

  • Calendar hours show the full customer journey. If a customer takes the weekend to reply, that delay stays visible.
  • Business hours are better for internal planning if you want to compare queues on a like-for-like basis.

For most ops reviews, use business hours for team comparison and keep calendar hours available for executive context.

How to interpret the number

Use agent wait time as a classification metric, not a vanity metric.

High agent wait time can be healthy when:

  • Your team handles technical tickets that require customer testing.
  • You support multiple time zones.
  • Engineering or compliance approvals are part of the normal workflow.

High agent wait time is a warning when:

  • Tickets sit in Pending because agents are punting ownership.
  • Customers are confused by the next step and do not know how to respond.
  • External escalations have no target turnaround time.
  • Your automation sends a generic “we need more info” message that customers ignore.

Common mistakes

1. Treating Pending as “safe”

A ticket in Pending is not automatically low risk. If the customer has been waiting to understand the next step, the work is stalled even if the queue looks under control.

2. Mixing customer wait with vendor wait

If a third-party dependency is common in your workflow, tag those tickets. Otherwise your report will make customer behavior look worse than it is.

3. Looking at totals without ticket mix

Billing issues, bug reports, and account access problems behave differently. Always segment by ticket type, tag, or form.

How to reduce agent wait time without forcing rushed resolutions

  • Ask better clarifying questions - One precise message reduces back-and-forth.
  • Use macro checklists - Make sure agents request all needed information the first time.
  • Set follow-up automations - Remind customers after one or two business days instead of letting tickets sit silently.
  • Add vendor escalation SLAs - If another team blocks support, give that dependency a measurable target.
  • Tag dependency patterns - If one issue type always creates long waits, improve the workflow upstream.

Agent wait time vs other time metrics

Metric Best for What it reveals
First reply time Initial responsiveness How quickly the team acknowledges work
Reply time In-conversation speed How quickly the team follows up
Requester wait time Customer experience How long the customer waits on you
Agent wait time External or customer dependency How long you wait on others
Resolution time End-to-end efficiency Total time to close the issue

Reviewing these together is how you avoid misreading the queue.

FAQ

Is high agent wait time always a problem? No. It is often normal for complex or verification-heavy tickets. It becomes a problem when the wait is caused by poor next-step communication, weak follow-up automation, or unclear ownership.

Should agent wait time count against agents? Usually no. It is better used as a workflow and dependency metric than an individual scorecard metric.

What should I compare it to? Start with requester wait time, reply time, and reopen rate. Together they tell you whether tickets are genuinely blocked or simply being handled poorly.


See where your tickets really stall - start free