Short answer: Fleet management software is the layer that turns a population of mobile robots into one system: it receives transport and task orders, assigns them to the right robot, manages traffic so robots do not block each other or people, schedules charging, and watches every unit's health. Above a handful of robots it stops being an accessory and becomes the product you are actually operating — the robots are its peripherals.
What the fleet manager actually does
Four jobs run continuously. Order management: transport requests arrive from a warehouse or production system, are queued, prioritised and broken into legs. Assignment: the software matches each leg to a robot by position, battery state, load capability and current task — the decision that most determines fleet efficiency, and the one buyers should watch in a live demonstration rather than a slide. Traffic management: routes are reserved and released so that robots neither deadlock in aisles nor queue uselessly at lifts and doors; in mixed traffic with people and forklifts, this layer also enforces the slowdowns and exclusions the site's safety design requires. Energy management: charging is scheduled against the work queue, so the fleet's capacity at the morning peak is a planned quantity, not an accident of who plugged in.
The multi-brand problem and VDA 5050
Single-vendor fleets are easy to manage and hard to expand: the second brand — a different robot for a different job — arrives with its own manager, its own map and its own traffic rules, and the two fleets share the building but not a brain. The industry's answer is interoperability standards, of which VDA 5050 is the most established: a public interface specification, originating in the German automotive industry, that lets a central fleet manager task and monitor vehicles from different makers. Support is uneven and versioned, so the buyer's question is precise: which VDA 5050 version, tested with which other vendors, in which reference installations? The suppliers in the software section of the directory include the independent fleet-layer vendors built around exactly this problem. The vehicle-side differences the standard abstracts away are compared in our AMR vs AGV guide.
Health monitoring and remote diagnosis
The second half of fleet software is maintenance. A fleet manager should surface each robot's state — errors, battery health, wheel and sensor warnings, software versions — as a single operations view, and log the history that lets a technician arrive with the right part. Mature operations treat the fleet layer as their maintenance system of record for the robots: mean time between failures by unit, repeat faults flagged automatically, updates rolled out in controlled waves rather than one risky fleet-wide push. When evaluating, ask to see the error history screens and an update rollout, not the map animation; uptime is made in those screens.
Integration with WMS and MES
Fleet software earns its keep at its interfaces. Upstream, it consumes orders and priorities from the warehouse management or manufacturing execution system and reports completion, exceptions and inventory movements back. Sideways, it exchanges state with doors, lifts, conveyors and charging infrastructure. The evaluation questions are unglamorous and decisive: which integrations are productised and which are projects, what the API looks like, what happens to in-flight orders when the WMS is down, and who owns an integration fault at 3 a.m. These are the same questions the wider warehouse automation stack asks of every layer — the fleet manager is where they concentrate, because everything passes through it.
Selection checks before you scale
Pilot the fleet layer at realistic disorder: simulate or stage peak order volume, a robot failure mid-aisle, a lift outage, and watch the system's behaviour, not the vendor's presentation. Confirm the scaling pricing model — per robot, per site, per order volume — because fleet software pricing decides what your fiftieth robot costs to operate. And check the exit: maps, configurations and historical data exportable in documented formats. A fleet layer you cannot leave is a landlord, and the time to learn its terms is before the fleet depends on it.
Frequently asked questions
At what fleet size does fleet management software become necessary?
A single robot or a pair can run on the maker's basic tools. Once robots share aisles, lifts and charging points — typically from a handful of units upward — uncoordinated operation wastes capacity in queues and conflicts, and a real fleet layer pays for itself. By a few dozen units it is indispensable.
Can one fleet manager run robots from different brands?
Yes, where the vehicles support a common interoperability interface such as VDA 5050, which independent fleet platforms are built around. Support varies by maker and version, so buyers should ask which standard version is implemented and where that exact combination is already running.
What is the difference between fleet management and a WMS?
The warehouse management system decides what work the site must do — orders, inventory, priorities. Fleet management decides which robot does each movement, by what route, and keeps the fleet charged and healthy. The two exchange orders and status continuously; neither replaces the other.
What should a buyer test in a fleet software pilot?
Behaviour under disorder: peak order volume, a robot failing mid-route, a lift or door outage, and recovery from the upstream system going down. Also test the maintenance views and a software update rollout — uptime is decided there, not in the route visualisation.