Splitting a shared need across two intakes is one of the quietest ways to overpay. The volume was always there. The negotiation just never saw it as one number.
Here is last month. The data team filed an intake for a workflow automation tool, forty seats, needed by end of quarter. Three weeks later the revenue operations team filed an intake for what the requester called a slightly different automation platform, ninety seats, needed next quarter. Two tickets, two owners, two timelines. Procurement picked them up as two deals and negotiated each on its own volume. The vendor, or in some cases two vendors covering the same capability, priced each request against its own seat count. Nobody ever put one hundred and thirty seats on the table as a single ask.
That is the problem this post is about. Not fraud, not a rogue buyer, just two honest intakes for the same underlying capability that never met. The result is that you negotiated from forty seats and from ninety seats, when the leverage you actually held was one hundred and thirty. The discount curve is not linear, and the gap between those two positions is real money you never asked for.
The split starts with language. Two teams almost never describe the same need the same way. One writes automation platform, the other writes workflow orchestration, and the intake queue treats them as unrelated because the words do not match. We wrote a whole piece on that failure, the same capability, described two ways, bought twice, and the volume-split problem is its close cousin. Even when the words do match, the timelines rarely do, so the two requests land in different weeks of the pipeline and get assigned to whoever is free.
It survives review because procurement measures each deal against its own baseline. A buyer closing the forty-seat request looks at forty-seat comparables, lands a discount that looks fine for forty seats, and books a win. The ninety-seat buyer does the same. Both deals pass their own gate. There is no gate that asks whether these two should have been one. The organisation never sees the counterfactual, because the counterfactual is a deal that was never quoted.
It also survives because consolidation is work. Combining two intakes means reconciling two timelines, two budget owners, and two internal sponsors who each want their delivery date protected. It is easier to let each run. The cost of that ease is invisible until someone quantifies the discount the combined volume would have commanded, which is exactly the number nobody has time to build by hand.
Discount curves reward volume in steps, not smoothly. A vendor that gives eight percent off forty seats may give fifteen percent off one hundred and thirty, because the larger commitment crosses a threshold in their own pricing model. When you buy the two halves separately, you sit below that threshold twice and pay the higher rate on both. The gap is not hypothetical. Benchmarking against closed deals at the combined volume shows you exactly where the step is.
This is where benchmarking against comparable closed deals earns its keep. Instead of arguing the combined buy deserves a better rate on principle, you show the vendor where similar organisations landed at similar volume. The conversation stops being about your budget and starts being about the market. That is a position the vendor cannot easily wave away, and it is one you can only build when the two intakes are treated as one.
The detection happens before either deal closes. Spend visibility gives Vera the estate, and Vera reads incoming requests against it. When two intakes point at the same capability, even under different names and different volumes, Vera flags the overlap and proposes the combined figure. One of the six specialist agents handles that cross-request matching so it is not left to a human noticing a pattern in a busy queue.
Once the combined volume exists as a single number, benchmarking prices it. The library holds 520 vendor benchmarks drawn from 500,000+ real closed transactions, and the relevant comparables narrow to the deals that actually resemble yours. You get the discount the combined commitment should command, expressed as a percentile against real outcomes rather than a guess. That figure travels straight into the negotiation as evidence.
If you want to interrogate the number rather than accept it, you can. Ask Vera directly, as covered in what is covered and what a good discount looks like, and she answers with cited figures you can hand to the vendor. The point is that the combined position is built once, defended with evidence, and negotiated as a single commitment instead of two undersized ones.
Consolidation is not always the right answer, and the platform will not make that judgement for you. Sometimes two teams genuinely need different tools that only look similar in an intake ticket, and forcing them onto one contract creates a fit problem worse than the discount is worth. Vera flags the overlap. Deciding whether the combined buy actually serves both teams is a human call.
Timelines can also be a hard constraint. If one team needs the capability this quarter and the other cannot commit budget until next year, combining them may mean the urgent team waits or the patient team pays before it is ready. The platform shows you the trade. It does not remove the trade. Some splits are the correct outcome once you can see the full picture, and that is fine. The failure this post names is not splitting on purpose. It is splitting by accident, and never knowing the combined number existed.
Finally, the discount curve belongs to the vendor. Benchmarking tells you where the market landed and where the volume threshold sits, but the vendor still has to agree to price the combined commitment on that curve. What the platform gives you is the evidence to insist. When the leverage is a shared decision, as it often is with cloud commitments in FinOps meets procurement, the same discipline applies. See the whole need as one number, price it against the market, and negotiate from there.
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.