A request for a new reporting tool raises practical questions: what would improve, what would it cost and is there a simpler solution? A business case answers those questions by comparing the benefits, costs and risks of realistic options. Unlike a business plan, it focuses on a particular proposal rather than the organisation as a whole. For a modest internal improvement, keep it proportionate and use any required approval template.
Establish the problem and the decision required
Start by identifying who will make the decision, what they can authorise and what evidence they expect.
Describe the current problem using a dated workload sample, an error log or service data. Establish the starting position, or baseline, before proposing a solution. Then specify how much reporting time you aim to release or which service measure should change. “Improve efficiency” leaves too much open to interpretation.
Explain unfamiliar terms so that operational and financial reviewers can follow the same argument. Contributors drafting in English as an additional language can use Business English vocabulary resources to check how they describe costs and assumptions.
Compare realistic options
Consider continuing with current arrangements, making a smaller improvement and adopting the proposed solution. Keeping things as they are avoids the proposed purchase but leaves the existing workload or service problem unresolved.
Compare feasible options against the same criteria: expected results, total cost, implementation effort, timing and risk. A simple table can make the trade-offs easier to see.
Explain why the preferred option offers the best balance. Extra features carry little weight unless they address an identified need; a simpler alternative deserves serious consideration.
Show the costs, benefits and delivery risks
Separate one-off costs from recurring charges. Include migration, training and temporary disruption alongside purchase or subscription fees. Record internal staff effort even where it requires no additional cash payment.
Use a consistent period for financial comparisons and state when benefits should begin. Supplier quotations support cost estimates; projected benefits need their own evidence, such as a timed task sample or a small trial. Distinguish what you have observed from what you expect to happen.
Time released creates capacity for other work. It becomes a cash saving only when expenditure actually falls, so explain how the organisation would use those hours.
Concentrate on uncertainties that could change the recommendation, pairing each significant risk with an owner and a practical response. An automated report depends on reliable source data, for example. Assigning someone to check its quality before rollout is more useful than a vague promise to “manage data risks”.
Set out who will deliver the change, essential dependencies and realistic milestones. These details let reviewers assess the work involved as well as the promised result.
A short business case example
Consider this hypothetical proposal to reduce duplicate monthly reporting. A workload log shows ten hours spent copying and checking figures each month. The options are to leave the process unchanged, simplify the existing spreadsheet or introduce an automated reporting tool.
The tool costs £600 to configure plus £75 monthly. Its first 12 months require £600 + (£75 × 12) = £1,500 in cash expenditure, alongside eight hours of internal setup effort. The forecast is four hours released each month once fully operational, to help clear an existing analysis backlog.
Test the spreadsheet option before seeking purchase approval. Achieving the same result at lower overall cost would weaken the case for buying the tool.
Also show a downside forecast of two hours released monthly. Would that smaller contribution to clearing the backlog still warrant the commitment? Use that downside to judge whether to proceed, choose the simpler option or test the forecast further.
If the comparison supports buying the tool, request £1,500 and eight setup hours, with the operations manager checking reporting time against the baseline after three months.
Write the summary and approval request last
Complete the analysis before drafting the executive summary, then place the summary first in the finished document. Cover the problem, preferred option, expected benefit, main uncertainty and decision requested.
Make the request specific about scope, spending, staff time and responsibility. Ask someone unfamiliar with the proposal to review it: can they identify the alternatives, follow the figures and challenge the assumptions?
Include a named person and an agreed date for reviewing actual results. Approval authorises the work; that later comparison establishes whether the expected benefit was delivered.












Comments