The RFP is not the evaluation

The checkbox is optimised for agreement

Most RFPs assume that the written response is a neutral account of product capability. It is not. It is a competitive sales document produced inside a process that normally rewards coverage.

If a yes receives the point and a qualification introduces doubt, every vendor has a rational incentive to find the most defensible route to yes. That answer may be technically true while depending on another module, custom development, a partner, an unpublished roadmap commitment or a workflow the customer would never choose to operate.

A candid vendor can therefore score worse than one that is more skilled at interpreting each question in its own favour. The scorecard creates consistency in arithmetic without creating consistency in meaning.

Generative AI has made the weakness harder to ignore

Fluent, complete responses can now be produced faster from approved content libraries, previous proposals and product documentation. In Loopio's vendor-produced 2026 survey, 79% of responding proposal teams reported using generative AI for RFP responses, including 62% using it to generate specific answers.¹

That finding should be treated as directional industry evidence, not a universal market measure. It also does not mean AI-assisted answers are necessarily inaccurate.

It means that the quality of the prose is an even weaker proxy for the quality of the product and its fit for the buyer.

Generative AI did not break the checkbox RFP. It exposed what the process was measuring all along.

Start by removing questions that cannot change the decision

“Can your platform create an audience?” is not a useful evaluation question for a CDP.

A credible candidate should satisfy the basic capabilities that define the category before entering the main evaluation. Asking the question again creates little more than an invitation for marketing copy.

The answer is positive. It tells the buyer almost nothing about how the product will work in the organisation, what it depends on or whether it can support the work that matters.

The objective is not to make the RFP shorter for its own sake. It is to remove questions that produce no decision value, so the evaluation can spend more time on material differences.

Give different requirements different jobs

Requirements become unmanageable when every stakeholder contribution is placed into the same weighted spreadsheet. Separate them before deciding how each should be evaluated.

This distinction matters. A mandatory data residency condition cannot be averaged away because a platform offers additional dashboard features. Equally, a commodity capability should not receive the same evaluation effort as the integration, identity, latency or governance question most likely to determine success.

World Bank guidance on rated procurement criteria applies the same broader principle: non-price criteria should reflect the specific risks and quality factors of the procurement, then be prioritised and weighted according to their importance.²

Do not confuse traceability with duplication

Use cases should connect to required capabilities, but those capabilities should not be copied underneath every use case.

Define each capability once in a consolidated requirements register, then map it to every use case that depends on it. Repetition creates unnecessary work, makes answers harder to compare and gives duplicated requirements accidental extra weight.

Do not evaluate an undefined bundle

A single RFP sometimes combines CDP, marketing automation and adjacent martech requirements without first deciding where one platform's responsibility ends and another begins.

The result can favour a broad suite simply because it can claim more rows, while specialist platforms are asked to answer for capabilities they were never designed to own. Commercials become difficult to compare and integration accountability remains unclear.

Consider the target architecture and platform boundaries before evaluating vendors. If multiple technologies are being procured together, give each component a defined role and separate requirements. Use shared end-to-end scenarios to test how the components will work together.

Write requirements in the buyer's language

Requirements often inherit the vocabulary of the incumbent or the vendors consulted during early discovery. This can happen innocently. A vendor introduces a useful concept, stakeholders repeat it and the term appears in the RFP.

But vendor terminology is rarely neutral. It can carry a particular architecture, product boundary or implementation assumption with it. The organisation may unknowingly turn one supplier's product design into everybody else's requirement.

If a requirement sounds like a vendor's navigation menu, rewrite it.

Describe what needs to happen, for whom, with which data, under which controls, within what timeframe and to influence which outcome. Let each vendor explain how its product would deliver it.

Formal procurement guidance applies the same wider principle: technical specifications can be written in performance or functional terms and should not improperly favour a particular supplier, design or licensing model.³

The second question reveals the delivery approach. It exposes additional modules, data dependencies, identity treatment, operator effort, activation behaviour and potential gaps. It also provides the foundation for a controlled demonstration.

If you ask a platform whether it performs the function its category exists to perform, you are not evaluating it. You are inviting marketing copy.

Turn the RFP into a claim-to-proof plan

The useful role of the RFP is to give every vendor the same decision context, capture how each proposes to meet it and identify what needs further validation.

1. 01Business outcome
2. 02Priority use case
3. 03Required capability
4. 04Vendor approach
5. 05Assumptions
6. 06Evidence
7. 07Acceptance threshold
8. 08Commitment

For each priority use case, ask the vendor to explain:

• How the use case would be delivered end to end
• Which products, modules and licence tiers are involved
• What work belongs to the customer, vendor and implementation partner
• The data, integration and identity dependencies
• The expected implementation and ongoing operating effort
• Known limitations, workarounds and scaling constraints
• What the vendor is prepared to demonstrate or prove

Replace yes with a delivery declaration

Require one unambiguous status for every material capability. The explanation can follow, but the status should not be hidden inside it.

• Available as standard
• Requires configuration
• Requires another licensed module
• Requires third-party technology
• Requires custom development
• Roadmap, not generally available
• Not supported

This does not prohibit a positive answer. It makes the route to that answer visible. An honest “not natively” can be safer than an ingenious yes.

Score fit and confidence separately

A platform may appear to meet 95% of the requirements, but support the important claims only through written assertions. Another may meet 88%, with the critical capabilities demonstrated and its limitations understood.

The second may represent the stronger decision.

Assess two things for every material requirement:

• Fit: how well the proposed approach meets the actual need
• Confidence: the strength of evidence supporting that conclusion

Not every item should reach the top of the ladder. A common, low-risk capability may only require current documentation. A use case dependent on uncertain latency, identity behaviour, integration or business-user workflow may warrant a controlled proof.

Gate the obvious. Explain the approach. Prove what matters.

The written response is one stage in the evaluation, not the evaluation itself.

1. 01

   Gate the obvious

   Confirm table stakes, mandatory controls and architectural constraints before the main evaluation. Vendors that cannot meet them should not consume evaluation time.

2. 02

   Understand the approach

   Ask shortlisted vendors how they would deliver the priority use cases, including dependencies, effort, limitations and operating implications.

3. 03

   Prove what matters

   Use controlled demonstrations and targeted proofs to resolve the important areas where fit remains uncertain.

Use buyer-controlled demonstrations

Vendors should be given the same priority scenarios, realistic context and sufficient opportunity to prepare. The buyer should define what must be shown and which questions need resolving.

This does not mean preventing a vendor from showing a better approach. Strong vendors can challenge assumptions and introduce capabilities the buyer has not considered. But the core scenario should not be displaced by a polished tour of whatever the product demonstrates best.

Gartner's current martech guidance recommends moving beyond conventional RFPs, asking vendors to show rather than tell and using competitive proofs against the same scenario.⁴

Use proofs to resolve uncertainty, not recreate implementation

A proof of concept should test the small number of concerns that are both important and genuinely uncertain. It should not spend weeks reconfirming base-level functionality already established through documentation and demonstration.

Define the scenario, representative data, participants, environment, timebox and acceptance threshold before the proof begins. Test the difficult part, not the most photogenic part.

UK technology purchasing guidance recommends using a product trial to solve one small but difficult problem, while also testing integration and actual user experience.⁵

Design the process to reward transparency

The evaluation should make it safer for vendors to qualify an answer, expose a dependency or say no.

Ask questions such as:

• Where would you not recommend your product for this requirement?
• Which part of the proposed solution sits outside your platform?
• Which described capabilities are not generally available today?
• What commonly prevents customers from delivering this use case?
• Which assumption in your response carries the most risk?
• What would you change about our proposed approach, and why?

Ask for a better answer when the first one misses the point

Evaluation teams often treat the submitted response as fixed. A vague answer receives a weak score, an answer written in the wrong context is marked down, and the process moves on without resolving what the vendor actually meant.

It is entirely reasonable to identify the gap, request clarification and ask the vendor to update its response. The objective is to understand fit, not to catch suppliers out for an imperfect first draft.

This is not an invitation to coach a preferred vendor towards a higher score. Apply the same clarification process and deadlines consistently, record the question and revised answer, and distinguish between clarifying an existing response and introducing a new capability or changing the requirement.

If the buyer's clarification changes the context for every participant, share it with every participant. Score the revised response against the original decision criteria.

Good vendor collaboration improves an evaluation. Vendors see patterns across customers and may identify a flawed assumption, unnecessary requirement or lower-risk route to the outcome.

The buyer still owns the decision. Translate useful vendor suggestions back into the organisation's language, test them against the original objective and apply accepted changes consistently across the evaluation.

Outline the process and decision criteria before responses are submitted. Give vendors a formal opportunity to ask questions, then share generally relevant clarifications with every participant. Maintain a change record when new information alters a requirement or validation step.

A disciplined scorecard still has a role. Forrester's 2026 vendor-selection guidance similarly calls for a structured process and scorecard based on objective data.⁶ The important point is that the score should reflect evidence, not merely the fluency of the written response.

The evidence must survive the selection

Too often, the RFP, demonstration notes and proof results are archived once a preferred vendor is chosen. The implementation team then rediscovers the assumptions, exclusions and product boundaries during delivery.

Carry validated claims into:

• The contract and statement of work
• Solution design and platform responsibilities
• Implementation assumptions and dependencies
• Acceptance criteria and service levels
• Delivery ownership and operating model
• Benefits, measures and value-realisation checkpoints

Roadmap statements, custom work and partner-delivered capabilities deserve particular attention. If the decision depends on them, they should not remain informal sales assurances.

Selection is the first phase of implementation. The evidence gathered before signature should become the guardrails used after it.

A better RFP does not try to predict the winner through a longer spreadsheet. It gives vendors enough context to propose a credible approach, makes the status of each claim explicit and directs the evaluation towards the evidence that matters.

The decision should not go to the vendor with the most yeses. It should go to the option with the strongest evidence against the required outcomes, acceptable unresolved risk and an operating model the organisation can sustain.