Everything is mandatory, so nothing is negotiable: the requirements document that collapses your shortlist to one

Your requirements document ran to 214 lines. Every one of them arrived from somewhere legitimate. Forty came from the security review. Thirty came from the team that runs the tool you are replacing. A dozen came from a finance controller who lost an argument three years ago and wrote the outcome into a template that nobody has opened since. Nobody ranked them. The column that would have held a priority said Required for all 214 rows, because that is what the template said, and because the person who compiled it had no mandate to tell the security review that forty of its lines were preferences. Six vendors were invited. Four scored below eighty percent on a scoresheet where every line weighed the same. Two survived. Then one of the two could not certify a residency clause that nobody had ever tested against a real workload, and your shortlist became a shortlist of one, eleven weeks before the incumbent contract expired.

You know how the rest of that quarter went. The surviving vendor knew the arithmetic before you did. Their account team had watched four competitors drop out of the process and did not need to be told what that meant. The discount they offered looked generous against list. The net unit price did not move much, because it did not have to.

A requirements list is a consensus artifact, not a specification

The reason nothing gets ranked is not laziness. It is that ranking is the only genuinely political act in the whole sourcing process, and the person holding the pen usually has the least authority in the room. Marking a line as a want rather than a need means telling a named colleague that their concern is tradeable. If the project later goes badly, that annotation is the first thing anyone will find. Marking everything as required costs nothing today and distributes the blame perfectly evenly. So the rational individual choice, repeated across eight stakeholders, produces an irrational collective document.

The second reason is that most requirement templates have no vocabulary for degree. A line either appears or it does not. There is no field for how much you would pay to have it, no field for whether a workaround exists, no field for whether three of the five bidders already offer it as standard so it costs nothing to demand. A requirement that every vendor in the category satisfies is not a requirement at all in any useful sense. It is a description of the market. Yet it sits in your scoresheet with the same weight as the one genuinely differentiating capability that only one bidder has, and that one bidder knows it.

The third reason is inheritance. Roughly half the lines in a typical enterprise requirements document are copied forward from the last cycle, and a good number of those were originally written by reading the incumbent vendor's own feature page. That is how a specification quietly becomes a portrait of one product. When you then run a competitive process against a portrait, the original sitter wins. This is a specific and measurable form of the problem we described in vendor lock-in: measuring switching costs before the vendor prices them for you, except here the lock-in is self inflicted and written down in your own document.

Mandatory everything is the same as leverage nothing

Negotiating power in software sourcing is almost entirely a function of what you can credibly decline. Not what you can threaten, not what you can benchmark, what you can decline. Every requirement you mark as mandatory is a thing you have publicly promised you will not walk away from. Two hundred and fourteen mandatory lines is two hundred and fourteen promises not to walk. The vendor's deal desk reads that document with more care than your own stakeholders did, and it reads it as a map of where you have no exit.

This is why the pricing conversation feels strange in these processes. You go in with a benchmark, you present a credible number, and the response is polite and immovable. The number was fine. The problem was that you had already told them, in writing, three months earlier, that only their product could satisfy lines 41, 96 and 173. The discount they eventually offer will be large as a percentage of list, which is exactly the trap described in discount off list is a trap. A sixty percent discount on a list price the vendor sets unilaterally is not a concession, it is a presentation choice.

There is a second cost that shows up later. When everything is mandatory during selection, nothing is contractually protected after signature, because the team is exhausted by the time it reaches the paper. The lines that mattered most were never separated out, so they never became commitments, service levels or price protections. You end up with a contract that satisfies a scoresheet and protects nothing, which is the gap we map in the must have coverage grid.

Ranking at intake, before the market ever sees the list

The platform motion here starts earlier than most people expect. Not at the RFP, at intake. When a requirements document enters VendorBenchmark, Vera reads it as a set of claims rather than a list of lines. She clusters near duplicates, flags text that has been inherited from previous cycles, and identifies lines that describe the same underlying capability in three different stakeholders' vocabularies. On a typical 200 line document that consolidation alone tends to remove a meaningful share of the volume before any judgement is required, because a large part of what looks like scope is repetition.

Then comes the triage. Vera asks the question the template never had a field for: if this line were not met, what specifically happens. There are only a few honest answers. The deal is legally impossible. A workaround exists but costs operational effort. A workaround exists and costs nothing. Someone will be annoyed. Those four answers produce a rank, and crucially they produce it as a recorded response from a named function rather than as an analyst's private opinion. That changes the politics. The security lead is not being overruled, they are being asked to describe a consequence, which is a question they are qualified and willing to answer.

Which requirements actually move price

Ranking by internal consequence is half the job. The other half is external. A requirement can be genuinely important to you and still be free, because every serious bidder in the category ships it as standard. Another can look minor and carry a large premium, because only two vendors support it and both price it as an upgrade tier. You cannot tell these apart by reading the requirement. You can only tell by looking at what comparable organisations actually paid.

That is where the benchmark library does the work. Vera maps each surviving requirement against closed transactions in the same category and size band, drawn from 500,000+ real closed transactions and organised into 520 vendor benchmarks. The output is not a score, it is a price impact estimate per requirement with the comparable deals behind it. Some lines come back with no measurable effect on net unit price. Those are the lines you should demand loudly and free. Others come back with a clear premium attached, and those are the lines that need a real internal decision rather than a checkbox.

What this does not solve

Be clear about the limits. Vera cannot rank your requirements for you in the sense that matters. She can identify duplicates, surface inherited text, ask the consequence question consistently and show you the market price of each line. She cannot decide that your compliance function is being overcautious about data residency, and she should not. That judgement belongs to people with accountability, and any tool that pretends otherwise is selling you a way to lose an argument you have not had yet.

The benchmarks also have honest boundaries. Price impact estimates are strongest in categories with deep comparable coverage and thinner where a requirement is genuinely rare. When only a handful of comparable deals include a given capability, the platform shows you the count rather than smoothing it into a confident number, and you should treat a thin sample as a direction rather than a target. Newly released capabilities in fast moving categories will always have less history behind them than mature ones.

And ranking cannot manufacture a second bidder where the market has only one. In some categories there is genuinely a single viable supplier for a specific regulated workload. What ranking does in that case is different but still valuable. It tells you honestly that you are in a sole source position before you spend eleven weeks discovering it, which means you can negotiate as a sole source buyer, on term length, price protection and exit rights, rather than pretending to run a competition the vendor already knows you have lost.

The failure mode this removes is narrow and common. It is the process where a shortlist of six became a shortlist of one for reasons that had nothing to do with capability, and everything to do with a spreadsheet column that said Required 214 times. That column costs real money every year, quietly, and nobody ever writes it down as a line item.