How Do You Write an ROI Page a CFO Will Believe?

What makes a CFO trust an ROI page?

A CFO trusts an ROI page when the math is visible, the inputs are the buyer's own, and the assumptions are stated plainly. Big numbers with no method behind them do the opposite. Finance leaders read ROI claims for a living and look for the weakest assumption first, so your page should show it to them before they go hunting.

An ROI page is the page on a B2B SaaS site that explains the financial return of buying your product. It might include a calculator, worked examples, or customer results. It is often the page a champion sends to their finance team when the deal reaches approval.

That handoff is why it matters so much. Your champion already believes. The ROI page has to convince someone who has never seen a demo and is paid to be skeptical. Here is how I write one that survives that reader.

Why do most ROI pages fail with finance buyers?

Most ROI pages fail because they lead with a number that sounds too good, hide how it was calculated, and use inputs the buyer cannot check. A claim like "save 10x your investment" with no method reads as marketing, not analysis. A CFO who sees that once will discount everything else on the page.

The other common failure is counting soft benefits as hard savings. Hours saved are not dollars saved unless those hours turn into lower costs or more revenue. A finance reader knows that freed-up time often gets absorbed into other work. If your page treats every saved hour as cash, the whole model loses credibility.

Finally, many ROI pages ignore cost. They show the benefit and leave out the price, implementation effort, and internal time needed to adopt the product. A model without costs is not a return calculation. It is a brochure.

What inputs should an ROI calculator ask for?

Ask for a small number of inputs the buyer already knows, such as team size, current volume, loaded hourly cost, or current tool spend. Use conservative defaults and let the buyer change every one. Avoid inputs that require research to answer, because a buyer who has to guess will not trust the output either.

Three to five inputs is usually enough. Each one should map clearly to part of the result. If an input does not change the answer much, remove it. Extra fields make the calculator look more scientific without making it more accurate.

Show where your defaults come from. "Default based on the median of our customers" is useful only if it is true and you can stand behind it. If you do not have that data, say the default is an example and invite the buyer to replace it with their own figure.

How should you show the math?

Show every step in plain language under the result. Write out the formula, the inputs used, and the assumptions, so a finance reader can rebuild the number in a spreadsheet. A transparent method is more persuasive than an impressive total, because it lets the CFO agree with the logic before they look at the answer.

A simple structure works well. State the current cost of the problem. State how much the product reduces it, and why. Subtract the product cost and any implementation cost. Show the payback period. Each step should be one or two sentences a non-specialist can follow.

Offer a downloadable version too. Many finance teams want to put your model into their own spreadsheet and adjust it. Letting them do that signals confidence and saves your champion a step.

How do you separate hard savings from soft benefits?

Split the page into two clearly labeled parts. Hard savings are direct cost reductions, such as a tool you replace or contractor spend you stop. Soft benefits are things like time saved, faster responses, or fewer errors. Put a number only on the hard savings, and describe soft benefits in words or as a separate, clearly marked estimate.

This split is the single biggest credibility boost an ROI page can get. It tells the CFO that you understand the difference and are not trying to blur it. Many will then give you some credit for the soft benefits anyway, because you did not overclaim.

The same thinking applies when I estimate the value of an automation. In how to estimate what an automation will actually save, I separate the hours an automation frees from the money it actually saves, for exactly this reason.

What proof should sit next to the calculator?

Put real customer results next to the model, with enough context to judge them: company type, starting point, what changed, and over what period. One specific, attributable result beats five vague ones. If a customer allows it, name them and link to the full case study. If they do not, describe the company honestly without inventing detail.

Proof should match the model. If your calculator focuses on reduced tool spend, show a customer who reduced tool spend. If the proof talks about something else, the CFO will notice the mismatch and wonder why.

Never publish a customer number you cannot back up. If a finance team asks your sales rep to show where a figure came from, the answer needs to exist. An ROI claim that falls apart on one question ends the deal faster than no claim at all.

How should the page handle costs and risks?

Include the full cost of adoption: subscription price, implementation fees, internal time, and any tools the buyer still needs. Then name the main risks, such as slow adoption or data migration, and say how you reduce them. A page that admits costs and risks reads as an analysis. One that hides them reads as a pitch.

This connects to how buyers move through approval. A champion who brings a balanced case to finance looks credible inside their own company. A champion who brings an inflated one gets embarrassed in the meeting. Your ROI page should make your champion look good.

I wrote more on designing for that approval step in how to write a pricing page for a buyer who needs approval. The ROI page and pricing page should tell the same story with the same numbers.

Should the ROI page be gated?

No, in most cases. Let buyers use the calculator and read the method without a form. A champion needs to share the page with finance quickly, and a gate slows that down. If you want leads from it, offer an optional emailed copy of the results instead of blocking the page itself.

An ungated page is also easier for AI assistants and search engines to read and summarize. If a CFO asks an assistant whether your product pays for itself, a clear, public method gives the assistant something accurate to work with.

If you build the calculator in Webflow, keep the method text as real page content rather than hiding it inside the calculator script. My tutorial on building a no-code ROI calculator in Webflow covers the build side.

How do you test whether the page works?

Show it to a finance person who does not know your product and ask them to find the weakest assumption. If they find it in seconds, strengthen or soften it. Then watch whether deals that reach finance approval move faster. Ask reps whether finance teams still request a separate business case after seeing the page.

Track how often the page is shared. Visits from new people at the same account, especially after a demo, often mean a champion forwarded it. That is the behavior you want the page to encourage.

Update the page when pricing or proof changes. An ROI page with an old price or a stale customer result is a quiet credibility leak.

What should you do next?

Rewrite your ROI page around visible math. Cut inputs to the few a buyer knows. Use conservative, editable defaults. Separate hard savings from soft benefits, include all costs, and place one strong, attributable customer result beside the model. Remove the gate. Then ask a finance person to break it, and fix what they find.

A believable ROI page does not need a huge number. It needs a number the CFO can defend to their own boss. That is what actually gets a deal approved.

If you want help rewriting an ROI page or building the calculator in Webflow, let's chat. I am happy to review your current version and point out where a finance reader will push back.