One robot's status fits in an operator's head. Ten robots across three sites exceed any head - which units are charged, which are mid-task, which reported a fault at 2 a.m., which is due a joint inspection - and the cost of not knowing is paid in availability: robots idle that were believed busy, faults discovered at the moment of need, maintenance done by calendar superstition rather than by condition. A fleet's economics are decided by its working hours, and working hours are decided by how well the operation is remembered. That memory is the platform.
The Fleet Problem Is a Data Problem
A robot operation and maintenance platform holds the fleet's single record: every unit's state, location, task, health and history, queryable by the people who run the programme and summarised for the people who fund it. Booster's platform layer - the operation and scheduling platform family - is built to this brief across our humanoid, quadruped and baggage fleets, because our customers' second purchase decision is always about the fleet, never the unit.
Alerts: Triage, Not Noise
Fleet alerts arrive as a stream; the platform's first job is to make the stream decidable. Severity is assigned by consequence, not by sensor enthusiasm: a safety stop outranks a missed reading, which outranks a low-battery notice that the schedule already handles. Alerts carry their evidence - position, imagery, the telemetry around the event - so the operator's first look is usually the deciding look. And every alert's resolution is recorded, building the dataset that later answers the only alert question that matters: which of these are becoming more frequent, and on which units?
This is the operational twin of the behaviour-analysis discipline on patrol robots: the goal is a stream a human trusts. Alert fatigue is a platform failure, not an operator failure, and it is engineered against with thresholds, grouping and honest severity - the same care whether the fleet is two quadrupeds on a campus or a hall of baggage robots under the scheduling and traceability platform.
Maintenance Planning From the Robots' Own Telemetry
Robots report on themselves continuously: joint loads and temperatures, battery cycle counts and charge behaviour, actuator hours, fall and intervention events, task success rates by route. Read as trends rather than snapshots, these are maintenance signals - the joint whose load profile is drifting, the battery whose capacity is fading ahead of its siblings, the route whose failure rate is climbing since a floor was resurfaced. A platform that surfaces these trends converts maintenance from reactive (fix what broke, during the shift it broke in) to planned (service what is drifting, during the window chosen for it).
The financial translation is direct: planned maintenance is cheaper than emergency repair in parts, freight and cancelled work alike, and availability - the fleet's saleable product - rises because downtime moves to scheduled hours. Booster's platform roadmap treats this telemetry layer as core product, and our delivery programmes include the operating rhythm: weekly fleet review, monthly trend report, spares decisions taken from data rather than from anxiety.
The Reporting Layer: Evidence for the Next Budget
Robot programmes live inside institutions, and institutions renew what they can see. The platform's reporting layer turns operations into evidence: rounds completed, readings delivered, exceptions handled, availability achieved, incidents and their timelines. For a baggage fleet, the same layer holds the full-process traceability record of every bag; for a patrol fleet, the dated condition and security record of the estate. These reports are what a programme manager carries into the budget meeting - and they are the reason platforms, not robots, are what customers describe as indispensable by year two.
Evaluate any platform on this layer with your own questions in hand: show me last month's availability by unit; show me every alert from one night and how each closed; show me which assets are trending toward service. A live demonstration against those questions separates a management system from a monitoring screensaver in about four minutes.
Data Ownership and the Long View
A final, contractual point: the fleet's data - routes, readings, imagery, telemetry, history - is the customer's operational asset, and the platform agreement should say so plainly, including exportability. Programmes change vendors more easily than they change histories, and an operator locked out of their own record has lost the fleet's memory in the only sense that matters. Booster's platform terms are written on that principle.
