How to measure support backlog and queue age

Backlog is the set of unresolved items that still require work or a decision. The count shows workload; age shows how long each item has remained open. Both must be visible. A queue can keep the same size and still deteriorate when old cases age while recent ones are solved quickly.

Define backlog before measuring it

Zendesk describes backlog as unsolved tickets and includes states such as new, open, pending, and on-hold. That reference is useful, but your operation must document its own rule. An item enters when it creates real work and leaves only when the agreed outcome is confirmed.

Separate at least three situations: waiting for your team, waiting for the customer, and blocked by a third party. All may remain in backlog, but accountability differs. Hiding “waiting for customer” can let abandoned cases age silently; mixing it with active work can distort capacity.

Choose one clock and keep it stable

Calendar age counts every minute from the eligible start. Business age counts only intervals covered by the team calendar. Atlassian documents SLA calendars and conditions that start, pause, or stop clocks, including waiting for a customer. Use that as a governance model, not as a universal benchmark.

Record time zone, working days, holidays, and pause conditions. Keep both fields when useful: total age reflects the customer experience, while operational age helps analyze time under team control. Never compare queues with different calendars without disclosing the difference.

Show the distribution, not only the average

An average can fall when many new items arrive even while the oldest cases remain stuck. Show median and percentiles such as P75, P90, and P95, plus the oldest item. The 90th percentile is the value below which 90% of current items fall; it is not automatically an SLA promise.

Create buckets that match your operating rhythm, for example under four hours, 4–24 hours, 1–3 days, 4–7 days, and over seven days. Publish both count and percentage in each bucket so demand growth is not confused with queue deterioration.

Handle reopens and exclusions with evidence

A reopened conversation requires work again and returns to backlog. Preserve original age and record a new work cycle so managers can see both the complete journey and time since reopen. Zendesk distinguishes reopened tickets and provides separate reopen metrics.

Exclude tests, spam, confirmed duplicates, and cancelled items only with an auditable reason. Do not remove conversations merely to improve a number. Automated closure needs a rule, notice, and reopen path. Report excluded volume by reason because unusual cleanup can hide the real problem.

Combine age with risk and ownership

Age should not be the only priority. Combine it with impact, urgency, customer promises, dependencies, and the value of the next action. A recent incident may need attention before an old question, but the old question remains visible and has a plan.

Every item needs a queue, current owner, and dated next action. Highlight unowned work, missing next actions, and breached promises. Use the backlog prioritization guide, the conversation ownership guide, and the service metrics guide together.

Turn the dashboard into a decision routine

In the daily review, start with unowned items, missed promises, and the oldest bucket. Weekly, compare inflow, resolutions, net change, reopens, and movement between buckets. A daily snapshot shows inventory; the time series shows whether the team is recovering or accumulating work.

Validate a sample of real conversations. Confirm that state, clock, owner, and next action match what happened. If the number improves because cases were closed early and reopened later, the operation did not improve. Measurement should reward durable resolution, not administrative disappearance.