Zendesk backlog burn-down rate report

Backlog size tells you how much work is still open. Backlog burn-down rate tells you whether you are winning or losing against that work over time.

That distinction matters. A backlog of 200 tickets can be healthy if the team is reducing it steadily. A backlog of 80 tickets can be dangerous if new work keeps arriving faster than the team can close it. This is why burn-down rate belongs next to your backlog and queue velocity views in any Zendesk operations review.

This guide shows how to build a practical burn-down report in Zendesk, how to interpret the trend, and what to do when the number stays negative for too long.

What backlog burn-down rate actually measures

Backlog burn-down rate is the net change between tickets leaving the queue and tickets entering it over a defined period.

The simple version is:

Tickets solved - tickets created

If the result is positive, the queue is shrinking. If it is negative, the queue is growing. If it stays near zero, the team is roughly matching incoming demand but not making progress on older work.

That is why burn-down rate is more actionable than backlog size alone:

backlog size is a snapshot
burn-down rate is momentum
momentum tells you whether the current operating model is sustainable

For the metric definition, see backlog burn-down rate.

Why support teams should track it

Burn-down rate is useful when support leaders need to answer questions like:

Are we actually recovering from the backlog, or just holding it steady?
Did the extra staffing or routing change work?
Is a recent incident still creating downstream queue pressure?
Which group is reducing old work and which group is falling behind?

Small teams especially benefit from this metric because it turns a vague feeling of “we are not catching up” into a measurable trend.

How to build the report in Zendesk

The cleanest version combines inflow, outflow, and backlog context in one weekly view.

1. Start with ticket inflow and outflow

Use the Support: Tickets dataset in Zendesk Explore and trend:

tickets created
tickets solved

Break the report out by week. Weekly views are usually easier to interpret than daily views because daily support traffic is noisy.

2. Create the net change view

Build a calculated metric or comparison view that shows:

Solved tickets - created tickets

This becomes your burn-down rate line. Positive values mean recovery. Negative values mean the queue is taking on more work than it finishes.

3. Pair it with historical backlog

Burn-down rate is much more useful when reviewed next to your historical backlog trend from the backlog history dataset. That gives you:

current direction from burn-down rate
actual queue size from backlog history

If burn-down turns positive but backlog stays high, the team is recovering slowly. If burn-down stays negative while backlog grows, the queue problem is worsening.

4. Segment by the operating dimensions that matter

Your most useful cuts are usually:

group
channel
priority
ticket form
issue type or root-cause tag

This tells you whether the negative burn-down is company-wide or isolated to one workflow.

The most useful report layouts

Weekly burn-down trend

This is the core chart. One line per week showing net queue change.

Good use: seeing whether the last six to twelve weeks show recovery, stability, or deterioration.

Burn-down by group

This is how you find the hidden lagging queue. Overall burn-down can look healthy while one specialist group is steadily falling behind.

Burn-down next to backlog aging

If burn-down is slightly positive but backlog aging is still getting worse, the team may be closing newer easy tickets while older hard tickets continue to stall.

Burn-down by priority

This helps answer a more important question than “is the queue shrinking?”:

Is the right part of the queue shrinking?

If low-priority work is burning down while urgent tickets stay flat or grow, the team is not actually reducing risk.

How to interpret the patterns

Positive burn-down, flat backlog

Usually this means recovery has only just started, or the positive weeks are not yet large enough to materially reduce the queue. Stay the course, but watch consistency.

Positive burn-down, aging still rising

The team may be clearing fresh tickets faster than old ones. Review the oldest backlog separately so “recovery” does not become a story about ignoring stale work.

Flat burn-down, high backlog

This is maintenance mode. The team is keeping up with new demand but not making progress on accumulated work. If leadership wants the queue lower, the team needs either temporary extra capacity or a narrower work scope.

Negative burn-down with stable ticket volume

This often means throughput or workflow quality has slipped, not just demand. Compare against resolution time, reopen rate, and group reassignment rate.

Negative burn-down in one queue only

That usually points to a local issue:

routing mismatch
understaffing in one specialty
a product area generating harder tickets
weak self-service for one category

Common mistakes

Reviewing only the net number. A burn-down rate of zero can hide unstable swings between high inflow and high outflow.
Using daily charts as the primary operating view. Daily support activity is too noisy for most staffing decisions.
Ignoring ticket quality. You can improve burn-down on paper by solving tickets too quickly and pushing more work into reopened tickets.
Not segmenting the trend. One healthy queue can hide another queue that is steadily getting worse.
Treating positive burn-down as permanent. Temporary recovery during an all-hands week does not mean the system is fixed.

What to do when burn-down stays negative

When the burn-down rate remains negative for several periods in a row:

Check whether ticket volume or ticket complexity changed.
Compare inflow vs outflow by group to find where the gap opened.
Review whether first response time and resolution time worsened at the same time.
Audit routing, triage, and backlog prioritization before assuming the only answer is more headcount.
If the queue truly needs recovery mode, set a target weekly burn-down and review it in the weekly support ops review.

The important point is that burn-down rate should trigger action, not just reporting. It tells you whether the current queue policy is working.

Where it fits in your dashboard

Burn-down rate works best beside:

Together, those views answer four different questions:

how much work is open
whether new work exceeds completed work
whether old work is getting stuck
whether the overall queue is improving

FAQ

What is a good backlog burn-down rate? There is no universal target. The right target depends on queue size, staffing, and how quickly leadership wants backlog reduced. The most important signal is trend consistency.

Should I review burn-down daily or weekly? Weekly is the best default for support operations. Daily views are useful during incidents or recovery sprints, but they are too noisy for normal management.

Can burn-down rate replace backlog size? No. Burn-down rate shows direction. Backlog size shows magnitude. You need both.

What if burn-down is positive but CSAT falls? That can mean the team is improving queue speed by resolving too aggressively or by neglecting quality. Pair burn-down with CSAT and reopen reporting so you do not optimize the wrong outcome.

See whether your Zendesk queue is actually recovering - start free