Treat vendor selection as a release candidate
Selecting a B2B marketing vendor is often handled as a comparison of proposals, logos, services and monthly fees. That view is incomplete. The real decision is whether an outside team can operate a defined part of the commercial system without making claims, data, handoffs or delivery capacity less reliable.
Treat the preferred vendor as a release candidate. A release candidate has a stated job, acceptance criteria, evidence, known defects, an accountable owner and a rollback path. The goal is not to predict a perfect partnership from a sales call. The goal is to discover whether the vendor can produce the minimum trustworthy operating result in a bounded pilot.
The GOV.UK Service Standard is a useful context for this discipline: start with the user need, join up the journey, define a service that works, and measure outcomes. It is not a B2B marketing procurement standard. Use it as a prompt to test the work itself rather than accepting a polished pitch as proof.
Freeze the decision contract before comparing vendors
Write a one-page contract for the decision. Include the audience, commercial problem, service boundary, internal owner, systems touched, expected first deliverable, review rhythm, budget ceiling and date by which a pilot verdict is required.
Define what the vendor is not being asked to do. Examples include guaranteeing revenue, inventing customer proof, using a purchased contact list without approval, changing production tracking, or contacting regulated audiences without a reviewed process. Explicit exclusions prevent a vague “full-funnel” promise from absorbing unpriced risk.
Set acceptance language in observable terms:
- a named audience and exclusion rule are documented;
- every deliverable has a source, owner, version and due date;
- claims are linked to evidence or marked as hypotheses;
- campaign and form records retain source context;
- handoffs have a receiver, response rule and outcome state;
- unresolved defects have severity, owner and recheck date;
- the pilot can be stopped without losing the underlying data or assets.
Do not ask a vendor to score itself against criteria it helped define after the proposal. The buyer owns the contract; the vendor supplies evidence against it.
Verify claims instead of counting logos
Request evidence that matches the proposed work. A logo page may show that a vendor once worked in a sector; it does not show which people delivered the work, what was actually changed, or whether the result was measured at a mature stage.
Ask for a redacted example of the operating artifact: a research brief, source map, acceptance checklist, reporting view or change log. Ask what the vendor would refuse to claim from that evidence. A credible team can explain the boundary between an observed result, a client-reported result, an inference and an open question.
For each case or performance statement, record:
- the client context and time period;
- the vendor’s exact role;
- the baseline and denominator;
- the outcome definition and maturity window;
- what was excluded from the calculation;
- whether the evidence may be shared and by whom;
- a contact or artifact that can be verified under permission.
The FTC advertising and marketing guidance offers a general substantiation lens for material marketing claims. It is not a certification of any vendor or B2B outcome. Use it to ask whether a claim has support, scope and a responsible reviewer.
Test the delivery workflow, not just the strategy deck
Run a small working session using a real but permissioned brief. Give every candidate the same inputs and a deliberately incomplete fact pattern. Observe how the team identifies missing information, protects private data, records assumptions and decides what can be delivered first.
The test should expose the handoffs:
- intake and problem framing;
- audience or account definition;
- research and source capture;
- draft or campaign production;
- review and claim approval;
- launch or distribution readiness;
- measurement and owner handoff;
- correction, pause or rollback.
Score the evidence at each boundary. A vendor that produces an attractive draft but cannot explain the source trail, review owner or change record is not ready for a larger scope. Conversely, a vendor that asks careful questions and narrows the promise may be the safer choice even when its first presentation is less polished.
Test measurement and data handoff
Ask the vendor to map the path from a response or engagement signal to an accepted commercial record. The map should name the source field, campaign or asset identifier, timestamp, owner, acceptance rule, opportunity link and outcome state. Unknown values must remain explicitly unknown; do not let a channel name stand in for a verified source.
Agree which system is authoritative for each field and who may correct it. Test a duplicate, a late-arriving record, a rejected lead and an offline conversion. Ask the vendor to show how the correction appears in the next report and how historical values are preserved.
A vendor may report platform conversions accurately while the company still has no reliable view of qualified pipeline. Google’s documentation distinguishes a platform-generated lead from a lead that was qualified or converted offline in a CRM or internal system. That distinction is a useful QA test, not a promise that the platform will resolve the company’s definitions for it.
Test privacy, security and change control
Ask what data the vendor needs, why it needs it, how long it retains it, who can access it, and how access is removed. Keep the pilot on the least sensitive data that can answer the question. Do not upload a customer or prospect export merely to make a demo feel realistic.
Request the vendor’s incident contact, change-notice process, subcontractor disclosure, account offboarding steps and asset return procedure. If a vendor proposes a new tracking tag, enrichment source or automation, require a written owner and a reversible test before production access.
The NIST Privacy Framework can provide a vocabulary for identifying, governing, controlling, communicating and protecting privacy risk. It does not decide which data a specific marketing vendor may process, and it does not replace the buyer’s legal or security review.
For access, incident and recovery questions, the NIST Cybersecurity Framework is a useful organizing reference; it is not a marketing-vendor compliance determination.
Score defects, not only strengths
Use four defect levels:
- Blocker: unsupported claim, unapproved data use, missing owner, unsafe access, or inability to return assets. The vendor does not enter the pilot until fixed.
- Major: a missing handoff, measurement gap, unclear acceptance rule or repeated delivery failure that could distort a decision. The pilot may proceed only with a named fix and date.
- Minor: formatting, naming or documentation issue that does not change the decision if corrected before the next review.
- Observation: a useful improvement or open question with no current gate impact.
Record the defect, evidence, affected deliverable, owner, due date, severity, decision and recheck. Do not hide a material concern in a weighted score. A high total score cannot cancel a blocker.
Run a bounded pilot with an exit gate
The pilot should have one audience or use case, one primary service, one internal sponsor, one measurement contract and a fixed timebox. Define the maximum number of records, campaigns, pages or hours before work begins. Keep the pilot small enough to stop without sunk-cost pressure.
At the end, hold an acceptance review. The verdict can be accept, accept with repair, extend research, or stop and restore. Acceptance requires evidence that the vendor delivered the agreed artifact, preserved source and version context, met the review boundary, and left the team able to operate or correct the result.
Rollback means revoke access, return or delete approved data according to the contract, preserve the decision record, restore the prior tracking or content version, and notify internal owners. It does not mean pretending the pilot never happened.
Use the Vendor Selection QA Checklist
Copy this artifact into the procurement record and add one row per criterion:
- Criterion: what must be true?
- Evidence requested: which artifact, test or reference proves it?
- Observed result: what happened in the review or pilot?
- Defect: what is missing or unsafe?
- Severity: blocker, major, minor or observation.
- Owner: buyer, vendor or shared.
- Recheck date: when will the fix be tested?
- Release gate: not ready, pilot-ready, accepted, or stopped.
- Rollback: what prior asset, route or permission is restored?
The checklist is complete when the preferred vendor is selected because its operating evidence meets the contract—not because its proposal is the most confident. Keep indexable: false until editorial, overlap, legal, privacy, security and canonical reviews are complete. A disciplined selection creates a smaller, testable commitment and gives both parties a fair way to correct or stop it.
How did this article land?
Choose one reaction. You can change it anytime.