2026-10-04
“Still testing on their side”: the deal that never dies
You've read it at three board meetings in a row: same account, same amount, close date pushed again, and the note that never changes, “still testing on their side.” The founder blames a long cycle. The real reason is simpler: nobody on the customer side agreed to decide. A deal with no judge can't be lost. So it stays, and it inflates the forecast.
Three boards, the same line
Third board meeting, and the same account at the top of the pipeline. The amount hasn't moved by a single euro. The close date has slipped one quarter, then another.
You open the deal record. The meeting happened, the demo landed, access was opened. Since then, no signature and no rejection. The deal doesn't move and doesn't die. It ages.
And the same line shows up elsewhere in the portfolio, with another product, another team, another segment.
The explanation arrives before the question
The founder has the answer ready: the segment is slow, buyers take their time, the team needs to follow up. Sometimes the proposal is a paid proof of concept, “to get the customer committed.”
All of that may be true. But offering a paid trial to someone who never opened the free one is asking them to fund a decision they haven't made.
As for the follow-up, “have you had a chance to look?”, it is shaped like a question. Mostly it's a rep looking for a reason to call.
A deal with no judge
The day access was opened, nobody wrote down what the trial had to prove. Not the problem to solve, not who would test, not who would decide, not when. The customer was given access. The sales team thought it had received a project.
A deal where nothing was promised cannot be lost: there's no deadline to miss and no ruling to accept. So it stays. The loss rate looks flattering, quota coverage looks comfortable, and the forecast slowly fills with deals that never started.
SAP and Stripe: two ways to run a trial
At SAP, a proof of concept wasn't a gift; it was a project. It took the customer's data, teams and weeks. So we scoped it before opening anything: which problem, which criterion, who takes part, who decides.
At Stripe, the opposite. A developer could integrate and test alone [1], with no rep organising anything, and the proof came from usage, then from the first real transactions. That model worked because someone was watching the usage: the founders had installed Stripe for their first users themselves, one by one [2].
I've also seen the flip side of both: paid proofs of concept signed for political reasons and never deployed, and self-serve accounts that never reached production. The price of the trial decides nothing. What decides is whether a name, on the customer side, is written next to the word “verdict.”
What the reporting already tells you
You don't need to ask the founder to see it. The pipeline export carries three dates per deal: when access was opened, the customer's last sign of life, and the expected close date. Side by side, they often contradict each other.
Working assumption, replace it with your own numbers: fifteen trial deals in this quarter's forecast, access opened five months ago on average, a stated four-month cycle. The trial alone has already outlasted the whole cycle.
Then come the columns. The signal is never a single deal, which always has a good excuse. It's the same empty cell, line after line: nobody named on the customer side, no written criterion, no verdict date. The amounts, meanwhile, are filled in to the cent.
None of this proves those deals are lost. It proves nobody can tell, and that treating them as late deals costs follow-ups, presales time and a forecast the board eventually stops believing.
Four questions for the next board
No audit, no new dashboard. Four questions, asked about every trial deal in the forecast:
What problem is the trial meant to solve, in the customer's words? What criterion will decide yes or no? Who, by name, will deliver the verdict? By what date?
A founder with answers has a slow pipeline. A founder without them has a pipeline that never loses. Either way you've learned something, and nobody had to defend themselves.
Among this quarter's trial deals: who, on the customer side, has agreed to deliver a verdict, and by when?
What I can’t do: I can't predict from a free trial that the customer will buy, or from a paid proof of concept that they'll deploy. Without seeing real usage, the people involved and the decision the trial is meant to inform, I can't tell a late deal from one that never started. There is no free-or-paid rule that holds for every product: the trial is designed around the proof the buyer needs to decide.
Grid · 8 rows · 6 columns · 15 minutes
Open Access Grid
An eight-row sheet, one row per trial deal, filled in from your own reporting in fifteen minutes, customers and amounts anonymised if you like. Send it back and I'll tell you which pattern it shows, and what it doesn't prove.
Sources
- Testing documentation — Stripe
A developer can test the integration alone, without going through sales. - Do Things That Don't Scale — Y Combinator, 2013
Paul Graham describes how Stripe's founders set up their first users themselves, one by one.
Would a paid proof of concept fix it?
Not on its own. A customer can pay for a proof of concept for political reasons and never deploy, just as one can test for free, commit developers and go to production. Payment sometimes makes commitment visible. It doesn't replace it.
Is the forecast wrong?
No: those lines are unverifiable. A deal with no customer-side judge and no verdict date is neither likely nor unlikely. It's unmeasurable. The rest of the pipeline can be perfectly healthy.
Sales problem or product problem?
Both. When usage speaks for itself, open trials work, provided someone watches that usage. When the customer has to mobilise teams and data, access opened without scoping turns a sale into a wait.