The Downtime Ledger: What a Dead Device Actually Costs
Every fleet has two ledgers. The one finance sees records what devices cost to buy. The one nobody keeps records what devices cost when they stop. The second ledger is always larger.
Every device fleet runs on two ledgers.
The first one is visible. It lives in the capital budget: what the laptops cost, what the warranty cost, what the refresh will cost in year four. Finance reviews it annually. Procurement negotiates it. Everyone understands it, because it's made of purchase orders.
The second ledger is invisible, and it's the one that actually matters. It records what happens when a device stops working: the practitioner who can't see patients, the machine operator staring at a dead panel, the new hire on day three of employment with nothing to work on. Nobody keeps this ledger, because no invoice ever arrives for it. The cost shows up as payroll paid for work that didn't happen, revenue that slipped a day, and a schedule that quietly re-sorted itself around a broken endpoint.
The first ledger is fixed and known. The second is variable and unbounded. Most IT organizations manage the first one carefully and the second one not at all.
The second ledger, by vertical
The entries look different depending on what the business does, but the arithmetic is the same everywhere: a person or a process is being paid to produce, and the device is the thing standing between them and production.
In a clinic, a practitioner without a working device is a schedule that stops moving. Run the illustrative math yourself: a provider who sees patients on twenty-minute slots loses three visits an hour while a laptop is down. Half a day of downtime isn't an IT inconvenience — it's a column of visits that either rebook into an already-full schedule or don't happen at all. The front desk going down is worse, because now nobody checks in.
On a plant floor, the endpoint is often the interface to the line itself. A dead HMI or line PC doesn't inconvenience one person — it idles a station, and depending on where that station sits in the flow, everything downstream of it. Floor downtime is measured in units that didn't ship, and unlike office downtime, it doesn't wait politely for business hours to occur.
In an acquisition, the downtime is scheduled in advance and still arrives as a surprise. Day one of a carve-out or roll-up, some number of employees sit down at desks where the device situation was somebody's row in a transition spreadsheet. Every one of them who can't work is deal-thesis value evaporating in real time, in front of new colleagues, on the most-watched day of the integration.
Different verticals, same ledger. The device was never the asset. The working person in front of it was.
Why response time is the wrong metric
Most IT service agreements measure the wrong end of this problem. They commit to response time — how fast a human acknowledges that the device is down. The second ledger doesn't care about acknowledgment. It accrues until the person is working again, and not one minute before.
The metric that maps to the ledger is time-to-working-device: the elapsed time from "this endpoint is dead" to "this person is producing again." Measured honestly, it's a physics problem, not a support problem. It's governed by three things:
- Where the spare is. If the replacement device is in a depot two shipping days away, time-to-working-device has a two-day floor no ticketing system can lower. If it's staged near the site, the floor is minutes.
- What state the spare is in. A spare that needs hours of setup after it arrives isn't a spare; it's a project. The replacement has to be a known-good configuration for that user or that station, ready the moment it's unboxed.
- Whether anyone owns the swap. A spare that exists but that nobody is dispatched to deliver, install, and verify is inventory, not recovery.
Notice what's not on that list: diagnosis. When the recovery model is a swap, the broken device's problem gets solved later, at a bench, without a human waiting on it. Troubleshooting in front of an idle employee is the single most expensive place to do it.
Reading your own second ledger
You don't need a consultant to estimate the invisible ledger. Three questions get you most of the way:
- What does an hour of stopped work cost, per role? Loaded payroll is the floor. For revenue-producing roles — practitioners, operators, salespeople — the real number is the revenue the hour was supposed to produce.
- What is your actual time-to-working-device today? Not the SLA. Pull the last ten dead-device incidents and measure ticket-open to user-productive. Most organizations that do this for the first time find the answer is measured in days.
- Multiply. Incidents per year × average hours down × cost per hour. That number is what the current recovery model costs annually. It never appears in the IT budget, and it is almost always larger than the cost of engineering it away.
The first ledger is what you pay for devices. The second is what you pay for not having a recovery operation. Once you've read both, the fleet conversation changes — from "what do laptops cost" to "what does downtime cost, and what would it cost to make it short."
That second conversation is the one we're built for.