Key points
- The most common outcome of a good intake interview is discovering you own a module that covers 70 percent of the need, for example.
- 4 The quoted price gets a percentile, not an opinion.
- Knowing you are paying above the 70th percentile for a deliberate reason is a defensible position.
Why the vendor name arrives before the need
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.
PART TWO
What the specification lock actually costs you
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.
"A vendor name is not a requirement. It is a conclusion someone else reached in a room you were not in."
PART THREE
The weekly licensing brief
Want to be updated when major licensing and pricing changes land? One analyst brief a week: the price rises, metric changes and audit campaigns that move software costs. Work email only.
Get the brief
The intake interview that converts a solution back into a need
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. ISVCOSELL 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.
app.isvcosell.com/ISVCOSELL/intake/REQ-4482
ISVCOSELL restates the named product as an outcome requirement, then cites what comparable deals paid for it.
THE SAME JOB, TWICE
TODAY, BY HAND
Read the ticket, the vendor quote and the demo recap deck, then list what the tool appears to do
Build a comparison spreadsheet by hand, guessing at three alternative vendors and pulling list prices from public pages
Search email and the contract folder for anything overlapping already in the estate, then ask two department leads to confirm
Draft a requirements summary and a challenge note back to the requester, then wait for the meeting that reframes the request
Roughly 11 hours of analyst time, spread across two to three weeks of waiting
WITH ISVCOSELL
Route the intake ticket to ISVCOSELL and let the structured interview run with the requester in their own words
Review the outcome requirement ISVCOSELL produces, edit the two lines that are wrong, and approve it
Open the benchmark set ISVCOSELL attached for that requirement and read the percentile position of the quoted price
Send the requester the one-page reframe with comparable deal evidence and a recommended shortlist
About 35 minutes of your attention
What changes: roughly 11 hours becomes about 35 minutes, and the calendar cost drops from two or three weeks to the same afternoon. For a desk handling, for example, eight named-vendor intakes a month, that is about 84 hours a month returned. Priced at a loaded analyst rate of roughly 70 per hour, that is in the region of 5,800 a month of capacity, before counting whatever the reframed shortlist saves on the deal itself.
PART FOUR
Benchmarking the need rather than the name
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 1,483 vendors benchmarked on modelled deal cohorts, and narrowed to the cohort that resembles you on size, sector and deployment shape. A typical requirement resolves against a cohort of comparable deals large 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.
app.isvcosell.com/benchmarks/collaboration-suite/percentiles
The quoted price plotted against the closed-deal distribution for the same outcome, not the same brand.
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.
1 Intake stops asking which vendor. The first question becomes what breaks today and how often. The vendor name is still captured, but as context, not as the specification. Requesters keep their preference and lose nothing by stating the problem underneath it.
2 The requirement becomes portable. Written in outcome language, the same requirement can be priced against three suppliers without anyone reading a competitor as a downgrade. This is the single change that restores your comparison.
3 Overlap surfaces before spend, not after. A requirement expressed as a job rather than a product can be matched against what the estate already does. The most common outcome of a good intake interview is discovering you own a module that covers 70 percent of the need, for example.
4 The quoted price gets a percentile, not an opinion. The requester sees where their number sits in the closed-deal distribution for that outcome. Evidence moves champions. Procurement scepticism does not.
5 The champion problem gets priced in. You go into the call knowing the vendor knows about the demo. That changes what you ask for and when. Rehearsing that conversation is worth more than another round of internal alignment, and the voice sparring room exists for exactly that.
6 The decision has a written trail. When finance asks in nine months why this tool and not that one, the answer is a requirement document, a benchmark position and a dated shortlist, rather than a memory of a demo.
PART FIVE
What this does not fix
Be honest about the boundaries, because overselling this motion is how it gets abandoned in month three. ISVCOSELL 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.
About the author
Fredrik Filipsson, Cofounder, ISVCOSELL
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 ISVCOSELL to hand that knowledge to every sourcing team.
More posts by Fredrik Connect on LinkedIn →
See it in the product
How benchmarking works → Browse the use cases → Every feature → Calculate your time saved →
FREE TRIAL · FULL PLATFORM · NO CARD REQUIRED
Turn the next named vendor request back into a priced need
The free trial opens the benchmarking database, 1,483 vendors deep, plus the negotiation guides, playbooks, and talking points for your own renewals. No card needed, a corporate email is all it takes.
Start your free trial → Or decode a contract free, no account
Free for 30 days, no card needed. Your data stays isolated at the database, and you can export or delete it any time.
V ISVCOSELL
A ISVCOSELL product · © 2026
PLATFORM Benchmarking Negotiations Contract management AI workflows Document search Renewal calendar
PRODUCT Use cases Features Security Pricing Deployment options About
RESOURCES Getting started ROI calculator Agent protocol FAQ Blog Request access
Watch it in action
ISVCOSELL: the three minute demo What discount should we expect? One question, every agreement