How to Build a ServiceNow Business Case
Your CFO Will Approve

1.  What a CFO Actually Reads — And What They Skip

Before writing a single section of your business case, understand how it will be read.

A CFO receiving a capital investment proposal does not read it cover to cover. They scan the executive summary, turn to the financial model, look for the risk section, and then — only if those three pass — they read the rest. If the executive summary does not give them the financial outcome in the first paragraph, many will not proceed further.

A winning ServiceNow business case is a financial document with a technology appendix — not the reverse.

Here is what a CFO reads first, second, and last — and what they skip entirely:

The implication is clear: structure your business case so that the CFO’s three questions are answered before page 3. Everything else supports those answers; it does not replace them.

2.  The 6 Components Every Approved ServiceNow Business Case Contains

After reviewing and contributing to dozens of ServiceNow business cases across enterprise clients, the same six components appear in every proposal that receives board approval. Remove any one of them and the approval rate drops significantly.

This is the number CFOs trust most — because it comes from the organisation’s own data, not a vendor benchmark. The current-state cost baseline answers: what is this problem costing us today?

Calculate it by documenting: the average cost per incident or transaction in the current process, the annual volume of those incidents or transactions, the FTE hours consumed by manual workarounds, and the cost of errors, rework, and compliance failures. Add them together. That is your baseline.

Turn the baseline into a business problem stated in financial terms. Not “our ITSM process is inefficient” but “our current process costs £X per incident, generates Y hours of manual work per week, and is contributing to Z compliance risk exposure per annum.”

One paragraph. Numbers only. No IT jargon.

The financial model is the centrepiece of the business case. It must include:

• Net Present Value (NPV) at a discount rate your finance team specifies
• Payback period — the month in which cumulative benefit exceeds cumulative cost
• Internal Rate of Return (IRR) for organisations that use it as an investment hurdle
• Sensitivity analysis — a low, base, and high scenario so the CFO can stress-test assumptions

Present the financial model on one page. If it takes more than one page, it is too complex to defend under questioning.

Every CFO will ask: what if this goes wrong? Answer the question before they ask it. A risk register with five rows — the top five risks, their likelihood, their financial impact, and your mitigation plan — signals maturity and preparation. A business case with no risk section signals overconfidence, and CFOs have been burned by overconfident IT proposals before.

Phased investment proposals have a meaningfully higher approval rate than single-tranche requests. Presenting the investment in phases does three things: it reduces perceived financial risk, it creates natural review points where value can be demonstrated before further spend is approved, and it surfaces early wins within 90 days that build executive confidence.

Define the three measurable outcomes the CFO will use to judge the investment at 6 months and 12 months. These must be agreed at approval stage — not defined retrospectively after go-live. The organisation that defines success before the project starts consistently outperforms the one that measures retrospectively.

3.  The Cost of Doing Nothing — The Number That Wins Budget Approval

The most powerful number in any business case is not the cost of the project. It is the cost of doing nothing.

Decision-makers are naturally loss-averse. When the choice is framed as “invest £X now” versus “do nothing and lose £3X over the next three years,” the psychology of the decision shifts fundamentally. The question is no longer whether to invest — it is whether the organisation can afford not to.

The CFO is not deciding whether to spend money. They are deciding whether the cost of spending is lower than the cost of not spending.

Here is how to calculate the cost of doing nothing for a ServiceNow proposal:

Present the three-year figure in your executive summary. This is the number your CFO will remember.

When you place this figure on the left side of a comparison table against the total cost of the ServiceNow programme on the right, the investment decision becomes self-evident. The CFO is no longer approving a cost — they are authorising a saving.

4.  Translating IT Outcomes Into CFO Language

The single most common reason a ServiceNow business case stalls at board level is not the financial model. It is the language.

IT teams present what the platform does. CFOs need to hear what the organisation gains. These are not the same thing, and the gap between them is where most proposals lose momentum.

Here is the translation table every IT leader needs before their next budget submission:

The rule is simple: every IT metric in your business case must have a corresponding financial translation. If you cannot express it in pounds, hours, or risk exposure, it does not belong in the executive summary. Teams trying to strengthen adoption outcomes should first fix the post-go-live operating model described in Why ServiceNow Adoption Fails After Go-Live — and the Change Management Model That Fixes It.

Print this table and use it as a checklist before you submit your next proposal. If any row in your business case uses the left-column language without the right-column translation, rewrite it before the CFO sees it. If you need a measurement framework before building the business case, read How to Measure ServiceNow ROI — The Metrics CIOs Actually Care About.

5.  The 5 Business Case Mistakes That Kill Budget Approval

We have seen all five of these in proposals that arrived at MJB Tech for review after being rejected internally. None of them are difficult to fix. All of them are common enough to warrant calling out explicitly.

Mistake 1: Leading with features. The first three pages describe ServiceNow modules — ITSM, HRSD, CSM — and what each one does. The CFO does not need to know what the modules do. They need to know what problem gets solved and what it costs today. Lead with the problem, not the product.

Mistake 2: Underestimating total cost of ownership. The financial model includes licence cost and implementation fees, but excludes ongoing admin, training, annual renewals, and the internal IT time required to manage the platform. CFOs who have been burned by a hidden-cost IT project will challenge every line of your model. Include everything, and then defend it. A complete model that is slightly higher than expected is far more credible than an incomplete model that looks suspiciously low.

Mistake 3: Using industry averages instead of internal data. Referencing analyst benchmarks (“industry average ticket cost is £22”) is a red flag for experienced CFOs. They know that benchmarks vary enormously by sector, organisation size, and process maturity. Use your own data wherever possible. If you do not have it, say so, and explain how you will establish a baseline in the first 30 days of the project.

Mistake 4: Presenting a single financial scenario. A business case with one set of assumptions signals that the author has not stress-tested them. Present three scenarios: a conservative case (assumptions challenged by 20%), a base case (your best estimate), and an optimistic case (if adoption is exceptional). This demonstrates rigour and makes the CFO’s job easier — they can see the range of outcomes rather than having to imagine it.

Mistake 5: Asking for full budget in year one. A single £600k capital request in year one is significantly harder to approve than a phased request: £180k in year one to deliver the first use case, with year two and year three investment contingent on achieving the success criteria defined at approval. Phased investment gives the board a natural off-ramp if the project underperforms, and that off-ramp is precisely what makes them willing to approve it.

6.  A Ready-to-Use Business Case Structure — Section by Section

Below is the exact structure used in ServiceNow business cases that have achieved board approval. Use it as your template. The word counts are guidelines based on what CFOs actually read in full — sections that exceed them tend to lose the reader before the financial model.

One final structural note: the technology appendix belongs at the back. Detailed module descriptions, vendor comparison matrices, and technical architecture diagrams are important — but they belong after the financial model, not before it. The CFO who needs to see the technical detail knows where to find it.

The Business Case Is the First Deliverable — Not the Last Step Before Approval

The most important shift in thinking is this: the business case is not a document you write to get budget. It is the first strategic agreement between IT and the business about what success looks like.

Organisations that treat it this way get faster approvals. They get fewer scope changes mid-delivery, because the CFO and CIO agreed the scope before the project started. They get stronger executive sponsorship, because the board approved specific outcomes, not a vague technology programme. And they get cleaner post-project reviews, because success was defined before go-live — not after.

Get the business case right, and the budget conversation takes care of itself.

The organisations that struggle — that have their proposals rejected, descoped, or deferred into the next financial year — are almost always the ones that treated the business case as the last administrative step before approval, rather than the first collaborative deliverable of the programme.

Write the business case with the CFO, not for the CFO. Involve finance in the financial model. Involve the business owners in the problem statement. Involve the risk team in the risk register. The document that a CFO helped to write is the document the CFO is most likely to approve.