Your requirements list is a demo transcript, and every vendor can tell

Open the requirements document you circulated to shortlisted vendors last month and read the first fifteen lines out loud. If four or five of them name a capability the way one specific product names it, a unified workspace view, a health score on the account object, a sentiment tag written back to the case record, then what you are holding is not a specification. It is a transcript. Somebody sat through a well built demo in week two, took clean notes, and those notes became the numbered requirements list in week five. Often the order of the requirements still matches the order of the demo, because the demo had a script and the script was good. The sales engineer led with the differentiator, spent eight minutes on the workflow that competitors handle differently, and closed on the roadmap item that no one else has shipped yet. All three are now in your must have column.

The consequence is arithmetic, not opinion. When the requirements come from one vendor's script, that vendor scores 92 or 94 percent on your own scoring model, and everyone else lands in the seventies because they solve the same business problem with a different noun. You then walk into commercial negotiation with a single compliant option and a file of technically non compliant alternatives, which is another way of saying you walk in without leverage. The spec did the deciding. Pricing is just the receipt.

How a demo becomes a specification without anyone deciding to let it

Nobody chooses this. It happens because of sequencing. In most organisations the first concrete artefact in a sourcing cycle is a demo, not a requirements workshop. The business unit has a pain, someone books a call, and forty five minutes later the room has seen a working product. That product is now the only tangible reference anyone has. When the procurement lead asks the stakeholders what they need, they answer with what they saw, because seeing something is far easier to describe than imagining an abstraction.

Three further forces push in the same direction. First, vocabulary. Cross functional groups need shared language fast, and the demo hands them a ready made glossary. Once the finance director and the operations manager both say health score in meetings, the term is load bearing and no one wants to relitigate it. Second, helpfulness. Pre sales teams frequently offer a requirements template, a sample RFP, or a scoring matrix, and these documents are genuinely useful and genuinely free. They are also authored by a party with a preference. Third, time. The demo happens in week two and the board wants a recommendation by the end of the quarter, so the requirements list is drafted in an afternoon by the person with the best notes rather than assembled from the underlying business outcomes over two weeks.

None of this is misconduct on the vendor side. A good sales engineer is supposed to make the differentiator memorable. The failure is on the buy side, and it is a process failure, not a character failure. We let the first artefact become the standard.

Why it survives review, and what it quietly costs

Demo shaped specs pass internal review easily, which is exactly why they persist. They look rigorous. They are specific, numbered, testable, and the stakeholders sign them off enthusiastically because they recognise their own words. Vague specs get challenged. Precise specs written in one vendor's dialect sail through, because precision reads as diligence.

The cost shows up in four places. It shows up in the shortlist, where two or three credible providers self deselect during clarification because answering honestly would mean writing partial compliance nine times. It shows up in pricing, because a specification that only one architecture satisfies removes any need for a competitive number, and you end up arguing about discount percentage on a list price nobody else is bidding against, which is the exact trap described in discount off list is a trap. It shows up in commit sizing, because features you first saw in a demo tend to arrive bundled with volume assumptions that were never tested against your own usage curve, a pattern we broke down in sizing AI commits from your usage. And it shows up three years later at renewal, when the requirements that were really roadmap items are now dependencies, and your switching cost has been quietly capitalised. If you have not measured that number, the vendor has, and measuring switching costs before the vendor prices them is the corrective.

The reframe: from feature wants to outcome requirements

The platform motion here is deliberately unglamorous. You paste the requirements list, the demo notes, the stakeholder wish list, whatever exists, into Vera and ask for a vendor neutral rewrite. Vera separates each line into the business outcome underneath it and the implementation detail sitting on top. A requirement that reads as a named product object becomes a requirement about the decision the user needs to make, the data that must reach them, and the latency they can tolerate. Where a line cannot be restated without naming one product's architecture, Vera flags it as a genuine architectural constraint so you can decide consciously whether to keep it, rather than inheriting it by accident.

Vera cites as she goes. Each reframed requirement carries the comparable providers that can answer it and the benchmark evidence behind the commercial range, drawn from the same evidence base the six specialist agents work against. What you get back is not softer than your original list. It is usually longer and harder, because outcome requirements are measurable and feature names are not.

Benchmarking the requirement, not the script

A neutral specification only earns its keep if the price attached to it can be tested. That is the second half of the motion. Once requirements are stated as outcomes, they map onto benchmarks rather than onto a single vendor's price book. The library holds 520 vendor benchmarks built on more than 500,000 real closed transactions, with roughly 5,000 comparable deals available for cohort work, and the percentile view tells you where a quoted number sits against peers of similar size, term and region.

This is where the demo shaped spec is most obviously exposed. Ask for a benchmark against a feature name and there is nothing to compare, because the feature name is proprietary. Ask for a benchmark against an outcome, cost per supported user, cost per processed transaction, cost per seat at a given service level, and three or four providers appear with real closed numbers behind them. The requirement stops being a description of one product and becomes a unit of measurement.

What this does not fix

Vera cannot tell you which outcomes matter to your business. Prioritisation is judgement, and it stays with the people accountable for the result. The platform can show you that a requirement eliminates three of four providers, but only you can decide whether that elimination is worth the leverage it costs.

It also cannot manufacture competition where none exists. Some categories are genuinely close to single supplier for a given estate, integration footprint or regulatory posture. In those cases a neutral specification does not produce three bidders, and pretending otherwise wastes a quarter. What it does produce is an honest record of why the field is narrow, which is a materially stronger position at the table than a spec that pretends the choice was open.

Nor does it resolve politics. If an executive sponsor has already told the board which product is coming, a rewritten requirements list will not change that, though it will change what you pay for it. And benchmarks describe commercial reality rather than functional adequacy. They tell you what comparable buyers actually paid for a comparable outcome. They do not tell you whether a niche capability works in your environment, which is what a structured proof of concept is for.

Finally, the incumbent may still win. That is a perfectly good outcome. The difference is that it wins against a specification you wrote and a price the market has tested, rather than against its own demo script. If you want to pressure test how that conversation actually goes before the call, rehearsing it against an AI rep is the cheapest hour in the cycle.