Zendesk backlog aging report: find stuck tickets before SLAs slip
A backlog count tells you size. A Zendesk backlog aging report tells you risk. When you break open work into age buckets, you can see which tickets are merely waiting and which ones are quietly turning into missed commitments, escalations, and unhappy customers.
This guide shows how to build a backlog aging report in Zendesk, how to read it, and what to do when older tickets start piling up. Pair it with your support metrics dashboard so backlog age becomes part of the weekly review, not a rescue exercise.
What a backlog aging report should show
For definitions, see backlog and open tickets in the glossary. In practice, an aging report should answer four questions:
- How many unsolved tickets do we have?
- How old are they? A simple bucket view like 0-24h, 24-48h, 48-72h, and 72h+ is usually enough.
- Where are the oldest tickets sitting? Break down by group, priority, tag, or channel.
- Is age getting worse over time? A point-in-time aging table is useful, but trend is what helps you decide whether this is a temporary spike or a system problem.
If you only report backlog count, you miss the difference between “we have 60 open tickets, but most are new” and “we have 60 open tickets, and 18 have been waiting for three days.”
How to build a backlog aging report in Zendesk
In Zendesk Explore, the report usually starts with the tickets dataset and a definition of backlog that matches your team language. Many teams include New, Open, and Pending; others exclude Pending. The important part is consistency across Explore, team reviews, and dashboard screenshots.
Build the report in this order:
- Filter to backlog tickets using the statuses that mean “still waiting for us to finish.”
- Count tickets so you can see total backlog size.
- Add an age bucket based on time since creation or time since last update.
- Break down by segment such as Group, Priority, Tag, or Channel.
- Add a time view by day or week if you want to see whether aging is improving.
If you are deciding between time since creation and time since last update, start with creation for a simple “how old is this ticket?” view. Add last-update aging later if your team needs to distinguish neglected tickets from active long-running ones.
For the broader backlog setup, see Zendesk backlog report and ticket backlog dashboard. For why age matters alongside size, see Backlog Isn’t Just a Number.
How to read the report
The useful question is not “what is the oldest ticket?” It is “what pattern explains the oldest tickets?”
- A large 0-24h bucket and small older buckets usually means intake is high but flow is healthy.
- A stable total backlog with rising 48h+ tickets means work is staying open longer even if the top-line count looks manageable.
- Old tickets concentrated in one group usually point to ownership, staffing, or routing issues.
- Old tickets concentrated in one priority or tag often mean one workflow is broken, not the whole queue.
Backlog age should be interpreted next to ticket volume, ticket inflow, resolution time, and SLA compliance. If age is rising while volume is flat, capacity is not the only story. You may have a triage problem, weak routing, or tickets bouncing between teams.
What to do when aging spikes
- Start with the oldest bucket. Do not spread attention evenly across the whole queue.
- Break the old tickets by group or tag so you can see whether one segment is causing most of the risk.
- Open the underlying ticket list and classify the cause: waiting on customer, wrong owner, blocked by engineering, low-priority work crowding the queue, or missing escalation.
- Fix the process behind the age. Reassigning tickets may clear this week, but if routing is wrong you will see the same pattern next week.
This is where a lightweight ops workflow matters. A report that shows age but not the ticket list is only half useful. Connect the metric to real tickets, then carry that review into your weekly support ops review.
Common mistakes
- Using too many buckets. Five clear ranges are easier to act on than a long table of tiny intervals.
- No trend view. A single aging snapshot does not tell you whether the problem is getting better or worse.
- Ignoring segment concentration. The queue may look unhealthy overall when only one team or topic is stuck.
- Treating Pending as automatically safe. Some pending tickets are truly blocked; others are effectively stalled work that still creates risk.
FAQ
What is a good aging threshold?
That depends on your SLA and ticket mix, but the point is consistency. Pick buckets that reflect your operating rhythm and use them every week.
Should backlog aging use business hours or calendar hours?
For queue management, many teams start with calendar age because it is simple. For SLA-related reviews, bring in business hours vs calendar hours so you do not overstate risk.
How often should we review backlog aging?
At least weekly in your support metrics dashboard. During a spike or peak season, daily is reasonable.