In 30 seconds
A business case for an AI pilot does not need forecasts to two decimal places. It needs one clear problem, a believable saving, an honest cost, and a way to tell afterwards whether it worked. Kept to one page, it also protects you: if you cannot fill it in, the pilot is not ready.
The one-page shape
1. The problem, in the team's words
Name the specific, repeated pain: "Finance re-checks every expense line by hand, four hours a week." Avoid "we should use AI." The problem comes first; the tool is a maybe.
2. The expected saving
Estimate the time or error reduction, using a real number from today's work. Be conservative. A saving that only works if everything goes perfectly is not a saving you can defend.
3. The honest cost
Setup, running cost, and review time, using how to estimate the cost of an AI workflow. Include the cost of the mistakes it will make. If the cost is fuzzy, say so rather than hiding it.
4. How you will measure it
Decide, before you start, what success looks like and how you will see it: hours saved, error rate, turnaround time. Pick something you already track or can start tracking cheaply.
5. The stop condition
Say in advance what would make you stop. A pilot with no way to fail is not a pilot, it is a purchase with extra steps.
Keep the pilot small
The case is easier to make and easier to prove when the pilot is narrow. A small, useful pilot turns your estimates into real figures fast, which is worth more than a bigger plan built on guesses.
What this does not solve
A business case predicts value; it does not guarantee it. The number that matters is the one you measure after the pilot, not the one you wrote before. Revisit it with how to measure whether a workflow is worth operating.
Good enough to move on when
- The problem is specific and stated in the team's own words.
- The saving beats the cost, conservatively, and both are written down.
- You have named how you will measure success and what would make you stop.


