A break/fix backlog grows when broken devices enter the repair loop faster than repaired devices leave it, and the cause is almost always one stage of that loop rather than the volume of failures. The five usual bottlenecks are no spare pool, slow repair turnaround, no tracking of where devices are, repeat failures from an aging fleet, and nobody owning the queue. Find the stage that holds the days, and the backlog stops growing.
If you’re the IT manager or director at a multi-site Canadian operation watching a device repair queue that only gets longer, this post gives you a way to diagnose which bottleneck is yours in a week, the process fixes that clear each one, and the signs that the queue needs a different owner rather than a better process.
Key takeaways
- A growing repair backlog is a throughput problem, not a volume problem. Reducing failures is the slow lever. Clearing the slowest stage of the repair loop is the fast one.
- Five bottlenecks cause nearly every growing backlog. No spares, slow turnaround, no tracking, repeat failures, and no queue owner. Each has one confirming question.
- The number to measure is days from ticket opened to device back on a worker’s belt. Vendor turnaround is usually the smaller part of it.
- Thirty tickets and five timestamps will diagnose it in a week. No dashboard required.
- Process fixes clear one stage at a time and cost IT hours. When the same stage refills within a quarter, the fix is changing who owns the queue.
What a break/fix backlog is and why it grows
A break/fix backlog is a stock, and a stock only grows when inflow exceeds outflow. Inflow is set by fleet age, working environment, and how devices are handled. Outflow is set by how quickly a broken device moves through five stages, which are report, triage, ship, repair or replace, and return with apps and enrolment working.
Most IT teams try to reduce inflow first, with better cases and user training. Inflow is the slow lever. Outflow is where the days hide, and it’s almost always one or two stages of the loop rather than all five.
The one metric to measure before anything else is days from ticket opened to device back in a worker’s hands, which is the full repair loop. Days at the repair vendor, the number most teams track, is usually the smaller part of it.
For a full explanation of what break/fix covers across that loop, the complete guide has it. This post is about why the loop jams.
The five bottlenecks behind a growing device repair backlog
Nearly every growing device repair backlog traces to one or two of five bottlenecks. Each shows up differently, and each has a single question that confirms whether it’s yours.
| Bottleneck | How it shows up | Confirming question | Stage it blocks |
|---|---|---|---|
| No spare pool | Every repair is also an outage; sites escalate and the queue is worked by who shouts loudest | Does the worker get a working device before the broken one leaves the building? | Triage and ship |
| Slow repair turnaround | The only stage with a visible clock, so it gets the blame; shipping legs often exceed bench time | Is the vendor’s receipt-to-ship time larger than your own ticket-to-ship time? | Repair |
| No tracking | Devices sit in drawers, boxes, or at the vendor with no return date; the visible backlog understates the real one | Can you say right now where every open-ticket device physically is? | Ship and return |
| Repeat failures | The queue refills as fast as it clears; the same serials keep returning | Do a fifth of your tickets come from a tenth of your devices? | Report (inflow) |
| No queue owner | Repair logistics is done in the gaps of other jobs and stalls whenever a project lands | Who would process the queue next week if your coordinator were away? | Every stage |
No spare pool, so every repair becomes an outage
Without a spare pool, a broken device and an idle worker are the same event. The repair ticket carries a productivity cost every hour it’s open, so sites escalate, IT expedites, and the queue gets worked by escalation rather than by sequence.
If a worker doesn’t get a working replacement before the broken device leaves the site, the backlog isn’t a repair problem yet. It’s a spares problem, and the post on why sites keep running out of working devices covers how a spare pool changes the loop.
Slow repair turnaround at the vendor or depot
Slow repair turnaround is the bottleneck everyone assumes they have, because it’s the only one with a visible clock, and it’s often not the biggest one. A device can spend three days at a repair depot and twelve days getting there and back.
Ask for the vendor’s actual turnaround on your last 20 repairs, measured from receipt to ship, and compare it with your own ticket-to-ship time. If the vendor’s number is smaller than yours, the vendor isn’t the problem. If it is, the reasons repairs take weeks are usually in the handoffs, not at the bench.
No tracking, so devices sit in limbo
A device that nobody can locate is a device that nobody is working on. When the only record is a ticket queue and an email thread, broken devices accumulate in drawers at the site, in a box at head office waiting for a courier, or at the vendor with no return date.
Here’s what actually happens. The ticket says “sent for repair” and closes, the device comes back weeks later to the wrong site or never comes back, and a new ticket opens for a new device. The backlog you can see understates the real one, because the limbo devices aren’t in it.
Repeat failures returning the same devices
A backlog that refills as fast as you clear it is usually being fed by a small share of the fleet. Devices past their security update window, units with worn batteries that get swapped and returned, or one model that fails under one site’s conditions will cycle through the queue repeatedly.
B2M Solutions’ 7th Annual State of Enterprise Mobility report (a vendor-published survey of 671 companies in the US and Europe, fielded November 2025) found that nearly 9 in 10 IT leaders say devices replaced in the field are often healthy on further testing, and over half say 20% or more of returned devices had nothing wrong with them. Every one of those units took a slot in the queue, a shipping leg, and a technician’s time.
Pull the serial numbers on your last 90 days of tickets and count how many appear more than once. If a fifth of the tickets come from a tenth of the devices, the fix is diagnosis and refresh planning, not more repair capacity.
No queue owner, so repair logistics happens in the gaps
Repair logistics is physical, constant, and rarely anyone’s main job. It gets done by the help desk between tickets or by a coordinator who also runs onboarding.
The same B2M survey found that 85% of IT leaders say fixing a frontline device problem takes 30 minutes or more each time it occurs, and that most frontline disruption never becomes a ticket at all. That’s a non-Canadian figure, but the pattern is familiar. The queue grows quietly because the work happens in the gaps of other jobs, and the gaps shrink whenever a project lands.
If the honest answer to “who runs the queue next week if the coordinator is away” is nobody, ownership is the bottleneck, and the backlog will keep growing no matter how good your vendor is.
How to find your repair backlog bottleneck in one week
You can diagnose a growing repair backlog with 30 recent tickets and five dates, without a dashboard or a new tool. One gap between stages will dominate, and that gap names the bottleneck.
- Pull the last 30 closed repair tickets, or open tickets older than two weeks if you don’t close many.
- Record five timestamps for each. Reported, triaged (someone decided what to do), shipped out, back from repair or replaced, and back in a worker’s hands with apps and enrolment working.
- Add up the days between each pair. One gap will dominate. That gap is your bottleneck, and it maps to a row in the table above.
- Count the serial numbers that appear twice. Repeat offenders point at the fleet, not the process.
- Count the tickets that lost a device along the way. Any ticket where the device’s location was unknown for more than a day is a tracking failure.
What the diagnosis looked like for a Canadian freight carrier
For one Canadian freight carrier we work with, the diagnosis wasn’t a slow vendor. Its handheld fleet was approaching six years old and failing regularly in the field, repairs ran through an IT team that had other work, and failures were outrunning the queue.
That is two bottlenecks compounding, an aging fleet feeding repeat failures into a queue nobody had capacity to run. The answer was a planned fleet replacement, about 800 devices across its depots in six weeks, paired with a managed repair loop, rather than more effort on the old queue.
How to reduce a break/fix backlog by fixing the process
You reduce a break/fix backlog by clearing the one stage the diagnostic pointed at, and each process fix clears a specific bottleneck. If your team can own the fix week after week, these are cheaper than changing the model.
| Process fix | Bottleneck it clears | What it costs | Just know that |
|---|---|---|---|
| Spare pool, sized to failure rate and sited where workers are | No spare pool | Device capital plus someone to manage and refill it | A spare pool without a working repair loop moves the backlog into the spares cupboard, which empties within a quarter |
| Single intake path, one form or address every site uses | No tracking (at the front) | An afternoon to set up, ongoing enforcement with sites | Devices that arrive in a box with a sticky note can’t be tracked, however good the sheet is |
| Asset record with serial, site, ticket, stage, and date for every broken device | No tracking (in the middle) | Updating five fields at every handoff | It doesn’t need to be a platform; a shared sheet exposes stuck devices within a week if it’s kept current |
| Triage before shipping, a ten-minute check of battery health, OS version, and app state | Repeat failures and no-fault-found returns | Ten minutes per ticket from someone who knows what to check | Catches the healthy devices that would otherwise ride the repair loop; it doesn’t fix an aging fleet |
Triage is the fix most teams skip and the one with the fastest payback, and the proactive support strategies that reduce downtime post covers how to run it.
What all four fixes cost is IT time, and that’s the honest limit. The cost of managing devices in-house is mostly hours, and these fixes add hours to the same people whose gaps the backlog already lives in.
When device repairs shouldn’t be an in-house IT job
Device repairs stop being a sensible in-house IT job when the process fixes need capacity the team doesn’t have, and the signs are consistent. You’ll usually see more than one of them.
Sites across several provinces, so shipping and spares have to be managed in multiple places. Rugged devices that need a certified depot. A queue that has had three owners in two years, or a fleet old enough that repeat failures are the norm.
If that’s you, the question stops being how to run the queue better and becomes who should run it. A managed lifecycle program takes the physical loop (intake, triage, repair logistics, spare pool management, asset tracking, and return) and runs it as its job, with repair turnaround reported rather than guessed. The decision guide on outsourcing device lifecycle management works through the full in-house versus outsourced comparison, including when in-house is the right call.
Repair backlogs in multi-province Canadian fleets
A Canadian fleet spread across provinces accumulates most of its repair-loop days in shipping, because every leg is a courier leg and every site needs its own spares. A device that crosses the border for repair adds customs handling and chain-of-custody questions on top, which matters for any unit that still holds corporate data.
That’s why in-country repair and advance-exchange spares shorten the loop more for a multi-site Canadian fleet than for a single-campus one.
Where PiiComm fits
Clearing the repair backlog is the work we do inside our lifecycle management program. Break/fix is handled as part of the loop, with repairs, advance-exchange spares, and asset tracking done by our own technicians in Canada, so the queue has an owner whose only job is to keep it moving. It fits multi-site Canadian fleets of rugged and shared devices where IT is carrying repair logistics on top of its real work.
It doesn’t fit everyone. A single-site fleet with a low failure rate and a coordinator who owns the queue will usually do better with the process fixes above. The same goes for fleets small enough that a managed program is more than they need.
Questions IT leaders ask about device repair backlogs
Why is our device repair backlog growing?
Because devices are entering the repair loop faster than they’re leaving it, and one stage is holding the days. The usual causes are no spare pool, slow turnaround, no tracking of where devices are, repeat failures from an aging fleet, or nobody owning the queue. Measure the days between report, triage, ship, repair, and return to find which one is yours.
How do I reduce a break/fix backlog?
Clear the one stage of the repair loop that holds the most days. A spare pool clears the no-spares bottleneck, a single intake path and a five-field asset record clear tracking, and triage before shipping clears repeat and no-fault-found returns. If the same stage refills within a quarter, change who owns the queue rather than adding another fix.
How many spare devices do we need to stop the backlog?
Enough that a worker gets a working device before the broken one ships, at every site. The number depends on your failure rate, repair turnaround, and how many sites you cover, so size it from your own ticket history rather than a rule of thumb. A spare pool only works alongside a repair loop that refills it.
Should device repairs be handled in-house?
In-house works when the fleet is concentrated, failures are infrequent, and someone owns the repair queue every week with a backup. It stops working when devices are spread across provinces, rugged units need a certified depot, or the queue is run in the gaps of other jobs. At that point a managed lifecycle program is worth comparing.
How long should a device repair take?
Measure the full loop, from ticket opened to the device back in a worker’s hands, not just time at the repair bench. Vendors usually quote the bench time, and the shipping and handoff days around it are often larger. Set a target for the full loop and track every ticket against it.
What should we track for every broken device?
Serial number, site, ticket number, current stage (reported, triaged, shipped, repaired or replaced, returned), and the date of the last stage change. With those five fields updated at every handoff, stuck devices become visible within days and repeat offenders show up by serial.
What is a no-fault-found return and why does it matter?
A no-fault-found return is a device sent for repair that tests healthy on arrival. It matters because every one takes a repair slot, a shipping leg, and a technician’s time while the worker goes without a device. A ten-minute triage of battery, OS, and app state before shipping catches most of them.
Where to start
Pull 30 tickets and five dates this week, find the stage that holds the days, and clear that one. If the same stage refills within a quarter, the backlog isn’t telling you the process is wrong. It’s telling you the queue needs an owner whose job it is.
References
- B2M Solutions, 7th Annual State of Enterprise Mobility Report (2026, survey fielded November 2025). No-trouble-found return rates, time to fix frontline device problems, unreported disruption. Vendor-published; US and European sample.