Pending vs On-hold in Zendesk: how to read time in status
Pending and On-hold both look like waiting. Operationally, they mean very different things.
If your team mixes them together, you lose the ability to answer one of the most important queue questions: are customers waiting on us, or are we waiting on something else? That distinction matters for staffing, follow-up discipline, and how you explain slow resolution to leadership.
This guide shows how to interpret Pending and On-hold in Zendesk, how to report them in a time-in-status workflow, and what each pattern usually means. For the broader stall analysis, pair this page with Zendesk time in status report and the support metrics dashboard.
The operational difference
In most Zendesk workflows:
- Pending means the team is waiting for the customer or requester.
- On-hold means the team is waiting on an internal or external dependency such as engineering, billing, compliance, or a vendor.
Both can increase total resolution time, but they signal different owners and different fixes.
Pending often points to follow-up quality, missing information, or customer responsiveness. On-hold usually points to dependency management and cross-functional process gaps.
What your report should show
A useful Pending vs On-hold report should answer:
- How much time do tickets spend in each status?
- Which groups or issue types create the most Pending time?
- Which workflows create the most On-hold time?
- What share of total resolution time comes from customer wait versus dependency wait?
That is why this report works best as a segmented time-in-status view rather than a single average.
How to review Pending well
Pending time is not automatically bad. In many cases it simply reflects realistic customer-side delay.
What matters is whether the Pending pattern is healthy.
Healthy Pending usually looks like:
- clear follow-up messages
- reasonable wait windows
- consistent reminders or closure rules
- faster progress after the customer replies
Risky Pending usually looks like:
- tickets left waiting without a clear next action
- repeated agent follow-ups with no real progress
- long requester wait time for one form, team, or channel
- tickets that reopen soon after closure because the original clarification was weak
If Pending is high and reopen rate is rising, the problem may be poor troubleshooting or weak information gathering rather than customer responsiveness alone.
How to review On-hold well
On-hold is where hidden dependency risk tends to accumulate.
Long On-hold time often means support has done what it can and is now blocked by another team, policy, or system. That is useful to know because the fix is usually not more frontline effort.
Look for:
- one dependency group causing most On-hold time
- a specific tag or issue type with repeated hold behavior
- long hold duration for urgent priorities
- increasing On-hold time at the same time SLA compliance falls
This is the part of the queue where escalation design matters. If no clear owner exists after support hands off the issue, customers feel the delay even when the support team is working correctly.
How to use Pending and On-hold in planning
A strong weekly review does not just look at the total hours. It asks who owns the delay.
If Pending is the bigger problem
Focus on:
- clearer first troubleshooting messages
- better macro quality for information requests
- follow-up reminders and closure rules
- segmenting customers or channels with unusually long reply gaps
If On-hold is the bigger problem
Focus on:
- escalation paths
- response expectations from partner teams
- ownership for blocked work
- better visibility for high-priority held tickets
This is why Pending and On-hold should rarely be blended into one bucket called waiting. They drive different operational actions.
Business hours vs calendar hours
This report gets more useful when you decide whether to view delay in business hours vs calendar hours.
- Use business hours when you want to understand process performance and team accountability.
- Use calendar hours when you want to understand the total elapsed customer experience.
For many support leaders, the most useful approach is to review both: business hours for internal improvement and calendar hours for customer communication and expectation-setting.
Common mistakes
- Treating Pending as internal slowness. Often the delay sits with the customer, not the queue.
- Treating On-hold as harmless. Dependency work still affects the customer experience.
- Reviewing only one global average. One group or issue type usually drives the problem.
- Ignoring the difference between wait ownership and resolution ownership. The team that closes the ticket may not be the team creating the delay.
FAQ
Should agents use Pending or On-hold more often?
Neither status is better. The right choice depends on who is expected to act next.
Does high Pending time always hurt the team?
Not necessarily. It is only a serious ops concern when the customer wait is avoidable, poorly managed, or distorting the queue review.
What should I pair this report with?
Start with Zendesk requester wait time report, Zendesk agent wait time report, and Zendesk time in status report.
See where customer wait ends and dependency delay begins - start free