The short answer
A business case for automation needs five things on one page. The task and how much of it there is. What it costs today, in hours and in errors and delay. What the system will cost to build and to run. How you will know it worked. And what happens to the exceptions it cannot handle.
Most cases fail on the first and fourth. They describe a technology instead of a task, and they promise savings without a measurement taken before the work starts. Fix those two and the rest is arithmetic.
I build production AI agents for operational teams, and the step I insist on is a baseline measured before anyone builds anything. This page is the method, and the free calculator linked below does the sums.
1. Name one task, not a technology
Write the case for a single piece of work with a start and an end, such as entering emailed orders, checking weekly timesheets or pricing enquiries. A case for adopting AI has no owner and no measure. A case for one task has both.
Pick work that is frequent, follows rules a person could write down and has past examples to test against. If you have several candidates, the scoring tool on this site ranks them.
2. Measure the task for one real week
Count how many items arrive, how long each takes from arrival to done, how much of that is someone working and how much is waiting, and how many come back with an error. Use a real week, because people underestimate repetitive work when asked from memory.
This baseline is the most valuable line in the document. Without it nobody can tell afterwards whether the project worked, and a finance director knows that.
3. State the cost of doing nothing
Hours are the obvious cost, and often not the largest. Add the delay, since a quote that takes three days loses work to one that takes three hours. Add the errors, since a wrong order line is a return and a credit note. Add the ceiling, the point where the team cannot take more volume without more people doing the same keying.
Put a number on each only where you can defend it. One defended number beats five estimates.
4. Price the build and the upkeep honestly
There is a one-off cost to build and a cost every month to run. The monthly cost is more than model usage. It includes hosting, monitoring, the upkeep of every connection to another system and a regular review of what the agent did.
Keep the share of work the system will take realistic. In the systems described on this site it ranged from about 60 to 90 percent of the manual work, and the remainder is exceptions that stay with people. A case built on 100 percent will not survive its first month.
5. Say how you will know it worked
Choose two or three measures from the baseline and set a target for each, for example turnaround time, the share of items handled without correction and the number of errors that reach the customer. Say when you will measure them again.
Include the test that would make you stop. A project with a stated stopping point is easier to approve than one that asks for trust.
6. Describe the first stage as small and reversible
Ask for approval of one workflow, run in shadow mode beside the team before it acts on anything, with a review at the end. The team compares its output with their own, and the decision to go live is made on that evidence.
A small first stage also answers the risk question before it is asked. Nothing changes for customers until the numbers say it should.
What a finance director will ask
What happens when it is wrong. The answer is the design, checks before anything is written to a system, a person who approves what the checks cannot confirm, and a record of every decision.
What it costs if volumes double. Usage costs rise with volume and the build does not, which is the opposite of doing the work by hand. Show both lines.
Who owns it. Name the person in the business who decides the rules and the person who keeps it running. A system with no owner is a common reason these projects fade.
What happens to the team. Say it plainly. The routine work goes, the exceptions and the judgement stay, and the same people handle more volume or the work that was being neglected.
When the honest answer is no
If the calculator shows a payback measured in years, the task is too small or too irregular. A form, a template or a script may fix it for a fraction of the effort, and saying so is part of a credible case.
If nobody can state the rules, the first project is writing them down. That costs little, helps the team at once and makes the next business case easy.
The one page, line by line
| Line | What to write | Where the number comes from |
|---|---|---|
| The task | One workflow with a start and an end | The team that does it |
| Volume and time today | Items a week, hours a week, turnaround | One measured week |
| Cost of doing nothing | Hours, delay, errors, the volume ceiling | The baseline, plus figures you can defend |
| Cost to build and run | One-off build, monthly running cost | A quote and an honest upkeep estimate |
| Measures of success | Two or three targets and a review date | The same baseline, measured again |
| Exceptions and ownership | Who handles what the system will not, who owns the rules | Agreed with the team before approval |
Put it together
Fill in the measured week first, then run the calculator with a realistic share and your real hourly cost. If it pays back within a year on time alone, the case stands before you count delay or errors. If it does not, lead with the delay or the error cost, but only if you can defend the figure.
Keep it to one page. The detail belongs in an appendix, and the decision belongs to the person who can read the page in five minutes.