Stop selling robots. Sell the hour nobody has to work.

A customer has just watched your robot do exactly what it was supposed to do. It moved the tote. Picked the part. Inspected the weld. Drove around the warehouse without flattening anybody important. The pilot is a success and somebody finally asks the question you have been waiting eighteen months to hear: what would it cost to deploy ten of these? This is where robotics founders often make a surprisingly consequential mistake. They take the cost of building a robot, add a respectable hardware margin and send the customer a quote. Perfectly rational. Also possibly the wrong product. Because the customer was never particularly desperate to own ten robots. They wanted 14,000 fewer hours of manual material movement, or another shift without hiring twenty people, or inspection that happens every time rather than when someone remembers. The robot is your unit of production. It does not necessarily have to be your unit of sale.

This distinction is becoming much more important as industrial robotics moves towards Robotics-as-a-Service, or RaaS. Search for RaaS today and you will find an enthusiastic collection of articles explaining that it is “SaaS for robots”, usually followed by a table of monthly prices whose provenance becomes increasingly mysterious the longer you look at it. The interesting part is not the subscription. It is the transfer of risk. Under a conventional equipment sale, the customer buys the machine and inherits much of what happens next. Under a serious RaaS model, the robotics company increasingly owns whether the machine actually produces the promised result.

Formic is probably the cleanest industrial example. Its model is not simply robot price divided by 36 months. The company pays for the automation project, handles the engineering and deployment, monitors and maintains the equipment, and charges for system uptime. Formic says that when a system drops below the agreed efficiency level, it absorbs the engineering cost of getting it back there. In other words, the thing being sold has moved from equipment towards productive capacity.

There is a very good reason this matters commercially. Imagine your robotic cell costs €120,000 to build and install. You can sell it for €180,000. Nice business, assuming the customer has €180,000 in its capital budget, your project beats every other investment competing for that budget and nobody decides to postpone the whole thing until next year. SLSCRW already has a piece on exactly this problem, the capex approval process: industrial capital spending moves through approval tiers, investment budgets and finance committees that your technical champion usually does not control.

Now change the commercial proposition. Instead of asking the factory to approve a €180,000 machine, you offer to perform the task for, say, €18 per productive robot-hour. The comparison is no longer €180,000 versus another capital project. It is €18 against the fully loaded cost of performing that hour another way. If the alternative requires a €32 labour-hour, overtime, agency workers, recruitment and the occasional empty shift because nobody turned up, the buying argument has fundamentally changed.

And so has the risk.

If the robot sits broken in the corner, the customer does not pay for a productive hour that never happened. You do.

That is why RaaS is not clever financing. It is pricing architecture.

Formic's public material makes the logic unusually explicit. It describes rates starting around $8 per operating hour and says customers pay only for system uptime, with service and maintenance included. The company also says its model produces average operating-expense savings of 42% for customers, although that is Formic's own marketing claim rather than independent evidence and should be treated accordingly. The more interesting fact is the incentive structure: if the robot works, both parties make money. If it does not, Formic owns more of the pain.

The humanoid market is beginning to make the same transition. In June 2024, GXO and Agility Robotics signed what they described as the first formal commercial RaaS deployment of humanoid robots. It followed a proof of concept at a GXO facility, after which Agility's Digit moved into live warehouse operations under a multi-year agreement. Importantly, the announcement did not frame the commercial milestone as “GXO bought some robots”. The robots were deployed as a service, integrated into the operation and able to scale with demand.

That was not a one-off curiosity. In February 2026, Toyota Motor Manufacturing Canada signed its own commercial RaaS agreement with Agility after a successful pilot, again moving Digit from technical evaluation into manufacturing, supply-chain and logistics work. Two of the world's most sophisticated industrial operators have therefore followed essentially the same sequence: pilot the robot, prove the task, then buy the capability as a service.

The obvious conclusion is that every robotics startup should switch to RaaS.

I don't think that is true.

There is a rather nasty financing consequence hiding behind the attractive recurring-revenue graph. Sell a €150,000 robot and the customer finances the asset. Sell the same robot for €5,000 a month and you finance it. Do that with one robot and you have a pricing model. Do it with 500 and you have accidentally started an equipment-finance company.

The cash mathematics can become brutal. Hardware is manufactured and paid for before much of the subscription revenue arrives. Integration happens upfront. Deployment engineers need salaries. Replacement parts need stocking. The customer can fail, churn or simply underuse the system. Meanwhile your balance sheet contains hundreds of physical assets slowly earning their cost back. SaaS comparisons become particularly unhelpful here because a software company does not have to manufacture another €100,000 server-shaped employee every time it signs a subscription.

This is why the best RaaS model is not necessarily the one with the lowest monthly fee. It is the one where the pricing unit matches the customer's value unit without bankrupting the supplier.

Sometimes that is uptime. Formic charges for hours the system is operating. Sometimes it can be output: per pallet moved, item picked, metre welded, hectare inspected, tray harvested or successful inspection. Sometimes the customer values availability itself and a fixed monthly price makes more sense. Sometimes utilisation is so predictable that selling the machine remains the cleanest answer. And sometimes the right model is hybrid: an upfront integration or commissioning fee to recover the genuinely customer-specific work, followed by recurring charges for the robot, software, service or output.

There is an interesting public example from ABB that shows how much the commercial structure can change while the robot itself stays exactly the same. A 2024 presentation for ABB's GoFa collaborative robot compared a €33,500 outright purchase with financing around €750 per month and a pay-per-hour model around €4.15 per hour, including connected services, preventive maintenance, insurance and an agreed allowance for underperformance. Same underlying machine. Three entirely different buying decisions.

That should change the first pricing question a robotics founder asks.

Not: what margin should we put on the robot?

Ask: what does the customer already pay for the outcome?

If you automate machine tending, what does an attended machine-hour cost? If you move pallets, what does one pallet movement cost today? If you inspect infrastructure, what does an inspection cost including travel, downtime and reporting? If your robot fills a labour gap, what does a reliably staffed productive hour actually cost the factory, including shift premiums, agency fees, absence and management overhead?

This is essentially the same logic as the SLSCRW piece on total cost of ownership, but robotics lets you take it one step further. Do not merely justify your price against the customer's economic unit. Consider making that economic unit the price.

Then work backwards.

Suppose the customer currently spends €30 per productive hour and you can credibly charge €20. If the robot can deliver 4,000 billable hours a year, that is €80,000 annual revenue. Now subtract service, remote monitoring, field support, replacement parts, financing cost, insurance, expected downtime and the amortised cost of the hardware and integration. What remains is your contribution margin. Then stress it. What happens at 3,000 hours? What happens if uptime is 85% rather than 95%? What happens when the gripper needs replacing twice as often as engineering promised? What happens when the customer changes the SKU and you need two weeks of reprogramming?

This is the part the “RaaS means recurring revenue!” articles tend to omit.

Your pricing model determines which risk you own.

Price per robot and the customer owns utilisation risk. Price per operating hour and you share it. Price per successful pick and you now own an impressive collection of hardware, software, integration, uptime and performance risk. That can be an excellent deal if you understand the system better than the customer and can price that risk correctly. It can be catastrophic if your Series A spreadsheet assumes every robot works sixteen hours a day forever.

Which is why I would be careful about copying software metrics too literally. A robotics company can have beautiful ARR and terrible economics. I would want to know revenue per deployed robot, gross margin after field service, deployment cost, time to deployment, utilisation, uptime, payback on the hardware you financed, redeployment value when a customer leaves and how much engineering each new site requires. If every new €100,000 of ARR requires €180,000 of hardware and six weeks from three engineers, the recurring revenue is not yet the triumph the pitch deck suggests.

The deeper commercial point is that robotics companies get to choose where the risk boundary sits.

Traditional equipment manufacturers put most of it on the buyer. Buy our machine. Here is the warranty. Good luck.

RaaS can move the boundary towards the vendor. We install it. We maintain it. We guarantee availability. Perhaps we only get paid when it works.

That can be extremely powerful for a startup because the exact things making a buyer nervous about a new robotics company, reliability, integration, obsolescence, maintenance, become things the startup can remove from the buying decision. You are effectively saying: you don't have to believe our robot will work for five years. We do.

That is a much easier sentence to buy.

But only say it if your balance sheet can afford to be right.

If you're working out whether your robotics company should sell machines, subscriptions, productive hours or actual output, SLSCRW works on exactly these commercial choices. The interesting question is rarely what the robot costs. It is what the customer should be buying.