A practical rugged-phone spare ratio should be based on how many devices can be unavailable at the same time—not on a fixed percentage copied from another fleet.
Required spares = peak concurrent replacements + repair-pipeline devices + deployment reserve
Each component measures a different risk. Combining them prevents a fleet from counting the same spare twice.
Define what counts as unavailable
A device should enter the unavailable count when it cannot perform the required workflow. Causes may include physical damage, battery or charging failure, a failed application update, enrollment problems, loss or theft, network-version mismatch, inspection quarantine, repair, or rebuilding after a security incident.
Minor cosmetic damage should not automatically count if the phone remains safe and fully operational.
Measure peak concurrent replacement demand
Historical averages are useful, but field operations fail at peaks. A fleet that averages two swaps per month may still need five replacements simultaneously if several devices fail during one event while others remain with the repair provider.
Review the highest number of swaps in one day and week, seasonal demand, new-project periods, high-risk locations, repair-return delays, and loss events. If no history exists, run a pilot and begin with a conservative temporary reserve.
Add the repair pipeline
Repair-pipeline demand = average devices sent for repair per week × average door-to-door turnaround in weeks
Use door-to-door turnaround, not bench-repair time. Shipping, claim approval, customs, parts availability and re-enrollment can extend actual downtime.
Separate operational spares from project spares
- Hot spares: charged, configured and immediately assignable.
- Cold spares: stored devices that still require enrollment or updates.
- Repair replacements: devices reserved for units already in repair.
- Deployment reserve: stock for new starters, sites or sudden expansion.
- Emergency reserve: protected stock released only during defined continuity events.
A device is not a hot spare if nobody knows its unlock status, battery condition, application version or regional configuration.
Use operational risk tiers
| Tier | Consequence | Approach |
|---|---|---|
| Low | Work can continue on paper or another device | Small centralized pool |
| Medium | Productivity falls but the shift continues | Local hot spare plus central reserve |
| High | Navigation, reporting or service stops | Multiple local hot spares |
| Critical | No substitute workflow and delay creates safety risk | Site-specific continuity plan |
Check compatibility inside the spare pool
Verify mobile bands and SIM configuration, application compatibility, device-management enrollment, authentication, accessories, charging connector, restore process, operating-system version and regional settings. Do not mix regional versions without labeling them.
Keep hot spares genuinely ready
A regular spare check should confirm that the device powers on, has no swelling or damage, launches required apps, receives current security policy, has its charger and cable, and matches the asset record. Rotate stored devices through controlled use so neglected batteries and expired credentials are discovered before an emergency.
Recalculate after material changes
Revisit the ratio when fleet size, region, repair provider, turnaround, application criticality, lifecycle stage, season, enrollment process or loss rate changes. Better automation may shorten activation time, but it does not eliminate the need for physical replacement stock.
Final decision rule
Start with the highest observed concurrent demand, add the repair pipeline, then add a risk-based deployment reserve. Round upward because partial devices do not restore a worker. Review the result against real swap data rather than treating it as a permanent industry benchmark.
Dejar un comentario
Todos los comentarios se revisan antes de su publicación.
Este sitio está protegido por hCaptcha y se aplican la Política de privacidad de hCaptcha y los Términos del servicio.