Fleet Physics: The One Number That Sizes Everything
Movements per device per year is the primitive that sizes spare pools, warehouse throughput, headcount, and budget. Everything else in a device program is downstream of it.
There's a single number that governs almost every operational and financial question about a device fleet, and most IT organizations don't know what theirs is.
It's not headcount. It's not device count. It's movements per device per year — the average number of physical events each endpoint in the fleet generates across a twelve-month window. Every serious question about how a fleet should be operated — how big the spare pool should be, how much throughput the imaging bench needs, how many people it takes to run the operation, what the annual budget shape looks like — resolves against this one variable.
When it's unknown, capacity is guessed. When it's guessed, it's wrong in one of two ways: either the operation is oversized and expensive, or it's undersized and breaks under surge. Both failure modes are common, and both come from the same root — nobody sized against the physics.
What counts as a movement
A "movement" is any physical event in the life of a device: it arrives somewhere, leaves somewhere, changes hands, or changes state in a way that requires the fleet operation to touch it. Five contributors show up in almost every fleet.
- Joiners. Every new hire in the population generates at least one device arrival, and often more than one when peripherals, docks, or secondary machines are involved.
- Leavers. Every departure generates a retrieval — the device coming back, being wiped with evidence, and returning to inventory or retirement.
- Breakfix. Every hardware failure that produces a swap generates two movements: one for the replacement out, one for the failed unit back.
- IMAC (installs, moves, adds, changes). Every desk change, room reorganization, workstation move, or peripheral addition that requires physical work is a movement, and this category is chronically undercounted because most of it never lands in the ticket system as a device event.
- Refresh cadence. Every device eventually ages out and is replaced. Amortize the refresh cycle across the fleet — a shorter cycle contributes more movements per device per year than a longer one.
The contributions are additive. Sum the annual events across the five categories and divide by fleet size, and you have the number.
How to compute yours from data you already have
The inputs live in two places you already own: the ticket system and HR.
From HR (or the identity provider):
- Joiner rate. Count the number of new hires in the population over the last twelve months. Divide by starting headcount to get an annualized joiner rate. This is the same number your HR partner uses for onboarding planning.
- Leaver rate. Same population, same window. Count departures, divide by starting headcount. HR already tracks this as attrition.
From the ticket system:
- Breakfix rate. Filter tickets classified as hardware failure or device replacement across the same window. Divide the count by average fleet size across the window.
- IMAC volume. This is the trickiest input, because IMAC tickets are often filed under generic categories. Sample the queue, classify honestly, and estimate the annualized total. If your team doesn't track IMAC at all, a walk-through with a facilities partner during a recent office change is the fastest way to reconstruct a defensible number.
From the asset system:
- Refresh contribution. Take the fleet's target refresh cycle in years and invert it. If the target is a three-year cycle, refresh contributes roughly one movement per device per year for the outbound leg — and another for the retrieval of the retired unit. If the cycle is longer, the contribution is proportionally smaller. Use your actual policy, not aspiration; many fleets run longer than policy states, and the honest number is what your asset ages show.
Sum the five contributions in the same units — annual events per device per year — and you have the fleet's movements-per-device number. Do this once and it will be the most important operational figure your program plans against for years.
What the number sizes, in practice
Once the number is on the page, the operational questions that used to be arguments become arithmetic.
- Spare pool size is a function of breakfix rate, dispatch time, and the acceptable time-to-working-device. A higher movements-per-device number, driven largely by breakfix, means a deeper pool. A fleet with low breakfix and high joiner activity needs less pool and more inbound-imaging throughput.
- Imaging bench throughput has to keep up with the sum of joiners and refresh-outs, plus the return-to-service leg of breakfixes. That's a weekly cadence to size against, not an annual one — the number tells you the average, and the peaks come from the seasonality of your business.
- Warehouse throughput — receiving, put-away, kitting, pack-out, returns processing — scales with total movements, full stop. A fleet with a high movements-per-device number is a busier facility than a same-size fleet with a low one, even though the asset registers look identical.
- Headcount on the logistics side is sized by movements per unit time, not by fleet size. Two companies with the same number of endpoints can need very different operational staffing if their movements per device diverge.
- Budget shape. The recurring cost of a device program is dominated by movement volume, not by device count. This is the reason a rate card built around per-movement pricing tracks reality better than one built around per-user or per-device subscriptions in isolation.
Every one of those decisions is being made inside your fleet right now, whether or not the number has been computed. When it's implicit, it's inconsistent — one team sizes against last year's surge, another against a quiet quarter, and neither is right for the fleet as it actually flows. When it's explicit, the whole program aligns to it.
One number, one meeting
Computing this doesn't require a project. It's a spreadsheet an IT leader and an HR partner can fill in together in an hour, using data they both already have. The point of doing it is not the number itself; it's that everyone in the room comes out of the meeting reasoning about the fleet as a flow — a population with an arrival rate, a departure rate, a failure rate, and a refresh cadence — instead of a static list of assets.
Fleet physics is what turns a device program from a series of ad-hoc reactions into a planned operation. Everything downstream — the spare pool, the bench, the warehouse, the headcount, the budget — is a consequence of one number. Compute it once, and the rest of the conversation gets simpler.