Business Case Template: Prove the Investment Before You Approve It

Business Case Template: Prove the Investment Before You Approve It

A business case should let a decision-maker compare the current situation, realistic options, total cost, measurable benefits, risks, and delivery ownership on one page. Use this template before approving software, automation, hiring, or process changes. If the evidence is weak, revise or reject the proposal before money and time are committed.

Updated August 29, 2026

Most business cases are written to defend an idea someone already likes. That is backwards.

A useful business case is a decision tool. It should make a weak proposal easier to reject, a promising proposal easier to improve, and a strong proposal easier to approve. It should also give the person funding the work a clear way to check whether the promised result actually happened.

The need is not theoretical. Microsoft's 2025 Work Trend Index, reviewed August 29, 2026, analyzed a survey of 31,000 workers across 31 countries plus Microsoft 365 and LinkedIn signals. It found that 82% of leaders viewed 2025 as a pivotal year to rethink strategy and operations. It also found that 53% of leaders said productivity needed to increase while 80% of the global workforce reported lacking enough time or energy to do their work.

That pressure creates a dangerous pattern: approve a new tool or project quickly, then search for the business logic afterward.

The same tension appears in AI adoption. OECD data on artificial intelligence, reviewed August 29, 2026, shows that 20.2% of firms reported using AI in 2025, up from 14.2% in 2024 and 8.7% in 2023. Adoption is moving fast, but fast adoption is not the same as a sound investment.

There is also a capability gap. PMI's 2025 Pulse of the Profession report, reviewed August 29, 2026, reports that only 18% of project professionals have high business-acumen proficiency; 66% are moderate and 16% are low. A good template helps teams connect delivery activity to business value even when that skill is still developing.

This guide gives you the template, a worked example, the financial formulas, and the approval rules. Use it for software, automation, AI, hiring, outsourcing, operational change, or any proposal that consumes meaningful money or management attention.

What should a business case template contain?

The shortest useful business case contains nine parts:

1. Decision requested: the exact choice the approver must make.
2. Problem and baseline: what happens today, expressed with evidence.
3. Desired outcome: what must improve, by how much, and by when.
4. Options: continue as usual, improve the current approach, buy, build, partner, hire, or stop the work.
5. Recommended option: the chosen route and why it beats the alternatives.
6. Total cost: cash, internal time, transition effort, ongoing operation, and contingency.
7. Benefits: revenue, cash savings, risk reduction, capacity, speed, or customer impact.
8. Risks and assumptions: what could make the case wrong and how you will test it.
9. Delivery and measurement: owner, milestones, success metric, review date, and stop conditions.

The order matters. Starting with the problem prevents the proposed tool from defining the problem. Comparing options prevents a preferred vendor from becoming the only imaginable answer. Naming an owner and review date prevents the document from dying after approval.

HM Treasury's 2026 Green Book, reviewed August 29, 2026, offers a rigorous five-part lens: strategic, economic, commercial, financial, and management cases. It also says the work should be proportionate to the proposal's cost, complexity, and risk. A small business does not need a 98-page government document, but it can borrow the discipline:

• Strategic: Is this a real priority?
• Economic: Is this the best option?
• Commercial: Can we obtain it on workable terms?
• Financial: Can we afford the cash commitment?
• Management: Can we implement and operate it?

If one of those answers is missing, the proposal is not ready for unconditional approval.

How do you use this one-page business case template?

Copy the table into a document or spreadsheet. Keep each answer short enough that an approver can challenge it in one meeting. Attach detailed calculations only when the decision requires them.

Write the executive summary last. If you cannot summarize the decision, baseline, recommendation, total cost, expected result, largest risk, and owner in six sentences, the analysis is probably not finished.

Do not hide disagreement. If sales expects a 20% conversion gain and operations expects 5%, show both. A business case is useful precisely because it turns optimism into assumptions that can be tested.

How do you define the problem without starting from a solution?

Begin with the current workflow, not the proposed purchase.

Weak problem statement:

“We need an AI assistant because competitors are adopting AI.”

Decision-ready problem statement:

“Account managers manually prepare 180 renewal summaries each month. The work consumes 135 hours, 22% are completed after the review meeting, and late preparation contributed to 14 renewals entering negotiation without an agreed retention plan last quarter.”

The second statement gives you a volume, a labor baseline, a delay rate, and a business consequence. It also leaves room for several solutions. The right answer might be automation, a simpler renewal process, clearer account ownership, better data, temporary support, or fewer low-value reviews.

Use this baseline formula:

Current annual cost = volume per period × time per item × loaded hourly cost × periods per year

Then add consequences that are not already included:

• Lost or delayed revenue.
• Refunds, rework, credits, or penalties.
• Customer churn or missed follow-up.
• Management review time.
• Compliance or operational exposure.
• Opportunity cost from work the team cannot do.

Do not convert every inconvenience into money. Some numbers will be defensible; others will be theatre. Keep hard cash, recoverable capacity, and risk exposure separate so the approver can see what genuinely changes the budget.

End the problem section with a counterfactual: what happens over the next 12 months if nothing changes? “The team stays frustrated” is weak. “At current volume, renewal preparation consumes about 1,620 hours per year and the backlog grows as accounts increase” is useful.

Which options should the business case compare?

Every proposal needs a do-nothing baseline. Without it, the case cannot show incremental value.

Then compare at least two credible alternatives. For a recurring manual workflow, the options might be:

• Continue as usual.
• Remove unnecessary steps and standardize the rest.
• Improve the existing system with configuration and training.
• Buy a specialist tool.
• Connect and automate the tools already in use.
• Build custom software.
• Outsource the work.
• Hire additional staff.
• Run a limited pilot before choosing a full route.

Compare options against the same criteria. Useful criteria include time to value, three-year cost, expected benefit, reversibility, adoption effort, data readiness, vendor dependence, security, operational ownership, and downside if the assumption is wrong.

The do-nothing option is not automatically bad. If the problem costs $12,000 a year and the proposed fix costs $80,000, continuing as usual may be rational. If volume is likely to triple, the same decision may reverse. State the volume assumption instead of pretending the answer is permanent.

Avoid fake options. “Buy our preferred platform,” “build an inferior version,” and “do nothing and fail” is not analysis. Give each route its strongest credible form. The recommended option should survive a fair comparison.

For AI or automation, include process simplification as a real option. Automating a duplicate approval or an unnecessary report makes the waste faster. First remove work that should not exist. Then decide what deserves automation.

How should you calculate cost, benefit, ROI, and payback?

Start with total cost, not vendor price.

Total first-year cost can include:

• Software or platform charges.
• Discovery, design, configuration, and implementation.
• Internal staff time.
• Data cleanup and migration.
• Training and adoption support.
• Parallel running during transition.
• Security, legal, or procurement review.
• Ongoing monitoring, maintenance, and support.
• Contingency for known uncertainty.

Calculate benefits in separate buckets.

Cash revenue is money expected to enter the business because the change improves conversion, capacity, retention, or pricing. Use contribution margin, not headline revenue, when the additional sale carries variable cost.

Cash savings are costs that leave the budget, such as avoided contractor spend, reduced refunds, or a license that will be cancelled.

Capacity value is time returned to the team. It is valuable only if the company can redeploy it to work that matters. Twenty saved hours are not automatically twenty hours of cash savings.

Risk reduction is the expected cost of an event before and after the change:

Expected risk cost = probability of event × financial impact

Use three simple calculations:

Net annual benefit = annual cash benefit + defensible capacity value + risk reduction − annual operating cost

ROI = (total benefit − total cost) ÷ total cost × 100

Payback period in months = upfront investment ÷ monthly net benefit

Show conservative, expected, and upside cases. Change the assumptions that matter most: adoption, volume, benefit per transaction, implementation delay, and operating cost. If a 10% reduction in adoption destroys the case, the proposal is fragile and should probably begin as a pilot.

Never count the same benefit twice. If faster processing enables more revenue, do not also count every saved hour at full cost unless those hours produce a separate measurable outcome.

What does a completed business case look like in practice?

Imagine a 35-person business-to-business services company considering an automated lead-follow-up workflow.

Decision requested

Approve a six-week pilot for one inbound lead source, with a fixed budget cap and a go-or-stop review at the end.

Problem and baseline

The company receives 420 inbound leads per month. Sales responds manually. Median first response is 11 hours, 19% of leads receive no second follow-up, and managers spend 24 hours per month assembling pipeline reports. The company does not yet know how many lost deals are caused by delay, so that claim is treated as an assumption rather than revenue.

Target outcome

Within six weeks of launch, reduce median first response below 30 minutes during working hours, reduce leads without a second follow-up below 3%, and remove at least 15 monthly hours of manual reporting without lowering qualified-meeting quality.

Options

1. Keep the current process and coach representatives.
2. Reconfigure existing CRM rules and standardize templates.
3. Add a specialist follow-up tool.
4. Build a connected workflow using the existing forms, CRM, email, calendar, and reporting tools.

Recommendation

Pilot option four for one lead source because it tests the whole handoff without replacing the CRM or committing the entire sales team. The pilot is reversible and produces evidence on response time, follow-up completion, meeting quality, and operating effort.

Costs

The case lists implementation, internal review time, data cleanup, training, and monthly monitoring. It does not quote a three-year saving from one month of data.

Benefits

The approved benefits are reduced reporting labor and recovered representative capacity. Additional qualified meetings are tracked during the pilot but are not counted as committed revenue until the company has enough evidence.

Risks

Poor routing data could send the wrong message. Representatives could ignore the workflow. Faster follow-up could increase low-quality meetings. Controls include data validation, approval of message rules, an easy human override, weekly sample review, and a meeting-quality threshold.

Decision rule

Proceed only if all three operating targets are met, qualified-meeting quality does not decline, and monthly ownership after launch is accepted by the sales operations lead. Otherwise revise once or stop.

Notice what the case does not say. It does not claim that AI will transform sales. It asks for a bounded decision, measures the current state, protects quality, and defines what evidence earns the next investment.

How do you expose assumptions and risks before approval?

List the five assumptions most likely to reverse the decision. Do not bury them in an appendix.

Common assumptions include:

• Demand or transaction volume will remain within a stated range.
• Staff will use the new workflow often enough to produce the benefit.
• Source data is accurate and available.
• The proposed system can work with existing tools.
• A named owner has enough time and authority to operate it.
• Customers will accept the new experience.
• Legal, security, or procurement review will not materially change scope.

For each assumption, record evidence, confidence, test, owner, and decision date. “Users will adopt it” is hope. “Ten representatives will complete three supervised cycles during the pilot; at least eight must use the workflow without assistance by week four” is testable.

Separate risks from issues. A risk might happen. An issue already exists. If customer records are incomplete today, data quality is an issue and its cleanup belongs in cost and scope. Calling it a risk hides work.

Set stop conditions before enthusiasm and sunk cost take over. Examples:

• Pilot adoption remains below 60% after training and one redesign.
• Error rate exceeds the current baseline for two consecutive weeks.
• Required data cannot be obtained lawfully or reliably.
• Total cost rises more than 20% without an equivalent increase in benefit.
• The operating owner refuses responsibility after seeing the real workload.

A stop condition does not make the proposal pessimistic. It makes approval safer.

Who should own approval, delivery, and benefit measurement?

One person should own the investment decision. One person should own delivery. One person should own the business result. They may be the same person in a small company, but the responsibilities should still be explicit.

The decision owner approves, rejects, or requests revision. This person controls the relevant budget or has delegated authority.

The delivery owner coordinates implementation, dependencies, testing, and launch. This person should not be judged only on shipping the tool.

The benefit owner owns the operating metric after launch. If the project promises faster follow-up, the sales leader may own the response-time and conversion measures. If nobody accepts this role, the proposed benefit is not credible.

Finance or an independent reviewer should challenge the model when the commitment is material. The proposal author should not be the only person validating assumptions.

Set review dates at approval:

• An early review checks delivery and leading indicators.
• A post-launch review checks adoption and operating stability.
• A benefit review checks the business result after enough time has passed.

Do not wait until the annual budget cycle to discover that the system shipped but the result never arrived.

How should the approver choose approve, pilot, revise, or reject?

Approve when the problem is material, the baseline is credible, alternatives were fairly compared, the expected case creates enough value, risks are controlled, and operating ownership is accepted.

Pilot when the potential value is meaningful but one or two important assumptions need evidence. A pilot should be small enough to limit downside and representative enough to answer the decision.

Revise when the problem is real but the proposal is incomplete. Common reasons include missing baseline data, hidden internal effort, weak option comparison, unclear ownership, or benefits that cannot be measured.

Reject when the problem is minor, the preferred option does not beat the baseline, the economics depend on implausible assumptions, material risks cannot be controlled, or no one will own the result.

Deferring is also a decision. Record why, what must change, and the next review date. Otherwise the proposal will return every quarter with the same gaps.

Use a short decision note:

“Approved for a limited pilot up to the stated cost cap. The pilot must meet the response-time, follow-up-completion, and meeting-quality thresholds by the review date. The sales operations lead owns measurement. Expansion requires a new decision based on pilot evidence.”

That note protects the business better than a vague “looks good, proceed.”

How can Wavicle help turn the case into a working result?

A template can expose the right questions. It cannot inspect your actual workflow, validate the data, compare practical implementation routes, or make the change stick.

Wavicle helps non-technical founders, sales leaders, operations teams, and managers build the case and the result together. We map the current workflow, establish the baseline, separate process problems from tool problems, compare improve, buy, automate, and build options, and define the smallest test that can answer the investment decision.

If the case supports implementation, we can design and build the automation or software, connect it to the tools your team already uses, and put measurement and human controls into the workflow. If the evidence says the project should not proceed, that is a useful outcome too. Avoiding a bad build is cheaper than rescuing one.

Book a free growth consultation at wavicle.tech/contact to review one proposed investment. Bring the current process, rough volume, known costs, and the decision you need to make. We will help you turn them into a case that can survive scrutiny.

What are the most frequently asked questions?

What is a business case?

A business case is a structured argument for a decision. It defines the current problem, target outcome, realistic options, total cost, expected benefits, risks, ownership, and measurement plan so an approver can choose to approve, pilot, revise, defer, or reject the proposal.

How long should a business case be?

Use the shortest format that supports the risk and cost of the decision. A one-page case is often enough for a small, reversible pilot. A large, expensive, regulated, or difficult-to-reverse investment needs deeper financial, commercial, security, legal, and delivery analysis.

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

A business case justifies one proposed investment or change. A business plan describes how an entire business will operate, compete, earn revenue, and grow. A company may have one business plan and dozens of business cases for projects, hires, tools, and process changes.

What is the difference between a business case and a project charter?

The business case decides whether an investment deserves approval and which option should be chosen. The project charter authorizes delivery after that decision by defining the objective, scope, ownership, constraints, and governance. Approve the case first; charter the selected project second.

Should a business case always include ROI?

No. Include ROI when benefits and costs can be estimated responsibly. Some safety, compliance, customer, or strategic decisions rely partly on risk reduction and non-financial outcomes. Show those effects clearly and avoid inventing false precision simply to produce a percentage.

What options should every business case include?

Include the current-state or do-nothing baseline plus at least two credible alternatives. Depending on the problem, those could include simplifying the process, improving an existing tool, buying software, building a custom solution, using a partner, outsourcing work, hiring, or running a limited pilot.

Who should write the business case?

The person closest to the business problem can lead the draft, but operations, finance, delivery, and affected users should challenge relevant assumptions. The final decision should belong to a named budget owner, and the promised business result should belong to a named benefit owner.

When should a proposal be piloted instead of fully approved?

Choose a pilot when the potential value is material but adoption, data quality, customer response, technical fit, or benefit size remains uncertain. Define the pilot population, cost cap, success measures, review date, owner, and stop conditions before work begins.

How often should a business case be reviewed after approval?

Review it at major delivery decisions, shortly after launch, and when the expected benefit should be visible. Also reopen it when cost, scope, timing, risk, or demand changes materially. Approval is not permission to ignore the assumptions that justified the investment.

The best business case is not the one with the most confident forecast. It is the one that makes the next decision obvious, makes uncertainty visible, and keeps the promised result owned after approval.

Book a free growth consultation at wavicle.tech/contact if you want a practical review of your automation, AI, or software investment before you commit the budget.