Most robotics writing, including my last post, focuses on the technical and operational side: how to ship the robot, how to handle the customer's environment, how to design for recovery. That's the part founders and engineers love to talk about.
The part nobody writes about, and the part that quietly kills more robotics companies than any sensor calibration ever did, is the commercial side. Specifically: why pilots stall, how to price autonomy without scaring the procurement team, and what an industrial buyer's ROI deck actually needs to say.
I've watched this play out across two product launches and a string of Fortune 500 deployments. The pattern is consistent enough that it deserves its own essay. Here's what I've learned, and what I'd tell a robotics PM who's about to spend 18 months in pilot purgatory.
Pilot purgatory
Almost every robotics company you talk to is stuck in the same place. They've completed pilots, sometimes several, and they don't have a real commercial PO. Not a follow-on pilot, not an extension. A purchase order, with capital approval, on the customer's standard procurement paper.
If you actually count the funnel, it looks something like this.
You demo to a hundred buyers and forty sign a paid pilot. Thirty of those pilots complete successfully on the technical metrics you agreed to. But of those thirty, only about eight turn into a first commercial PO, and three scale to five or more units. The drop between "pilot completed successfully" and "first PO" is the cliff. It's where most companies live, and many die.
Why does this happen? Mostly because the pilot proved the wrong things.
A "successful" pilot, as commonly run, proves that the robot can do the task in a friendly bay, during a friendly champion's tenure, on a curated product mix, at light volume. That is not nothing. It is also much, much less than what the customer's commercial buying process actually requires.
When the pilot ends and the conversation shifts to "let's place a real order," a different group of people walks into the room. The innovation team, the friendly champions who ran the pilot, hand the conversation off to procurement, finance, plant operations, and EH&S. None of those people were in the pilot. None of them care about the technical metrics. They care about TCO, payback period, what breaks at scale, what the labor agreement says about robots, who carries the liability, and whether this slots into next year's capex plan or has to wait for the year after.
The innovation team can sponsor a pilot. They cannot, in most large industrial companies, sponsor a fleet rollout. The buyer changes between the pilot and the PO, and the new buyer needs a different proof.
What a pilot actually has to prove, if you want a PO at the end:
TCO at scale, not unit cost. The customer doesn't care that one robot is profitable. They care what 20 of them cost to run, including the integration, the training, the spares, the network upgrade, and the teleop.
Behavior across product mix. A pilot run on three SKUs doesn't predict behavior on thirty. If your customer's plant does mix changes at quarter-end, your pilot has to survive a quarter-end.
Performance under operational stress. A four-hour shift demo doesn't predict a sixteen-hour shift over six months. Holidays, headcount changes, equipment swaps — those are the stress tests.
Buy-in from someone who is not the champion. If the only person who will defend your robot in the procurement committee is the innovation team's director, your odds are bad. Build the relationship with the plant manager and the operations VP early.
A clean handover plan. The customer needs to know, on paper, what their team will own and what your team will own after install. If they have to call you every time the robot stops, that's not a product. That's a consulting engagement they're paying for as a product.
Pilots in robotics shouldn't be technical demonstrations dressed up as commercial milestones. They should be commercial dress rehearsals dressed up as technical demonstrations. The technical work is the floor. The commercial proof is the ceiling.
RaaS vs CapEx
The single most underwritten lever a robotics PM has is pricing.
You can, broadly, sell autonomy two ways. CapEx: the customer buys the robot, depreciates it over five to seven years, owns the asset and the risk. RaaS, robotics as a service: the customer pays a monthly fee, often bundled with support and uptime guarantees, and you keep the asset on your books.
Most founders treat this as a billing detail. It isn't. It's one of the few decisions that changes the customer profile, the deployment model, your cash position, and what features you build, all at once.
Start with the customer. A plant manager who is risk-averse on autonomy, and they all are, sensibly, finds CapEx terrifying for an unproven product. Buying a $240k robot they're not sure will still be useful in three years means defending that purchase to a capital committee that doesn't want to hear about it. RaaS, in contrast, often slides through as plant-level OpEx without the same approval cycle, because cancelling a subscription is reversible in a way that buying a depreciating asset is not.
That same dynamic flips at scale. A plant that has decided robots work, and is committed to a fleet, often prefers CapEx. They want the asset on their books. They've stopped seeing it as a risk and started seeing it as infrastructure. The monthly fee starts to feel like rent on something they should own.
Now flip to your side. RaaS makes you a fleet operator. You hold the hardware on your balance sheet, you carry the redeployment risk when a customer cancels, you fund maintenance and refurb out of recurring revenue. To survive that model you need genuinely excellent fleet ops, telemetry, and support infrastructure. You also need a balance sheet that can absorb the float, which for most early-stage robotics companies means raising more money. CapEx, by contrast, makes you a hardware company. You sell, install, and walk away with cash. The customer's pain becomes your support burden, but your unit economics are simpler and your cash conversion is faster.
Pricing also changes what features matter. RaaS punishes downtime hard, because the customer can churn next quarter. So a RaaS-priced product needs aggressive uptime monitoring, fast remote intervention, and rollover spares as a default. CapEx punishes underdocumentation hard, because the customer's ops team has to learn the robot, and you don't have a recurring relationship to fall back on. So a CapEx-priced product needs serious documentation, training programs, and a spare-parts pipeline that survives without you on the phone.
Most early-stage robotics companies should start with RaaS, even though it's harder on the balance sheet, for two reasons. It lowers the buying friction at exactly the moment when buying friction is the bottleneck. And it forces you to build the support infrastructure your CapEx version will eventually need anyway.
But pick deliberately. The biggest mistake is treating pricing as a default rather than a design choice. Both models work. Choosing wrong for your stage costs you a lot more than the price tag suggests.
The ROI deck the plant manager actually reads
When the conversation moves from pilot to PO, you will be asked, often with awkward suddenness, for "the business case." Whatever you send is going to land on the plant manager's desk and, eventually, on the CFO's. If you send what most robotics PMs send — a deck full of features, demo videos, and "AI-powered" language — they're going to be polite, and they're going to say no.
Industrial buyers reason differently from SaaS buyers, in ways that catch most PMs off guard.
A SaaS buyer thinks per-seat, expects fast trials, makes a low-risk decision, and measures ROI in soft terms like "team productivity." An industrial buyer thinks per-unit, expects long trials, makes a high-risk capital decision, and measures ROI in hard dollars. They are accountable to a CFO who will read their slide and ask: what's the payback? And then: what breaks this number?
The slide that gets signed looks something like this.
That's the whole pitch. Five fields, no marketing language, no "our breakthrough AI," no slide of robot photos. Cost, savings, payback, NPV, and the sensitivity that breaks the case. A CFO can decide on that page in two minutes.
A few things worth saying about each line.
Per-unit cost should be honest about both pricing models. Plant managers who can't get capital approval will look at the RaaS column. Plant managers with capital budgets will look at the CapEx column. Both belong on the slide.
Annual savings need to be FTE-denominated, fully loaded, and defensible. "Fully loaded" means salary plus benefits plus turnover plus training, usually 1.3 to 1.5x base. If you say a unit replaces 1.4 FTE, you'd better be able to show which 1.4 — what shifts, what tasks, what overtime — or operations will tear the number apart.
Payback period in months, not years, is what gets attention. Single-digit-month payback is an easy sale. 12 to 24 months is normal. Anything over 36 needs either a really good story or a really patient customer.
NPV is for the CFO. Most plant managers don't compute it themselves; they care about payback. But the CFO will, and a clean NPV with the discount rate stated saves a round of questions.
The "breaks if" line is the one most PMs skip, and it's the one that builds the most trust. Industrial buyers know your model has assumptions. Showing the sensitivity — "this case breaks if loaded labor cost falls below $42k/FTE" — tells them you've actually thought about it. That single sentence has closed deals for me.
Build that slide before you build the deck. If you can't fill in those five lines for your product on a real customer's data, you don't have a business case yet. You have an aspiration.
Closing
The thing nobody tells you about robotics 0→1, on the commercial side, is that you are not selling a robot. You are selling a financial model. The robot is what makes the financial model real, but the model is what gets bought.
The pilots that succeed are the ones designed to validate the financial model, not just the technical one. The pricing that works is the pricing that makes the model approvable inside the customer's actual procurement process. The ROI deck that gets signed is the one that hands the CFO a defensible case in five lines.
If you're a robotics PM staring down pilot purgatory: stop sending more demo videos. Build the model. Validate it on the pilot. Pick the pricing that fits the buyer. And give the CFO the slide they actually need.
The robot is the easy part. The slide is where the company actually closes.