Pilots That Turn Into Contracts, and Pilots That Turn Into Free Work

Your first big buyer wants a pilot. Your rep is excited. You are, too, until the buyer asks for custom setup, a weekly meeting, and your personal help getting the test over the line.

You spent a year getting out of sales. Now a possible six-figure contract has you doing unpaid work at night. The buyer likes the product, but nobody has said who will approve the purchase or when.

For a B2B company at $1M to $10M ARR, that matters. Your delivery team is small. Your founder time is limited. A pilot can use both while the rest of your pipeline waits.

A good pilot reduces one real buying risk and ends in a decision. Build the written plan before you commit the people. That lets your rep run the test without turning you into the closer again.

A pilot without a finish line is a project your buyer can keep extending.

When does a pilot make sense?

A pilot makes sense when the buyer needs evidence that a demo or reference can't provide. Perhaps your product must work with their data. Perhaps their team needs to test a specific workflow before replacing the current tool.

Ask: "What would this pilot prove that you need to know before buying?" The answer should name an uncertainty you can test. "We want to get comfortable" needs more work before it becomes a plan.

Test one buying question

Suppose the buyer needs to know whether your software can reduce the time required to prepare a weekly report. That's a testable question. Agree on the report, users, current preparation time, and way you'll measure the result.

"See what the platform can do" is different. That invites every department to add requests. Your rep can't tell when the test is done because the buyer never defined what done means.

Keep the test narrow enough to produce useful evidence. My rule of thumb is to choose the smallest real workflow that can settle the buying question. A full rollout disguised as a pilot is too much work for too little commitment.

Separate testing from postponing

Before agreeing, ask the buyer what happens if the test meets the criteria. Can they explain the purchase path? Is there a budget owner willing to review the result? Will the people doing the test have time to participate?

If the answer is "We'll figure that out afterward," pause. The test may succeed while the sale goes nowhere. A pilot won't create an approved budget just because end users enjoy it.

Sometimes the next step should be a better demo, a reference conversation, or a direct proposal. Don't add a pilot because the logo is big. Add it because there is a specific risk worth testing.

Why paid pilots are my default

A paid pilot asks the buyer to make a business commitment before your team starts delivering. Someone needs to approve the spending. That brings useful questions forward: whose budget, what scope, and what result?

Payment also makes your commitment clear. You owe the buyer the agreed work, within the agreed boundaries. You can assign people and plan their time rather than hoping a free evaluation becomes worth the effort.

Yuri Sagalov, founder of AeroFS, described this point in a Y Combinator interview: asking buyers to pay for a pilot can reveal buying intent, and some prefer paying because it establishes responsibility. That's an operator's observation, not a conversion-rate guarantee.

Price the work you are agreeing to do

There is no universal pilot price. Start with what your team must provide: setup, training, support, evaluation work, and any agreed integration. Consider the value of settling the buyer's question, too.

Write the fee alongside the scope. Name the users, workflow, included support, and work you won't include. If custom development is required, make that a separate approval with its own price and delivery plan.

You might credit the pilot fee toward the first contract. If you do, state the amount, eligibility, and deadline upfront. Don't promise a credit at kickoff and leave your rep to negotiate its meaning at the end.

Make free pilots an approved exception

A free test can make sense when the work is limited and there is a clear commercial reason. A tightly scoped evaluation using a standard setup is different from several weeks of consulting and custom development.

My rule of thumb is that a free pilot still needs every boundary a paid one needs. Write down why you're waiving the fee, cap the team effort, and name who approved the exception. A famous logo alone isn't a reason.

If the buyer refuses payment, ask why. A purchasing rule may prevent a small preliminary order. Or the buyer may have no budget at all. Those answers call for different decisions. Find out before donating your team's month.

Write success criteria the buyer can accept

"The users liked it" is feedback. It isn't a purchase decision. Your criteria should describe what you'll test, how you'll measure it, and who on the buyer's side will accept the evidence.

Write this with the buyer. Sending over your standard scorecard and getting silence isn't agreement. Have the buyer confirm the criteria in writing before the start date.

Record the starting point and the target

Here's an illustrative example, not a client result: "For the agreed weekly report, reduce preparation time from four hours to two hours or less, using the same required fields and accuracy checks."

The numbers only belong in the plan after the buyer confirms their baseline and target. Specify who records the time, which reports count, and where the evidence will be stored. If quality matters, include the buyer's quality standard.

Some tests won't use a time or revenue measure. An integration may need to pass agreed technical checks. A service pilot may need to deliver a defined output that the buyer approves. Use evidence suited to the question.

Give buyer responsibilities names and dates

A pilot can fail because the buyer never supplies the data or the users don't attend training. Put those responsibilities into the plan. "Buyer provides approved sample data by the setup date" needs a named owner.

Agree on what happens if an input arrives late. You may move the schedule by mutual agreement. You may stop. Don't silently extend access while your team keeps working around missing inputs.

Also name who accepts the result. The test user can confirm usability, while the executive sponsor reviews the business outcome. Your rep needs to know whose acceptance matters for the next purchase step.

Agree on what success means before anyone has a reason to move the goalposts.

Book the decision and agree on what comes next

The decision meeting belongs on the calendar before kickoff. Invite the person who can approve the commercial next step, alongside the people who will present the test results. Confirm they accept the invitation.

My rule of thumb is to choose the shortest period that lets the buyer observe the agreed workflow. A weekly task needs enough real cycles to evaluate it. A quarterly task won't be proved by a two-week test.

Fixed dates don't mean rushed testing. They mean both sides know when work starts, when evidence is reviewed, and when the decision is due. Set dates based on the test, then protect them.

Agree on commercial terms before results arrive

Review the proposed contract scope, price, term, implementation costs, and pilot credit before the pilot begins. Confirm which approvals remain. Successful testing can settle product fit without settling security, legal, or procurement.

The plan should say what happens if the criteria are met: who reviews the result, what purchase approval follows, and when the order is expected. A booked meeting is useful only if the buyer knows what decision they're being asked to make.

Don't treat test success as an automatic legal obligation to purchase. Any binding conversion mechanism belongs in documents reviewed by the people responsible for your agreements. This checklist is a sales planning tool, not contract language.

Pilot Agreement checklist

Copy this into your pilot planning document and complete it with the buyer:

Spot the pilot that is drifting

Drift often starts with a reasonable request. Another department wants access. Someone suggests a different test. The sponsor can't make the decision meeting, so the buyer asks for another month.

One request doesn't make the deal bad. But each request changes the work you agreed to do. Your rep should bring it back to the plan rather than say yes and ask the founder to absorb the extra effort.

Treat extensions as a new decision

Ask what evidence is missing, why it wasn't gathered, and what the extension would prove. Then set the added scope, fee if applicable, owner, and new decision date. Get approval before doing the work.

"More people want to try it" might be an expansion conversation. It doesn't automatically justify extending the original test. "We need more time" without a specific reason gives your rep nothing to manage.

Watch for a disappearing sponsor, changing goals, repeated missed buyer tasks, and pricing pushed into the future. These are reasons to review whether the pilot still has a purchase path, not reasons to throw more founder time at it.

Let the rep run the pilot

The rep owns the plan, kickoff agenda, buyer updates, CRM record, and decision meeting. A delivery or technical owner handles the agreed implementation work. The founder approves exceptions within the company's rules.

That split matters. Owning the sale doesn't mean the rep performs every technical task. It means the buyer has one clear commercial contact who tracks the commitments and brings the right people into the conversation.

Coach from the written plan

In your deal review, ask the rep to show the accepted criteria, current evidence, buyer tasks, remaining approvals, and decision invitation. Ask what changed since the last update and what they propose to do about it.

If the buyer contacts you directly, bring the rep into the reply. If an exception needs your judgment, decide it and let the rep communicate the next step. Teach them to handle the situation instead of making yourself the permanent pilot manager.

At the decision meeting, the rep presents the agreed question, evidence, and outcome. If the criteria were missed, say so. If they were met, ask for the agreed purchase step. Either way, close the test with a recorded decision.

Track completed pilots, paid contracts that follow, delivery effort, and reasons for a no. Over time, you'll see which tests help buyers decide and which consume capacity. That's how pilots become part of your Sales Playbook rather than another job only the founder can do.

Frequently Asked Questions

Should a B2B pilot be free or paid?

Paid is my default when your team provides setup, support, or delivery work. A free evaluation can be an approved exception with limited effort and a clear business reason. Both need written criteria, dates, and a purchase path.

How long should an enterprise pilot last?

Long enough to observe the agreed workflow and gather evidence. My rule of thumb is the shortest period that can answer the buying question. Fix the dates before starting, and review any extension as a separate decision.

How do you price a paid pilot?

Base the fee on the agreed scope, delivery effort, support, and value of the evaluation. There is no universal percentage of the annual contract. Explain any contract credit and its conditions before kickoff.

What if the pilot succeeds but the buyer won't sign?

Ask which purchase requirement remains unmet. Product success doesn't establish budget approval or finish procurement. Return to the agreed next step, identify its owner, and record the reason for the delay rather than extend the test by default.

Should the founder run the pilot for a big logo?

The rep should own the commercial plan and buyer communication. A technical owner runs delivery. The founder can approve an exception or join a planned executive conversation while the rep continues to manage the deal.

What belongs in a pilot agreement checklist?

Include the problem, scope, success evidence, buyer inputs, dates, owners, fee, conversion terms, remaining approvals, and exit plan. Use it to guide the sales conversation. Have the people responsible for agreements review any binding terms.