A named solution at intake is not a requirement. It is a conclusion someone else reached in a demo, and it quietly sets your ceiling before the first quote lands.
The ticket lands on a Tuesday. Subject line: Purchase request, renewal of licences, please expedite. In the body there is a vendor name, a seat count, a quote reference and a note that the team has already run a demo, loved it, and told the account executive that paperwork will follow. There is no requirement document. There is no statement of the business outcome. There is a decision, and it has been handed to you to execute. You are not being asked what to buy. You are being asked to process something already bought in everything but signature.
Every procurement desk recognises this. It is not sabotage and it is rarely political. The requesting team believes they are helping. They did the research you would have asked for, they narrowed the field, they even negotiated a little. What they did not do, because nobody asked them to, is separate the problem from the product. By the time the ticket reaches you, those two things have fused, and unfusing them is now your job, against a deadline you did not set.
Software sales cycles are designed to produce exactly this ticket. The demo is the mechanism. A good demo does not describe capability in the abstract, it shows a specific person doing a specific task they currently hate, in a product-shaped way. Forty minutes later, the requester no longer has a problem called our handoffs between support and engineering leak. They have a problem called we do not have this tool yet. That translation happens inside the vendor's frame, on the vendor's slides, using the vendor's vocabulary for the feature set.
The second reason is structural. Most intake forms ask for a vendor, a cost centre, a start date and a business justification field that is three lines tall. A three line justification cannot hold a requirement. It can hold a sentence, and that sentence will almost always be a restatement of the product. Ask a narrow question, get a narrow answer. Procurement then inherits a form that was never designed to capture the thing procurement needs most, which is the outcome the business is willing to pay for, expressed independently of who supplies it.
The third reason is the one nobody says out loud. Requesters have learned that naming a vendor gets the ticket moving. An abstract need sits in a queue. A named vendor with a quote and an expiring discount has urgency attached to it. So the naming behaviour is rewarded, and it persists. This is the same pressure that produces overlapping tooling across departments, which we covered in Shadow IT and duplicate tools: catch them at the request. The request stage is where both problems are cheapest to fix and where nobody has time to fix them.
A named vendor at intake does not just remove alternatives. It removes your pricing frame. Once the specification is written in one vendor's product language, every comparison you attempt afterwards looks like a downgrade. The requester reads a competitive quote and sees missing features rather than a different architecture of the same outcome. You end up defending a comparison instead of running one, and the defence costs you weeks you do not have.
It also removes your leverage narrative. The account executive on the other side knows the demo happened. They know the champion exists. In most enterprise sales methodologies, an internal champion who has already declared preference moves the deal from contested to defended, and defended deals get priced accordingly. You are negotiating from a position the vendor already scored, and your only remaining lever is volume or term, both of which cost the business something real.
Finally, it removes the option value of the outcome itself. Consider a request for a dedicated tool at, for example, 120 seats. The underlying need might be met by an existing platform module you already pay for, by a smaller specialist product at a third of the price, or by the named vendor at a tier below the one demoed. You cannot price any of those alternatives if the requirement is written as the product name. The specification lock is not a philosophical problem. It is a spend problem with a number attached, and the number is invisible precisely because the alternatives were never quoted.
The unlock is not a longer form. Longer forms get abandoned, and abandoned forms push requesters back to email, which is where the vendor name gets named again. The unlock is an interview, run in the requester's own language, that walks backwards from the product to the job. Vera runs that interview at intake. It takes the named solution as the starting point rather than treating it as an obstacle, then asks the questions a good analyst would ask if they had thirty uninterrupted minutes with the requesting manager, which no one ever has.
The questions are unglamorous and that is the point. What breaks today, and how often. Who touches the process, and at what point in the week. What was the last incident this would have prevented. What happens if nothing changes for two quarters. Which of the demoed capabilities did the team actually react to, and which were background noise. Answers to those questions produce a requirement that is portable across suppliers, which is the whole objective. The requester is not being interrogated. They are being helped to write down the thing they already know.
A portable requirement is only half the answer. The other half is evidence, because a requester who has already fallen for a product will not be moved by a procurement opinion. They will be moved by what comparable organisations actually paid for the same outcome. That is where the requirement gets matched against 520 vendor benchmarks drawn from 500,000+ real closed transactions, and narrowed to the cohort that resembles you on size, sector and deployment shape. A typical requirement resolves against something on the order of 5,000 comparable deals, which is enough to show a distribution rather than a single anecdote.
The output is not a verdict, it is a position. The quoted price sits at some percentile of what comparable buyers paid for that outcome. Adjacent suppliers who satisfy the same requirement sit at their own percentiles. Sometimes the named vendor is genuinely competitive and the fastest honest answer is to say so, run a short price challenge and sign. That result is a win too, and it arrives in days rather than after a procurement process nobody believed in. The point of unwinding the specification is not to block the request. It is to know which of those two situations you are in before you commit.
One practical note for small teams. This motion does not require a sourcing committee. A single buyer can run intake interviews, benchmark checks and the reframe note in the same week, which is the working pattern we described in The one-person procurement desk: doing a team's job with agents. If you want to test the evidence layer before you change anything about your intake process, you can start with a free price check on a live quote and see where the number you were handed actually sits.
Be honest about the boundaries, because overselling this motion is how it gets abandoned in month three. Vera cannot stop a requester from taking a demo. Nor should it. Demos are how technical teams evaluate fit, and a team that has seen a product working is a better informed team than one reading a feature matrix. The interview changes what happens after the demo, not before it.
It also cannot override an executive decision. If a chief officer has committed to a supplier for strategic reasons, benchmarking will tell you what that decision costs relative to market, which is genuinely useful, but it will not reverse the decision and you should not pretend otherwise. Knowing you are paying above the 70th percentile for a deliberate reason is a defensible position. Not knowing is not.
Benchmark coverage is uneven by category. Mature categories with many transacting buyers produce tight, confident distributions. Newer categories, niche vertical tools and heavily bespoke arrangements produce wider bands, and the platform shows that width rather than hiding it. When the band is wide, the honest read is that the benchmark narrows your range rather than fixing your target, and your leverage has to come from term, scope or timing instead.
Finally, this does not fix the calendar. If the ticket arrives four working days before a quote expires, you have four working days, and the fastest version of this motion is an interview, a benchmark read and a price challenge rather than a full competitive process. The structural fix for that is upstream renewal visibility, not faster intake. What the interview does buy you, even in a compressed week, is the knowledge of whether you are executing someone else's decision or making one.
The measure of success here is unromantic. Six months in, you should be able to open any approved request and find, above the vendor name, two or three sentences describing what the business was trying to achieve, and beside it a percentile. If those two things are present, procurement inherited a need. If only the vendor name is there, you inherited a decision again, and the tooling did not change the habit. The interview is the habit.
Fredrik has spent more than twenty years in enterprise software, with time at Oracle, IBM, SAP, and Salesforce before moving to the buy side. He structured and priced the kind of large agreements most buyers only see once or twice in a career, which taught him where the leverage sits and how far a vendor will actually move. He started VendorBenchmark to hand that knowledge to every sourcing team.