Swap, Don't Troubleshoot: The Case for Spare Pools
Every hour spent diagnosing a device in front of its user is the most expensive hour in IT. The airlines solved this decades ago: exchange the unit, restore the operation, and do the diagnosis where nobody's waiting.
There are two ways to respond to a dead device.
The first is to fix it where it lies: remote in, ask questions, try things, order the part, schedule the visit. This is how most IT support is structured, and it has a property nobody prices in — the user is down for the entire duration of the diagnosis, and diagnosis is the least predictable step in the whole process. The ticket might close in twenty minutes or three days, and no one can tell you which at the moment it opens.
The second is to exchange it: get a known-good replacement into the user's hands, restore them to work, and diagnose the failed unit later, at a bench, on nobody's clock. Aviation has run on this model for decades — a plane at the gate with a failed component gets a serviceable unit swapped in and departs, while the failed part goes to a shop. The industry that prices downtime most honestly chose the swap. That's not a coincidence.
The difference between the models isn't repair skill. It's where the waiting happens.
The economics, honestly
Fix-in-place couples the user's downtime to the failure's complexity. Simple failure, short outage; weird failure, long outage. Your downtime cost is a lottery drawn per incident. The support process can be excellent and the user still eats every minute of an unlucky draw.
Swap-then-diagnose decouples them. The user's downtime is the time it takes to physically deliver and exchange a staged, pre-configured unit — a number that logistics can drive down to minutes-or-hours and, critically, hold constant regardless of what actually broke. Failure complexity still exists; it just gets paid at the bench, where a minute costs a technician's minute instead of a technician's minute plus an idle employee, an empty exam slot, or a stopped station.
The standard objection is that spares are idle capital — machines "doing nothing" on a shelf. That framing has it backwards. The spare pool is downtime insurance, and its premium is a handful of devices; the payout is every hour of payroll and revenue that didn't burn while someone diagnosed a mainboard in front of a waiting employee. Run the arithmetic from your own second ledger — incidents per year times hours saved per incident times what an hour costs — against the carrying cost of the pool. For any organization where people or lines wait on devices, the pool wins by a wide margin. What's actually expensive is the fleet's invisible spare pool: the drawer of maybe-working machines every office accumulates, uninventoried, unimaged, and never ready when needed.
What makes a swap program real
A pile of extra laptops is not a spare pool. The model only delivers its economics when four conditions hold:
Spares are known-good, per role. A spare that needs hours of setup on arrival just relocates the outage. Pool units are maintained at the current configuration for the roles or stations they back — ready to sign in, not ready to begin a project.
Placement matches density. Where the fleet is concentrated — a large site, a campus, a plant — spares staged at or near the site make same-day exchange the norm. Where the fleet is scattered — remote workers, small offices — a depot pool with fast shipping is the honest model, and next-day is the realistic promise. Pretending every location can have on-site same-day service is how programs discredit themselves; matching the promise to the density is how they keep it.
The loop closes. The failed unit doesn't vanish into a drawer. It returns on a tracked path to a bench, gets diagnosed and repaired or retired, is wiped with certification either way, and re-enters the pool. A pool that only drains is a countdown; the reverse leg is what makes it an operation instead of a stockpile.
Someone owns the pool as inventory. Serial numbers, stock levels, replenishment triggers, condition. The pool is a supply chain in miniature — which is exactly why it fails when it's a side duty of a help desk and works when it's run by a logistics operation.
The metric that proves it
A swap program makes one number auditable: time-to-working-device. Not response time, not ticket age — elapsed time from failure report to user-productive. Under fix-in-place, that number is a wide distribution with an ugly tail. Under a real swap program, it collapses toward the physical delivery time and stays there, incident after incident, regardless of what broke.
That's also why this model can be proven rather than pitched: run it on a defined slice of the fleet for thirty days and read the number. Either the distribution collapses or it doesn't.