The FTE Math of a Device Program
A device logistics program should be evaluated against the support labor it removes, not against the shipping spend it replaces. Here's the worksheet — filled in with your own numbers, not ours.
The most common mistake in evaluating a device logistics program is comparing it to the wrong thing.
The instinct is to line it up against the shipping and warehousing line items it obviously replaces — the freight, the warehouse space, the racks of spares nobody counts. Those numbers are visible on invoices, so they feel like the fair comparison. They aren't. A device logistics program's biggest effect is almost never on what you were already spending on logistics. It's on the support labor it quietly makes unnecessary, most of which lives on a payroll line, not a vendor invoice.
That's the number to build a framework around. Not to prove a case for us — to help finance make an apples-to-apples comparison with whatever they're evaluating.
The worksheet — five inputs, one output
This is a framework you fill in with your own numbers. Every input is available inside your organization; none of the values below are supplied, because supplying them would make this a marketing chart instead of a real worksheet. Do the arithmetic on your own fleet.
Input 1: Devices in fleet.
The total count of managed endpoints in the population you're modeling — laptops, workstations, and any workstation-class critical devices you'd include in the program. This is a number your asset system already carries. If the asset system's count is unreliable, that itself is worth noting; it's a symptom of the operating model this framework is meant to evaluate.
Input 2: Movement events per device per year.
Every device generates a predictable number of physical events across a year: it arrives, may be moved, may fail and be swapped, is retrieved when its owner leaves, is eventually refreshed. Sum the annual events for the whole population and divide by the fleet count. This is the number of movements per device per year — the fleet's core physics. It's derived below in the companion piece; for this worksheet, use whatever value your own data supports.
Input 3: Hours per event, handled internally today.
For each event type — joiner, leaver, breakfix, IMAC, refresh — estimate the fully-loaded labor hours it consumes end-to-end when your team handles it: the ticket work, the physical work, the coordination with the user, the follow-up, the asset-record updates, and the time your engineers spend on it when it escalates. Do not use raw ticket duration; use the total human hours the event consumes across whoever touches it. Weight-average across event types by their frequency to get a blended hours per event, internal.
Input 4: Hours per event, when the program handles it.
The same event still consumes a small amount of your team's time when a logistics operation is running it — the initial trigger, the approval, the coordination with the user, the record confirmation. Estimate what those residual hours look like per event type, weight-averaged the same way, to get hours per event, with program.
Input 5: Loaded cost per support hour.
The fully-loaded hourly cost of the people whose time is being displaced — salary, benefits, taxes, tooling, facilities. Your finance team already carries this figure for internal budgeting; use their number, not a guess. Different roles have different rates, and if your logistics work spans L1 through L3, use a role-weighted blend based on who actually touches this work today.
The output.
Multiply. Devices × events per device × hours per event × loaded cost = annualized labor cost of the current model. Do it twice — once with hours per event, internal, once with hours per event, with program — and the difference is the labor cost the program removes. That difference is the number to compare against the program's cost, not the shipping and warehouse line items alone.
Three things the worksheet clarifies, once you've run it
The worksheet isn't just a total. It exposes three things that most fleet conversations get wrong.
Where the labor actually goes. Most IT leaders, asked before running the exercise, will say support labor is concentrated in breakfix and joiners. When they actually classify a quarter of tickets by hours (not count), the distribution is usually different from what they expected — often with IMAC and leaver work carrying more labor than assumed, and refresh cycles hidden inside surge periods that nobody remembers to count.
How much of "headcount pressure" is actually logistics. Teams asking for another support hire are, in many cases, asking for another logistics operator disguised as a support engineer. The worksheet makes it possible to see, in labor hours, whether the growth pressure is on judgment work or movement work.
Where the honest comparison sits. The program's cost is one number. The labor it displaces is another. Those two numbers are the comparison. Freight and warehouse costs are a secondary line — sometimes higher, sometimes lower, but never the main thing. Any comparison that doesn't include the displaced labor is understating what's actually being decided.
One thing the worksheet deliberately doesn't do
It doesn't include the cost of downtime on the user's side — the practitioner not seeing patients, the operator standing next to a dead HMI, the new hire on day three without a working device. That's the second ledger, and it's covered elsewhere. Combining the two on one page tends to make the number look like a marketing exaggeration, even when it isn't.
Do the labor worksheet on its own first. If the labor arithmetic alone justifies the decision, the downtime ledger is a bonus. If it doesn't, the downtime ledger is where you look next. Both are real. Neither should be smuggled into the other.