By: Elad Inbar

For two years, every operator I sat down with asked the same opening question. Can the robot actually do this? By 2026, that question is settled. Service robots cook, deliver, clean, transport, scan, and dispense across hospitality, healthcare, logistics, and retail. The hardware works. The software works. The deployments are commercial, not pilot.

The interesting question now is different, and it is the one keeping operations leaders up at night. Why do identical robots succeed in one building and stall in another?

I see this every week. Two locations of the same chain. Same model robot. Same vendor. Same training. One site is running ninety percent uptime, throughput is up double digits, and the team is asking for a second unit. The other site has the robot parked by the back door, plugged into a wall outlet that nobody is using, with a Post-it note that says "broken" stuck to the screen. The robot is not broken. It never was.

The difference is whether somebody redesigned the work around it.

You deploy a workflow, you use a robot to run it

The phrase I keep coming back to with operators is this. You do not deploy a robot. You deploy a workflow, and you use a robot to run the parts of that workflow that should never have been done by a person in the first place.

That framing matters because the unit of value in automation lives in the redesigned task pattern, not the device. A delivery robot in a restaurant only earns its keep if the kitchen pass, the order system, and the floor plan are arranged so the robot can leave a station, complete a run, and return inside a known cycle time. A transport cart in a hospital only earns its keep if the dispatch interface lives inside the application the nursing assistant already uses, not on a separate console. A picking arm only earns its keep if the inventory system stops sending it the wrong totes.

In every case, the win comes from assigning the repeatable baseline to the machine. The unloading, the running, the moving, the dispensing, the monitoring. The work nobody got into the industry to do. People are reserved for what only people are good at, which is judgment, exceptions, and the moments a customer or a patient actually wants a human face. The robot does not elevate itself. The redesign elevates the staff.

Operators who get this right stop seeing automation as a labor substitute. They see it as a labor concentrator. The headcount on shift may not change. What changes is what each person on that shift spends their hours doing.

Stop measuring sticker price. Start measuring cost per unit of work 

Most boards still evaluate automation the way they evaluated equipment in 2010. They ask how much the robot costs, how long it will take to pay back, and whether the lease beats the loan. Those are the wrong inputs, and they push operators toward the wrong decisions.

The right input is cost per unit of work.

A robot is not a piece of capital equipment in the way a forklift is. Treat it as a recurring producer of completed tasks. Stop comparing robot price to hourly wage. Compare the all-in cost of one completed run, one cleaned floor, one delivered tray, one picked tote, against the same unit delivered by a human pathway, including the parts of the human pathway nobody puts on a spreadsheet.

Those off-spreadsheet costs are higher than most operators want to admit. Turnover and the hiring cost to replace a worker in accommodation and food services or warehousing run into the thousands of dollars per role. Workers' compensation for soft-tissue injuries from repetitive transport and lifting drives premium hikes year over year. Over time, to backfill a no-show shift compounds quickly. None of those line items appear when an operator compares a robot quote to an hourly wage. All of them appear in the unit economics of every shift.

When you reframe the question as cost per unit of work, two things happen. First, automation becomes evaluable on its real merits. Second, the deployments that should be obvious become obvious. A task pattern where the human cost per completed unit is high, predictable, and persistent is one that automation can absorb without drama. A task pattern where the cost is low, variable, and judgment-heavy is one to leave alone.

The operators winning right now are the ones who did this math first and bought hardware second.

The four non-technical failure modes 

When a deployment stalls, the post-mortem almost never points at the robot. It points to four things, and they show up in roughly the same order every time. The first is an unnamed owner. The robot arrives. Operations celebrates. The vendor leaves. Six weeks later, nobody on staff has a calendar reminder to check telemetry, refill consumables, or update the route map. The robot drifts off-pattern, and nobody catches it because nobody is responsible for catching it. This is the most common stall I see, and it has nothing to do with the technology. It has to do with operating cadence.