Every IT team holds spare laptops and almost none can say why that number. The pool grows from returned devices and shrinks when somebody needs one urgently, and the size settles wherever it happens to settle.
TL;DR
- Spare stock is capital sitting still, so the right number is the smallest one that covers your real demand.
- Three things drive it: failure rate, replacement lead time, and how lumpy your hiring is.
- Most teams hold too many in their main market and none in the markets that need them.
- A spare that is not enrolled and patched is not a spare, it is a project.
- Returned devices should be triaged on arrival, not piled up and sorted later.
- Cap the pool and record the cap, or it becomes a cupboard nobody owns.
What the pool is actually for
Spares cover four distinct demands and conflating them is why sizing goes wrong.
Failures. A machine dies and somebody needs one today. This is the demand everybody thinks of first, and across most fleets it turns out to be the smallest of the four by a wide margin.
New starters arriving faster than procurement. Someone was hired at short notice, or a start date moved forward. This is frequently the largest single source of demand and it isn’t a hardware failure at all, which is why counting failures alone gets the number wrong.
Loaners. A machine is away for repair, or somebody is travelling and can’t take their own, or a contractor needs one for a fortnight. Short-term, predictable in aggregate.
Holds. Devices preserved for an investigation or dispute. These aren’t spares at all, and keeping them in the same cupboard as the spares is precisely how a preserved device gets issued to a new starter by accident.
Sizing it from your own numbers
The calculation is simple once you’ve three figures, and all three are available from records you already hold.
Start with a count. Take your annual failure and loss rate as a number rather than a percentage. Take your replacement lead time in weeks for that market. Multiply the two and divide by fifty-two, then round up. A fleet with 23 failures a year and a three-week lead time needs roughly two machines in reserve to cover failures.
Then add for hiring. If you occasionally onboard four people in a week against a four-week procurement cycle, that burst is your real driver and it is larger than the failure number. Size for the burst you actually had last year rather than the average.
Most teams discover the honest answer is a smaller pool in the main market and a couple of machines in each market they had none in.
A team holding the wrong stock in the wrong place
A company of about a hundred and forty held nineteen spare laptops, all in its head office, all in the main market.
A year of requests showed that eleven of fourteen urgent needs had come from people in three other countries, where head office stock was useless because shipping took longer than ordering new. The nineteen machines had covered three incidents. The other eleven people had waited.
Redistributing to six in the main market and two in each of the three others covered everything with twelve devices instead of nineteen, and released seven for redeployment. Nothing was bought.
Triage returns on arrival
Most spare pools are fed by returned devices, and most are fed badly, because the machine arrives and goes into a cupboard to be dealt with later.
Later never arrives, so the pool fills with machines of unknown condition that nobody will issue because nobody trusts them. The pool looks healthy and functions at a fraction of its size.
What to do:
- Check, wipe and reimage on arrival, not on demand.
- Record the outcome against the asset, including battery condition.
- Sort into issue-ready, parts, or disposal immediately.
- Keep issue-ready machines enrolled and patched on a schedule.
- Store holds somewhere separate and labelled.
Battery condition is the one most often skipped and the one that most often makes a spare unusable. A three-year-old machine with ninety minutes of runtime isn’t a replacement for somebody who travels.
Cap it, and write the cap down
A pool with no stated limit grows, because adding to it is always easier than deciding something should go. Within a few years the cupboard holds machines two generations old that will never be issued and can’t be thrown away because nobody has the authority.
Set a number per market, write it somewhere visible, and make exceeding it the trigger for a disposal decision rather than a bigger cupboard. The cap does more work than any process.
Where a lifecycle platform helps
RemoAsset is our own product, stated plainly. Its relevance to spare stock is in-market supply: with procurement and retrieval across 80+ countries, a replacement can often be sourced inside the market, which reduces how much buffer you need to hold at all. Pricing is published, with the Subscription tier from $1,499 a year for companies with 50 to 5,000+ employees and a 60 per cent reduction on retrieval charges.
Its limits apply directly. It has no network discovery, so it won’t find hardware you forgot you owned, and an uncounted cupboard stays uncounted. It has no software licence management. And only the Subscription tier publishes a figure, with the pay-as-you-go tier quoted rather than listed. It won’t triage your existing pool, which remains a job somebody has to do once.
Workwize holds stock in its own warehouses, which is an alternative to holding it yourself. Firstbase, GroWrk, allwhere and Deel IT operate on broadly similar lines, and not one of the five publishes a rate card you can model against. The live Workwize domain is goworkwize.com.
A worked sizing
| Input | Example | Effect on the pool |
|---|---|---|
| Failures per year | 12 across the fleet | About one in reserve at a 3 week lead time |
| Largest hiring burst | 4 in one week | Four, if procurement is slower than that |
| Loaners in use at once | 2 typical | Two |
| Markets over five people | 4 markets | Split the total, do not centralise it |
| Devices on hold | 3 | Excluded, stored separately |
The checklist worth keeping
Checklist:
- A stated cap per market, written down.
- Sizing based on last year’s actual failures and hiring bursts.
- Stock held where the people are, not where the office is.
- Returns triaged on arrival with the outcome recorded.
- Battery condition checked before a machine joins the pool.
- Spares enrolled and patched on a schedule.
- Held devices stored separately and labelled.
Final Thoughts
Spare pools are rarely sized and frequently misplaced. The common pattern is too much stock in the market that needs it least, in unknown condition, with no cap and no owner.
Count last year’s actual demand, split the pool by where people are, triage on arrival and set a limit. Most teams end up holding fewer machines that work more often.
Frequently asked questions
How many spare laptops should we keep?
Count, don’t guess. Size it from your own failure count, your replacement lead time and your largest recent hiring burst, rather than from a percentage of the fleet. For most teams the hiring burst is the largest driver and the failure rate is smaller than expected. The answer is usually a modest number split across markets rather than a single central pile.
Should spares be held centrally or locally?
Locally, wherever you have a meaningful number of people and a slow replacement lead time. Central stock is useless to somebody in a market where shipping takes longer than ordering new, which is the situation most distributed teams are in without having measured it. Split the pool by where the people are.
What makes a spare unusable?
Most often an untested battery and an out-of-date build. A machine that has sat for a year needs updates, enrolment checks and a battery assessment before anybody can work on it, which defeats the purpose of holding it. Keeping spares patched on a schedule is the difference between a pool and a cupboard.
Should returned devices go straight into the pool?
Only after triage. Check, wipe, reimage and assess condition on arrival, then sort into issue-ready, parts or disposal. Pools fed by untriaged returns fill with machines of unknown state that nobody will issue, so the stock level looks healthy while the usable number is much lower.
Why should devices on hold be stored separately?
Because somebody under pressure to equip a new starter will take the nearest working machine, and a preserved device sitting among the spares is exactly that. Keep them in a different place, labelled, with a named owner and a separate list, so blundering into one requires effort rather than being the default.
How do we stop the pool growing?
Set a cap per market and write it where people can see it, then treat exceeding the cap as the trigger for a disposal decision rather than for more storage. Pools without a stated limit grow indefinitely because adding is always easier than deciding something should go, and nobody wants to be the person who threw away a working laptop.
