Part 4 — Get It Approved
The One-Page Business Case
Four hundred to five hundred words. Two minutes to read. If a sentence doesn’t help someone decide, cut it — model architecture, vendor names, API detail, and the project plan all live in an appendix most executives will never open.
The five blocks
| Block | What goes in it |
|---|---|
| 1. The problem | Specific and measurable — volume, time, cost, or a KPI that has moved the wrong way. “We want to be more innovative” is an aspiration, not a problem. |
| 2. The proposed solution | What it does, in business language. Not the architecture, not the vendor, not the model. What changes in the process, and for whom. |
| 3. Expected impact, with numbers | Lead with the headline figure, then the supporting detail. Use the conservative scenario from Part 3, never the optimistic one. Connect it to a priority the company already has. |
| 4. Risks and mitigation | Name them, from the Canvas in Part 1. Ignoring a risk doesn’t remove it — it tells the reader you haven’t thought about it. One line of mitigation each. |
| 5. Implementation plan | High level, with a decision point. Management needs to know what they’re approving, and when they’ll find out whether it worked. |
The same project, written two ways
Nothing below is technically wrong. That’s exactly the problem with the second version.
The version that gets approved
The problem. Our customer support team is handling 5,000 tickets per month with an average response time of 24 hours. Satisfaction has dropped 15 points over the past year because of long wait times. The team is at capacity and cannot absorb projected growth of 40% over the next 12 months without significant hiring.
The impact, with numbers. $300,000 net annual benefit, 214% ROI, payback in 5.6 months. Handle 7,000 tickets a month with the existing team, up from 5,000. Reduce error and rework from 8% to 3%. Avoid hiring four additional agents.
Decision point. Proceed to full rollout only if the pilot reaches a 50% automation rate and holds quality scores above 4.0 out of 5.0.
A CFO who reads only the first line of the impact block already knows the answer. The figures come straight from the four-step calculation in Part 3, which is what makes them defensible under questioning.
The version that gets shelved
“We propose to implement a state-of-the-art transformer-based large language model fine-tuned on our customer support data using a retrieval-augmented generation architecture, integrated with our existing CRM via REST APIs and deployed on auto-scaling clusters to ensure high availability and low latency.”
Two hundred words about architecture before the reader learns why they should care. What follows is no better: technical metrics with nothing about cost or capacity, a cost figure with no return beside it, and a close that asks for urgency instead of offering a plan. Nothing here is factually wrong. It was simply written for a technical reader, and the person signing the budget isn’t one.
The five things missing from the version that fails
- No clear business problem — is the team overwhelmed, are customers waiting, are costs too high? The reader never finds out.
- No business-level KPIs — accuracy and F1-score are the data team’s language. Satisfaction, cost, and capacity are the decision-maker’s.
- No ROI calculation — a cost figure with no return attached is just a number being asked for.
- No risk analysis — low adoption, poor data quality, integration overrun. All real, none acknowledged, so the reader assumes they weren’t considered.
- No plan or success criteria — when will Phase 1 be judged to have worked, and what happens if it doesn’t?
Use this list as a checklist before you send anything, not as a warning after the fact.
Three checks before you send it
- Could someone who has never heard of this project explain the problem after reading block one alone?
- Is the number in block three the conservative scenario from Part 3, and not the optimistic one?
- Is there a date in block five on which somebody finds out whether it worked?
If any of those three fail, the document isn’t ready yet — however good the underlying project is.