The form was built for the audit trail, not the decision
Look at who actually designed your intake form and the field list stops being mysterious. Finance needed a cost centre so the accrual lands in the right place. IT security needed a data classification so the review queue routes correctly. Legal needed to know whether personal data is involved. Procurement needed an estimated value so the request crosses or does not cross a threshold. Each field exists because a specific control function would otherwise have to chase the requester for it.
An outcome field serves none of those functions. No auditor has ever failed a purchase because the requester could not articulate a success measure. No accrual is misposted because the business case was vague. The outcome field is the only field on the form whose beneficiary is the negotiation itself, and the negotiation is not in the room when the form gets designed. So it is never added, or it is added as an optional free text box labelled Business Justification, which is a different thing entirely and which we will come to.
The result is a form optimised for movement rather than judgement. It gets the request routed, approved and accrued with minimal friction. It does not get the request understood. When you later try to run a real comparison, you discover you are benchmarking a product category rather than a need, and product categories are far too coarse to price against. Two companies buying the same customer support platform for very different outcomes should not be paying the same per seat rate, and in the closed transaction data they usually are not.
PART TWO
Why the gap survives every intake redesign
Most procurement teams have redesigned intake at least once in the last three years. The outcome field still is not there, or it is there and empty. Three reasons, in order of how much damage they do.
First, free text fields degrade under load. Add a box labelled What outcome are you trying to achieve and within a quarter it fills with the words improve efficiency, replace manual process, and align with strategy. Not because requesters are lazy, but because a single open box gives no signal about what a good answer looks like. Nobody writes a baseline, a target and a measurement method into a text area on a form that also asks for their cost centre. The field becomes a formality, and formalities get copied and pasted.
Second, the person filling the form frequently cannot answer the question alone. A team lead requesting a scheduling tool knows the symptom, which is that coordination is painful. Turning that into an outcome requires a short back and forth about what specifically is painful, how often, what it currently costs in time, and what would count as fixed. That is a conversation, not a field. Intake forms are built on the assumption that all required knowledge lives in one person's head at one moment, and for outcomes it never does. This is the same argument we make about renewals in starting the renewal with an interview rather than a blank dashboard, and it applies with more force at intake, where nothing has been established yet.
Third, the cost of the omission is deferred and lands on someone else. The requester feels no pain from the missing outcome. The approver feels none. The pain arrives nine to eighteen months later, on the desk of whoever has to defend the renewal, and by then the field is a historical curiosity. Costs that arrive late and on other people do not get designed out. They get absorbed. It is the same structural blind spot that lets duplicate tools accumulate, because nobody at the point of request is measured on what the estate looks like in aggregate.
app.isvcosell.com/intake/req-4182/interview
ISVCOSELL works the request as an interview, asking for baseline and target before it asks for a vendor.
THE SAME JOB, TWICE
TODAY, BY HAND
Read the intake ticket, note that it names a vendor and a go live date but no measurable objective, and flag it for clarification
Open the spend spreadsheet and prior year contract folder to work out whether anything already in the estate does part of this job
Email the requester, then their manager, then the two stakeholders they name, and wait across a fortnight for answers that partly contradict each other
Draft a requirements document from the fragments, guess at the success measure, and circulate it for a review nobody has time to do properly
Roughly 11 hours of work, spread across three weeks of waiting on replies
WITH ISVCOSELL
Forward or route the raw request into the intake queue exactly as the requester submitted it
ISVCOSELL runs a short structured interview with the requester, asking for the current baseline, the target, how it would be measured and what happens if nothing is bought
ISVCOSELL drafts the specification from those answers and matches it to the comparable deal cohort for that outcome, not just that product category
A procurement lead reviews the draft, edits two lines, and approves it into sourcing
About 25 minutes of your attention
What changes: roughly 11 hours per request becomes about 25 minutes. For a team handling, say, eight intake requests a month, that is about 88 hours becoming under 4, so roughly 84 hours returned each month and around 1,000 hours a year. At an illustrative loaded rate of 70 per hour, that is on the order of 70,000 a year in analyst time, before you count the negotiation leverage of walking in with a specification that can actually be benchmarked.
PART THREE
What an outcome anchored specification actually contains
An outcome is not a sentence about ambition. It has four parts and all four are short. A baseline, meaning the current number. A target, meaning the number you want. A measure, meaning where that number is read from and by whom. And a decision date, meaning when the organisation concludes the thing worked or did not. Onboarding takes 14 days today, we want 7, measured from HR system start date to first completed task, reviewed at the end of Q3. That is an outcome. It fits on one line and it changes everything downstream.
ISVCOSELL's intake motion gets to that line by interviewing rather than collecting. The questions adapt to the answers. If the requester names a vendor first, ISVCOSELL asks what that vendor would do that the current arrangement does not. If they describe a symptom, ISVCOSELL asks how often it occurs and what it costs when it does. If they cannot produce a baseline, ISVCOSELL says so explicitly in the output rather than filling the gap with a plausible sentence, which is a boundary we describe in more detail in what we will not let the AI do on your deals. Six to eight questions, answered in the tool or in the chat client the requester already lives in, and the specification writes itself from the transcript.
"A category tells you what to buy. An outcome tells you what to pay for it."
PART FOUR
Why the outcome is the thing that makes a request benchmarkable
Here is the commercial payoff, and it is larger than the time saved at intake. Once the request carries a baseline, a target and a measure, the deal has a denominator. You are no longer asking what other companies pay per seat for this category. You are asking what companies with a comparable estate paid to move a comparable metric by a comparable amount, which is a question the closed transaction record can answer with precision. That is the difference between a benchmark that a vendor can wave away as unrepresentative and one that survives contact with their commercial desk.
It also changes what you are willing to concede. A specification with a measurable target makes it obvious which modules are load bearing and which are attached to the quote because the sales motion prefers a bundle. Requests without an outcome cannot make that distinction, so they buy the bundle and negotiate the percentage. Requests with one negotiate the scope first and the percentage second, which is consistently where the larger number sits.
app.isvcosell.com/benchmarks/collab-suite/percentiles
With a measurable target attached, the request lands in a cohort rather than a category.
1 The request stops naming a vendor first. Interviews that begin with the outcome surface, in a meaningful share of cases, that the requester chose a product because a peer mentioned it. Establishing the outcome before the shortlist keeps at least one genuine alternative in play, which is the precondition for any real negotiation.
2 Duplicate spend gets caught at the door instead of at audit. An outcome expressed as a measurable job can be matched against what the existing estate already does. Category names cannot do this because three tools in three categories routinely do the same job.
3 The benchmark stops being generic. A cohort selected on comparable outcomes and comparable scale produces a defensible target price. A cohort selected on product name produces a range so wide the vendor can pick a point inside it and call it fair.
4 The renewal has a scoreboard waiting for it. A baseline recorded at intake becomes evidence at renewal. Without it, the incumbent's own usage dashboard is the only account of value in the room, and it is not a neutral one.
5 Finance gets a forecast it can defend. Requests carrying a target and a decision date roll up into something closer to a plan than a list, which is the raw material for the kind of view described in answering the overpaying question on one page.
PART FIVE
What this does not fix
ISVCOSELL cannot manufacture an outcome that does not exist. If a request genuinely originates from an executive preference with no measurable objective behind it, the interview will document that clearly and route it onward. That is useful, because an explicit note saying no baseline was available is far better than a fabricated one, but it is not the same as changing the decision. Some purchases are political and will remain political. The platform makes the politics visible rather than dissolving it.
Benchmark coverage is real but finite. For genuinely novel categories, particularly early AI tooling where pricing models are still moving quarterly, the comparable set is thinner and the range is wider. ISVCOSELL will tell you when the cohort is small rather than presenting a confident percentile off a handful of points. Treat those cases as directional and negotiate on structure, term length, exit rights and expansion pricing, rather than trying to hold a precise unit rate you cannot yet defend.
There is also a friction cost and it is honest to name it. An interview asks more of the requester than a form does. Some will resent it, particularly for small purchases, and you should set a threshold below which the full interview does not run. And none of this fixes the organisational habit of committing to a vendor in a conversation months before the request ever reaches intake. Nothing in the tooling reaches backwards into that. What it can do is ensure that once the request does arrive, it carries the one field that makes every step after it worth doing.
About the author
Morten Andersen, Cofounder, ISVCOSELL
Morten brings two decades of enterprise and software procurement, with stints across Oracle, IBM, SAP, and Salesforce shaping how he reads a deal. He has led sourcing through hundreds of renewals, from mid market order forms to nine figure global agreements, and learned that the buyers who win are the ones who walk in knowing the market. He built ISVCOSELL to make that pattern recognition repeatable.
More posts by Morten Connect on LinkedIn →
FREE TRIAL · FULL PLATFORM · NO CARD REQUIRED
Make every intake request benchmarkable before it becomes a purchase order
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