On this page
A support dashboard can show an improving average response time while a small group of customers waits longer every week. Completed tickets are easy to measure because they have an ending event. Unresolved work needs its own view, otherwise the cases most in need of attention can disappear from a reassuring average.
A backlog age review asks what remains open at a defined moment, how long it has been waiting, and what action could move it forward. It is an operating review, not a competition to close the largest number of records. The useful outcome is fewer unresolved needs and clearer ownership of the ones that remain.
Define the population before calculating age
Write down which records count as backlog. You might include all unresolved customer requests, or maintain separate views for new requests, work awaiting an internal decision, and work awaiting customer information. Keep those definitions stable enough to compare one review with the next.
Include the snapshot time and time zone. A count taken before the morning intake is not directly comparable with one taken after the afternoon peak. If you change channels, ticket types, or status mappings, annotate the change rather than presenting the series as uninterrupted.
Do not quietly remove difficult cases from the report by moving them into an excluded status. If a case remains unresolved for the customer, the operating view should explain where it went and who is responsible for the next action.
Use more than one clock when they answer different questions
Elapsed age from creation describes how long the request has existed. Time since the last meaningful action describes how long it has been idle. Business-hour age describes waiting within a defined service schedule. These are different measures, not interchangeable labels for the same experience.
For example, a request created late Friday and reviewed Monday morning may have a large calendar age but little business-hour age. Both can be useful: the customer experienced the weekend, while the staffing promise may apply only during stated hours. Show which clock supports which decision.
A meaningful action should be defined deliberately. An automatic tag update or an internal note saying “still checking” may change a record's updated timestamp without advancing the request. If you use last-updated time as a proxy for progress, state that limitation and inspect the underlying events.
Do not substitute completed-ticket metrics for live waiting
Read the provider's metric definitions before building a report. Zendesk documents that native duration metrics measure defined event pairs and can remain null until the required events occur. A null value is therefore not necessarily zero waiting time.
Its first-reply metric also describes a specific response event, with calendar and business-hour variants and channel details. That metric can answer how long an initial reply took; it cannot by itself answer whether the customer's problem is now resolved.
Use a live backlog snapshot alongside completed-ticket measures. The customer service metrics guide covers the broader measurement set. A backlog review adds visibility into work that has not yet produced a completion event.
Group age into bands that lead to actions
Age bands make a queue easier to inspect than one average. Choose boundaries that fit the service's commitments and work types. A few hours may matter for one channel, while a multi-party investigation needs a different frame.
Label the bands precisely and avoid overlapping boundaries. For example, an illustrative calendar-age report could use less than one day, one to less than three days, three to less than seven days, and seven days or more. These are demonstration bands, not recommended service targets.
Show both counts and the total population. If the oldest band falls from twelve tickets to eight while overall backlog doubles, the result differs from a reduction achieved while incoming demand remains stable. Context prevents a single number from carrying more meaning than it supports.
Work through a small example
Suppose a fictional support team takes a snapshot of forty unresolved requests. Twenty are less than one day old, ten are one to less than three days old, six are three to less than seven days old, and four are at least seven days old. The oldest band is four out of forty, or ten percent.
During the next interval, eighteen new requests arrive and twenty-two unresolved requests are resolved. With no other changes to the population, the new backlog is forty plus eighteen minus twenty-two, which equals thirty-six. That total reduction is useful, but it does not reveal whether any of the oldest four moved.
At the next snapshot, all four oldest cases might still be unresolved and two additional cases may have aged into that band. The oldest band would then contain six of thirty-six requests, about sixteen point seven percent. Overall backlog improved while the oldest waiting group grew.
This example shows why count, age distribution, and cohort movement belong together. It does not establish a benchmark for another team or prove why those cases were delayed.
Follow an aging cohort, not only the latest chart
Take the oldest cases from one snapshot and ask what happened to each by the next review. Did it resolve, receive a substantive next step, transfer to a responsible team, or remain blocked? This cohort view exposes work that repeatedly survives each cleanup effort.
Preserve identity across merges and transfers where the system allows it. A ticket disappearing from one queue may mean it moved, not that the customer received a solution. Record the destination and whether ownership was accepted.
Avoid exporting unnecessary customer details into a separate spreadsheet. A controlled report can use ticket references and relevant operational fields while keeping sensitive content in the support system.
Classify the reason for waiting
Use a small set of actionable waiting reasons, such as missing customer information, internal approval, specialist investigation, external supplier response, scheduled follow-up, or unclear ownership. These are working categories to adapt, not diagnoses to apply automatically.
Require enough evidence to justify the status. “Waiting for customer” should correspond to a clear request the customer can answer, not an unexplained status change. “Waiting for engineering” should identify the linked issue and the agreed next update.
Separate reason from blame. A case can wait for customer information because the original question was vague or the upload process failed. Reviewing a few examples can reveal whether the support team's own process is creating the dependency.
Assign the next action and its owner
For each priority aging case, state the next concrete action, responsible person or team, expected checkpoint, and escalation condition. “Monitor” is incomplete unless someone knows what signal they are watching and when to act.
If the work needs another team, obtain an accepted handoff. Forwarding a message is not proof that the receiving team owns the request. The customer service escalation matrix helps define the appropriate route and authority.
Do not invent a resolution date to make the review look complete. A truthful checkpoint for the next update is more useful than an unsupported promise. Tell the customer what is known, what remains uncertain, and when they can expect another communication where the service process calls for it.
Check whether the queue is being optimized for the metric
Watch for patterns such as solving tickets immediately after a generic reply, repeatedly moving them between statuses, or selecting only easy requests while difficult ones age. These actions may improve a dashboard without reducing customer effort.
Pair speed measures with reopens, repeat contacts, substantive resolution checks, and a sample of conversation quality. A higher reopen rate does not automatically prove premature closure, but it gives you a concrete question to investigate.
The reopened-ticket cause review can help distinguish a genuinely new request from an unresolved original problem. Use the evidence to improve the workflow rather than assigning motive from a metric alone.
Interpret capacity and demand together
Aging backlog can reflect more incoming work, more complex work, less available capacity, a blocked dependency, or several factors at once. Compare arrivals, completions, work types, and staffing availability before choosing a response.
An average handling time from one request type should not be applied blindly to another. A short access question and a multi-system billing investigation create different workloads. Segment the data where the distinction changes a staffing or process decision.
If demand exceeds available capacity, identify what can be simplified, prevented, routed differently, or staffed appropriately. Do not present overtime or skipped breaks as the default solution. A sustainable operating plan must account for the work people can actually complete.
Make the review short enough to repeat
Prepare the data before the meeting and focus discussion on exceptions, blocked cohorts, and decisions. Keep routine individual case work in the support system. The meeting should resolve ownership and systemic obstacles, not read every ticket aloud.
Record a small action list with an owner and review date. At the next meeting, check whether those actions changed the relevant waiting pattern. If the same issue returns, investigate why the previous intervention did not alter the dependency.
Keep a note of data limitations, such as missing timestamps or a recent status migration. A report can still be useful with known limitations; pretending the fields are more precise than they are makes decisions less reliable.
Close the loop with the customer experience
After an improvement, inspect a sample of the affected journeys. Did customers receive clearer requests, fewer repeated questions, and a usable resolution? Did the oldest cases move because their needs were met, or because records were removed from the view?
Use backlog age as a signal that directs attention to unresolved work. The review succeeds when the team can explain who is waiting, why they are waiting, and what will happen next. A smaller number is valuable when it reflects that improvement in the underlying service.
Sources and further reading
Primary and contextual sources used to verify definitions or give readers a relevant next resource.
- Zendesk: Support time duration metrics Native duration metrics measure intervals between defined events and can remain null until both events occur; they are distinct from live SLA counters.
- Zendesk: Ticket reply time First reply time has a specific event definition, calendar and business-hour variants, and channel-specific details.
- GOV.UK: Using performance data to improve a service Performance analysis should connect measurements to user needs and decisions about service improvement.