A spare pool should hold enough pre-configured devices to cover every device a site loses during one full repair loop, plus a buffer for peak weeks. In practice that’s the number of devices that leave service each week (failures plus losses) multiplied by the number of weeks a swap takes to come back, so fleet size only matters through its failure rate. Where the spares sit and how far your sites are from each other change the loop length, and with it the size.
If you’re an operations leader who already knows you need a spare pool and now has to defend a number to Finance, this post gives you the sizing method, a worked example you can rerun with your own figures, the three placement models and what each does to the count, and how Canadian distance changes the answer.
Key takeaways
- Size a spare pool from the repair loop, not the fleet count. Two sites with the same number of devices can need very different pools.
- Three inputs decide the number. Devices out per week, weeks until a swap comes back, and a buffer for peak weeks.
- Shortening the repair loop shrinks the pool faster than anything else. Halve the loop and you roughly halve the spares you need.
- Placement changes loop length, so it changes size. Centralized pools hold fewer devices; distributed pools swap faster.
- Re-size every quarter from your swap log. Failure rates climb as a fleet ages, and a pool sized at deployment is too small by year four.
How to calculate how many spare devices you need
The number of spare devices a site needs is its weekly devices out multiplied by its repair loop in weeks, plus a peak buffer. It’s the same arithmetic warehouses use for any stock that has to cover demand while replenishment is on its way, applied to devices instead of parts.
Spares needed at a site = devices out per week × repair loop in weeks + peak buffer. Run it per site and per device type, then add the results up.
A flat percentage of the fleet skips all three inputs, which is why it fails in both directions. If your sites keep running short anyway, the post on why sites keep running out of working devices covers the causes. This post is about the number.
| Input | Where to get it | What pushes it up |
|---|---|---|
| Devices out per week | Help desk tickets and swap records for the last 90 days, by site and device type | Fleet age, harsh environments, shared devices, high staff turnover, no protective accessories |
| Repair loop in weeks | Days from swap to the repaired or replacement device back on the spare shelf, across your last 20 swaps | Courier legs, batching shipments, repair queues, devices returning unconfigured |
| Peak buffer | Your busiest four weeks of devices out, compared with the average | Seasonal volume, new-hire waves, winter conditions, a model reaching end of life |
Failure and loss rate by device type and site
Devices out per week counts every device that leaves a worker’s hands, whether it broke, went missing, or was stolen. Count them separately, because a broken device comes back through repair and a lost one never does.
Split the count by device type and by site. A rugged handheld in a freezer warehouse and a tablet at a head-office reception desk shouldn’t share a rate, and averaging them hides exactly the sites that run short.
Repair loop length, from swap to spare back on the shelf
Repair loop length is the time from the moment a spare goes out to the moment a working device is back on the shelf, ready for the next swap. It includes shipping the broken unit, time at the repair bench, shipping back, and configuring and enrolling the device again.
Most teams only know the bench time, which is the smallest part. The reasons repairs take weeks usually sit in the handoffs around the bench, and every day they add is a day of spare stock you have to carry. For lost devices, the loop is your procurement lead time for a replacement, which is often longer than any repair.
Peak buffer for seasonal and shift peaks
A peak buffer covers the weeks when devices leave service faster than average, so the pool doesn’t run dry exactly when the site is busiest. The simplest version is to size the pool from your peak-week rate instead of your average rate.
How large a buffer to carry depends on what an empty pool costs you. The cost of device downtime in Canadian logistics is mostly idle workers and missed scans, so a site where one missing device stops a route or a dock door earns a bigger buffer than a site where workers can share.
A worked spare pool sizing example
The worked example below shows that the repair loop moves the size more than fleet count does. The numbers are an illustration, not a benchmark, so rerun it with your own swap log.
Take a site where three devices leave service in an average week and five in a peak week. If a swap takes two weeks to come back, the base pool is six devices (three a week for two weeks). Sizing from the peak rate instead adds four more (two extra devices a week for two weeks), for a pool of ten.
Now shorten the loop to one week, by shipping the broken unit the same day and having it return pre-configured. The same site needs three devices for the base and two for the buffer, a pool of five. Nothing about the fleet changed, yet the shorter loop halved the pool.
Here’s what actually happens with a flat percentage instead. A quiet site with a large fleet holds spares that sit in a drawer for a year, and a busy site with a smaller fleet runs out by midweek. The total looks right on a budget sheet and is wrong at almost every site.
Spare pool placement models: centralized, distributed and regional hub
Where you hold spare devices sets the length of the repair loop, so placement is a sizing decision as much as a logistics one. There are three models, and most multi-site fleets end up with a mix.
| Model | How a swap works | Effect on pool size | Fits | Watch for |
|---|---|---|---|---|
| Centralized | One pool ships a spare to the site when a device fails | Smallest total pool, because one buffer covers every site | Sites within a day’s courier reach, work that can wait a day for a device | The worker goes without a device until the courier arrives |
| Distributed | Each site holds its own spares and swaps on the spot | Largest total pool, because every site carries its own buffer | Mission-critical work where a missing device stops a route, a till or a shift | Spares that go flat, go missing or get used as extra devices |
| Regional hub | Hubs serve clusters of nearby sites, with a small on-site float at the busiest ones | In between, since buffers are shared within each region | National fleets with dense clusters around a few cities and outlying sites | Someone has to own each hub’s count and refill |
The centralized model is smaller because buffers pool. A peak at one site is usually offset by a quiet week somewhere else, so one shared buffer covers what a dozen site buffers would. The distributed model gives that up in exchange for a swap that takes minutes instead of a day.
The regional hub is the usual answer for a national fleet. Size each hub with the same formula, using the combined devices out for its cluster and the loop from hub to repair and back, then add an on-site float only where a same-day swap is worth the extra stock.
How geography changes spare pool size for Canadian fleets
Distance is the Canadian multiplier on spare pool size, because every courier leg between a site, a hub and a repair facility adds days to the loop. A fleet spread across provinces needs more spares than the same fleet in one metro area, even with identical failure rates.
Multi-province fleets and courier legs
A multi-province fleet adds a shipping leg in each direction to every swap that goes through a central pool. The longer and less frequent those legs are, the stronger the case for regional hubs, and the post on supporting mobile users across the world’s second-largest country covers how that plays out operationally.
Where repairs happen matters as much as where spares sit. A device that crosses the border for repair adds customs handling to the loop and raises chain-of-custody questions for any unit that still holds corporate data. Repair done in Canada keeps the loop shorter and the custody trail simpler.
Remote and northern sites
Remote and northern sites should hold spares on site, because their courier access is limited and their loop is the longest in the fleet. When a shipment only reaches a site a few times a week, a central pool can’t deliver a same-day swap at any size.
Size these sites from their own loop, not the fleet average, and plan refills around the courier schedule rather than around each failure. Winter conditions push both the failure rate and the loop up at the same time, so the peak buffer at these sites belongs in the winter months.
Spare pool sizing for retail, logistics and healthcare fleets
The formula is the same in every industry, but the inputs that dominate it differ. Retail is driven by seasonal peaks, logistics by fleet age and route coverage, and healthcare by shared devices that never leave the unit.
Retail stores and seasonal peaks
Retail spare pools are sized by the holiday peak, not the average week, because that’s when volume, new hires and device wear all rise together. Stores rarely have IT staff, so the swap has to be something a store manager can do in minutes with a device that arrives ready.
That’s why the device decisions upstream matter. In our work with a national retailer across hundreds of stores, devices with swappable batteries arrived staged, configured and enrolled in MDM (mobile device management) before shipping, which takes battery failures and set-up time out of the store-level loop.
Logistics depots and rugged handhelds
Logistics spare pools sit at the depot and are sized by how many drivers and dock workers start a shift each day, since a device that fails on a route can’t be swapped until the driver returns. Hold the spares where shifts start, and make the swap part of the shift check-out.
Fleet age changes the number more than anything else here. One Canadian freight carrier we work with had a fleet approaching six years old with batteries swelling and hardware failing in the field. No spare pool would have kept up, and the answer was replacing about 800 devices across its depots in six weeks, which reset the failure rate the pool is sized from.
Healthcare units and shared clinical devices
Healthcare spare pools are usually held per unit, because shared clinical devices pass between staff across shifts and a unit can’t wait on a central store. Daily cleaning and constant charging raise the wear rate, so count devices out per unit rather than per hospital.
Keep the pool small and fast-cycling. A clinical spare should be charged, enrolled and ready to log into, since a spare that needs IT to set up isn’t a spare during a night shift.
How to keep a spare pool the right size over time
A spare pool stays the right size only if the refill loop runs every time a spare goes out and the count is re-checked against real swap data. The size you set at deployment is a starting point, not a standing number.
Keep every spare hot, meaning charged, staged with your apps and enrolled, so the swap is a hand-off rather than a set-up. Ship the broken unit the same day, and route the repaired device back to the pool rather than to the worker who already has a spare.
Log every swap with the serial out, the serial in, the site and the date. That log gives you devices out per week and loop length without any extra work, and re-running the formula against it each quarter will show the pool drifting before a site runs dry. Just know that failure rates climb as a fleet ages, so a pool sized in year one is usually too small by year four.
Where PiiComm fits
Spare pool management is part of our lifecycle management program. Advance-exchange spares, repairs, staging and asset tracking are handled by our own technicians in Canada, so a spare arrives staged and enrolled and the broken unit goes into a tracked repair loop that refills the pool. It fits multi-site Canadian fleets of rugged and shared devices where operations is carrying spare logistics on top of running the business.
It doesn’t fit everyone. A single-site fleet, or one with a low failure rate and short courier distances, will usually do fine running its own pool with the method above.
Questions operations leaders ask about spare pool sizing
How many spare devices should we keep?
Keep enough to cover every device a site loses during one full repair loop, plus a peak buffer. Multiply your devices out per week by the weeks a swap takes to come back, using your peak-week rate rather than the average. Run it per site and per device type, then add the results up for the total pool.
Is 10% of the fleet a good rule for spares?
A flat percentage is a budgeting shortcut, not a sizing method. It ignores failure rate, repair loop length and distance, so quiet sites end up holding idle spares while busy or remote sites run short. Use the percentage only as a sanity check on the total after sizing each site from its own swap data.
Should spares be kept at each site or centrally?
Keep them centrally when sites are within a day’s courier reach and work can wait a day for a device, since one shared buffer needs fewer spares. Keep them on site when a missing device stops a route, till or shift. National fleets usually combine regional hubs with a small float at the busiest sites.
What is a hot spare pool?
A hot spare pool holds devices that are charged, staged with your apps and enrolled in your MDM, ready to hand to a worker without any set-up. It turns a swap into a minutes-long hand-off at the site. Spares that need IT to configure them first add that set-up time to every swap.
How do we handle lost devices in the spare pool count?
Count lost and stolen devices separately from broken ones, because they never come back through repair. Their loop is your procurement lead time for a replacement, which is usually longer than a repair. Sites with high loss rates need a larger pool, or a faster replacement path, than their failure rate alone suggests.
How often should we re-size a spare pool?
Re-size it every quarter from your swap log, and again before any seasonal peak or fleet change. Failure rates rise as devices age, sites open and close, and loop length shifts with courier and repair arrangements. A pool sized once at deployment drifts out of step within a year or two.
How do we track repair turnaround for spare devices?
Record the serial out, serial in, site and date for every swap, and the date each repaired or replacement device returns to the pool. The gap between swap date and return date is your repair loop. Review it monthly by site to see where spares are waiting on shipping or repair.
Where to start
Pull 90 days of swap and ticket records, work out devices out per week and loop length for each site, and run the formula. Then look at the loop before buying more spares, because shortening it is usually cheaper than stocking for it. For how we run support after a fleet goes live, our service standard sets out the work.