How to Build a Business Case for AI Automation That Gets Approved

Most automation pitches die not because the project is bad, but because the person making the case buried the answer. They lead with the tool, the vendor, the demo. The decision-maker wants to know what hurts today, what it costs, what the fix is, and when the money comes back. Four questions. Four sections. Two pages.

If you are trying to get a manager, owner, or board to fund an AI automation project, here is the document that works.

Section 1: The Problem (in their language, not yours)

Open with the operational problem, framed in terms the decision-maker already cares about. Not "we lack an AI-powered workflow layer." Try: "Our intake team is spending roughly 14 hours a week manually copying quote requests from email into the CRM, and we are losing about one qualified lead per week because requests sit unanswered overnight."

Two things matter here. First, the problem has to be one they have already heard complaints about. If you are introducing the pain for the first time, you are also selling the existence of the problem, which doubles your work. Pick something already on their radar.

Second, keep this section to a single paragraph. Five or six sentences. If you cannot describe the problem in that space, you do not understand it well enough yet to propose a solution.

What to skip: industry trends, competitor anecdotes, statistics from McKinsey reports. Nobody approves a project because Gartner said so. They approve it because it solves a problem in their own building.

Section 2: The Current Cost (the number that does the heavy lifting)

This is the section that decides whether your case moves forward. You need a defensible dollar figure for what the status quo costs every year. Three components usually matter:

Labor time. Hours per week spent on the task, multiplied by the loaded hourly cost of the person doing it, multiplied by 52. Loaded cost means salary plus benefits and overhead, not the raw wage. For most small businesses, a $55,000 salary represents roughly $72,000 in true cost, or about $35 an hour.

Lost revenue or capacity. If the bottleneck causes missed sales, slow follow-ups, or capped throughput, estimate it conservatively. One missed qualified lead per week at a 25% close rate and a $3,000 average deal is $39,000 a year. Round down. Always round down in this section. A skeptical reader will challenge optimistic math.

Error and rework cost. Bad data, duplicate entries, missed steps. Harder to quantify, so be careful. If you cannot estimate it within a defensible range, leave it out or list it qualitatively as a secondary benefit.

Add these together and you have your annual cost of the current state. For the intake example, that might look like:

• 14 hours/week × $35 loaded cost × 52 weeks = $25,480 in labor
• 1 missed lead/week × 25% close × $3,000 deal × 52 weeks = $39,000 in lost revenue
• Total annual cost of status quo: $64,480

That number is your anchor. Everything else in the document is measured against it.

What to skip: efficiency percentages, productivity multipliers, anything that smells like vendor marketing. "40% productivity gain" means nothing. Dollars per year mean everything.

Section 3: The Proposed Change (specific, bounded, boring)

Describe what you actually want to build or buy. Be specific enough that a reasonable person could repeat it back to you, but resist the urge to explain the technology. The decision-maker does not need to know that you are using a vector database. They need to know what happens differently on Monday morning.

"We connect our shared inbox to an automation that reads incoming quote requests, extracts the relevant fields, creates a CRM record, and sends an acknowledgment email within five minutes. A human reviews anything the system flags as ambiguous. Expected implementation: six weeks. Expected ongoing cost: $400 per month in software plus roughly two hours per week of oversight."

That is the entire section. Three or four sentences. Include:

• What the change does in plain operational terms
• Implementation timeline (be honest, padded if needed)
• Ongoing cost (software, maintenance, the human hours that do not go away)
• One sentence on what stays human, because this preempts the "what about edge cases" objection

What to skip: tool comparisons, architecture diagrams, the word "AI" used more than twice. The case is about the outcome, not the mechanism.

Section 4: The Payback (when the money comes back, and what could go wrong)

Close with the math that turns the case into a decision. Three numbers:

Year one net. Annual benefit minus annual cost minus one-time implementation cost. For our example: $64,480 benefit − $4,800 software − $3,640 oversight labor − $12,000 implementation = $44,040 net in year one.

Payback period. How many months until the project pays for itself. Implementation cost divided by monthly net benefit. Twelve thousand divided by roughly $4,700 per month is about 2.6 months.

Sensitivity. What happens if your assumptions are half as good as you think? Cut the benefit by 50% and recompute. If the project still pays back inside a year at half the expected impact, you have a defensible case. If it only works at full assumptions, you have a fragile one and the decision-maker will sense that.

End with one short paragraph on risk. Not a risk matrix. One paragraph. What is the worst realistic outcome and what would it cost to walk away? For most automation projects, the answer is: software contracts can be cancelled, implementation cost is sunk, and the team returns to the old workflow. State that plainly. Decision-makers approve reversible bets faster than irreversible ones.

What the whole document should look like

Two pages. Maximum. If it runs longer, you are explaining instead of proposing. Plain formatting. Numbers in the body, not in an appendix. No screenshots of vendor dashboards. No links to whitepapers.

The test: a busy reader should be able to skim the four section headers and the dollar figures in under ninety seconds and have a clear yes-or-no instinct. The full read is for confirming that instinct, not forming it.

If you want a second set of eyes on the numbers before you send it up the chain, walk us through your scenario and we will help you pressure-test the math.