When a distributor’s or integrator’s engineer runs your POC, you keep the outcome and lose sight of how it was reached. You can get most of that sight back with an operating standard the partner signs up to: certified engineers, your and templates, the POC registered with the deal, a review gate above a size threshold, an escalation path, a lab, and a written answer to who pays for the partner’s time. Then measure POCs run, conversion, time to readout and engineer capacity, per partner.
why the partner runs the POC
There are three good reasons, and they are the same reasons you signed the partner.
- Language. The workshop, the test plan and the readout happen in the customer’s language. A security team argues more freely about false positives in its own language than in a vendor’s English.
- Local presence. The partner’s engineer can be on site on Tuesday, works in the same time zone and often already has an NDA, network access and a history with the customer’s IT team.
- Implementation follows. The engineer who runs the POC usually deploys the product afterwards. The customer is evaluating the partner along with the product, and the partner earns its services revenue on that trust.
There is a fourth reason nobody puts in a partner guide: arithmetic. A vendor covering a mid-sized European country rarely has enough presales engineers to run every evaluation itself. Co-selling covers the deals where your engineer works next to the partner’s. This guide covers the more common case, where the partner’s engineer runs the evaluation and you hear about it in status calls.
The work splits across four parties. You set the standard: certification, the criteria and readout templates, the lab and the escalation path. The distributor gives first-line technical support, lab access and evaluation licences, and reviews POC plans for smaller partners. The partner’s engineer runs the POC: plan, installation, tests and the readout draft. The customer signs the criteria, provides the environment and decides.
Who does what in a partner-run POC
- vendorSets the standard: certification, criteria and readout templates, lab, escalation path.
- distributorFirst-line technical support, lab access, evaluation licences, plan review for smaller partners.
- partner engineerRuns the POC: plan, installation, tests, readout draft.
- customerSigns the criteria, provides the environment, decides.
what you lose when your engineer is not in the room
Visibility. The POC guide names the gap in one line: the vendor learns about a failed partner-run POC after the deal is lost. Until then the POC often exists only in the partner’s calendar, so it is missing from your pipeline and your forecast.
Quality control. The customer judges your product by the configuration it saw. A partner engineer who tests the wrong use case, runs an old version or leaves noisy defaults in place can lose a deal your product would have won. You never see the configuration, only the result.
Learning. Why the customer hesitated, which competitor was in the bake-off, which integration failed: this stays in the partner engineer’s head. Your product team gets “customer chose another vendor” and nothing it can act on.
None of this is bad faith. The partner’s engineer has three other vendors’ POCs running and is paid by someone else. If your standard is harder to follow than the competitor’s, yours gets followed last.
one standard for every POC, whoever runs it
Certified engineers only. A POC on your product is run by a named engineer who holds your current certification, and the certification includes your POC method along with installation. Ask for two per partner, so a holiday or a resignation doesn’t stop a running evaluation. Varonis’s certified delivery partner datasheet (2022) is a public example of the exchange: partners commit “to train at least two engineers and renew certifications annually” and to share customer status updates with Varonis, and in return get NFR software, lab licences and technical support. That programme is about delivery, but the trade is the one you want for POCs: access for named skills and shared information. Track those names as described in partner enablement.
Your success criteria template. The same one your own engineers use, translated: the problem in the customer’s words, who decides and by when, one to three criteria with a baseline, a target and an evidence source, and what happens after a successful readout.
Your readout template. One row per criterion: target, evidence, result, gaps, next step. A partner who writes the readout on your template gives you the learning without a debrief call, and lets you compare POCs across partners. A readout written as a cheerful email gives you neither.
register the POC and gate the large ones
Make the POC a stage of the registered opportunity, with a start date, a readout date, the engineer’s name and the signed criteria attached. Tie the evaluation licence and any escalation to that record: no registered deal, no licence. The partner gets protection for its work, and you get every POC in your CRM on the day it starts.
Above a size threshold you set per product (illustrative: €30,000 in first-year value), add review gates.
Review gates for a partner-run POC above the threshold
- gate 1registered with a POC plannedStart date, readout date and the named certified engineer on the opportunity.
- gate 2criteria review before kickoffYour engineer reads the plan and the signed criteria in a 30-minute call with the partner's engineer.
- gate 3mid-point checkStatus on your template. Any extension is a written change request.
- gate 4readout reviewThe draft reaches you two working days before the customer sees it.
Escalation path. A POC has an end date, so a slow answer costs more than it does after go-live. Publish named contacts and a POC-specific response target: the partner’s engineer, then the distributor’s, then yours, then product support. The partner should be able to get your engineer onto a call within the response target without asking its channel manager first.
the lab and the licences
A partner engineer who meets your product for the first time in the customer’s environment will learn on the customer’s time. Give partners an always-on lab, run by you or the distributor, with scripted scenarios that match your criteria templates and the current product version. The engineer rehearses the POC there first.
Keep NFR licences for the partner’s own demo, training and lab, and check your NFR terms before anyone uses one in a customer’s environment. Issue customer POCs a separate evaluation licence tied to the registered deal, with an end date. Licence data then becomes POC data: you can see every evaluation start, run and expire.
who pays for the partner’s presales time
A POC costs the partner several engineer days, and the licence margin rarely covers them. Decide in writing how that time is paid, or the partner decides for you by doing the minimum.
| Option | What it pays for | Condition to set |
|---|---|---|
| POC funds | A fixed amount per completed POC | Registered deal, signed criteria, readout on your template |
| MDF | Marketing activity that creates POCs | Written rule on whether presales time qualifies |
| Registration protection | The margin the partner keeps if it wins | Registration before the POC starts |
| Services | Paid pilot, or implementation after the win | Scope and price agreed with the customer |
Large programmes keep these separate. AWS’s partner funding page, checked in 2026, lists funds for partner-led opportunities that help partners “explore proof of concepts”, and describes as money that helps “offset your marketing costs”. Palo Alto Networks announced in 2026 a Partner Development Fund that reinvests earned rebates into partner-led demand generation, training and solution development. For a smaller vendor, a simple rule is to pay POC funds against a delivered readout on your template. You are paying for the evidence and the information, and the template makes both checkable, which reported hours are not.
what to measure, per partner and per quarter
| Metric | How to count it | What it tells you |
|---|---|---|
| POCs run | Registered POCs started | Whether the partner evaluates at all |
| Technical win rate | Readouts that met the criteria, over POCs finished | Quality of qualification and execution |
| Close after technical win | Deals won, over technical wins | Whether a decision was attached |
| Time to readout | Days from start to readout, against plan | Discipline, and stalled environments |
| Engineer capacity | Certified engineers, and POCs each can run in parallel | How many POCs the partner can take next quarter |
| Readouts on template | Share of finished POCs with a template readout | How much learning reaches you |
Most partners run a handful of POCs a year, so read rates across all partners together and look at individual partners as counts. There is no published benchmark for partner-run POC conversion to rely on, so your own numbers are the reference. For crediting the deal itself, sourced against influenced, follow the rules in channel metrics.
failure signals
- POCs appear in the CRM for the first time as closed lost.
- Evaluation licences get extended twice or more on the same deal.
- Readouts arrive as an email saying the customer is happy, with no criteria in it.
- One engineer at the partner runs every POC, so one holiday stops the pipeline.
- Escalations reach you in the last week of the POC.
- The customer asks for your engineer at the readout, which means it lost confidence in the partner’s.
- Losses get recorded as “price” with no detail.
Any two of these on the same partner are a conversation for this quarter’s business review.
the next partner POC above your threshold
Before it starts, ask the partner’s engineer for two things: the criteria signed by the customer and the readout date. Then book the 30-minute plan review. If the partner cannot produce either, the POC is not ready to start.
glossary
success criteria
Written statements of what a POC must show for the buyer to proceed. Good ones are few and measurable, each with a baseline, a target and an evidence source, sorted into mandatory, weighted and observed, and approved before the POC starts by the people who decide. The guide adds one sentence on what success leads to, and a buyer's refusal to sign it is information you get before spending engineering time.
read more: how to run a security POC that ends in a decisionglossary
glossary
readout
The meeting at the end of a POC, which the guide treats as the decision meeting. Written results go to the champion first, the readout walks through each signed criterion with its evidence, gaps are stated before the buyer raises them, and the commercial proposal is ready. A technical win without agreement to proceed means the decision process or budget was never confirmed, and the work goes back to qualification.
read more: how to run a security POC that ends in a decisionglossary
glossary
MDF
Money a vendor gives partners for marketing, usually paid against proof of execution. The often repeated claim that 60% of MDF goes unused has no published study behind it: an August 2026 analysis by Technology Match traced it to a single vendor blog post. The agreed reasons funds stay unspent are pre-approval, co-funding and proof paperwork that cost a small partner more time than the money is worth, and the guide's fix is to fund outcomes such as registered deals.
read more: content your channel partners will actually sendglossary
questions
Who should run a security POC when the deal goes through a partner?
Usually the partner's engineer, because the partner speaks the customer's language, is on site and will implement the product afterwards. The vendor sets the standard: certified engineers only, the vendor's success criteria and readout templates, the POC registered with the deal, and a review by the vendor's engineer before kickoff on larger deals.
How do vendors pay partners for POC work?
Through some mix of POC funds paid per completed evaluation, market development funds, deal registration protection and the implementation services that follow a win. AWS's partner funding page, checked in 2026, lists funds for partner-led opportunities that help partners explore proofs of concept, separately from MDF, which it describes as money to offset marketing costs.
How do you know whether a partner-run POC is going well?
Ask for three things: the success criteria signed by the customer before the start, a readout date in the calendar, and a mid-point status on your template. A POC that cannot show all three is running without a decision attached, and you are likely to hear about the result only after the deal is lost.
sources
Security Revenue · every Tuesday
How security vendors build pipeline.
Subscribe and get the Hardwired POC Kit: the 3P gate, a success plan the buyer signs, go or no-go wording and a one-page report. It comes with the welcome email, together with the other subscriber kits.