A new maintenance manager opens the work-order list on day one and finds 340 open tickets, which is enough to ruin anyone’s first morning. Then she looks closer. Half are duplicates, a third are “someday” requests with no real urgency, and the genuinely overdue critical work comes to maybe a dozen jobs. The 340 was noise. The dozen was the actual problem, and she nearly missed it while staring at the scary number.
A backlog is really a workload, even though everyone counts it in tickets. Measured the right way, it tells you a lot about how healthy your operation is. So let’s get it measured and then burned down.
What backlog actually is, and what it isn’t
Maintenance backlog is the body of identified, approved work that’s ready to do but hasn’t been done yet. Two words in that sentence carry most of the weight. Approved means a wish-list request nobody signed off on isn’t backlog, it’s an idea. Ready means a job waiting on a part that’s three weeks out isn’t backlog either. It’s parked, and counting it just makes your numbers lie.
So the first move is to clean the list. Strip out the duplicates, reject the requests that were never real work, and move the parts-blocked and approval-blocked jobs into a separate “waiting” bucket. What’s left, the approved and ready and undone, is your true backlog. It’s almost always smaller than the raw ticket count, and a lot more useful. The blocked and deferred work still matters, but it’s a different problem, and our note on deferred maintenance covers where that work goes.
Measure it in crew-weeks, not tickets
A ticket count tells you nothing about effort. Two hundred two-minute jobs and twenty all-day jobs both read as “a lot of tickets,” but one is an afternoon and the other is months of work. The only honest unit is labor hours.
So estimate the hours on each backlog job, where even a rough guess beats none, and add them up. Then divide by your crew’s available wrench hours per week. Say you have four techs and figure 30 productive hours each. That’s 120 crew-hours a week, so a backlog of 600 ready hours is 5 crew-weeks. Now the number means something. It’s how long the team would need to clear everything if no new work showed up. No new work ever stops showing up, of course, but it’s still the right yardstick.
Crew-weeks also makes the backlog comparable over time and across sites. “We’re at 5 crew-weeks, up from 4 last month” is a sentence you can act on. “We have 312 tickets” is not.
Know healthy from unhealthy
Worth saying up front, because it surprises people: zero backlog is bad. A backlog of zero usually means you’re overstaffed, or you’re not finding all the work, or you’ve got techs doing low-value tasks just to look busy. Some backlog is the buffer that lets you plan and schedule efficiently instead of jumping at every new request the second it lands.
The widely used healthy range is 4 to 6 crew-weeks of ready backlog. Inside that band you have enough queued work to plan a full week ahead and batch jobs sensibly, but not so much that work ages out before you reach it. Below 2 crew-weeks you’re probably overstaffed or scheduling hand-to-mouth. Above 8, the backlog is growing faster than you clear it. Work is aging, “ready” jobs are quietly turning overdue, and you’re sliding back toward the firefighting you were trying to escape. Watch the trend more than the absolute number. A backlog creeping up week over week is the early warning, well before any single job becomes a crisis.
Triage before you burn it down
You don’t clear a backlog by working the oldest ticket first. You clear it by working the most important ticket first, and importance comes down to two things: how critical the asset is and how urgent the work is.
A fast triage tags every backlog job by asset criticality (does this machine matter?) and by consequence of delay (what happens if it waits another month?). The jobs that score high on both, critical asset and real consequence, jump the line no matter their age. The ones that score low on both are candidates to defer on purpose or even cancel outright. A six-month-old request to repaint a railing is not more important than a two-day-old vibration warning on your main line, whatever the dates say. Sort that way and the backlog stops running you.
Burn it down without starting new fires
The usual mistake is clearing a backlog through overtime and weekend heroics. You knock it down for a month, burn out the crew, and it climbs right back because nothing underneath actually changed. Burndown has to be sustainable, or it isn’t burndown. It’s a loan.
A few moves that hold up:
- Carve out dedicated backlog hours. Reserve a fixed slice of each week, say one tech-day, for backlog only, protected from new reactive work. Steady pressure beats heroic sprints.
- Batch by location and asset. Clear five jobs in one area on a single trip instead of five separate walks. Backlog is where batching pays off the most.
- Attack the inflow, not just the outflow. A backlog that keeps growing is a generation problem. If the same asset keeps throwing reactive work, fix the root cause so the tickets stop coming. A working preventive maintenance program is the long-term cure, since it converts surprise breakdowns into planned work you can schedule. That’s the difference between a backlog you manage and one that manages you.
But what about backlog that’s actually deferred maintenance?
There’s a kind of “backlog” that isn’t really yours to schedule away, and that’s deferred maintenance, the work you know needs doing but can’t, usually for budget reasons. A roof that needs replacing. A chiller running well past its life. Lumping that into your weekly crew-week number distorts both sides. It makes the operational backlog look hopeless, and it hides the capital problem from the people who actually control the budget.
Keep it separate. Track deferred maintenance as its own list with its own dollar figure, and report it up as a capital and risk conversation rather than a scheduling one. Your crew can’t wrench away a $200,000 roof, and pretending the backlog metric covers it just buries a decision that belongs to finance. Clean separation gives you an honest operational number and a credible case for the capital you need.
Make it a number you watch, not a pile you dread
Backlog stops being scary the moment it becomes a measured trend instead of an intimidating list. Clean it, size it in crew-weeks, hold it in the 4-to-6 band, triage by criticality, and reserve steady hours to burn it down while you fix whatever keeps generating it. Once it’s a number on a chart, you can manage it like anything else.
The hard part by hand is the measurement. Estimating hours and rolling them into crew-weeks across hundreds of jobs is exactly the spreadsheet work that never quite gets done. When the work lives in one system, reports and analytics can size the ready backlog and chart its trend for you, so you see the number move week to week. Maintenance managers can stand up backlog tracking during a 30-day free trial at teamworkcmms.com and get an honest crew-week number on their own work in the first afternoon.