How to Generate Business Cases and ROI Documents That Help Deals Get Approved

Every complex deal has an approval step where someone, a VP, a CFO, a procurement committee, has to justify the investment internally. Your champion knows why the product is valuable. The approver needs a business case that makes the financial logic clear, quantifies the expected return, and addresses the risks of the investment. If you don't help build that business case, your champion is going in with nothing but enthusiasm.

A great business case is a financial story. It starts with the cost of the current situation (what is the problem costing them today?), defines the expected improvement (what will change with your product?), quantifies the value of that improvement (what is that change worth in dollars?), and compares it to the investment (is the return worth the cost?). When the math is compelling and clearly presented, approvals happen faster.

The Components of a Business Case Document#

Executive Summary: 1 page. The situation, the proposed solution, the expected ROI, and the investment. Written for someone who won't read anything else.

Current State and Cost of Inaction: Quantify what the problem is currently costing. Lost revenue, wasted time, inefficiency costs, risk exposure. Use the prospect's numbers wherever possible, numbers they provided carry more credibility than industry benchmarks.

Proposed Solution and Expected Improvements: How your product addresses the identified costs. Be specific about the mechanism, how does your product create the improvement, and by how much?

ROI Model: The financial model that shows the return on investment. Three-year model is standard for enterprise deals. Include: Year 1 costs (implementation, licensing, training), Year 1-3 benefits (specific improvement metrics × value per metric), and payback period (when does the investment break even?).

Risk Analysis: What are the risks of doing nothing (cost of inaction compounding), what are the implementation risks, and how are they mitigated? Addressing risk proactively builds trust.

Recommendation: A clear recommendation section with the proposed investment, expected ROI, payback timeline, and why the current timing is right.

Using the Prospect's Numbers#

The strongest business cases use the prospect's own numbers, not industry benchmarks. If they told you "we lose about 3 hours per rep per week to manual data entry," that's the number to use, not "companies typically save 2-4 hours per week." Their number carries their implicit endorsement; an industry benchmark requires them to accept a claim they didn't make.

This is why discovery matters so much for business cases. The questions you ask in discovery, "how much time does your team spend on X?", "what does that cost you?", "what would a 20% improvement in Y be worth?", are the inputs for the business case you'll build later.

For complex deals where business case development is a regular part of the process, River's Sales workspace maintains deal context that feeds directly into business case generation.

Building ROI Models That Prospects Actually Trust#

The most common business case mistake is presenting ROI projections that seem implausible to the prospect, even when they're mathematically accurate. A business case claiming 500% ROI is technically true and practically useless if the prospect's internal review process treats anything above 200% as a red flag indicating inflated assumptions. Building business cases for internal credibility requires understanding the organization's threshold for plausibility and staying within it.

The elements that make ROI projections credible: using the prospect's own numbers (not industry benchmarks), showing conservative assumptions clearly, including sensitivity analysis (what happens if adoption is 20% lower than expected?), and building in implementation costs that many vendors conveniently omit. A business case that acknowledges implementation friction and still shows positive ROI is far more trustworthy than one that assumes frictionless success.

Handling the "We Don't Know Our Numbers" Objection#

One of the most common business case obstacles is when prospects say they can't quantify the problem you're trying to solve. "We know our current process is inefficient, but we haven't measured how much it costs us." This is more common than it might seem, particularly in organizations that haven't done systematic process cost analysis. The response is to help them estimate, not to accept "we don't know" as a conversation-stopper.

The estimation approach: if they can estimate how many people are affected, and roughly how many hours per week each person spends on the problematic activity, you can calculate a person-time cost. If they can estimate the cost per incident of the problem (sales cycles that take 30 days longer than they should, support tickets that require 2 hours of work instead of 30 minutes), you can model the aggregate cost. Most organizations can provide rough estimates for these inputs even when they don't have precise data. Rough estimates with acknowledged uncertainty are more useful than no numbers at all.

The Three Business Cases: Optimistic, Base, and Conservative#

A single-point ROI projection is inherently less persuasive than a range. When you present "we project 350% ROI," sophisticated buyers immediately ask "what assumptions does that depend on?" When you present optimistic, base, and conservative scenarios, you've already answered that question and demonstrated analytical rigor.

Conservative scenario: What's the ROI if adoption is 50% of expected, if implementation takes 50% longer, and if benefits materialize at 70% of projected levels? If the conservative scenario still shows positive ROI, the investment is low-risk.

Base scenario: Your best estimate given realistic assumptions and what you know about similar deployments at comparable organizations. This should be the one you discuss most.

Optimistic scenario: Full adoption, smooth implementation, full benefit realization. This is the ceiling, presented as such, not as the expected outcome.

Presenting all three demonstrates intellectual honesty and gives the economic buyer what they need to make a defensible internal case regardless of how the deployment actually performs relative to projections. For deal management including business case storage and sharing, River's Sales workspace keeps deal artifacts organized alongside deal intelligence and next steps.

Building Business Cases for Different Organizational Cultures#

The type of business case that persuades an economic buyer depends significantly on the organizational culture of the buying company. A financial-first culture (many PE-backed companies, public companies with demanding boards) responds to rigorous ROI models with detailed assumptions and sensitivity analysis. An operations-first culture (many family businesses, privately held companies with long tenure leaders) responds to concrete operational improvement examples and peer-company references. A risk-first culture (regulated industries, large government contractors) responds to risk reduction framing and compliance benefit emphasis.

Understanding which type of business case framing will land best requires knowing the organization's culture, which discovery should surface. If the economic buyer uses ROI language and asks about payback periods, lean into the financial model. If they ask about what other companies in their industry have done, lean into the case study approach. If they ask about compliance risk and what happens if the current approach fails, lean into the risk reduction framing. The same underlying business case data can be organized very differently for each culture type, and the framing matters as much as the numbers.

Updating Business Cases as Deals Progress#

Business cases written at the beginning of an evaluation need to be updated as discovery continues. Initial business cases are built from publicly available information and the rep's knowledge of similar deals. As discovery deepens, the prospect provides actual numbers, actual pain points, and actual success criteria that should replace the initial assumptions. A business case that still uses estimated numbers when the prospect has provided actual numbers signals that the rep stopped listening after the initial draft.

Update the business case after every significant discovery conversation with any new numbers, specific pain points, or success criteria the prospect shared. A final business case delivered before the proposal should incorporate everything learned throughout the evaluation. This "earned" business case, built incrementally from the prospect's own input, is both more accurate and more persuasive than one built at the beginning of the process and never revisited.