Skip to content

Business Case & ROI

Business case template for a software purchase

By Justin HamptonLast updated Reviewed by Justin HamptonHow we write these

Short answer

A business case for a software purchase fits on one or two pages: the problem and what it costs, the options you considered, the one you recommend, every cost, the return and payback period, the risks, a timeline and the decision you need. Copy the template below, fill it with real numbers, and write the summary last.

Key takeaways

  • Payback in months is the total first-year cost divided by the monthly benefit.
  • Count staff time to set up and train as a cost; leaving it out loses an approver's trust.
  • List at least three options, including doing nothing, so the decision looks considered.
  • Show what happens to payback if the savings come in at half what you expect.
  • End with one specific request: the amount, budget line, vendor, term and the date you need it by.

This business case template is built for one job: getting a software purchase approved. It has eight short sections, a payback formula, and a filled-in example you can copy the shape of. It works whether you are the buyer asking your boss for budget or the seller helping your champion make the case internally.

I've sat through a lot of demos where the person on the call loved the product and the deal still died. Almost every time, the reason was the same. The champion had to explain the purchase to someone who wasn't on the call, and they had nothing to hand over. A one-page business case fixes that. For the longer walkthrough of how to argue each section, read how to write a business case.

The business case template

Copy this, delete the hints in brackets, and fill in each section. Keep it to one or two pages.

Business case template: software purchase

Business case: [Name of the software or project] Prepared by [Name, role] for [Approver name, role]. Date: [date].

1. Summary (write this last) [Three or four sentences. The problem, what it costs us, what I recommend, what it costs, when it pays back, and the decision I need by when.]

2. The problem and what it costs us [Describe the problem in plain words, the way the team describes it. Then put a number on it: hours lost, revenue missed, errors, overtime, churn. Show the math: people × hours × hourly cost × weeks.]

Current cost of the problem: [$ per year]

3. Options we considered

  • Option A: Do nothing. [What happens if we change nothing. What it keeps costing.]
  • Option B: [Alternative, e.g. hire, build in-house, a different tool]. [Cost, pros, cons.]
  • Option C: [Recommended software]. [Cost, pros, cons.]

4. Recommended option and why [One paragraph. Why this option beats the others on the things we care about. Name the deciding factor.]

5. Costs

  • Subscription or licence: [$ per year, term length]
  • Setup, onboarding or migration: [$, one-time]
  • Staff time to set up and train: [hours × hourly cost]
  • Other (integrations, hardware, contract overlap): [$]

Total first-year cost: [$] Ongoing yearly cost after year one: [$]

6. Return and payback

  • Expected benefit: [$ per year, and how we got it]
  • Monthly benefit: [yearly benefit ÷ 12]
  • Payback period: [total first-year cost ÷ monthly benefit] months
  • First-year ROI: [(yearly benefit − total first-year cost) ÷ total first-year cost × 100]%

Assumptions: [List each assumption and its source. Say which ones are estimates.]

7. Risks and how we'll handle them

  • [Risk 1, e.g. the team doesn't adopt it] → [What we'll do about it]
  • [Risk 2, e.g. security or data review] → [What we'll do about it]
  • [Risk 3, e.g. the savings come in lower] → [What happens to payback if benefit is half what we expect]

8. Timeline

  • Decision by: [date]
  • Contract signed: [date]
  • Setup and training: [dates]
  • Live: [date]
  • First review of results: [date, e.g. 90 days after go-live]

Decision needed [Exactly what you're asking for. "Approve $X from the [budget line] budget for a [term] contract with [vendor], signed by [date]."]

The payback and ROI formulas

These are the two numbers approvers look for first. Use the same formulas every time so nobody argues about the method.

Payback period (months) = Total first-year cost ÷ Monthly benefit

First-year ROI (%) = (Yearly benefit − Total first-year cost) ÷ Total first-year cost × 100

Total first-year cost means everything: subscription, setup, and the hours your own people spend getting it running. Leaving out staff time is the fastest way to lose an approver's trust. If you want the math done for you, the free ROI and payback calculator runs both formulas.

A filled-in example

This is a made-up example. Fernhill Accounting is a fictional 22-person accounting firm, and every number below is illustrative. Use it to see the shape and level of detail, not as a benchmark.

Example: Fernhill Accounting (fictional)

Business case: client document collection software Prepared by Dana Ruiz, Operations Manager, for Mark Ellison, Managing Partner. Date: November 3.

1. Summary Our accountants spend hours every week of tax season chasing clients for documents by email. That costs us about $32,400 a year in staff time. I recommend DocPortal (a document collection tool) at $9,300 for the first year, including setup and training. If it halves the chasing, it pays back in about 7 months. I need approval by November 15 to be live before January.

2. The problem and what it costs us Clients send documents by email, in pieces, often late. Each of our 9 accountants spends about 5 hours a week during the 16-week tax season chasing and filing them.

9 accountants × 5 hours × 16 weeks × $45 per hour = $32,400 per year.

3. Options we considered

  • Do nothing. Keeps costing $32,400 a year, and the team has said this is the worst part of the season.
  • Hire a part-time admin for the season. About $14,000. Moves the chasing to one person but doesn't reduce it.
  • DocPortal. $6,000 a year. Clients upload to one checklist; the tool sends reminders.

4. Recommended option and why DocPortal. The admin option moves the work; DocPortal removes most of it. It also gives clients one place to upload, which is what they asked for in last year's feedback.

5. Costs

  • Subscription: $6,000 per year, 1-year term
  • Setup and template build: $1,500, one-time
  • Staff time to set up and train: 40 hours × $45 = $1,800

Total first-year cost: $9,300. Ongoing yearly cost: $6,000.

6. Return and payback

  • Expected benefit: half of chasing time removed = $16,200 per year (estimate)
  • Monthly benefit: $16,200 ÷ 12 = $1,350
  • Payback period: $9,300 ÷ $1,350 = 6.9 months
  • First-year ROI: ($16,200 − $9,300) ÷ $9,300 × 100 = 74%

Assumptions: hours from a two-week time log in March; $45 is our blended staff cost; the 50% reduction is our estimate, not a vendor claim.

7. Risks

  • Clients don't use it → we keep email as a backup for one season and send setup instructions with the engagement letter.
  • Security review → the vendor's security documents go to our IT contractor before signing.
  • Savings come in at 25%, not 50% → benefit drops to $8,100 and payback stretches to about 14 months. Still worth doing, but slower.

8. Timeline Decision November 15. Signed November 20. Setup and training December 1-19. Live January 5. Review results April 30.

Decision needed Approve $9,300 from the 2027 operations budget for a one-year DocPortal contract, signed by November 20.

Notice what the example does. It shows the math for every number. It includes doing nothing as an option. It counts staff time as a cost. And it tells the approver what happens if the savings come in low, before they ask.

How to fill it in

  1. Write the problem in the team's own words. Use the phrases people used when they complained about it. An approver trusts "we chase clients for documents for weeks" more than "document workflow inefficiency."
  2. Put a number on the cost of the problem. People × hours × hourly cost × weeks is enough. Show the math so anyone can check it.
  3. List at least three options, including doing nothing. One option looks like a decision already made. Three looks like a decision you thought about.
  4. Add up every cost, not only the price. Setup fees, migration, training hours, overlapping contracts. Use the full number in your payback.
  5. Calculate payback and ROI with conservative numbers. Use the formulas above. Say which numbers are estimates and where each came from.
  6. Name the risks and your answer to each. Include the "what if the savings are half" case. It shows you've done the thinking for the approver.
  7. Ask for one specific decision with a date. Amount, budget line, vendor, term, and the date you need it by.
  8. Write the summary last. Three or four sentences that someone could read in the hallway and say yes to.

If you're the seller

Your champion has a day job. Don't expect them to write this from scratch. After the demo, draft it for them with their words and their numbers, then let them correct it and send it as their own.

You can do that in a doc, or start with the free Business Case Builder, which turns a few numbers into a one-page case your champion can print or forward. In AfterDemo, the buyer can build the same one-page business case straight from your proposal, using the pricing option they picked. If you're writing the proposal too, pair it with the one pager template so the approver gets a short summary of what they're buying.

Free toolBusiness Case Builder

Common mistakes

  • It reads like a sales pitch. If it sounds like the vendor wrote it, the approver discounts every number. Plain words, the team's voice, no adjectives.
  • Only one option. Approvers ask "what else did you look at?" Answer it on the page.
  • Leaving out staff time. Twenty hours of setup at your team's hourly cost is a real cost. Count it.
  • Best-case savings. If your payback only works with perfect adoption, it doesn't work. Show the conservative case.
  • No decision asked. A business case that ends with "let me know your thoughts" gets parked. Ask for a yes, an amount and a date.
  • Too long. Ten pages signal you're not sure. One or two pages, with detail in an appendix if someone wants it.
  • Numbers with no source. Every figure should say where it came from: a time log, an invoice, a quote, or "estimate."

Questions people ask

What should a business case for software include?

The problem and what it costs today, the options you considered (including doing nothing), the option you recommend, the full cost (subscription, setup and staff time), the expected return and payback period, the main risks, a timeline, and the exact decision you need from the approver.

How long should a business case be?

For most software purchases, one or two pages. The approver should be able to read the summary in under a minute and find any number they want to check. Put long supporting detail in an appendix or a link.

How do you calculate the payback period?

Divide the total first-year cost by the monthly benefit. If the software costs $9,300 in year one and saves $1,350 a month, payback is about 6.9 months. Use conservative benefit numbers and say where each one came from.

What is the difference between a business case and a proposal?

The seller writes the proposal to the buyer. The buyer's team writes the business case to their own approver, comparing options and asking for money. A good proposal gives your champion the facts they need to write the business case quickly.

Who should write the business case?

The person inside the buying company who wants the purchase, usually the champion. Sellers can help by drafting it with the buyer's own words and numbers, but the champion should own it, check every figure and send it under their name.

Free toolBusiness Case Builder