Pilot purgatory is a go-to-market problem
AI and robotics pilots rarely die on the technology. They die because nobody designed them to convert. How to scope pilots that end in a rollout.
Contents07 sections
Key takeaways
- A pilot that ends without a decision is not a technical failure. It is a go-to-market design failure.
- Write the exit before the entry: success metric, budget owner, readout date and rollout price are agreed before anything ships.
- Free pilots are the most expensive kind. Buyers who pay show up to the readout.
- In physical AI, the pilot is part of product development. Staff it, scope it and price it that way.
- Track Time-to-Proof: the days from the first real conversation to the first result your buyer can verify.
Pilot purgatory is the state where a buyer is using your product, likes it, and never decides. The pilot gets extended. Then extended again. Your champion is enthusiastic in every call and absent from every budget meeting. Your board sees logos. Your bank account sees nothing.
I want to define the word tightly, because “pilot” hides a lot. A pilot is a bounded test, run on the buyer’s own data, floor or workflow, that ends in a yes or a no. If it can’t end in a no, it isn’t a pilot. It’s free consulting with your product attached.
Why isn’t it a technology problem?
When a pilot stalls, founders go back to the product. They add a feature, push accuracy up a few points, ship a new model. Sometimes that’s the right call. Usually it isn’t. In my experience, most stalled pilots have a working product and a broken deal.
Three things break, and none of them live in your codebase:
- Nobody agreed what success means. “Let’s see how it performs” is not a success criterion. It’s an invitation to move the goalposts every week.
- Nobody with budget is in the room. The person running the pilot is often an enthusiastic operator who can say yes to a test and no to nothing else.
- Nobody priced what happens after yes. If the rollout price, scope and timeline appear for the first time after the pilot, you’ve started a second sales cycle at the exact moment you should be closing the first one.
On the Summit Route, these are three different camps. The first is Position: the buyer can’t say what the pilot is for. The second is Systems: the deal has nowhere to go, because the person who can move it isn’t attached to it. The third is Price: the decision at the end is heavier than anyone admitted. More engineering doesn’t change any of them.
Write the exit before the entry
The single most useful thing you can do is write a one-page pilot agreement before anything ships. Not a contract. One page, signed off by someone on the buyer’s side who owns a budget. It answers six questions:
- The problem, in the buyer’s words. If you can’t write it in their language, you don’t understand it yet.
- The metric and its baseline. What number moves, and what is it today?
- The threshold. What result counts as success?
- The owner. Who on their side is accountable for the decision, by name?
- The readout date. When do both sides sit down and decide? Put it on the calendar on day one.
- The rollout. If the threshold is met, what happens next: scope, price, start date.
That last line does most of the work. If a buyer won’t agree in principle to what a yes looks like, you’ve learned something important, and you’ve learned it in a week instead of six months.
Free pilots are the most expensive kind
Founders give pilots away to reduce friction. It does the opposite. A free pilot has no owner on the buyer’s side because nothing was spent. It competes for attention with everything that was paid for, and it loses.
Charge for the pilot, and credit the fee against the first-year contract. The point isn’t revenue. The point is that money moves a decision up the org chart. Someone had to approve it, which means someone will ask what they got for it. That person is the one you need at the readout.
If the buyer refuses to pay anything, treat it as information about the deal, not as an objection to overcome.
In physical AI, a pilot is product development
Software pilots and robot pilots are different animals. When your product touches a warehouse floor, a vehicle or a production line, every site teaches you something you didn’t know: a layout, an integration, a safety process, a shift pattern. At Suggaa, we built software for something as physical as rides and drivers, and later sold that software to fleet operators in the US and UAE. The physical world does not care how good your demo was.
So be honest about it. A physical-AI pilot is partly co-development. Split the pilot agreement into two lists: what we need to learn (integration, site conditions, edge cases) and what we need to prove (the metric, the threshold). Staff the learning properly. Price it. And don’t let learning goals quietly replace the success criteria, which is how robots win the demo and lose the fleet.
Pilot-to-Fleet: four stages, four gates
Pilot-to-Fleet is a simple sequence for physical-AI deals. Each stage has a gate you must pass before moving on.
- Scope. Success criteria, owner, readout date and exit price are signed. Paid pilots only.
- Prove. The metric is instrumented from day one. Weekly readouts, in writing, to the owner.
- Expand. Site-two pricing is agreed before site one finishes. Your champion gets a kit: the results, the business case, the safety and procurement pack.
- Fleet. A multi-site agreement, a RaaS or enterprise contract, and a rollout plan both sides own.
Most stalled deals skipped a gate. Usually the first one.
The one number to watch: Time-to-Proof
If you track one thing, track Time-to-Proof: the days from the first qualified conversation to the first result your buyer can verify on their own data, floor or workflow.
It’s a useful number because it compresses everything above into one figure. Vague success criteria make it longer. Missing budget owners make it longer. Unpriced rollouts make it longer. And it’s the number your buyer actually feels: the time between “this looks interesting” and “this works for us”.
Four ways to shorten it:
- Make the first proof smaller. One line, one shift, one workflow. Expand after.
- Fix the data before the clock starts. Most early pilot weeks are spent cleaning inputs. Do it in scoping.
- Put the decision-maker at kickoff. Thirty minutes of their time on day one saves a month at the end.
- Send the readout invite on day one. A date on the calendar is a commitment. A plan to “regroup” is not.
A checklist for your next pilot
- One-page pilot agreement, signed by a budget owner
- Metric, baseline and threshold written down
- Readout date on the calendar
- Rollout scope and price agreed in principle
- Pilot fee, credited to year one
- Learning goals separated from success criteria
- Time-to-Proof measured from the first conversation
None of this is technology. All of it is go-to-market. That’s the good news: it means pilot purgatory is a design problem, and design problems can be fixed.
Questions from the trail
What is pilot purgatory?
Pilot purgatory is when a buyer uses your product in a pilot, likes it, and never makes a purchase decision. The pilot gets extended instead of converted, usually because success criteria, a budget owner and rollout pricing were never agreed up front.
Should AI and robotics pilots be paid?
Yes, in most cases. A paid pilot, credited against the first-year contract, filters for buyers with budget and forces a real readout. The point of the fee is commitment, not revenue.