The pilot agreement: five things to settle before anyone plugs anything in

The pilot that passed and died anyway

A robotics founder told me his pilot went perfectly. Six weeks on the line, every metric hit, the engineers happy. Then nothing. He chased for four months and eventually got the real answer from his champion: nobody had ever agreed what would happen if it worked. There was no next step written down, no budget owner in the room, no date. The pilot had produced a result and no decision, and results do not buy anything.

I see this more than any other failure in industrial sales. The pilot is treated as a technical event when it is a commercial instrument, and the difference lives entirely in a document most founders skip because asking for it feels like slowing down a customer who finally said yes.

What success means, in their numbers

The first thing to settle is the pass mark, written in the customer's own units, agreed by the person whose numbers they are. Not the system performs well but throughput above X units per hour measured over Y shifts, or scrap below Z percent on their material. Vague criteria are not neutral: at the end of an ambiguous pilot, the party with more to lose from a yes gets to decide what the data meant, and that is never you. Writing the pass mark also does something quieter. It forces the customer to state what would actually change their mind, and occasionally you discover there is no number that would, which is a very cheap thing to learn in week zero.

Who decides, and who else has a veto

The second is the name. Which specific person declares the pilot passed, and who else can block it afterwards. In industrial accounts the answer is usually a small committee: the engineer who feels the pain, the plant manager who owns uptime, quality who can veto on standards, procurement who runs the process. I have written about mapping those five roles elsewhere. In the pilot agreement, the practical version is a short line naming the decider and a request that the other roles see the criteria before the pilot starts. If quality first hears about your system when the results land, quality will find a reason to need another six months.

What happens if it passes

The third item is the one the robotics founder was missing, and it is the whole game. Write the next step in advance: if the criteria are met, the parties will proceed to a purchase order for N units by date D, or enter supplier qualification with a target of Q. Not a binding commitment necessarily, but a named path with a date and a budget holder attached. Customers rarely resist this, because it costs them nothing to state their own process. When someone does resist, you have learned that the pilot was never connected to a buying decision, and you can decide whether to run it anyway with your eyes open.

Who pays, and what that buys

Fourth: money. Paid pilots behave differently from free ones. Payment creates an internal owner, a line in someone's budget, and a reason for the plant to allocate real shifts and real material instead of squeezing you in around production. A free pilot has no defender when priorities shift in month two. If the customer genuinely cannot pay from an operating budget, get something else with a cost attached: dedicated engineering hours, machine time, or a written commitment to a reference visit. The principle is not the revenue, it is the selection: paying customers tell you the problem is real, and I have made the same argument about design partners.

Data, IP, and the report you will reuse

Fifth, settle the paperwork that determines whether the pilot compounds. Who owns the data generated. Whether you may publish the results anonymized, and whether you may name the customer. What happens to any IP created during the work. Whether the customer will host a reference visit if it passes. A pilot that produces a value map in the customer's numbers, which you are allowed to reuse, is the foundation of your price list and your next three sales, as I argued in the value based pricing piece. A pilot whose results you cannot mention is a favor you did for free.

Say no to the pilot that fails all five

None of this is legal armour, and the document can be two pages. Its real function is diagnostic. A customer who will agree a pass mark, name a decider, sketch the next step, pay something and let you use the results is a customer with a genuine buying process. A customer who will do none of these is asking for a free evaluation with no path attached, and running it will cost you two quarters of engineering time to learn what a fifteen-minute conversation would have told you. The most profitable pilot decisions I have watched founders make were the ones they declined.

Common questions

What should a pilot agreement include?

Five things: success criteria in the customer's own units, the named decider and any vetoes, the agreed next step with a date and budget holder if it passes, the payment or equivalent commitment, and data, publication and reference rights.

Should a pilot be paid?

Where possible, yes. Payment creates an internal owner and a budget line, which means the plant allocates real shifts and material. If cash is impossible, secure a different cost: dedicated engineering hours, machine time, or a committed reference visit.

What if the customer refuses to agree a next step?

That tells you the pilot is not connected to a buying decision. You can still run it, but do so knowingly, and treat the refusal as the most useful information the pilot produced.

If your pilots keep passing without turning into orders, the gap is in the document, not the technology. Tell us what you have built.