Before the pilot starts, agree on what happens if it works.

At Voltaic Coatings, technical proof was not the problem. We earned roughly $250,000 in non-dilutive funding, including a $150,000 NSF SBIR Phase I award, and the science worked at the benchtop. The commercial problem was manufacturing economics. I eventually stopped the company because I could not see a responsible path from the proof to a scalable product.

That experience changed how I look at pilots. A successful test answers the question written into the test. It does not automatically establish a buyer, a budget, acceptable rollout economics, or a production decision. One industry estimate on the benchmarks page puts median pilot-to-production conversion at 12%. The exact rate will vary by category, but the operating problem is familiar: the test finishes and the commercial work starts too late.

A hardware pilot should do two jobs. It should produce credible technical evidence, and it should give the customer enough information to make a purchase decision. Those jobs need to be scoped together.

Start with the production owner, not only the pilot champion.

The person who wants to run an evaluation may not own the budget or the operating result after rollout. That distinction matters.

A good test plan answers both questions: did it work, and is it worth rolling out?

Before signing, name the person who would own production, the budget the rollout would use, the results that person needs to see, and the meeting where those results will be reviewed. Put estimated production pricing, implementation requirements, and timing in writing. These are planning assumptions, not a forced commitment, but they prevent a successful pilot from turning into a brand-new sales cycle.

If the operating owner will not participate, decide what the pilot is really for. It may still be valuable technical learning. Just do not count it as near-term production pipeline without a customer-side path to purchase.

How much commitment should a pilot require?

A paid pilot is usually a stronger signal because the customer has to assign budget, procurement time, staff, and an internal owner. But price alone does not create commitment. A free or subsidized pilot can still be rational when the vendor is deliberately buying market learning, reference data, or access to a hard-to-reach environment.

The important part is to label the work honestly. If the main return is learning for your company, treat it as product development or market research. If it is a sales stage, require customer participation that makes a production decision possible.

Three commercial terms help. Credit: apply some or all of the pilot fee to a production purchase. Production assumptions: document expected unit pricing, volume ranges, implementation needs, and support. A dated decision: book the review meeting when the pilot is signed.

Run a decision review when the evidence is ready.

There is no universal ninety-day window. The date should match the time needed to collect credible evidence for that product and use case. What matters is scheduling the meeting at the start and inviting the people who can evaluate production.

Review performance against the agreed criteria, the operating benefit, actual integration effort, incidents and support response, expected rollout cost, and remaining risks. The pilot champion should be in the room, along with the operating owner and whichever finance, procurement, safety, IT, or compliance roles matter for that account.

The meeting should end with a written outcome: move to a production proposal, run a defined second phase, or stop and record why. All three are more useful than an enthusiastic email followed by months of silence.

A pilot that ends without a decision meeting was a demonstration, not a deal stage.

A second phase is reasonable when the missing evidence is specific and important. Define what still needs to be learned, who owns it, what it costs, and when the next decision will occur. Otherwise the second pilot is just a delay with new dates.

Give each buyer the information they need.

Do not focus on an average committee size. Map the actual account. Finance may need payback and cash timing. Procurement may need vendor and contract information. Operations may need installation, uptime, training, and support plans. Safety, IT, legal, and compliance may each have requirements that can stop deployment.

Use the pilot to create those materials with the customer. A clear results summary, production quote, implementation plan, risk register, and support plan make it easier for the champion to carry the recommendation into meetings you may not attend.

The practical sequence.

Before the pilot, confirm the operating owner, budget path, success criteria, production assumptions, and decision date. During the pilot, track technical results and the real cost of integration. At the review, make a documented decision. If the answer is not yet, define exactly what evidence is missing and whether another phase is worth the time.

The Hardware Go-to-Market Diagnostic also reviews pilot design, the buying process, business case, and pipeline. Pillar 03 covers who should own that work as the company grows.