Support-ticket backlog reporting

A support backlog is the work still open at a particular moment. It is the best place to see customers at risk now, but only if the report shows what is old, unowned or blocked. A single “open tickets” number can fall because cases were solved well, or because a rule closed them too soon.

Zendesk's backlog history dataset is explicitly a dated snapshot of unsolved tickets. Freshdesk's backlog report focuses on unresolved trends and bottlenecks. Both reinforce a basic reporting discipline: define the population and the snapshot time before comparing days.

Define the snapshot

Choose which statuses count: new, open, pending customer, on hold, awaiting an internal team, or reopened. State the time zone and snapshot time, such as close of each support day. Compare the same time on each day; a morning count and an evening count describe different operational states. If the platform's unsolved category includes waiting-on-customer cases, retain that total but display a separate “agent action due” view.

Backlog is a count, not a percentage. To understand movement, reconcile opening backlog + new work − resolved work ± reopens, merges and other adjustments = closing backlog. This reconciliation can be imperfect if the tool changes historical status after a reopen or import, so check the calculation against the actual snapshot. Zendesk documents how reopens can move solved counts between periods.

Ageing is the useful part

Group unresolved tickets into consistent age bands measured from creation, and add time since last meaningful action. A five-day-old case with a scheduled supplier update is different from a five-day-old case nobody owns. Show each ticket's customer-facing owner, next action and next update time. A daily sweep should begin with unassigned work, overdue promises and the oldest high-risk cases.

Split by issue type and blocker. If returns investigations build up while routine password resets clear, an overall backlog average hides the true bottleneck. For a small team, a short table of the ten oldest cases can be more actionable than an elaborate chart. If the same reason appears repeatedly, connect it to a knowledge-base or workflow fix.

Diagnose a growing queue

Compare arrivals and resolutions for like periods, then inspect capacity and case mix. A promotional week may create more tickets than the team can clear. A new routing rule may leave cases unassigned. A change in status policy may increase the counted backlog without changing real customer waits. Annotate these events rather than assuming an agent productivity problem.

When work exceeds capacity, prioritise by harm and promise, not simply by newest ticket. Move ownership, change coverage, communicate delays honestly and remove preventable contact causes. Pair the backlog with first-response time and resolution time to see whether customers are waiting to be heard or waiting for an outcome.

For example, a queue can rise from 40 to 55 even when the team has replied quickly to every new ticket. If new contacts outnumber completed cases, the issue is sustained clearing capacity or preventable demand; if the extra 15 are old supplier investigations, the problem is an escalation dependency. Compare the opening and closing snapshots, read those cases and assign the next customer update. A blanket “work faster” instruction would miss both causes.

Review the oldest cases daily until they move. A ticket with no owner or next action should be treated as an operational exception, even if the overall backlog is small. Conversely, a larger queue of clearly owned, scheduled follow-ups may be less risky than a smaller queue containing neglected urgent work. Report both the total and the exceptions.

Sources

• Zendesk: Support and backlog metric definitions
• Freshdesk: curated backlog reporting
• Zendesk: report and export discrepancies

The reconciliation example and management guidance are Support Sorted's editorial judgement.