Building the Internal Business Case Your Buyer's Boss Actually Needs to See

Your champion is usually convinced by the product itself: the workflow it fixes, the hours it saves them personally, the frustration it removes from their day. Their boss, the person who actually signs off on budget, is typically convinced by none of that directly. They care about whether the spend is justified against competing priorities, whether the risk of the decision is contained, and whether the outcome is measurable enough to defend later if questioned.

A business case built only from the champion's enthusiasm, handed up the chain unchanged, usually reads as thin to the approver, because it answers questions the approver was not asking. The fix is not a longer document, it is a different document, built specifically for the audience that has to approve the spend rather than the audience that wants the product.

An approver typically wants three things stated plainly: the cost of the current situation in terms their function already tracks (lost hours, missed pipeline, redundant tool spend), the cost of this specific solution including the full commitment not just the sticker price, and a conservative statement of expected outcome with enough specificity to be checked later. Vague claims of transformation read as marketing to an approver whose job is to be skeptical of exactly that kind of claim.

It also helps enormously to preempt the approver's likely first question, which is almost always some version of what happens if this does not work. A business case that addresses the downside directly, what the exit looks like, what the contract terms are if it underperforms, reads as more trustworthy than one that only discusses upside, precisely because it signals the vendor has nothing to hide about the risk.

In practice this document usually reaches the approver as a forwarded email or a one-page attachment, without the champion in the room to add context, and often without you either. It needs to make its full argument in that condensed form: a clear headline statement of the problem and proposed fix, the cost comparison, and the conservative expected outcome, all skimmable in under two minutes by someone who was not in any of the earlier conversations.

This means cutting anything that depends on having watched a demo or having heard a live pitch to make sense. Product screenshots, feature lists, and phrases like as we discussed do not survive being forwarded to someone who was not in the room. Numbers, comparisons, and plain statements of cost and outcome do survive, because they require no shared context to understand.

The business case should read as coming from the champion's own analysis, not as a vendor sales document forwarded verbatim, even though the vendor helped build it. An approver who recognizes vendor marketing language in what is presented as their own team's analysis becomes more skeptical, not less, since it suggests the champion has not actually done independent thinking about the decision.

The practical fix is collaborative drafting: the vendor provides the structure, the numbers, and the comparisons, but the champion writes it in their own voice and adds the internal context only they would know, like how this fits with other initiatives already underway. A business case that sounds like it came from inside the buying organization, because much of the thinking genuinely did, is the version that survives scrutiny best.