The intake form that asks for everything except the point

Open your intake queue and read the last ten requests without skipping. You will find a cost centre on every one. A requested go live date. An estimated annual value, usually rounded. A data classification, a named approver, a checkbox confirming the requester has read the acceptable use policy. Every field is complete. Every field is correct. And on not one of those ten requests does a single line explain what will be true twelve months from now that is not true today.

That is the problem this post is about. Not a slow form, not a missing approval step, not a vendor behaving badly. A form that looks finished and is structurally incapable of telling you why the purchase exists. Procurement then runs a competent process against a request it does not understand. You shortlist three products, you run a fair evaluation, you take a respectable discount off list, and eighteen months later nobody in the building can say whether the thing worked. The process was clean. The question was wrong.

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.

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.

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.

Vera'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, Vera asks what that vendor would do that the current arrangement does not. If they describe a symptom, Vera asks how often it occurs and what it costs when it does. If they cannot produce a baseline, Vera 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.

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.

What this does not fix

Vera 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. Vera 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.