Maintenance is where robotics programs are won or lost
The capital approval is the easy part. The hard part starts about ninety days after go-live, when the implementation team has rolled off and the floors expect the robots to perform like any other piece of hospital infrastructure. Robots that nobody is maintaining stop moving. Robots that nobody is monitoring fail at the worst possible moment — during peak census, during an inspection, or during a leadership tour. The maintenance program is what separates a robotics pilot from a robotics capability.
This guide walks through the maintenance practices that consistently produce 95-plus percent uptime in mid-size and large U.S. hospitals, regardless of which OEMs are in the fleet.
The three layers of a credible maintenance program
1. Preventive maintenance (PM)
Preventive maintenance is the scheduled, calendar- or hours-based service that every robot in the fleet receives whether it has shown any problems or not. PM intervals typically run on three cadences: a light weekly check (sensors, brushes, wheels, bumpers), a monthly inspection (battery health, drive train, alignment), and a quarterly or semi-annual deep service (firmware updates, full diagnostics, replacement of consumables).
The single biggest PM failure in hospital robotics programs is not missed intervals — it is unowned intervals. When in-house biomedical engineering and the OEM service contract both assume the other will handle PM, neither does. The fix is a written PM matrix that names a single responsible party for every line item, every cadence, every robot.
2. Predictive maintenance (PdM)
Predictive maintenance uses telemetry from the robots themselves — battery degradation curves, motor current draw, navigation error rates, time-to-charge — to flag components that are likely to fail before they actually do. A good PdM program reduces unscheduled downtime by twenty to forty percent compared to PM alone, because the parts that would have failed catastrophically get replaced during scheduled service windows.
PdM requires three things hospitals often don’t have in-house: streaming telemetry from the fleet, a data layer that aggregates across OEMs, and someone reading the alerts daily. This is one of the strongest arguments for a vendor-neutral operating partner — the partner aggregates telemetry across the entire installed base and learns failure patterns faster than any single hospital can.
3. Corrective maintenance (the on-call layer)
When a robot stops moving, the clock starts. Corrective maintenance is measured in mean-time-to-respond (MTTR) and mean-time-to-restore. Best-in-class programs target a 15-minute remote response and a 4-hour on-site response window, twenty-four seven.
The corrective layer requires three building blocks: a remote operations team that can resolve a high percentage of incidents without dispatching a technician, a regional parts depot with the critical spares stocked at known locations, and a field service network with documented response radii.
Uptime SLAs that actually mean something
An uptime SLA is only as strong as the metric it uses and the remedy that backs it. Three rules:
- Measure scheduled hours, not calendar hours. A robot that doesn’t need to run at 3 a.m. shouldn’t be penalized for being offline at 3 a.m. SLA denominators should reflect actual mission hours.
- Use a per-robot, per-month measurement. Fleet-average uptime obscures a single robot that is consistently down. Each robot carries its own SLA.
- Tie service credits to missed thresholds. If the contract says 95 percent uptime and the vendor delivers 91 percent, the bill should reflect the gap. Without a financial remedy, the SLA is decorative.
Parts strategy: the unsung variable
Most uptime failures are not robot failures — they are parts failures. A wheel module fails, but the replacement is on a truck from another state. A battery degrades, but the replacement requires a four-week OEM order cycle. A LIDAR module drifts out of calibration, and the replacement requires a vendor-only firmware reload.
A mature program operates with three parts tiers: critical spares held on-site (the parts that go bad most frequently), regional depot inventory (within a four-hour drive of every served hospital), and OEM-sourced low-volume parts handled through contracted lead-times. The math behind which parts go in which tier comes from failure-mode analysis on the installed base — another reason vendor-neutral operating partners with a large fleet have a structural advantage.
Mixed-fleet realities
Most health systems do not standardize on a single OEM. A hospital might run one vendor’s AMRs for materials transport, a different vendor’s autonomous units for pharmacy, and a third platform for EVS-adjacent applications. Each OEM ships with its own service portal, its own ticketing system, its own technician network, and its own SLA framework.
Hospitals that try to manage three OEM contracts themselves end up with three escalation paths, three reporting formats, and no single accountability when something goes wrong. The vendor-neutral operating model collapses all of that into one team, one SLA, and one report — while preserving the underlying OEM relationships for parts and firmware.
What “good” looks like, by the numbers
- Fleet uptime: 95–98 percent measured against scheduled mission hours.
- Remote first-touch resolution: 60–75 percent of incidents resolved without a field dispatch.
- Mean-time-to-respond: under 15 minutes for any priority-1 incident.
- Mean-time-to-restore: under 4 hours for priority-1, under 24 hours for priority-2.
- Unscheduled downtime: under 2 percent of fleet hours, trending down quarter over quarter.
The takeaway
The OEM sells you the robot. Someone has to keep it running. The hospitals that get this right treat maintenance as an operating discipline — with measured SLAs, written ownership of every PM line, a real parts strategy, and a single team accountable across whatever OEMs are in the fleet. The hospitals that get it wrong assume the warranty covers everything, find out it doesn’t, and then watch the program quietly stall.
