Software purchases rarely close on enthusiasm alone. Before anyone signs, the people who own the budget need a structured argument that connects the new tool to measurable business outcomes. A business case does that job: it turns features into the language finance, executives and procurement use, which is cost, return, risk and timing.
Two people usually write it. You, the seller, draft most of it because you have the numbers, the implementation plan and the security answers. Your champion owns it, edits it into their company's voice and takes it into the room you are not in (see champion enablement). The readers are the economic buyer who signs and the finance team who checks the math.
This template is built for that situation: a new software purchase, with one worked example filled in so you can see what good looks like.
When you need a business case for new software
Not every deal needs one. A small team buying a tool on a credit card can skip it. Write one when any of these show up:
- Someone outside your champion's team approves the spend. The moment budget sign-off moves up a level or into finance, your champion needs a document that stands on its own.
- A buying committee is involved. IT, security, legal and the line of business each read the case for a different reason.
- The purchase was not in this year's budget. Unplanned spend has to win against everything else finance could fund.
- The buyer is replacing a tool they already pay for. Switching costs, overlap months and migration effort all need to be on paper.
- The buyer is comparing vendors or considering doing nothing. A written case gives them a frame to evaluate against.
- Your champion asks for "something I can send up." That request is the trigger. Do not wait for it to come twice.
What a business case for new software includes
Every strong software business case answers six questions:
- What problem are we solving? The current state, the tools in use today and what both cost.
- What are we buying? The product, the number of seats and who will use it.
- What does it take to roll out? Implementation effort, change for the team and the security and procurement steps.
- What does it cost over three years? Total cost of ownership, not just the license line.
- What do we get back? Savings and gains in numbers finance can check.
- What else did we consider? Other vendors, building it in house and doing nothing.
Business case template for a software purchase
Copy the sections below into a doc. Every section has a blank to fill in and one example row from a fictional company, Fernwood Logistics, a regional delivery business buying a field service scheduling platform to replace a legacy scheduler and a set of spreadsheets. The example numbers are made up for illustration.
1. Executive summary
Write this section last and keep it to one page. Many approvers read only this.
- Current situation: [The business problem in 2-3 sentences]
- Proposed solution: [One sentence: what you are buying, for whom]
- Expected impact: [The two or three numbers that matter: hours saved, cost removed, revenue protected]
- Three-year cost: [Total cost of ownership]
- Recommendation: [The decision you are asking for, and by when]
Example: Fernwood's eight dispatchers spend about five hours a week each rescheduling jobs by hand across a legacy scheduler and two spreadsheets. We recommend replacing both with a field service scheduling platform for 60 users. Expected impact: about 1,900 dispatcher hours a year returned and the legacy license retired from year two. Three-year cost: $255,400. We ask for approval by November 14 to go live before the spring peak.
2. Problem statement: current tools and their cost
List what the team uses today and what it costs, in money and in time. Finance trusts this section most when the numbers come from the buyer's own systems (invoices, time tracking, ticket counts).
Current tool or process | Annual cost | Hours per month | Problem it causes |
|---|---|---|---|
[Tool name] | $[amount] | [hours] | [What breaks or slows down] |
Fernwood example: legacy scheduler | $38,000 | 160 (manual rescheduling across 8 dispatchers) | No live technician location, so every change is a phone call |
Then add the knock-on cost:
- Revenue or service impact: $[amount] per year (Fernwood example: about 30 jobs a month re-dispatched at roughly $150 each)
- Time lost: [hours] per month across [number] people
- Risk carried today: [Missed SLAs, compliance gaps, a tool going out of support]
3. Proposed solution: seats and adoption
Describe what is being bought at the level a business reader needs, then show who uses it. Seats are where finance looks first for waste, so tie every seat to a person and a use.
User group | Seats | What they use it for | Adoption target |
|---|---|---|---|
[Team] | [number] | [Main job they do in the tool] | [Weekly active users by day 90] |
Fernwood example: dispatchers | 8 | Build and change daily routes | All 8 active weekly by day 30 |
Fernwood's full count is 60 seats: 8 dispatchers, 40 technicians on mobile, 6 customer service agents and 6 managers. If the adoption target is not met, say what happens: fewer seats at renewal, more training or a check-in with the vendor.
4. Implementation and change effort
Finance and IT both want to know how much of the buyer's own time this costs. Name the phases, the people involved on the buyer's side and the hours.
Phase | Weeks | Buyer-side owner | Internal hours |
|---|---|---|---|
[Phase name] | [Weeks] | [Name or role] | [hours] |
Fernwood example: data migration and route setup | 3 to 5 | Operations manager | 120 |
Fernwood's plan has four phases (setup, migration, pilot with one depot, full rollout) over ten weeks and about 300 internal hours in total. Add the change you are asking people to make: new habits, retired spreadsheets, who trains whom.
5. Security and procurement steps
Most software purchases pass through security review, legal and vendor onboarding before anyone can sign. Listing the steps in the business case shows the approver the deal is real and stops the timeline from slipping late. For the security part, see how to answer a security questionnaire.
Step | Owner (buyer side) | Owner (vendor side) | Target date |
|---|---|---|---|
[Step] | [Name or role] | [Name or role] | [Date] |
Fernwood example: security questionnaire and SOC 2 report review | IT security lead | Vendor sales engineer | October 24 |
Other common steps: data processing agreement, legal review of the order form, vendor setup in the procurement system, budget approval and signature.
6. Total cost of ownership over three years
Show every cost, not just the license. A case that hides implementation or internal time gets sent back.
Cost | Year 1 | Year 2 | Year 3 |
|---|---|---|---|
Software licenses | $ | $ | $ |
Implementation services | $ | $ | $ |
Internal time | $ | $ | $ |
Training | $ | $ | $ |
Total | $ | $ | $ |
Fernwood example: licenses $64,800 a year (60 seats at $90 per seat per month, price held for three years); implementation $25,000 in year 1; internal time $18,000 in year 1 and $4,000 in each later year; training $6,000 in year 1 and $2,000 in each later year. Totals: $113,800, $70,800 and $70,800, or $255,400 over three years.
Then the returns:
Benefit | Year 1 | Year 2 | Year 3 |
|---|---|---|---|
Legacy tools retired | $ | $ | $ |
Time saved | $ | $ | $ |
Revenue protected or gained | $ | $ | $ |
Total | $ | $ | $ |
Fernwood example: legacy scheduler retired when its contract ends, so $0 in year 1 and $38,000 in each later year; dispatcher time saved at 1,920 hours a year valued at $45 an hour ($86,400), counted at half in year 1 for ramp-up; re-dispatches cut by a third ($18,000 a year, half in year 1). Totals: $52,200, $142,400 and $142,400, or $337,000 over three years.
Summary:
- Three-year net benefit: $[amount] (Fernwood: $81,600)
- Three-year ROI, net benefit divided by total cost: [percent] (Fernwood: about 32%)
- Payback period: [months] (Fernwood: month 23)
For the detailed return math, use the ROI calculator template.
7. Alternatives considered, including doing nothing
Approvers will ask what else was on the table. Answer before they do, and always include doing nothing.
Option | Three-year cost | Main upside | Why not chosen |
|---|---|---|---|
[Option] | $[amount] | [Upside] | [Reason] |
Fernwood example: keep the legacy scheduler and add its mobile module | $171,000 | Lowest change for dispatchers | Still no live location; the vendor is ending support for the on-premise version |
Other rows to fill: a second vendor, building it in house and doing nothing.
8. Risk assessment
Name the risks before finance does, with a plan for each.
Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
Implementation runs late | Medium | Medium | Phased rollout, pilot at one depot first |
Low adoption | Medium | High | Named owner per team, adoption review at day 30 and day 90 |
Security review stalls signature | Medium | Medium | Start the questionnaire in week one, share the SOC 2 report early |
Integration with existing systems | Low | Medium | Vendor-supported integration, tested during the pilot |
9. Cost of inaction
This is often the most persuasive section, because doing nothing is the option finance defaults to. Show what it costs to wait:
- Ongoing cost: $[amount] over the next 12 months (Fernwood: $38,000 for the legacy license, about $86,400 in dispatcher time and about $54,000 in re-dispatches)
- What gets worse: [How the problem grows: more volume, more headcount, a contract or tool that expires]
- Deadline it misses: [The business date this protects: a peak season, an audit, a launch]
- Team impact: [Overtime, turnover, morale]
10. Recommendation and next steps
End with a clear ask:
- Recommendation: [The decision in one sentence]
- Decision needed by: [Date, and why that date]
- Next steps if approved:
- [First action, owner, date]
- [Second action, owner, date]
- [Third action, owner, date]
A mutual action plan is the natural home for these steps once the case is approved.
How to present the business case to finance
Finance reads a business case differently from your champion. Your champion wants the problem solved. The CFO or finance partner wants to know whether the money is better spent here than anywhere else.
What the CFO checks first
- The total, over three years. Not the year 1 license, the full cost of ownership.
- Where the savings come from. Hard savings (a retired tool, a contract not renewed) count for more than soft ones (time saved). Label which is which.
- The assumptions. Every number should trace back to a source the buyer recognises: their invoices, their headcount, their ticket volume.
- What happens if it goes wrong. Exit terms, seat flexibility and the downside if adoption is slow.
Use conservative numbers
Take the low end of every estimate and say so. Count time savings at half in the first year. A case that still works with cautious numbers survives questioning; an optimistic one falls apart at the first challenge and takes your champion's credibility with it.
Put one page up front
Lead with the executive summary on a single page, then attach the detail. Most approvers decide from the first page and only open the tables to check a number. If you need help with that page, use the executive summary template.
Tips for writing a business case that gets approved
Lead with outcomes, not features. Approvers care about what changes for the business, not how the product works.
Use the buyer's words. Mirror the metrics and terms from their own plans, board decks or earnings calls.
Show your assumptions. Put the inputs next to each number so finance can change one and see the effect.
Keep it scannable. Headers, tables and bold labels. Most readers skim before they read.
Give a date and a reason. "Decision by November 14 so we go live before peak season" moves a deal. "Soon" does not.
Draft it for your champion, not at them. Hand over an editable document, not a PDF, so they can make it theirs.
FAQ
What should a business case for new software include?
An executive summary, the problem and what current tools cost, the proposed solution with seats and adoption targets, implementation effort, security and procurement steps, three-year total cost of ownership and returns, alternatives including doing nothing, risks and a clear recommendation. The template above covers each one with an example row.
Who writes the business case, the vendor or the buyer?
Usually both. The seller drafts most of it because they have the pricing, the implementation plan and the benchmarks, and the champion on the buying side edits it, checks the numbers against internal data and presents it. The buyer should own the final version, because approvers trust a case that comes from their own team.
How long should a business case be?
Short enough to read in one sitting. Keep the executive summary to one page and put the tables and assumptions behind it. For most software purchases that means a one-page summary plus a few pages of detail.
Business case vs ROI analysis: what's the difference?
An ROI analysis is one part of a business case: the financial calculation of what the purchase returns against what it costs. The business case adds the problem, the alternatives, the risks, the rollout plan and the recommendation. Use the ROI calculator template for the numbers, and read about business case selling for how sellers build the case with the buyer.
When should you start the business case in a sales cycle?
As soon as you know who signs and that the spend needs approval, usually right after discovery. Starting early surfaces the security and procurement steps while there is still time to run them, rather than at the end of the quarter.
How demoshake helps
A business case sent as a PDF goes stale the day pricing or scope changes, and you never know who read it.
In demoshake, the business case lives in the Deal Room for that deal, as the sections written for the Economic Buyer's Stakeholder Role. The economic buyer and finance open their own share link and see the case written for them, while your champion and the technical team see the sections written for theirs. When the numbers change, you update the sections and everyone reads the current version.
Engagement analytics show you when finance opened the business case, so you know whether it has been read before the approval meeting. The next steps go into the room's Action Plan as Milestones and Action Items assigned to people on both sides, from the security review to signature.