The request that never states the cost of doing nothing

Look back at the last request that landed on your desk. It probably opened with a solution and a budget line, and it almost certainly did not tell you what the business currently pays to live without the tool. There was no number for the status quo. No cost of the spreadsheet the team has been maintaining, no cost of the manual reconciliation, no cost of the existing license that already does eighty percent of the job. The request assumed the purchase was necessary and asked you to process it, not to test it. That single missing number, the cost of doing nothing, is what turns procurement from a decision into a rubber stamp.

Why the baseline goes missing

A requester writes intake to get to yes, not to expose the trade off. Stating the cost of the current workaround is work, and worse, it invites the question the requester would rather avoid: is the pain actually expensive enough to fund. So the field stays blank. The business case becomes a description of the new tool's features rather than a comparison against the present state. This is the same failure pattern as a ticket that names the vendor instead of the need, and it produces the same result: procurement inherits a conclusion and is asked to source it.

The reason this persists is structural, not personal. Nobody owns the counterfactual. The requester owns the request, finance owns the budget, but the cost of the status quo belongs to no one, so no one measures it. In a world without a baseline, every request clears the same low bar. A tool that saves ten hours a year and a tool that saves ten hours a week look identical on paper, because neither is asked to prove the size of the problem it removes.

What a missing baseline actually costs you

Three failures follow from the blank field. First, you cannot prioritise. If no request states the value of the current situation, you cannot rank one against another, so requests get funded in the order they arrive or in the order of who shouts loudest. Second, you cannot detect duplication. A request for a new tool rarely mentions that a broader platform already in the estate covers the same function, which is exactly how rights the business already owns get requested again. Third, you lose the negotiation. Without a documented cost of the workaround, you have no walk away position, because you have never established that walking away is survivable.

The compounding effect is a spend base full of tools that were never tested against the alternative of not buying them. Some of those tools overlap. Some replace a workaround that cost less than the license. You only find out at renewal, when the usage report is thin and nobody remembers why the purchase cleared.

The platform motion: show the estate, then demand the counterfactual

The fix has two halves, and both live before approval rather than after. The first half is visibility. Before you can judge a new request, you need to see what the business already owns and pays for, because a large share of new requests are quietly covered by an existing entitlement. The spend and estate view gives you that map, so a request for a point tool can be checked against the platform license already sitting in the portfolio.

The second half is intake discipline. Vera, the analyst agent, pushes the request back until it states the cost of the current workaround before any new spend is approved. This is not a form field that people skip. It is a gate. The requester has to name what doing nothing costs, in hours or dollars, and Vera cites the estate data that either supports a purchase or shows the function is already licensed. The same discipline catches shadow IT and duplicate tools at the request, because the overlap check runs before approval, not at the next audit.

What a good request looks like once the gate holds

None of this requires the requester to become an analyst. It requires the request to carry one number it was hiding, and the platform to check that number against what you already own. Once both halves run before approval, the pile of requests stops looking uniform and starts sorting itself. The connection to answering the CFO's overpaying question in one page is direct: you cannot answer whether you overpay until you know what each purchase was measured against.

Honest limits

The platform can force the baseline to be stated and can check the estate for overlap, but it cannot verify that the stated cost of the workaround is honest. If a requester claims the manual process eats forty hours a week when it eats four, the arithmetic will still favour the purchase. Vera cites what the estate data can prove, and it can challenge a number that looks inconsistent with usage, but it cannot audit a team's own time logs it never sees.

Visibility also depends on the estate being loaded. A license bought on a personal card and never brought into the system will not appear in the overlap check, which is the same blind spot that lets duplicate tools survive. And the gate raises the friction of asking, which is the point, but a determined requester with executive air cover can still route around procurement entirely. The platform makes the disciplined path the default and the well documented one. It does not remove the human judgement about whether a stated number is true, and it does not replace the conversation you still owe the business when a request is declined.

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.