The Business Case for Salesforce:
Template and Techniques

The Business Case That Fails at First Challenge

A Salesforce business case that has been accepted by the technology team but not challenged by the finance function is not ready for board approval. Most Salesforce business cases fall into one of two failure modes: they are too optimistic (benefits are aspirational, costs are minimised, and the CFO's first question exposes the gap), or they are technically thorough but strategically unconvincing (the financial model is sound but the narrative does not connect to business strategy).

The goal is a business case that survives a rigorous CFO challenge and creates genuine conviction among approvers — not just a document that secures a signature. A business case that is approved based on inflated benefits creates a programme that will be judged against those benefits for the next three years.

The Strategic Context: Why Now, Why This

The business case must open with the strategic problem it is solving, not the technology solution it is proposing. "We need a CRM" is a technology solution. "We are losing X% of pipeline visibility because sales data exists in four disconnected systems, creating £Y of foreseeable revenue risk over the next 12 months" is a strategic problem that Salesforce can solve.

The strategic context section answers three questions: What is the current-state problem? What is the business impact of the problem? Why is now the right time to address it? The urgency question is critical — if the problem has existed for three years and the organisation survived, the board will ask why it cannot survive another year. The answer requires evidence of escalating impact, competitive pressure, or compliance requirement — not "we want a better system."

The Do-Nothing Option

Every business case should explicitly analyse the do-nothing option — the cost and risk of not investing. Most Salesforce business cases omit this, which means approvers cannot compare the investment against the alternative. The do-nothing analysis should include: continued productivity loss from current-state inefficiency (quantified), escalating risk exposure (data quality, compliance, competitive), and opportunity cost (the revenue or savings that cannot be captured without the capability).

A well-constructed do-nothing analysis often makes the investment decision straightforward. If the current-state costs £800,000 per year in productivity loss and the Salesforce investment costs £400,000 per year all-in, the financial case is clear. If the do-nothing cost is unclear, the investment case is weak.

The 5-Year Financial Model

The financial model is the core of the business case for any finance-literate approver. It should project costs and benefits year by year over at least 5 years, with a clear NPV and payback period. Key construction principles:

Cost completeness. Include all five TCO categories (from ENT-002): licences, implementation, ongoing support, infrastructure/integration, and internal talent. Under-representing costs is the most common failure — it destroys credibility when actual costs exceed the plan.

Benefit conservatism. Use conservative benefit assumptions with explicit evidence. If you claim a 10% improvement in win rate, show that 10% is based on comparable implementations, not aspirational targets. Benefit claims that cannot be evidenced will be challenged and discounted.

Phased benefit realisation. Benefits do not materialise at go-live — they ramp over 12-18 months as adoption increases and process changes embed. Model this explicitly. A benefit that appears in Year 1 at 100% of potential is not credible; the same benefit at 20% in Year 1, 60% in Year 2, 90% in Year 3 is credible and defensible.

The Benefits Realisation Plan

A benefits realisation plan is the section that connects the financial model to accountability. It specifies: which benefit, how much, by when, measured how, owned by whom. Without this section, approved benefits remain aspirational. With it, each benefit has an owner who is accountable for its realisation — and the programme has a mechanism for tracking whether benefits are materialising.

The benefits realisation plan also forces a conversation about pre-implementation baselines (from ENT-003). If you cannot agree pre-go-live what the baseline is and how you will measure improvement, you cannot demonstrate the benefit after go-live.

The Risk Register and Mitigation

A business case risk register that says "implementation may take longer than planned" and "users may not adopt" without quantifying either risk, identifying its cause, or proposing a mitigation is not a risk register — it is a risk list. A credible risk register includes: risk description, probability, impact (in financial terms if possible), root cause, mitigation, and residual risk after mitigation.

The risks that most commonly challenge Salesforce business cases: implementation cost overrun (scope discovered during build), talent and knowledge transfer (what happens if key people leave), integration complexity (what if the third system integration takes 3× as long), and adoption failure (what if users do not change behaviour). Each should have a named mitigation and a contingency reserve in the financial model.