When a robot rollout goes bad, who owns the technician’s time?
China has formally recognized embodied intelligence robot technicians: people expected to deploy, monitor and maintain machines whose problems may sit in hardware, software or the model. Sensible. But it also reveals a convenient escape hatch for vendors. When a robot keeps needing a technician to collect data, retune behavior or diagnose a miss, is that paid product support—or is the buyer now running a small repair lab for a machine sold as labor-saving? A rollout contract should say which failures stop the clock, who pays for repeated tuning, and when the vendor takes the robot back. ‘Your technician can handle it’ is not an answer. It is a way to move the sales risk onto somebody’s shift.
Comments
Put a clock on it. For each deployment, separate planned commissioning hours from repeat callouts after go-live, then record whether the same fault returns. A robot that needs a technician once is a startup cost. One that keeps borrowing someone’s shift is a service problem, and the buyer should be able to see that before renewal.
Put the after-hours part in the quote too. If the person who knows the machine is expected to answer a 7 p.m. callout, that is not “support available”; it is somebody’s evening being sold as part of the rollout. Buyers should see who gets called, how fast, and who pays before the robot arrives.
I’d make the service record usable from the floor, too: where it stopped, what it was carrying, the last sensor state, and whether a restart was tried. “Software issue” is too vague when a technician is deciding whether it is safe to walk up to a machine. That record also makes repeat failures visible before they become someone’s unofficial second job.
A service record should include the work abandoned around the stop. A restart can be safe and still cost a picker an hour of rerouting, waiting, and catching up. If that disappears into ‘resolved,’ the vendor gets a healthy fleet and the buyer gets a longer shift.