Requirements That Get
Scoreable Answers

When six proposals come back and none of them can be meaningfully compared, the cause is almost never the vendors. It is the wording of the requirements. Ask a question that can be answered with a confident yes, and every vendor will answer yes.

The good news is that this is the most fixable part of procurement. Rewriting requirements is a few hours of work, it requires no new process or system, and it changes what lands in your inbox more than any other single intervention.

What makes a requirement scoreable

Four properties. A requirement missing any of them will produce answers you cannot rank.

The first property does most of the work. Before writing any requirement, ask: could a weak vendor answer this in a way that sounds fine? If yes, you have written a formality rather than a question.

Eight rewrites

These are drawn from patterns that recur across most RFPs. Each shows the version that usually gets written, the version that produces comparable answers, and why the change works.

The opposite failure: over-specifying

Everything above pushes toward specificity, and it is possible to overshoot. The over-specified requirement describes an implementation rather than a need, and it excludes better solutions without anyone noticing.

"The system must provide a nightly batch export in CSV format to an SFTP endpoint" is a description of how your current system works. A vendor offering a real-time API — better for you in every respect — is now non-compliant, and either withdraws or proposes a batch job that throws away their advantage.

The distinction is between the need and the mechanism. Specify the need precisely; leave the mechanism open unless it is genuinely constrained.

Note that the second version is longer and more specific about the constraint that actually matters — 24-hour latency, Snowflake — while leaving the mechanism open. That is the shape to aim for. Precision about outcomes, flexibility about implementation.

When a mechanism genuinely is constrained — a regulator requires a specific format, a legacy system cannot be changed — say so and say why. Vendors respond well to constraints with reasons and badly to constraints that look arbitrary, because arbitrary constraints are the signature of an RFP written around an incumbent.

The hard case: requirements from stakeholders who disagree

Requirements rarely come from one person. Operations wants one thing, IT another, finance a third, and the requirements document becomes a treaty in which every faction's wording survives intact. The result contradicts itself, and vendors either ask a dozen clarification questions or quietly pick an interpretation.

The tell is two requirements that cannot both be maximised — "the system must be highly configurable by business users" alongside "all configuration changes must follow formal change control with IT approval". Both are reasonable. Together, without a stated priority, they ask vendors to guess which one you meant.

Two mechanisms help, and both need to happen before publication.

Run a contradiction pass. Read the requirement set looking specifically for pairs in tension. For each pair, state the priority explicitly in the document — "business users may configure X, Y, and Z without approval; all other configuration follows change control". Vendors can design to a stated trade-off; they cannot design to an unstated one.

Make the mandatory/desirable split the negotiation. Rather than arguing over whether a requirement is included, agree that everything can be included but only a defined number can be mandatory — say, thirty. That forces a real prioritisation conversation and produces a document that expresses priority instead of listing everything at maximum volume.

Testing before you publish

One exercise is worth more than a full review cycle. Take your ten most important requirements and write the worst honest answer a weak vendor could give — the answer that is technically true but reveals nothing.

If that answer would score acceptably, the requirement is broken. Rewrite it until the weak answer visibly fails. You will usually find you can break three or four of the ten this way, and those are precisely the requirements that would have produced an unrankable field.

This takes about an hour and is the highest-return hour in the whole process. It is also the one most often skipped, because by the time the requirements are drafted everyone is ready to publish.

Why this matters more than it seems

Requirements are the interface between what you need and what you get told. Everything downstream — the comparison matrix, the evaluation debate, the shortlist, the contract — inherits their quality. A well-written requirement set makes evaluation almost mechanical. A poor one makes evaluation a matter of opinion, and opinion is where politics enters procurement.

The vendors on the other side are working from your wording too. The better your requirements, the less they have to guess about what you want — and the more of their effort goes into demonstrating genuine capability rather than covering every possible interpretation.