Want help applying this guide?Ask the DripTell team
A support dashboard can improve while one customer keeps waiting. The open count falls and the median drops, yet the oldest unresolved case barely moves.
Backlog size is not enough. Measure age from a complete daily snapshot. Keep customer and actionable time visible, read the distribution, and give every overdue case an owner and next decision. Otherwise the dashboard can improve while the experience gets worse.
Start with every unresolved customer issue
Define the population before calculating anything. Include all unresolved customer work, not only the tidy queue already assigned to agents. Microsoft's backlog work-items report defines work item age as days since a case or record was created and places it beside queue, status, agent, unique case number, creation time, and priority. That combination is useful because an age without identity and operating context cannot drive a decision.
- 1Capture all open workTake one complete snapshot that includes assigned, unassigned, waiting, and blocked issues.
- 2Start two clocksPreserve total customer elapsed time and separate the time when the team can act.
- 3Expose the old tailRead the median, a high percentile, and the oldest actionable case together.
- 4Check the consequenceCombine age with priority, customer commitment, issue type, and blocker.
- 5Accept the next stepName the owner, action, and review time without resetting the original age.
Take the snapshot at the same operational time each day. Count issues, not message events. A long WhatsApp thread is one issue when the customer still seeks one outcome; two unrelated problems are two issues. This prevents busy channels from inflating the backlog.
Use a stable start event, usually when the business first knew about the issue. Do not reset it after a channel, queue, priority, or assignee change. A transfer changes ownership, not the customer's elapsed time. A clear conversation SLA queue design and reliable identity key help preserve it.
Keep two honest clocks
One clock cannot describe both the customer's wait and the team's controllable delay.
The customer elapsed clock runs from the original start until verified resolution. It answers the human question: how long has this problem existed for the customer?
The actionable clock runs only while your team can take the next meaningful step. It can pause when you genuinely need customer evidence, a supplier decision, or a planned external event. A pause needs a reason, an owner, and a review time. It should never make the case disappear.
This separation avoids two common mistakes. Leaving every clock running makes an agent appear responsible for time they cannot control. Pausing the only clock hides the customer's total wait. Keep both.
Microsoft's case handling time guidance makes a related distinction: active representative work can be five hours while the case resolves five days after creation. Your two clocks are not those product fields, but the example shows why one duration is inadequate. Write down your start, pause, and finish rules before comparing weeks.
| Backlog signal | What it may mean | Useful decision |
|---|---|---|
| Open count rises while age stays young | Demand exceeds capacity | Check demand type and protect near-term capacity |
| Median falls while the oldest tail grows | Easy work moves while hard work is stranded | Review the oldest actionable blockers |
| Customer age is high but actionable age is low | Waiting dominates the delay | Confirm owner, update, and review time |
| Actionable age clusters by issue type | Skill, authority, routing, or knowledge is missing | Fix the system constraint |
| Old cases change assignee repeatedly | Ownership moves without progress | Require acceptance and a recorded action |
Read the tail as well as the middle
An average can be pulled around by a few extreme cases. A median can hide those same cases. Use a small set of views together:
- total unresolved issues;
- median age;
- a high percentile such as the ninetieth percentile;
- the oldest actionable case;
- age bands split by priority, issue type, status, queue, and owner.
Choose age bands from your actual service commitments and operating history. Do not copy another company's thresholds. The point is to see movement and consequence, not to produce a universal green score.
First response time and backlog age also answer different questions. A quick acknowledgement may improve first response time while the underlying issue keeps ageing. Full resolution time describes completed work; backlog age exposes risk in work that is still open. You need both completed and unfinished views.
Turn old age into a next decision
An age report is useful only when it changes work. Review the oldest actionable cases at a short, regular cadence. For each one, record the customer outcome still missing, current owner, blocker, next action, and promised review time.
Do not bulk close old records merely to improve the chart. Some may be duplicates or genuinely obsolete, but each closure needs a defensible reason and, where appropriate, a customer update. The goal of a backlog recovery is verified resolution or an honest decision, not cosmetic cleanup.
Create escalation rules around consequence as well as age. An old password question and an old payment failure do not carry the same risk. Priority, vulnerability, customer commitment, and business impact should change the action, while the age clock keeps the waiting visible.
Keep the measure fair across channels
Age the issue, not the inbox. If a customer starts on Instagram, follows up on WhatsApp, and later calls, joining those records should not create three young cases that hide one old problem. Use a stable issue identifier and preserve the original known time through routing and handoff.
The reverse matters too. Do not merge unrelated issues only because they came from the same person. Identity helps connect context; it does not erase separate outcomes.
When a resolved issue returns because the outcome did not hold, apply a written reopen rule. A fair reopen-rate method can keep teams from treating a premature closure as a fresh success.
Use backlog age as a system signal, not an agent leaderboard. Old work often reveals missing authority, product defects, unclear ownership, dependency delays, or poor routing. A shared customer operations view, such as the one described in DripTell's support workflow, should make those conditions visible enough for the right team to act.
The most useful daily question is simple: which customer has waited longest for something we can do now, and who has accepted the next step?
Frequently Asked Questions
How do you calculate customer support backlog age
For each unresolved issue, subtract its stable original start time from the snapshot time. Keep total customer elapsed age and team-actionable age as separate fields, then review their distribution rather than reporting only one average.
Should waiting for a customer stop backlog age
It can pause the actionable clock when a real customer response is required. It should not stop or erase total customer elapsed time. Keep the case visible with a waiting reason, owner, and review date.
Is median backlog age enough
No. Pair the median with a high percentile, the oldest actionable case, total open work, and splits by priority, issue type, status, queue, and owner.
How often should backlog age be reviewed
Take a comparable snapshot daily and review the oldest actionable cases during operations. Critical commitments should trigger attention sooner rather than waiting for the next scheduled review.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy