Summary
The purchase or monthly price is easy to compare. A machine that misses two critical shifts is harder to price, especially when staff must cover its route at short notice. That is why uptime belongs in the business case from the beginning.
Price the delivered work, including support and fallback labor, rather than the machine in isolation.
01 / Analysis
Separate available time from useful work
A robot may be powered on yet unavailable for the assigned job because it is charging, waiting for a part, stuck behind a locked door, or running a map that no longer fits the site. Define “available” as ready for the scheduled task, then define “productive” as completing work the team accepts.
This distinction prevents a dashboard uptime percentage from hiding missed work. The clock should start when a scheduled run is due and stop only when the route is complete or someone has taken over.
02 / Analysis
Build a full shift cost view
List recurring charges, consumables, setup and training time, planned service, unexpected support, and the labor needed when the robot is unavailable. Then compare those costs with the work that actually moved off the team’s schedule. A saved minute is only useful if it can be assigned to another task or changes staffing needs.
The support agreement deserves the same attention as the machine specification. Ask who responds, how quickly, what parts are stocked, how software changes are handled, and what the team does during a prolonged outage.
What to record
- Scheduled runs versus accepted runs
- Mean time to restore a failed route
- Staff minutes spent on setup and interventions
- Fallback labor and missed service windows
03 / Analysis
Use an honest decision rule
Set a minimum acceptable run completion rate before the pilot. If the robot misses it, diagnose the cause and repeat the test after a change. A cheaper machine with frequent rescue calls can be the expensive choice; a costly machine on a poorly chosen route can also fail.
Review the result over enough shifts to include ordinary variability. One smooth demonstration and one bad night are both weak evidence. The pattern of work delivered is the thing to buy.
04 / Analysis
A fair field test
Set the service window and accepted work before a pilot begins. Then record scheduled runs, completed runs, minutes of staff intervention, and time to restore service after each interruption. A missed run should stay visible even when a worker quietly completes it by hand.
At review, sort failures by cause. A route blocked by routine traffic suggests a scheduling or mapping change. Repeated hardware faults suggest a support or product problem. The cost model should reflect the fix that is actually available, not an assumption that every issue disappears after launch.
05 / Analysis
Limit of this note
No universal payback period follows from this framework. Contract terms, labor arrangements, service coverage, and the value of the task vary by site.
Sources and method
This paper synthesizes the sources below and proposes a site-level evaluation method. It does not present original field measurements or a controlled trial.
