Ticket backlog age is the number of days each open ticket has been waiting, counted in bands rather than added up into one total. The total tells you how much work is sitting in the queue. The age tells you who has been forgotten. If you only report one backlog number this week, make it the count of tickets older than your age ceiling, plus the age of the single oldest ticket.
Most desks report the backlog as a count: 300 open tickets, down from 320 last week, everyone relaxes. That number is easy to pull and nearly useless on its own. A backlog of 300 tickets that all arrived yesterday is a healthy queue. A backlog of 300 where thirty customers have been waiting a month is a quiet crisis, and the total can’t tell you which one you have.
Why does the backlog total hide the problem?
Because a desk naturally works the easy, new tickets first. They’re quick, they close the same day and they make the daily count look good. The awkward tickets, the ones waiting on a vendor, a developer or a customer who never replies, drift to the bottom and stay there. The total keeps falling while the tail keeps getting older.
Here’s an illustrative example. Two teams, 300 open tickets each, and almost exactly the same average age:
| Age band | Team A | Team B |
|---|---|---|
| 0 to 2 days | 150 | 230 |
| 3 to 7 days | 100 | 40 |
| 8 to 14 days | 50 | 0 |
| 15 to 30 days | 0 | 15 |
| Over 30 days | 0 | 15 |
| Average age | 4.0 days | 4.1 days |
| Median age | 3.5 days | 1 day |
| Oldest ticket | 10 days | 31 days |
On the total, they’re identical. On the average, they’re identical. On the median, Team B looks better, because most of its queue is fresh. Only the bands show that Team B has thirty customers who have waited more than two weeks, and fifteen who have waited over a month. Those are the customers who stop renewing, and they’re invisible in every summary number except the bands.
Running a service desk for a hosted eCommerce platform, I see the same pattern every time: the new tickets are rarely the ones that hurt. Bands also only work if the tickets are classified well enough to tell you what the old ones are. If half your aged tickets sit under “Other”, fix the categories first. I covered how in building a ticket taxonomy that survives reporting.
How do you measure ticket backlog age in Excel?
Export every open ticket with its ID, priority and the date it was opened. That’s all you need. Put the opened date in column B, then:
- Age in days, column D:
=TODAY()-B2, formatted as a number, filled down. - Age band, column E:
=LOOKUP(D2,{0,3,8,15,31},{"0-2","3-7","8-14","15-30","31+"}). LOOKUP finds the largest boundary at or below the age, so a 14-day ticket lands in 8-14 and a 15-day ticket in 15-30. - Count per band:
=COUNTIF(E:E,"15-30")for each band, or=COUNTIFS(D:D,">=15",D:D,"<=30")straight from the age column. - Oldest open ticket:
=MAX(D:D), with the ticket ID next to it from=INDEX(A:A,MATCH(MAX(D:D),D:D,0)).
Three decisions make or break the sheet. Measure age from the date the ticket was opened, never from the last update, or every “just checking in” note resets the clock. Exclude tickets that are genuinely waiting on the customer only if you have a status for it and you report that pile separately. And split the bands by priority, because ten aged high-priority tickets matter more than eighty aged low-priority ones.
There’s one more number worth working out once. Little’s Law, a basic result in queueing theory that MIT teaches in its queueing models course, says the average time a ticket spends in the system equals the backlog divided by the rate you close tickets. With 300 open and 75 closed a day, the average ticket spends four days in the queue. If closures drop to 60 a day and the backlog holds at 300, that average becomes five days, even though the backlog chart is flat. A flat backlog doesn’t mean a stable desk.
What age ceiling should you set?
Set it from your own resolution targets, not from a number someone quotes at a conference. My rule of thumb is a ceiling at twice the resolution target for that priority. If a priority 3 ticket should be resolved in five working days, any priority 3 ticket older than ten working days goes on the aged list. If you already run a tiered SLA matrix, the ceilings fall straight out of it.
Then track two things weekly: how many tickets are over the ceiling, and the age of the oldest one. Both should go down. The aged count tells you whether the tail is growing. The oldest ticket tells you whether anyone owns it.
How does backlog age get gamed?
Every metric gets worked around once people know it’s watched. With backlog age, the usual ways are:
- Closing and reopening. The old ticket is closed and a new one logged for the same problem, so the age resets to zero. Count reopened and duplicate tickets alongside the bands.
- Parking in a pending status. Tickets move to “waiting on customer” without a real question being asked. Sample a few each week and read them.
- Bulk closures before the report. A Friday afternoon purge of tickets nobody contacted. Check how many closures went out with no customer reply in the last 24 hours.
The fix is the same as with any KPI: pair it with something that pulls the other way. I made that argument about picking the right KPI after the MobileMe launch, and it applies here. Backlog age paired with reopen rate is much harder to game than either one alone.
Make the oldest ticket visible every morning
The cheapest change you can make is to print, or put on the team screen, the five oldest open tickets every morning, with the owner’s name beside each. No charts, no commentary. Just the ticket, the age and the name.
It works because the oldest ticket is rarely stuck for a technical reason. It’s stuck because it fell between two people, or it’s waiting on a team nobody wants to chase. Putting a name and a number in front of the room gets it moving faster than any escalation process, and the first week you do it, expect a few tickets nobody knew they owned.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
