PoC win rate and technical win rate: define what you count

01

Five PoC win rates from one made-up quarter

In this made-up quarter, changing the numerator or denominator produces rates from 40% to 80%. A team starts ten proofs in a quarter. At quarter-end, six have met their written success criteria, two have failed them and two have no recorded technical decision. Of the six technical wins, four deals have closed as won, one has been lost on budget and one is still open. This is a snapshot at that date, with time still left for some outcomes to change.

Any of these could go on the slide as "the PoC win rate":

40%: deals closed as won over proofs started, 4 of 10.

60%: technical wins over proofs started, 6 of 10.

67%: deals closed as won so far over technical wins, 4 of 6.

75%: technical wins over proofs with a recorded technical decision, 6 of 8.

80%: deals closed as won over technical wins whose commercial outcome is decided, 4 of 5.

The 75% excludes the two proofs without a technical decision. The 80% excludes the open deal. For this quarter-end snapshot, keep those unfinished cases visible and report:

Technical wins so far: 6 of 10 proofs started (60%). Two failed their criteria; two have no recorded technical decision.

Closed as won so far: 4 of 6 technical wins (67%). One lost on budget; one is still open.

Put the definitions and the reporting date beside the numbers. Before comparing this cohort with another, check that both have had the same time to reach a result.

02

Write down how PoC success is defined and counted

A technical win needs success criteria written and agreed before the proof starts, plus confirmation from the people judging the result that those criteria were met. Keep proofs started without agreed criteria in the starting cohort and show them separately. They do not provide the same evidence as a proof judged against an agreement made in advance.

What you divide by. Every proof started, PoC or PoV. Pick an entry event you can see in the CRM and apply it the same way every time. For WinIQ, "A deal where an SE joined one call is not a technical evaluation."

State the cohort and the clock. Group proofs by the quarter they started and put an as-of date on the report. For conversion after a technical win, choose a follow-up window and apply it consistently. AiSales.Engineer uses 90 days after a proof passes; that is an example to assess against your sales cycle.

Show which technical wins still have time left in that window. Do not compare their provisional conversion rate with a cohort whose full window has elapsed. A deal still open at the cutoff has not converted within the window, but its commercial status remains open.

Keep inconclusive proofs and proofs still in progress in the starting cohort, with separate status lines at the reporting date. Rework warns against dropping abandoned proofs from the denominator because it lets a team hide bad results. A proof still running and a proof ended without a decision need different follow-up.

To calculate these rates, record the proof start date, the dated agreement on criteria, the technical outcome and its date, and the commercial outcome and close date. Link the evidence for the technical result. Those dates let you apply the same observation window and identify outcomes that are still unknown.

GitLab’s working draft playbook describes agreeing technical win, technical loss or inconclusive as possible outcomes before a proof starts. WinIQ also argues that the SE working the deal should not alone determine whether it enters the evaluated population. If you reconstruct historical outcomes from memory, label them as estimates and keep them distinguishable from documented results.

03

What to investigate behind the rates

If many proofs meet their criteria but few of those technical wins become deals, examine the individual cases before deciding what went wrong. A missing business case is one possibility; the rates alone do not establish it. A Proof of Value also tests whether the product delivers the business outcomes the economic buyer has agreed to. I train Sales Engineers to agree, run and hand over that kind.

For technical wins that did not close, examine the go or no-go before the proof. Did the account executive and Sales Engineer confirm the outcomes, timeline and next step with the economic buyer? Peter Cohan suggests comparing proofs where a pathway to purchase was understood and agreed with those where it was not. Compare those groups over the same follow-up period, then read the individual cases. An agreed next step is useful qualification evidence, not a guarantee that the customer will buy.

For technical losses, look for recurring requirements the product could not meet and for problems in discovery or execution. SE Rockstars discusses those possibilities and warns that a very high reported rate may reflect loose definitions or selection of easier deals. Use that as a reason to review which evaluations were counted and what the customer confirmed. The rate alone cannot tell you whether qualification improved or difficult opportunities were simply avoided.

04

Before you set your number beside a benchmark

Check the numerator, denominator and time window before comparing a published range. Rework’s enterprise range of 25 to 40% counts closed-won deals over all closed deals with medium or heavy SE involvement. Those deals need not all have included a formal proof. SE Rockstars’ 70 to 90% range concerns technical wins over qualified evaluations, regardless of the eventual commercial result.

The made-up team’s 40% uses all ten proofs started, including unfinished cases, so it cannot be compared directly with Rework’s closed-deal range. Its 60% technical rate is still a quarter-end snapshot. Before comparing it with a technical benchmark, check how that benchmark handles unfinished evaluations and the observation period. The customer segment also needs to be relevant. A different percentage is not yet evidence that the team performed better or worse.

05

Which deals get a proof

The rate depends on which deals get a proof as well as on how the proofs are run. Rework points to weak qualification as one explanation for proofs that succeed technically but do not become business. Test that explanation against the actual deals before tightening access to proofs or judging the team. My advisory for Sales Engineering leaders covers where the function’s time goes, which opportunities get it and how its contribution is reported to the CRO.