Humanoid robots are reaching an awkward point in the product cycle: the demos are getting better faster than the business cases.
Reuters reported this week from China’s World Robot Conference that more than 300 companies showed over 2,000 exhibits, with more than 150 product launches. The more important detail was the shift in the questions around them. Buyers and investors are increasingly looking for productivity, autonomy, and return on investment rather than another impressive dance or backflip.
That’s the right shift. If I were evaluating a humanoid robot pilot, I wouldn’t start by asking how many tasks the robot can perform in a demo. I’d start with a narrower question: can this system complete enough useful work, with little enough human intervention, to change the economics of the workflow?
That sounds like an ROI question. In practice, it’s also a product instrumentation problem.
Humanoid robot ROI starts with the work unit
Before measuring autonomy, I’d define the smallest unit of useful work.
In a factory, that might be moving a tote from a staging area to a workstation. In a warehouse, it could be picking an item and placing it into the correct container. In a hotel, it might be completing a delivery from dispatch through handoff.
The unit needs a clear start, a clear successful outcome, and a way to identify incomplete work. Otherwise, teams end up measuring robot activity instead of customer value.
This is similar to how I’ve thought about autonomous delivery systems. A robot moving for forty minutes isn’t necessarily productive. What matters is whether the intended job completed, how long it took, and what the operation had to do to make that happen.
For a humanoid pilot, I’d want the basic denominator to be something like:
successful work units / attempted work units
Then I’d attach time and operating cost to it.
A robot that completes 95% of tasks but takes four times as long as the existing process may not be useful. A robot with a lower raw completion rate might still be interesting if it works during otherwise uncovered hours or removes a difficult staffing bottleneck.
The economics live in the workflow, not in the headline autonomy percentage.
Human intervention belongs in the cost model
One metric I’d watch closely is interventions per completed work unit.
Suppose a robot completes 80 tote moves during a shift but needs a remote operator 16 times. Calling that an 80-task autonomous shift hides a meaningful part of the operation.
I’d want to know why each intervention happened and how expensive it was. A five-second confirmation is different from a teleoperator spending four minutes recovering a robot from a bad grasp. A local worker pressing a reset button has a different cost than a centralized operator who can support several robots.
This is where an exception-first operations view becomes useful. I don’t need an operator staring at twenty healthy robots. I need the exceptions organized well enough that one person can understand which system needs help, why, and what action is available.
Intervention rate also exposes a common pilot trap. Teams can quietly add human labor behind the scenes until the robot appears reliable. That’s reasonable during development. It becomes a problem when that labor disappears from the ROI calculation.
If the product needs a person, count the person.
Recovery time can matter more than failure rate
Robots will fail. The operational question is what happens next.
I care about mean time to recovery, but I’d break it down by recovery mechanism. Did the robot recover itself? Did software retry the task? Did a remote operator intervene? Did someone have to walk across the building?
Two systems with the same task completion rate can have very different economics if one recovers from most failures in seconds while the other routinely needs physical assistance.
I’d also track recurrence. Ten unrelated edge cases are different from the same grasp failure happening ten times. The latter is much easier to prioritize and potentially much more valuable to fix.
That connects to the way I think about operational metrics that should trigger a response. A pilot metric becomes much more useful when the team knows what condition deserves investigation and who owns the first move.
Utilization is where the hardware economics show up
Reuters reported humanoid prices in China around 300,000 to 500,000 yuan for some systems. Hardware price matters, but purchase price by itself doesn’t tell me much about ROI.
I’d want productive utilization:
time doing useful work / time available for assigned work
Charging, maintenance, waiting for tasks, blocked paths, software faults, intervention time, and changeovers all eat into that number.
Imagine two robots that each cost $60,000. One performs productive work for 14 hours per day. The other manages four because its workflow has long idle periods and frequent resets. The same capital cost produces very different economics.
This is why I’d be cautious about evaluating a general-purpose humanoid with a giant task catalog. Breadth looks good in a demonstration. A commercially useful pilot may be much narrower: one or two repetitive workflows, high utilization, measurable labor or throughput impact, and enough instrumentation to understand every failure.
That is also why an MVP should remove uncertainty rather than maximize features. For a robotics pilot, the risky uncertainty may not be whether the robot can perform twenty tasks. It may be whether it can perform one economically important task often enough, fast enough, and reliably enough to justify deployment.
A simple humanoid robot ROI calculation
I’d put a rough cost model next to the pilot metrics early, even when several inputs are still estimates. It makes the missing evidence obvious.
Here’s an intentionally simple example. These are illustrative assumptions, not market benchmarks.
Suppose a $60,000 robot is expected to operate 250 days a year for three years and complete 120 useful work units per day. Assume $12,000 per year for maintenance and software, $8 per operating day for energy, and 12 remote interventions per day. If each intervention consumes two minutes of operator time at a fully loaded $35 per hour, remote support costs about $14 per day.
The daily robot economics look like this:
capital allocation = $60,000 / (3 years × 250 days) = $80/day
maintenance + software = $12,000 / 250 = $48/day
energy = $8/day
remote intervention = 12 × 2/60 hours × $35 = $14/day
total = $150/day
robot cost per completed work unit = $150 / 120 = $1.25
Now compare that with the existing workflow. If the same work unit takes a person eight minutes at a fully loaded labor cost of $28 per hour, the direct labor cost is about $3.73 per work unit.
For a simple payback calculation, I’d separate the $60,000 purchase price from recurring robot operating costs so I don’t count the capital twice. Recurring maintenance, energy, and intervention labor total $70 per day. The baseline labor for 120 work units is about $448 per day, leaving roughly $378 per day before other costs and benefits.
At 250 operating days per year, that’s about $94,500 in annual gross savings and a simple hardware payback of roughly 0.63 years, or about 7.6 months.
I wouldn’t approve a deployment from that spreadsheet. The useful part is seeing which assumptions the pilot now has to prove. Can the robot actually sustain 120 completed units? Are 12 interventions realistic? Does maintenance really behave like a predictable annual cost? Does the workflow still need local labor that the model hasn’t counted? What happens to throughput when the robot is charging or unavailable?
Change any of those inputs and the answer can move quickly. That’s exactly why I’d want the calculator before the pilot ends, not after someone has already decided the pilot was a success.
The pilot should end with a deployment decision
I’d define the decision before starting the pilot.
Maybe expansion requires a minimum completed-work rate, intervention below a certain level, recovery under a target time, and a cost per work unit that is competitive with the current process. The exact thresholds depend on the workflow, labor environment, safety requirements, and what the robot is replacing or augmenting.
The point is to prevent the pilot from ending with a highlight reel and a vague sense that the technology is promising.
A useful robotics pilot should leave the team able to answer a harder question: what has to be true for the next ten robots to make economic sense?
That’s a much better product requirement than proving the first robot can do something impressive once.
Comments
Comments are powered by GitHub Discussions through Giscus.