"Can We Just Do a Free Pilot First?" — When to Say Yes and When It's a Trap

The ask that sounds like a yes

You run a good discovery. You run a good demo. The technical lead nods in the right places. And then, near the end of the call, someone says it:

"This looks great. Can we just do a free pilot first?"

Every instinct in your body says yes. They want the product in their hands. They want to touch it. That is engagement, that is momentum, that is a thing you can put in your forecast notes and tell your manager about on Monday.

It is also, more often than not, the exact moment the deal stops moving and starts decaying. Not dying — decaying. Dying is fast and clean and you can go find another deal. Decaying is slow. Decaying eats your quarter while looking like progress.

I have been on both sides of this. I have asked vendors for free pilots when I had no budget and no intention of buying that year, because a pilot was a polite way to keep the conversation alive without saying no. And I have run pilots as a seller that consumed weeks of solution engineering time and ended with a champion telling me, apologetically, that priorities had shifted.

So this is not "never do a pilot." Pilots are a legitimate part of how technical products get bought. This is a decision framework for telling the good ones apart from the bad ones, and the language for converting a free pilot request into something that actually advances a deal.

Why free pilots kill deals

Start with the mechanics, because the mechanics are what get you.

Free things do not get executive attention. This is the big one. Nothing on a company's calendar competes for senior time like something with a cost attached. When a pilot is free, it does not appear in a budget line, it does not appear in a forecast review, and no VP has to explain it to anyone. It becomes a side project for one enthusiastic engineer who also has a day job. That engineer will get pulled onto an incident in week two and you will not hear from them until you send the fourth follow-up.

The clock resets your entire cycle. You spent weeks getting to a demo. Now you agree to a six-week pilot. That six weeks is not six weeks — it is however long it takes to get environment access, plus however long it takes for their security review to approve a test instance, plus the two weeks nothing happens because of a holiday or a quarter close, plus the pilot itself, plus the readout you cannot schedule because the sponsor is travelling. A pilot you agreed to in March is a decision in June if you are lucky. Meanwhile your own close date has quietly slid two quarters and nobody wrote it down.

Nobody defined what winning looks like. Ask a buyer what would make a pilot successful and listen to the answer. If it is "we want to see how it performs in our environment," you have no success criteria. You have a vibe. And a vibe cannot be passed. At the end of the pilot, whatever the product did, someone senior can say "I'm not sure it proved out" and there is no document you can point to that contradicts them.

Free anchors the price. If a buyer used the product for six weeks and paid nothing, the psychological floor for what it costs is now zero. Every pricing conversation after a free pilot starts from a worse position than one that never had a pilot at all. This is the part sellers underestimate. You did not give away six weeks of software. You gave away your negotiating position, which is why the pilot ask and the pricing conversation are really the same conversation happening in two parts.

It changes who is deciding. A pilot moves the decision from the business — where the pain is, where the budget is, where someone is accountable for an outcome — to the technical evaluation team, where the job is to find things that do not work. That is not a criticism of technical evaluators. That is literally their function. But an evaluation run by people whose incentive is to find flaws, with no business sponsor to weigh those flaws against the cost of doing nothing, has one likely ending.

The four conditions

Here is my rule. I will run a pilot when all four of these are true. Not three. All four. Each one exists because a specific failure mode exists without it.

1. A named executive sponsor who knows the pilot is happening

Not "we've briefed leadership." A name. A title. Ideally a person who has been on a call with you, or who will be on the kickoff call, or who has replied to an email thread you are on.

The test question is simple: "Who signs off if this works?" If the answer is a shrug or "it would go up to the leadership team," you do not have a sponsor. You have a hopeful engineer.

The reason this matters more than anything else on the list: the sponsor is the only person who can make the pilot matter to other people's calendars. Without them, your champion has to beg for resources internally with no authority, and they will run out of goodwill before you run out of pilot.

2. A written success metric

Written. In an email. In a shared doc. Something you can quote back.

Not "see how it works." Something like: the system flags at least the same set of high-risk assets our current manual review catches, and does it inside a single working day. Or: three reps on the team log in unprompted four days out of five for three weeks. Or: we can complete the report that currently takes a full day in under an hour.

The number does not have to be aggressive. It has to be specific and it has to be theirs, not yours. You are not writing the criteria. You are asking the buyer to write them and then confirming them in writing.

The conversation looks like this:

"Happy to look at a pilot. Before I take it to my side, I need to know what a pass looks like. If we run this for six weeks and it works — what specifically would you have seen that told you it worked? Give me the thing you'd say to your CFO."

Then shut up and let them build it. If they cannot answer, that is your answer. A buyer who cannot describe success has not thought hard enough about the problem to buy a solution to it.

When they do answer, you send the recap email that afternoon: "Confirming what we agreed — success is X, measured by Y, reviewed on Z." That email is the single most valuable artefact of the entire pilot. It is what you hold up in the readout when someone starts inventing new criteria.

3. A hard end date, set before you start

A pilot without an end date is a free tenancy. Set the date at kickoff. Put the readout meeting in calendars at kickoff, with the sponsor on the invite, before a single user is provisioned.

The readout date is more important than the pilot duration. A four-week pilot with a booked readout beats a two-week pilot with "we'll circle back." Because the readout is the forcing function — it is the meeting where somebody has to say a word out loud.

And say the end date means something:

"To be straight with you, the access ends on the 14th whether we've made a decision or not. That's not a pressure tactic, it's just how we resource these. If we need more time we can talk about extending, but I don't want us drifting into a situation where you're using it for three months and nobody's made a call."

4. Signed intent on what happens if it passes

This is the one people skip, and it is the one that makes the other three worth having.

Before the pilot starts, you agree — in writing, in whatever form their legal team will tolerate — what happens on the day the success criteria are met. Not a contract. An understanding of sequence: if the criteria in the recap email are met by the readout date, we move to a paid agreement for scope X, starting on date Y, subject to standard procurement.

Why this matters: without it, passing the pilot buys you nothing except the right to start the sales cycle. You will hit every criterion, present a clean readout, and hear "great — so now we'd need to build a business case and take it to the budget committee, which meets next quarter." You just did six weeks of unpaid work to earn a first meeting.

The language:

"Last thing and then I'll stop being annoying. Let's say we hit everything on that list. Walk me through what happens next on your side — who has to approve, what does the paperwork look like, and roughly when could it start? I'm not asking you to commit to buying. I'm asking whether there's a path, because if the answer is 'we'd start a budget process in the new fiscal year', I'd rather we plan around that now than discover it in November."

Most buyers will tell you the truth if you ask this way. The ones who dodge it have told you something too.

Converting the ask into a paid first phase

Here is the move I reach for first, before I even evaluate the four conditions. Do not refuse the pilot. Reshape it.

"Yeah, I think starting small makes complete sense — I'd rather you prove it on one team than sign something huge you're not sure about. Let me suggest a version of that. Instead of a free trial that nobody owns, let's do a paid first phase: one team, sixty days, scoped to the use case we talked about, at a fraction of the full number. You get to prove it. I get a customer who's actually resourced. And if it works, we expand — if it doesn't, you've spent a small amount to find that out, which is cheaper than spending six weeks of your engineers' time on something free."

The argument that lands with senior buyers is the resourcing one. Point out — honestly, because it is true — that free pilots get free attention. Paid engagements get a kickoff, a named implementation contact, and a QBR. Free ones get a login and hope. Most experienced buyers know this from their own side of the table.

The argument that lands with technical buyers is the risk one. A small paid phase is smaller risk than a long free evaluation that consumes their team's time. Time is the expensive thing in their world, not your licence fee.

A few things to hold firm on when you scope the paid phase:

Scope it by use case, not by discount. "One team, one workflow, full functionality" is a first phase. "Everything at eighty percent off" is a discount you will never claw back. The first can grow. The second sets your price forever, which is exactly the trap I walk through in the SaaS pricing negotiation script for holding price after the technical win — the pilot discount and the renewal discount are the same conversation, twelve months apart.

Make the expansion price explicit up front. Write the full price into the pilot agreement. "Phase one is this. Phase two, on these dates, at this rate." If they will not agree to the phase two number now, they will agree to it even less later, when they have leverage and you have a live deployment you do not want to lose.

Do not make the pilot fee refundable if they do not buy. Creditable against the full contract if they do, absolutely — that is a fair and easy give. Refundable if they walk is just a free pilot with extra paperwork.

When procurement mandates a POC anyway

Sometimes none of this is negotiable. Regulated industries, large enterprises, public sector — there are organisations where a proof of concept is a required step in the buying process and no amount of good framing changes it. Security software is the classic case; so is anything touching operational infrastructure.

When that happens, stop fighting the POC and start controlling it.

Get the POC scope document and read the actual criteria. In mandated evaluations there is usually a real document, often written by someone who is not in your meetings. Ask for it. Read it. If it contains a requirement you will fail, you need to know that in week one, not at the readout — and you need to know whether it is a hard fail or a scored item you can lose and still win overall.

Insist on the readout attendees before you start. "Who is in the room when the results are presented?" If your economic buyer is not on that list, you are running an evaluation whose output goes to someone you have never spoken to. Fix that before you provision anything.

Cap what you will resource. A mandated POC still costs you solution engineering hours, and those hours are finite. Agree internally how many you will spend, and be willing to say: "We can support two weeks of hands-on engineering. Beyond that we'd need to move to a paid engagement." This is a normal thing for vendors to say and buyers hear it constantly.

Assume the pricing fight is still coming. Winning a mandated POC produces a technical recommendation, not a purchase order. Procurement's job starts after you win, and the fact that you passed their evaluation will be used as evidence that you want the deal badly. The dynamic is the same one in the cybersecurity pricing negotiation script for holding your number after the SOC says yes: technical approval and commercial approval are separate gates, and clearing the first one does not soften the second.

When the answer is no

Sometimes you run the four questions and get four bad answers. No sponsor. No criteria. No end date. No path if it works. And they still want the free pilot.

Say no. Kindly, specifically, with a door left open:

"I'm going to be honest with you, and you can push back. Based on where we are, I don't think a pilot is the right next step — not because I don't want you to see it, but because free pilots without a business owner tend to sit unused and then everyone concludes the product didn't work. I'd rather spend an hour with you and whoever owns this outcome, get clear on whether it's a priority this year, and then design something that actually gets resourced. Can we do that instead?"

Half the time you get the meeting. Some of the time you find out the deal was never real and you get the rest of your quarter back, which is worth more than an unused pilot instance. And occasionally the buyer respects the directness enough that it changes the whole tone of the relationship.

The pilot ask almost never arrives out of nowhere, either. It tends to show up right at the end of a strong demo, when the buyer is impressed but not yet responsible for anything. That is why I treat the close of the demo as the place to pre-empt it — the structure I use for that is baked into the energy and utilities demo script for selling asset risk analytics, where the ask is loudest because the buyer's environment genuinely is hard to replicate and "just try it on our network" feels like the obvious next step.

The one line to remember

A pilot is a commitment device or it is nothing. If the buyer is committing something — budget, executive time, a written standard, a named next step — the pilot is real and worth running. If the only thing being committed is your product and your engineers, you are not in a sales cycle. You are in a free trial with a Gantt chart.

The hardest part is not knowing this. It is saying it out loud on a live call, to a friendly buyer, without sounding like you are being difficult. That takes reps, and the four questions above are much easier to ask when you have already asked them a hundred times somewhere it does not cost you anything. If I were building this skill from scratch right now, I would take the exact wording in this post into DrillCall and run the pilot conversation over and over against a buyer who pushes back, until "who signs off if this works?" comes out sounding curious instead of confrontational — because tone is the whole game on that question.

Ask for the sponsor. Ask for the metric. Set the date. Get the intent. Then run the pilot and go win it.