AI Pilots That Convert to Contracts

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

An AI pilot converts to a contract when it was designed as the first stage of a purchase, not as a free experiment. The pilots that stall usually have a working product and a pleasant buyer. What they lack is an owner who can sign, a number to beat, and an agreed next step.

This page covers why so many AI pilots end in "pilot purgatory," the gap between a pilot and production, and the structural features that separate pilots that become revenue from pilots that become a polite email thread. It focuses on what's specific to AI and to the commercial side. For demo mechanics and evaluation sets, see why demos matter more for AI products. For the general SaaS version of proof-of-concept programs, see POC and pilot programs.

What "Pilot Purgatory" Looks Like

Pilot purgatory is the state where an AI project is neither cancelled nor bought. The pilot ended, the results were "interesting," and nobody has a reason to decide. Weeks turn into quarters. Eventually the champion changes jobs, the budget cycle closes, or a different tool gets a pilot instead.

It's common enough that the numbers worth knowing come from several directions, and each measures something different.

  • Conversion once a buyer commits. Menlo Ventures' 2025 State of Generative AI in the Enterprise reports that 47 percent of AI deals go to production, compared with 25 percent for traditional SaaS. That's a flattering figure for vendors. It also means more than half of AI deals still don't reach production.
  • Value, not just deployment. BCG's The Widening AI Value Gap puts 60 percent of companies as reaping hardly any material value from AI despite significant investment, 35 percent as scaling AI with emerging gains, and 5 percent as generating substantial value.
  • The contested headline. A 2025 MIT NANDA report, "The GenAI Divide," widely reported that 95 percent of enterprise generative AI pilots delivered little to no measurable P&L impact. Fortune's coverage describes the research as built on leader interviews, an employee survey and a review of 300 public AI deployments, and quotes its conclusion that the problem is organizational integration and a "learning gap" rather than model quality. Treat the 95 percent with care. It rests on a modest sample, and "no measurable P&L impact" is a harsh bar for a pilot that was never meant to move a P&L. The numbers above come from press coverage of the report.

Different studies, different definitions, same direction: getting an AI system to work in a pilot is much easier than getting it to change a business result. A founder's job is to design the commercial process around that gap.

Why Pilots Stall: The Pilot-to-Production Gap

When a pilot doesn't convert, the product is rarely the only reason. Three gaps show up again and again.

Integration. A pilot often runs on exports, spreadsheets or a side interface. Production means connecting to the CRM, the ticketing system or the document store, with permissions, logging and error handling. That's an engineering project on the buyer's side that nobody scoped.

Data readiness. The pilot used a clean sample someone hand-prepared. The full data estate is scattered across systems, inconsistently labeled, and owned by teams who weren't in the pilot. Performance on the sample says little about performance on the estate.

Change management. The pilot users were volunteers. Production means telling a whole team their workflow changes. Someone has to train them, update the process, and decide what happens to the work the AI now does.

Notice that none of those is a model-quality problem, and none can be fixed by a better demo. They're buyer-side work, which means they need a buyer-side owner. A pilot with no one accountable for them is a pilot waiting to stall. The practical consequence for the vendor: scope the pilot so it exposes these gaps early, while there's still time to price and plan them.

The Features Pilots That Convert Share

Pilots that become contracts tend to have eight structural features. None is exotic. Most are agreed in writing before the pilot starts.

1. A named economic owner

The person who uses the product isn't always the person who can fund it. You need someone who owns the budget or the business outcome, and who has agreed to make a decision when the pilot ends. If the only sponsor is a curious engineer or a team lead without budget authority, the pilot proves value to someone who can't buy. The questions in the MEDDIC framework about the economic buyer and the decision process apply here directly, because the economic buyer is the person who has to carry the result upward.

2. A business problem with a baseline

"Explore what AI can do for support" isn't a pilot. "Cut the average handling time on billing tickets" is. The problem should be a number that already exists and that someone is measured on, so the pilot can be compared with how the work is done today.

3. Success criteria agreed in writing before the start

Write down what counts as a pass, what the measurement method is, and who signs off on it. If the criteria get negotiated after the results arrive, the buyer can always find a reason the results don't count. Both sides should hold the same one-page document.

4. A fixed time box

Open-ended pilots don't have a decision date, so nothing forces a decision. Four to eight weeks is a typical range for a single workflow, though the right length depends on how long it takes to see enough real cases. Put an end date and a results meeting on the calendar on day one.

5. Scoped data access and an early security review

Security and legal review is the most predictable source of late delay. Start it in the first week, in parallel with setup, not after the pilot "works." Agree what data is shared, where it's processed, how long it's kept, and whether it's used to improve models. Limit the pilot to the data it needs. A narrow scope also makes the later production review shorter, because the buyer has already seen the answers.

6. A pre-agreed path to contract

This is the feature most pilots lack. Before the pilot starts, agree what happens if the criteria are met: the commercial terms, the pricing model, the volume, the start date and who signs. A draft order form that already exists keeps a good result from turning into "let's evaluate further." Pricing mechanics are covered in usage vs outcome-based pricing for AI.

7. A decision meeting with the right people

Schedule the results review at the start and invite the economic owner, the technical owner and whoever handles procurement or security. The meeting's agenda is one question: do the agreed criteria pass, and if so, do we proceed on the agreed terms?

8. A defined exit

Say what happens if the pilot fails or the buyer says no. A clean exit, with a short written review of what was learned, protects the relationship and often produces a smaller, better-scoped second pilot. It also makes the buyer more willing to start, because the commitment feels reversible.

Pilot That Stalls vs Pilot That Converts

Dimension Stalls Converts
Sponsor Interested user, no budget Named owner who can sign
Problem "Explore what AI can do" One workflow with a measured baseline
Success criteria Discussed, never written One page signed by both sides before day one
Duration Open-ended Fixed window with a results meeting booked
Security and legal Started after the pilot works Started in week one
Commercial terms "We'll talk after the pilot" Pricing and order form drafted in advance
Buyer effort Vendor does everything Buyer owns integration, data and users
After the pilot More evaluation Decision meeting, then contract or a written stop

Whether to charge is a real trade-off, and it's worth being honest about both sides.

A free pilot lowers the barrier to starting and can win an evaluation a skeptical buyer would otherwise decline. The cost is that the buyer has put in nothing. Free pilots attract people who are curious, not people who are committed, and they're easy to deprioritize when something urgent comes up. They also tend to run long, because nothing is lost when they do.

A paid pilot filters for seriousness. A buyer who has raised a purchase order has usually found a budget line, involved procurement and told a manager. That's a stronger buying signal than enthusiasm. The cost is a slower start, because even a small payment can trigger a vendor-onboarding process.

Common middle options:

  • Paid pilot, credited against the first contract. The pilot fee is deducted from year-one pricing if the buyer proceeds. This turns the fee into a deposit rather than a cost.
  • Free pilot with a committed buyer-side resource. If you won't charge money, charge in effort: named people, dedicated hours, weekly reviews, all written down.
  • Tiered scope. A small free diagnostic on sample data, then a paid pilot on live data.

An illustrative example, with made-up numbers. Say a vendor offers an eight-week pilot at $20,000, credited against a $120,000 annual contract if the buyer signs within 30 days of the results meeting. If the buyer converts, they pay $100,000 more in year one, so the first-year total is still $120,000. If the buyer walks away, the vendor has covered some of its costs and learned the buyer wasn't committed. The credit makes the pilot feel like the first installment of the purchase, which is what you want the buyer to believe.

Whichever you choose, decide before the conversation, and don't switch to "free" under pressure on the call. A discount you give in the moment tells the buyer the pilot wasn't worth much.

Setting Pricing Before the Pilot, Not After

Pilots stall on pricing for a simple reason. If the first time the buyer sees the price is after a successful pilot, they're now making two decisions at once: is the product good, and is this price acceptable. Many will resolve the second by delaying.

Show the pricing model at the start. It doesn't have to be a final number, but the structure should be clear: per seat, per unit of usage, per outcome, or a platform fee plus usage. This matters more for AI because the cost to serve varies with usage, and the buyer's bill may depend on how much the product is used during the pilot. A pilot that runs at a volume nobody expects in production will produce a misleading price signal in either direction.

For practical guidance on structuring that conversation, see usage vs outcome-based pricing for AI products and free trials for AI products, which covers where a self-serve trial can replace a pilot.

A Success-Criteria Template

Use something like this, filled in with the buyer, before any data is shared.

Field What to write Illustrative example
Workflow One process, one team Triage of billing support tickets
Baseline Current performance, how it was measured 6 minutes average handling time across 4,000 tickets a month, measured from the ticketing system for the last quarter
Target The result that counts as a pass Average handling time of 4 minutes or less on the agreed sample
Quality bar Accuracy or acceptance rate and who grades At least a stated share of outputs accepted without edit, graded by two reviewers
Guardrails What must not get worse Customer satisfaction, escalation rate
Time box Start date, end date, results meeting Eight weeks, review booked for week eight
Buyer owner Name and role Head of support operations
Decision rule What happens on pass and fail Pass: proceed to the agreed order form. Fail: written review, no further commitment

The arithmetic in the example is easy to check and worth showing to a buyer. Cutting handling time from 6 to 4 minutes across 4,000 tickets saves 2 minutes per ticket, which is 8,000 minutes a month, or roughly 133 hours. That number is illustrative, not a benchmark. The useful part is that the buyer can take their own figures and do the same calculation, which feeds directly into the ROI business case a finance reviewer will want.

Who Else Needs to Be in the Room

Pilots that convert usually involve more people than the first champion expected. IT, security, legal, procurement and the future end users each have a veto that can show up late. Mapping them early is the whole point of the AI buying committee, and it's the same impulse behind selling AI to skeptical buyers: find the objection while you can still address it.

A short checklist at the pilot kickoff:

  • Has security reviewed the data flow, or is it scheduled?
  • Does procurement know a contract may follow, and what their process takes?
  • Do the future end users know the pilot is happening?
  • Who will own the integration work if the pilot passes?
  • Is there a person who can say yes, and have they agreed to attend the results meeting?

When to Walk Away From a Pilot

Not every pilot is worth running. Some warning signs that the effort won't convert:

  • The sponsor can't name who would approve the purchase.
  • There's no baseline and no appetite to create one.
  • The buyer refuses to agree to criteria in writing.
  • Security review "will happen later" with no date.
  • The buyer wants the pilot to run on a scope much larger than the production use case.

Declining, or offering a smaller scoped diagnostic, protects your team's time. Pilots consume engineering, support and attention, and a pilot that was never going to convert has a real cost even if it's free to the buyer.

Key Facts

  • Conversion at commitment: 47 percent of AI deals go to production, versus 25 percent for traditional SaaS, per Menlo Ventures' 2025 enterprise report.
  • Buy over build: the same report finds 76 percent of AI use cases are purchased rather than built internally.
  • Value gap: BCG reports 5 percent of companies generating substantial AI value, 35 percent scaling with emerging gains, and 60 percent reaping hardly any material value.
  • The contested pilot figure: Fortune's coverage of the 2025 MIT NANDA report says 95 percent of enterprise generative AI pilots showed little to no measurable P&L impact, and attributes it to integration and learning gaps rather than model quality. The sample is modest and the figure is contested.
  • What to write down before the start: owner, baseline, success criteria, time box, data scope, pricing and the decision rule.

About the author

Brian Tr

Brian Tr

Co-Founder & COO

Brian Tr is Co-Founder and COO of Rework, with 12+ years in B2B go-to-market and operations. Brian scaled Rework from 0 to 10,000+ B2B customers across CRM and productivity tools. Brian writes for founders and owner-CEOs: startup fundamentals, founder-led and family businesses, partnerships, and how SaaS, marketplace, AI and EdTech companies grow.