Why do B2B pilots stall after the buyer says yes?

A pilot, data challenge or parallel run stalls because the buyer’s commitment was never asked before the proof: the buyer writes the protocol, proposes the PoC, then pauses it on an undefined “comfortable” once its true cost in time, capital, data and scarce hardware shows up. The reversal worth testing is the order, not a shortcut: the commitment comes before the live test, the pilot is written as an offer with a start condition the seller’s readiness date allows, and the next step is a dated slot the buyer controls.

What does “yes to a pilot” actually mean on the buyer’s side?

A yes to a pilot is a yes to spending, not a yes to buying. What the buyer has agreed to is their own people’s time, data that has to be pulled and cleared, scarce hardware, and an internal argument the champion has not yet had with the people who own all of that. The seller hears a purchase decision. The buyer has made a scheduling promise, and a scheduling promise is only as strong as the calendar it lands in.

Pilots and proofs of concept with a few lighthouse customers are the normal early motion for a deep-tech company, and investors expect the seller to understand the whole journey, including how long it takes to educate and convince one customer [1]. A pilot is one link in that journey. A yes to one link is not a yes to the chain, and not a yes to the link after it.

The question that decides whether the pilot ever starts is the one the yes skips: who on the buyer’s side has committed to what, in writing, by when. If the answer is one enthusiastic person and no date, the pilot has not been agreed. It has been welcomed.

Why does the buyer write the protocol and still not run it?

One pattern repeats across founder-led deals with a proof device in front of the contract. The buyer’s technical lead writes the challenge themselves: the dataset, the criteria, the pass mark. Engineering pride is part of it; control of the criteria is the rest. The seller reads this as a strong signal. Weeks later the same person writes that the pilot is paused “until things are more comfortable”, and no date follows.

An undated pause is a polite no that costs the buyer nothing. The person who wrote the protocol wanted the pilot; the people who have to pay for it in hours, data and hardware time were never asked, and once they were, the price of the yes became visible. The champion’s own exposure adds to it. A champion is buying insurance against becoming the person who backed a vendor that failed, and what lengthens procurement in front of a committee is perceived vendor risk [3]. An unproven company, an unscoped integration, an unowned regulatory question: each is a reason to let a pause run.

The seller’s mirror error is the self-imposed hold: “We keep the pipeline quiet until our own field test is done.” Both sides now wait for the other’s proof. The distinction to hold on to: a delay has a date, an owner and a written condition. A pause has none of the three. A pause is a stall.

What does a pilot really cost the buyer, and why does the seller underestimate it?

The seller prices a pilot in its own currency: engineering hours, a demo unit, a discount. The buyer pays in a different one: people who run a parallel process while keeping the live one running, data extracted, cleaned and cleared with whoever guards it, a production window or a hardware slot, and the internal case someone has to make to release all of it. That someone is usually the champion, who has other work.

When a pilot is priced at zero, or in access to data, the buyer’s cost is written out of the offer and left in the buyer’s calendar, where it competes with everything that already has a deadline. That is where “comfortable” comes from. Practitioners describe early sales as a feedback channel as much as revenue: the first customers shape the product, and the feedback loop from those conversations is part of what the seller gets out of them [2]. That is why the seller underestimates the buyer’s side. The seller counts what it learns. The buyer counts what it spends.

The intake for the free session on this site asks for this line on purpose: what a pilot costs the partner today, and what it should cost once the product is stable. A pilot offer that names the buyer’s cost in the buyer’s currency, the people, the data, the slots, the weeks, and states in the same document what the buyer gets for it, is already the first version of the contract the pilot was supposed to lead to.

Who on the committee said yes to what, and which seat has never been heard from?

A stalled pilot is rarely one person’s no. A technical champion wants the parallel run and wrote the protocol. A signer has said yes to the priority and the problem, is worried about lock-in and upfront investment, and has never confirmed in their own words how the thing would work on their side. And there is a seat the deal has never heard from: procurement, the plant manager, the finance lead, the person whose team would run the protocol.

The read Cosa runs inside its engagements lays this out as stakeholder × gate. Every person on the committee gets a row. The seven gates a buyer passes get the columns: G0 Priority, G1 Problem, G2 Thesis, G3 Mechanism, G4 Onboarding and resources, G5 Features, G6 Commercials. Each cell is marked from the record only: on record in the buyer’s own words with the date, assumed, never touched, or adverse on record.

STAKEHOLDER × GATE · A STALLED PILOT

• S1, the champion: G0 on record, in the buyer’s words · G1 on record, in the buyer’s words · G2 on record, in the buyer’s words · G3 on record, in the buyer’s words · G4 never touched · G5 never touched · G6 never touched

• S2, the signer: G0 on record, in the buyer’s words · G1 on record, in the buyer’s words · G2 on record, in the buyer’s words · G3 assumed · G4 never touched · G5 never touched · G6 adverse on record

• S3, the seat never heard from: G0 never touched · G1 never touched · G2 never touched · G3 never touched · G4 never touched · G5 never touched · G6 never touched

• Frontier gate: G4

each mark on record carries the buyer’s own words, with the date

A schematic. On a stalled pilot the frontier gate is usually G4: resources and onboarding were never agreed by the person who owns them.

G0 Priority · G1 Problem · G2 Thesis · G3 Mechanism · G4 Onboarding and resources · G5 Features · G6 Commercials

Read it row by row. The champion’s row runs through G3: they have seen how it works on their side and said so. The signer’s G3 is assumed: they never confirmed the mechanism in their own words, and their lock-in worry sits at G6 as an adverse mark nobody has addressed. The row for the seat that owns the resources is empty. An untouched cell is a finding: a person the deal has never heard from, or a question never asked. The full method, and what to do with a matrix like this one, is in Where is my B2B deal actually stuck?.

What is the frontier gate of a stalled pilot?

The frontier gate is the first gate where a stakeholder has not said yes. That is where the deal is stuck and where the next move aims.

On a stalled pilot the frontier is usually G4, and the schematic above shows why. The protocol lives at G3 Mechanism: the champion has seen the approach work on their own data and agreed. The pause lives at G4 Onboarding and resources: can my people and my data carry this, and by when. Nobody who owns those people has said yes, because nobody who owns them has been asked. The signer’s lock-in worry belongs at G6 Commercials and was never taken out there, and the rule underneath every read applies: an objection not taken out at its own gate comes back at the end as a concession.

Two further patterns from the deal records behind this document belong here. The first: the buyer’s default is phasing, one department first, a small pilot before anything larger. That is reasonable risk management, and the path from the phase to the deployment has to be designed and sold explicitly, or the pilot becomes a permanent risk-management device with no exit toward a contract. The second: the only priority container the deal ever had was an external deadline. When it passed, the clock stopped with it and nobody re-scoped the pilot against a new one. A pilot with no priority of its own at G0 will stall at G4 whatever the protocol says.

What does commitment before the proof device look like in an offer?

The reversal worth testing is the order, not a shortcut. The pilot is never bypassed; it moves from the gate in front of the offer to the first phase inside it. As an offer structure it has four parts.

1. The commitment is asked first, in the buyer’s words: what will you sign if the live test meets the criteria you wrote? The buyer states it; the seller writes it down and sends it back.

2. The live test is written into the offer as phase one, with acceptance criteria the buyer wrote. The protocol already drafted stops being a gate and becomes the acceptance test.

3. A start condition is tied to the seller’s readiness date. If the product cannot run a parallel pilot for months, that date goes into the offer and the commitment is signed against it: the readiness months are spent with a signed partner, not a paused one.

4. The next step is a dated slot the buyer controls, with named attendees, never an “either way”.

THE ORDER THAT STALLS

• Interest: The champion wants the parallel run.

• Pilot agreed: A yes to spending, heard as a yes to buying.

• Protocol written by the buyer: Dataset, criteria and pass mark, chosen by the person who wants it.

• Paused, undated: “Until things are more comfortable.” No owner, no date.

• Contract: Never reached: the proof was the gate in front of it.

THE REVERSAL WORTH TESTING

• Commitment asked, in the buyer’s words: What they will sign if the test meets the criteria they wrote.

• Offer with the live test as phase one: The buyer’s own protocol becomes the acceptance test.

• Start condition: seller’s readiness date: Phase one starts on the date the product can run it.

• Dated slot, buyer-controlled, named attendees: The next step sits in the buyer’s calendar, not the seller’s.

• Contract, then the pilot runs: The proof device is kept; it moves behind the commitment.

Same buyer, same pilot, reversed order. The proof device is kept; the commitment moves in front of it.

A mutual action plan, the shared milestone list a seller and a buyer keep together, is the familiar artifact this resembles. The reversal sharpens it to one dated commitment ahead of the proof, instead of a list of milestones the proof has to pass before anyone commits. The practitioner advice to define explicit, written exit criteria for each stage of a deal [2] points the same way: the criteria exist before the stage runs.

One more observation from the record. Told through someone else’s deal, the reversal is rejected; the buyer re-asserts their own order. It lands only when it is laid out on the buyer’s own stuck deal, with their own protocol as phase one. That is the order the AI-native sales department runs on every deal; the validate phase of the methodology is where it is proven by hand before anything becomes a system.

Why do external deadlines set the clock, and what happens when they pass?

Founder-led pilots are lost to timeline fear more often than to product doubt. The seller’s clock is real: the round needs signed design partners by a date, and every follow-up deferred past the first delivery costs runway. Investors ask for this link explicitly: the go-to-market connected to the round, capital raised against milestones such as completed pilots, and an honest account of why deep-tech timelines run longer and are harder to validate early [1].

The clock is the seller’s, not the buyer’s, and a deadline the buyer does not own is not a priority on the buyer’s side. When the seller’s date passes, nothing changes for the buyer, which is why the pause holds. The fix is not pressure. It is a priority the buyer owns, confirmed in writing: their budget cycle, their program, their own date for the problem the pilot solves. In the deal motion this is a step, not a hope: the priority is confirmed in the buyer’s words before the pilot is designed, and re-dated in writing when the world moves.

Delivery capacity and signing capacity are two different numbers. A product that cannot run a pilot this quarter can still have a signed partner this quarter, if the offer carries the start condition.

What should the next touch show, and then ask?

The next touch is prepared per attendee: what to show them, then what to ask. One commitment, as one closed question.

For the champion: show the protocol they wrote, placed as phase one of a written offer, and ask whether the acceptance criteria are theirs. For the owner of the resources: show the pilot’s cost in their currency, people, data, slots, weeks, and ask for the slot. For the signer: show the start condition and the exit, and ask for the date. Each answer moves one cell in the matrix from open to on record.

Claims stay inside what the record supports. A bounded, honest claim gets rewarded; overreach gets punished. One pattern from the same records: a return-on-investment claim sized for a large ticket, made to a buyer whose pilot was priced small, failed the buyer’s own arithmetic in the meeting and cost more trust than it could have bought.

A consented analog on this site is Alethia.io: an offer sold on goodwill, free sprints and one-off negotiations, rebuilt into pre-paid contracts with one price logic and sold on the live pipeline. It is an offer redesign, not a deep-tech pilot; what carries over is the shape: the free phase became the first phase of a paid offer instead of the gate in front of it.

When the pilot is signed and the question becomes who runs the motion after the founder, the answer is in When should a technical founder hire a sales leader?. If you want the read done on your own pilot, the free session is at /startups.

Sources

1. hard2beat.vc: 10 Slides You Need in Your Deeptech Startup Pitch Deck · retrieved 2026-09-09

2. Pipedrive: Founder-led sales · retrieved 2026-09-09

3. fello.agency: How Much of Your Seed Round Should Go to Brand and Go-to-Market · retrieved 2026-09-09

Questions this document answers

The buyer proposed the pilot themselves. Why would they not run it?

Because proposing it cost them nothing and running it costs people, data and hardware time. The protocol was written by the person who wants the pilot; the pause comes from the people who have to pay for it and were never asked. The seat that has not said yes is where the pilot is stuck.

Should we make the pilot paid?

The question underneath is whether the buyer has committed anything. A paid pilot is one way to find out; a signed commitment with the live test written into the offer as its first phase is another, and it keeps the proof device intact. What matters is that the commitment is asked before the proof, not after it.

Is asking for commitment before the proof not just pressure?

Not if the commitment is conditional on the proof. The offer states the acceptance criteria the buyer wrote, the start condition the seller’s readiness allows, and the date. The buyer keeps every exit; what changes is that the exit is written down instead of left as an undated pause.

Our product is not ready for a parallel run yet. Should we wait?

Delivery capacity and signing capacity are two different numbers. The pilot is designed and the commitment asked during the readiness months, with a start condition on the date the product can run. Waiting is the failure mode described on this page; the readiness date is part of the offer, not a reason to have none.

How do we know which stakeholder is holding the pilot?

Lay the deal out as stakeholder by gate from the record: who said yes to what, in their own words, with the date. The pilot is held at the first gate where a named person has not said yes, or by the seat the deal has never heard from. The method is in “Where is my B2B deal actually stuck?”.