Zendesk Backlog by Tag Report

Overall backlog tells you how much open work exists. Backlog by tag tells you which support topics are actually trapping that work in the queue.

That difference matters because a queue can look manageable in total while one issue type quietly holds most of the aging workload. The blended backlog number shows volume. The tag cut shows cause. This guide explains how to build a Zendesk backlog by tag report, how to interpret concentrated topic-level queue drag, and what to do when one issue category keeps work stuck open.

What this report should answer

A useful backlog-by-tag report should answer:

Which issue types hold the most open tickets right now?
Which tags also hold the oldest unresolved work?
Is backlog concentrated in a few categories or spread across the queue?
Are the heaviest tags also slow to resolve, high-risk on SLA, or prone to reopen?

For the metric definition, see backlog. For the structure underneath the chart, review issue taxonomy, tag co-occurrence, and tag-to-resolution time. For the broader weekly context, keep this report beside the support metrics dashboard.

Why tag-level backlog matters

Backlog is rarely a generic capacity problem for long. It usually becomes concentrated in specific categories of work first.

That happens when:

one issue type requires repeated specialist handling
product or policy friction creates the same open tickets over and over
certain topics are harder to progress after first response
one category accumulates aging work while the rest of the queue still moves

This is why backlog by tag is so useful for support ops. It helps teams separate “the queue is too big” from “this specific kind of work is quietly trapping capacity.”

How to build the report in Zendesk

Use the Support: Tickets dataset in Zendesk Explore and filter to currently open or unresolved tickets.

1. Group backlog by tag

Use issue-type tags or product-area tags as the main dimension. Avoid workflow or cleanup tags unless those labels genuinely explain why work is stuck.

2. Count open tickets by tag

This creates the core concentration view. A descending table or bar chart works well because it shows which categories hold the most queue weight.

3. Add aging context

Open count alone is not enough. Pair it with age buckets or oldest-ticket age so you can tell the difference between:

a high-volume tag with mostly fresh work
a smaller but unhealthy tag with old unresolved tickets

For the setup details, compare with Zendesk Backlog Aging Report: Find Stuck Tickets Before SLAs Slip and Zendesk Backlog Burn-Down Rate Report.

4. Add supporting cuts

The most useful secondary dimensions are:

group
channel
customer segment
priority
ticket form

These help turn “billing has a lot of backlog” into “billing backlog is mostly urgent chat work in one team.”

5. Trend concentration over time

The strongest version of this report shows whether a few tags are holding a larger share of total backlog over time. That tells you whether the queue problem is becoming more concentrated or more diffuse.

The most useful report layouts

Open tickets by tag

This is the main concentration view. It tells you which issue types occupy the most open work right now.

Open tickets by tag with aging

This is the operating view. It shows which categories are merely busy and which are actually going stale.

Backlog by tag and group

This helps you identify whether one team’s workflow is creating most of the backlog inside a topic.

Backlog by tag with resolution and reopen context

Use this when you want to understand whether the heaviest tags are also the least durable or slowest to finish.

How to interpret the patterns

That usually means the queue problem is more concentrated than the headline metric suggests. The next question is whether the issue is fresh demand or aging unresolved work.

One tag has moderate volume but very old tickets

This is often the more dangerous pattern. A category does not need to dominate count to create major queue drag if the work stays open too long.

That may mean your taxonomy is splitting one broader problem into several labels. Review tag co-occurrence before assuming you have several unrelated backlog problems.

One tag is heavy but resolution time is normal

This can happen when a category simply creates lots of fresh demand. High open count is not automatically unhealthy if the work continues to move.

Common mistakes

Treating every high-volume tag as a backlog problem. Fresh work and stale work are different.
Skipping aging. Backlog without age becomes a noisy workload count.
Using weak tags. Internal routing or cleanup tags rarely tell a useful customer-facing story.
Ignoring lateral metrics. Backlog is easier to fix when reviewed with resolution time, SLA compliance, and reopen rate.
Using the report without owners. If no one owns follow-up, the chart turns into a curiosity instead of an operating tool.

What to do when one tag stands out

If one issue type repeatedly traps the most aging backlog:

Check whether the open work clusters in one group, channel, or priority tier.
Compare it with Zendesk Tag-to-Resolution Time Report and Zendesk Reopen Rate by Tag Report.
Decide whether the cause is product friction, routing, policy complexity, or specialist scarcity.
Separate fresh backlog from stale backlog before deciding on the fix.
Recheck concentration weekly until the aged open work normalizes.

The goal is not to shame one topic for being busy. It is to identify which categories are quietly consuming too much open queue capacity.

Where this report fits in your dashboard

This report works best beside:

Together, those views show which issue types create open work, which of that work is aging, and which categories still fail to resolve durably.

FAQ

Should I use every tag in the report?
No. Start with the tags that represent real issue types or product areas. Too many low-value tags make the backlog story harder to trust.

What if one ticket has several tags?
That is common. Choose a primary reporting tag where possible, or use tag co-occurrence when the overlap is operationally meaningful.

How often should I review backlog by tag?
Weekly works well for operations. Monthly is useful for deeper root-cause review and cross-functional planning around product or policy friction.

See which Zendesk issue tags quietly trap the most aging backlog - start free