Writing the Business Case That Gets Approved
A one-page case that survives a board meeting: four measured numbers, one blank, the full cost including your own hours, and the sentence about what you are not buying. Written for the person who has to ask, not the person who has to sell.
Most internal cases for operations software fail for the same reason: they are a vendor's case with the logo removed. Percentages nobody derived, benefits stated as certainties, cost stated as the subscription, and no acknowledgement of what the thing will not do. Whoever approves spending in your organisation has seen that document before and knows how to discount it.
A case that gets approved and, more importantly, survives being reviewed in a year, has a different shape. One page, five parts.
Part one: the problem, in your own numbers
Not "we lack visibility". Three specific, dated observations that anyone in the room can verify.
Collect these over four weeks before you write anything
- A stockout tally. A sheet at the counter: every time a customer wanted something you did not have. Four weeks. This single number persuades more effectively than any other and almost nobody has it.
- One shelf counted blind. A high-value shelf, counted against whatever record exists. The variance is your evidence that the rest is worth counting.
- Three timed tasks. The daily payment-matching, a typical stock query, the month-end close. Minutes, with dates. Boring and unarguable.
- The value of the slow-moving corner. Every storekeeper can point at it. Price it. It is usually the largest number in the whole case.
- One recent incident, described in two sentences. The order nobody could find, the invoice paid twice, the delivery received and never recorded. Specific and recent beats general and true.
Part two: the cost, all of it
Including the parts that are your own hours. This is counter-intuitive — it makes the number bigger — and it is what makes the case credible, because whoever approves it already suspects the real figure is larger than the quote and will trust a document that says so.
The cost table to put on the page
A case showing only the subscription invites the question "and what else?" — which you then answer live, badly, from memory. A case that pre-empts it moves the conversation to whether the benefit is worth the total, which is the conversation you want.
Part three: the benefit, with one figure left blank
Four quantified, one blank. The blank is not a weakness — it is the most persuasive element on the page, because it signals that the other four were not made up.
| Benefit | Basis | Type |
|---|---|---|
| Cash released from dead stock | The value of the slow-moving corner, from part one | One-off. Say so. |
| Reduced count variance | First count against second count, at 90 days | Recurring, and partly a records correction — say that too. |
| Time recovered | Your three timed tasks | Recurring, small, unarguable. |
| Commitment visibility | From "unknown" to "a number on screen" | Not quantifiable, and worth stating as a control rather than a saving. |
| Stockouts avoided | To be measured. Baseline tally attached; benefit assessed at 90 days. | Deliberately blank. |
Part four: what we are not buying
Two or three sentences naming the limits, in your own words. This is the part nobody includes and the part that protects you personally in twelve months, when somebody asks why the system does not do the thing they assumed it did.
Concretely, for this product: it is not a statutory book of account — there is no manual journal entry, so the accountant still assembles the accounts. It does not reconcile the bank. It carries no bill of materials, no work orders, and no student, patient, tenant or vehicle record. eTIMS files invoices and POS sales for Kenya and does not file credit notes. Say those out loud in the document. A case that names its limits is a case that cannot be undermined by discovering them.
Part five: how you will know, and when
Three numbers with their before-values and a review date. This converts the case from a promise into a commitment, and it is what makes the same document useful a year later rather than embarrassing.
-
Stock count variance, as a percentage of counted value
Before: the shelf you counted. Review at 90 days, on a full second count. This is the number most likely to move visibly and quickly.
-
Committed spend not yet invoiced
Before: unknown, and say "unknown" rather than estimating. Review at 90 days as a figure on screen. Going from unknown to known is the whole benefit and it is legitimate to state it that way.
-
Days to close a month
Before: whatever it is now, honestly. Review at 90 and 180 days. Slower to move than the others because it depends on the upstream records being real first.
-
Set the review date in the document
A named date, ninety days after go-live, in the same paragraph as the numbers. Nobody will schedule it later, and a case with no review date is a case nobody is accountable to.
One sentence to include verbatim
"If the three numbers above have not moved by [date], the correct response is to fix how we are using it rather than to buy something else." That sentence does more for your credibility than any projection on the page, and it is also true — the six ways rollouts fail are all organisational, so a system that has not delivered by day ninety is almost never the wrong system.
What to leave out
- Vendor percentages. Any figure you cannot derive from something you counted yourself weakens everything next to it.
- Feature lists. Nobody approving a budget cares that there are 255 permissions. They care what stops happening.
- Competitor comparisons. Save these for the decision, not the approval. Including them invites a procurement process you did not ask for.
- Five-year projections. A ninety-day review beats a five-year model, because one of them will actually happen.
- The word "transformation". Every time it appears, the credibility of the surrounding sentence drops.
Our take
Spend four weeks measuring before you spend an hour writing. Put the full cost including your own hours on the page, quantify four benefits and leave the fifth explicitly blank, name what the system will not do, and commit to three numbers with a review date. That document gets approved more often than a persuasive one — and it is the version you will still be comfortable with when somebody reads it back to you next year.
We will help you write the honest version
Including the paragraph about what we do not do. A case that names the limits survives the year-one review, and that is worth more to us than a signature this month.
See plans & pricingFrequently asked questions
How do we write a business case for operations software?
One page, five parts: the problem in three measured observations of your own, the full cost including your own hours, four quantified benefits with a fifth left explicitly blank, a paragraph naming what the system will not do, and three numbers with before-values and a review date ninety days after go-live.
Should we include our own internal time as a cost?
Yes, even though it makes the number bigger. Whoever approves the spend already suspects the real figure exceeds the quote, and a document that says so is trusted. A case showing only the subscription invites the question "and what else?", which you then answer live and badly from memory.
Why leave one benefit unquantified?
Because it is the most persuasive element on the page. A blank where a stockout figure would go, with a note saying the baseline tally is attached and the benefit will be assessed at ninety days, signals that the other four numbers were not invented. One made-up percentage discredits everything beside it.
Should the case mention what the software cannot do?
Yes, in two or three sentences, in your own words. It is the part nobody includes and the part that protects you in twelve months when someone asks why the system does not do something they assumed. A case that names its limits cannot be undermined by their discovery.
What should be left out of a business case?
Vendor percentages, feature lists, competitor comparisons, five-year projections and the word "transformation". Any figure you cannot derive from something you counted yourself weakens the numbers next to it, and a ninety-day review beats a five-year model because one of the two will actually happen.
