Managing a Mobile Computer Fleet: Beyond the Purchase

Buying rugged mobile computers is the visible cost. Managing them across a three-year deployment is the larger one, and it is the part that determines whether the fleet works in year two.

Why fleet management is not optional

Twenty devices can be configured by hand. Two hundred cannot, and the difference is not gradual — it is the point at which manual processes stop scaling.

Four things need doing repeatedly across the life of a fleet: initial provisioning, application deployment and updates, configuration changes, and recovering devices that have drifted or broken.

Without tooling, each of those is a person handling each device individually. With tooling, they are a task applied to a group.

Budget for device management before rollout rather than discovering it during. It is a common gap in mobile computer projects.

Provisioning

Getting a device from box to working state should not require an administrator per device.

Enterprise Android platforms support staged enrolment where a device joins the management system on first boot and receives its configuration and applications automatically. Setting that up takes effort once and saves it repeatedly.

Two things worth getting right at this stage.

A defined baseline. Every device should end up in a known state — same applications, same settings, same restrictions. Devices configured individually drift, and drift is what makes support difficult later.

Recovery to that baseline. A device that has gone wrong should be resettable to the standard build in minutes rather than rebuilt by hand.

Locking devices down

A rugged mobile computer is a general-purpose Android device, and left open it behaves like one.

Kiosk or single-application mode restricts the device to the applications it needs. This is worth doing for reasons beyond policy: it removes the ways operators accidentally break things, reduces support calls, and stops battery being consumed by things unrelated to work.

Controlling updates matters more than it does on phones. An operating system or application update that changes behaviour mid-shift is disruptive, and an update that breaks compatibility with your warehouse application is worse. Fleet tooling lets you test on a small group before deploying widely.

That testing step is the one most often skipped and most often regretted.

Batteries are the real consumable

The operational issue that dominates year two.

Batteries degrade with charge cycles. A fleet deployed together degrades together, so battery problems arrive across the whole fleet at roughly the same time — the same correlated-failure pattern as drives bought together.

Three things follow.

Budget for replacement batteries as a recurring cost from the start, not as an unexpected one in year two.

Hot-swap operations need more batteries than devices. If workers swap mid-shift, charged batteries have to be available where they are.

Track battery health. Many enterprise devices report it, and fleet tooling can surface which units are degrading. That turns battery replacement into a scheduled task rather than a device dying mid-pick.

Our mobile computers guide covers why hot-swap matters on multi-shift operations.

Charging infrastructure

Frequently under-specified because it is bought after the devices.

Multi-bay cradles for overnight charging, battery-only chargers for hot-swap operations, and vehicle mounts where devices are used on forklifts or in vans.

The design question is where charged batteries need to be. Hot-swap only works if a charged battery is within reach of the worker who needs it, which usually means charging points distributed around the building rather than concentrated in an office.

Spares and repair

A fleet needs spare devices, and the number is a risk decision rather than a formula.

Devices get dropped, lost and damaged. A worker without a working device is either idle or working on paper, and both cost more than a spare unit sitting in a cupboard.

Two practical points. Keep spares configured and charged, not boxed — a spare that needs an hour of setup is not a spare. And establish the repair path before you need it: whether devices are repaired under contract, replaced, or held as parts donors.

On discontinued models, the same logic applies as to end-of-life server platforms: parts availability thins over time, and a spare bought now is materially different from one you plan to buy when a device fails.

Accessories add up

Small individually and meaningful across a fleet: holsters, hand straps, screen protectors, vehicle docks and rugged cases.

Two of these earn their cost directly. Screen protectors are far cheaper than screen repairs. Hand straps reduce drops, which reduces damage.

Specify them with the devices rather than afterwards, since ordering accessories separately for two hundred units is a second procurement exercise.

Planning refresh

Fleets are usually replaced on a cycle, and two things drive the timing.

Battery and physical condition. Batteries degrade, housings crack, screens scratch, connectors wear.

Software support. Operating system support ends, applications require newer versions, and security updates stop. This is frequently the binding constraint rather than the hardware, which is often still physically fine.

Plan the refresh while the current fleet still works. A staged replacement lets you test the new devices against your applications, train workers gradually, and keep the old fleet as spares through the transition — all of which disappear if the refresh is forced by devices failing.

Common questions

Planning a fleet deployment? Tell us the device count, shift pattern and environment and we will help specify batteries, charging and spares alongside the units.