A B2B Sales Telecom proof of concept “POC” that has no defined success criteria doesn’t close deals — it just delays the objection it was meant to resolve. Module 9‘s “prove it” objection response only works if the proof-of-concept that follows is actually designed to produce a clear yes or no, not an open-ended technical exploration that quietly stalls.
A POC without an exit criterion isn’t a proof of concept. It’s a free pilot with no deadline.
Four steps to a POC that actually closes
Figure 1. Four steps, worked in order, before a single piece of equipment gets deployed.
| Step | What it means | Why it matters |
| Define success as a number | “Reduce latency below X” or “sustain Y throughput under Z load,” agreed with the customer before the POC starts, not after | A subjective “did it go well” POC gives every stakeholder room to reinterpret the result after the fact |
| Scope narrow | Test the one use case the deal actually depends on, not the entire platform’s capability | A broad POC takes longer, costs more, and makes the pass/fail criteria harder to pin down |
| Set exit criteria upfront | Agree explicitly: what happens commercially if the POC succeeds — ideally a specific next step, not “we’ll discuss it” | Without this, a successful POC can still stall indefinitely because nobody committed to what success actually triggers |
| Run it with the skeptic present | Directly involve whoever Module 8 identified as the Skeptic/Blocker, not just the already-supportive Technical Champion | A POC the blocker wasn’t part of doesn’t actually resolve their objection — it just gets dismissed as not representative of their concern |
Worked example
A platform deal is offered a POC by the customer’s technical team, framed loosely as “try it out for a month and see how it goes.”
- Push back on the open-ended framing before agreeing. Propose a specific success metric instead — in this case, sustaining a defined throughput level during the customer’s actual peak-load window, not a generic test period.
- Narrow the scope. Rather than testing the full platform, scope the POC to the single use case the deal’s business case actually depends on.
- Get exit criteria in writing. The customer’s technical lead agrees: if the metric is met, the deal moves to contract within a defined window — documented, not assumed.
- Include the Skeptic. Module 8’s mapping flagged a procurement stakeholder who’d expressed vague past dissatisfaction with a prior vendor POC — that stakeholder is invited to observe the results directly rather than hearing about them secondhand.
- Result. The POC produces an unambiguous pass, with a stakeholder who might otherwise have quietly blocked the deal now a firsthand witness to the result.
What comes next
Module 11 covers competitive displacement — the specific playbook for taking an account away from an incumbent telecom provider, a different motion from the greenfield and hyperscaler-competing deals covered so far.
Think of your last POC: did it have an agreed numeric success criterion before it started, or only after?