Writing the business case for AI around one process you already measure

Writing the business case for AI works best when you build it on one process your company already runs and measures. Ticket routing in Zoho Desk is a good example. You then put the costs, expected savings and risks on one page that a director can approve or reject. General promises about productivity give a director nothing to check.

A business case for AI is a short decision document. It states what one process costs today and what an AI step would cost to build and run. It also states what that step should save and what could go wrong.

The word "one" matters. A case that covers every department at once needs assumptions nobody can test. A case that covers one queue of tickets can be tested within weeks.

This guide walks through each part of that page. It covers how to choose the process and measure the baseline, how to price the AI from the vendor's own figures, and how to discount your savings estimate. It also covers which risks to name. A worked example shows the finished page as a table you can copy.

A claim such as "AI will save every employee an hour a week" fails a director's review because it has no baseline and no owner. Nobody measured the hour before. Nobody will measure it after. The director can only accept or refuse the claim on trust. That is not a decision, it is a guess.

Broad promises also hide the state of the process underneath. The Local Government Association's playbook for agentic AI in local government puts it plainly: "Agentic AI will not fix unclear processes, weak ownership or poor-quality data. In many cases, it will make those weaknesses more visible." The playbook defines agentic AI as an AI system that works towards a defined goal. It uses approved knowledge sources or tools and carries out tasks within boundaries set by people.

That warning applies to any business, not only councils. If nobody knows how tickets should be routed today, an AI step will route them inconsistently too. It will just do so faster. A business case built on a measured process forces those questions into the open before money is spent. You have to name the rule, the owner and the number before you can write the page at all.

The right process for an AI business case runs often, has a known right answer and already leaves a record in one of your systems. If it fails any of these tests, the savings cannot be measured, and the case will rest on opinion again.

Use these four tests when you shortlist candidates:

• Volume: the process happens many times a week, so small gains per item add up.
• A clear right answer: a person can say whether the outcome was correct, for example whether a ticket reached the right team.
• An existing record: the system already stores each item and its outcome, so you can count before and after.
• One owner: a single manager answers for the process and will sign off the result.

Ticket routing in Zoho Desk passes all four in most service teams. So does case handling, where a request moves through fixed stages. Lead assignment in Zoho CRM often qualifies as well. Invoice coding and quote drafting can qualify if the outcome is recorded.

If you want more candidates grouped by department, the overview of AI by business task lists common ones. Pick one process. Leave the rest for the second business case, which will be easier to approve once the first one has delivered.

The baseline is the measured performance of the process today, and it is the number every saving is compared against. Without it, nobody can show the AI changed anything. Record it from your own system before anyone builds or buys a thing.

For ticket routing, four measures usually cover it:

• tickets received per month;
• the share of tickets that reach the wrong team first and have to be moved by hand;
• staff time spent reading and moving each misrouted ticket;
• time to first response, because misrouted tickets wait longer.

Take these figures from the ticket history, not from memory. Staff estimates of how often tickets are misrouted tend to drift from the record, and a director will ask where the number came from.

At Svennis, we pull the ticket history and count the hand-moved tickets before anyone discusses models or prices. The projects that go wrong are the ones where nobody could say how many tickets were rerouted before the change.

Write down who owns each baseline figure and the date range it covers. That owner should be the same person who will report the figure after go-live. The comparison then uses the same definition twice, and the result is hard to argue with.

The cost side of an AI business case has three lines: model usage, the work to connect the model to your systems, and staff time to review its output. Many drafts include only the first. The other two are usually larger in the first year.

Model usage is priced per million tokens, the units of text the model reads (input) and writes (output). Anthropic's models overview lists these prices in US dollars:

To estimate the monthly model cost, multiply tickets per month by the tokens used per ticket, then by the price, then divide by one million. Do this for input and output separately and add them. Measure tokens per ticket on a sample of real tickets rather than guessing. Anthropic's own advice is that if you are unsure which model to use, you should start with Claude Opus 5.5 for most workloads. Test a cheaper model only if it meets your accuracy target.

Build work and review time come from your supplier's quote and your own payroll. Put both on the page as separate lines.

Savings in an AI business case should be calculated from the baseline, then reduced to allow for optimism bias. Optimism bias is the tendency to expect more benefit and less cost than a project delivers. The UK government's business case prompt on the AI Knowledge Hub asks for the Economic Case to include "cost-benefit analysis and optimism bias adjustments". A private company gains from the same discipline.

For ticket routing, the cash saving follows from three of your own numbers. Take the misrouted tickets per month that the AI step should prevent. Multiply by the staff minutes spent on each one. Multiply that by the hourly cost of the staff involved. Each figure comes from the baseline or from payroll, so a director can check every step.

Then present two figures, not one. The expected case uses your target accuracy. The cautious case assumes a smaller improvement, and it is the figure a careful director will judge you on. If the project only pays back in the expected case, say so.

Keep benefits that are real but hard to price on a separate line. A faster first response is the obvious one. Do not convert them into pounds with a formula nobody believes. A director can weigh a shorter wait time on its own terms.

Every risk in an AI business case needs a named owner and a planned response. A risk without an owner is a worry, not a control. Five risks come up in almost every routing or case handling project:

• Wrong outcomes: the model sends tickets to the wrong team. Agree in advance the accuracy below which a person reviews every decision.
• Access and safeguards: the LGA playbook notes that flexible tools such as Claude place "more responsibility on the organisation to design the safeguards, control what the model can access, and decide where human confirmation is required."
• Model retirement and price changes: Claude Haiku 4.5 retires not sooner than 15 October 2026. Anthropic says Claude Opus 5.5 costs 40% less to run than Claude Opus 5, so prices move in both directions.
• Workforce effects: the playbook lists deskilling and over-reliance on AI outputs among its risks.
• Weak process exposed: unclear routing rules surface once the AI applies them.

Model retirement belongs in the plan, not in small print. Write down which model the case assumes and when you will test its successor. Keep your prompts and checks independent of one model, so the change is a test rather than a rebuild.

The safeguards risk is the one directors ask about most. Answer it with specifics: which systems the AI can read and which it can change. Say where a person confirms an action before it happens.

The one-page business case below is for an AI step that reads incoming Zoho Desk tickets and assigns them to the right team. Each line names where its figure comes from. That way the director can check any number without asking for a second document. Replace the descriptions with your own figures.

The decision line matters most. Ask for a limited, time-bound pilot rather than an open commitment. The LGA playbook recommends that shorter commitments, "such as one-year arrangements", become commonplace where technology supports new ways of working. A short term lets the director approve a test rather than a bet.

The Five Case Model is a business case structure made up of five cases: Strategic, Economic, Commercial, Financial and Management. UK government uses it for public spending. A small company does not need the full document, but the five headings make a useful checklist for a one-page case.

Each case maps onto a line of the worked example:

• Strategic: why this process, and why now.
• Economic: savings against costs, with the optimism bias adjustment.
• Commercial: what you buy, from whom, and for how long.
• Financial: build cost, running cost and when it is paid.
• Management: who owns the result and how it will be reviewed.

The AI Knowledge Hub prompt says it is suitable for any AI assistant. It also warns you to "check the results from this prompt for accuracy, as AI can make mistakes and the library has not been formally evaluated." Treat any draft as a first pass. You are still the author of every figure.

If you draft the page in Claude, it can appear as an artifact. Anthropic defines an artifact as anything Claude makes that you would put in front of someone, such as a document or a deck. According to the Claude Help Center article on artifacts, docs export to Word, PDF, Markdown and Google Docs.

For a UK company, an AI business case built on one measured process fits the way public bodies and larger customers already judge spending. The Five Case Model follows HM Treasury practice. If you supply the public sector, the people who review your proposals will recognise the structure.

Data handling needs a line of its own. The AI Knowledge Hub tells civil servants: "Do not upload any personal or official information to free tools, or any tool not advised by your department." Apply the same rule when you draft the case. Use a sample of tickets with names and contact details removed, and use a tool your company has approved. The legal side is covered in the overview of AI law in the UK and what applies to your business.

Scale the governance to the risk. The LGA playbook describes a three-tier model used by North East Derbyshire District Council. In it, the top tier covers system-integrated or public-facing AI, which is high risk and needs formal corporate approval and assurance. An internal routing step usually sits lower than a public-facing chatbot. Say which tier your case falls into.

The playbook also recommends appointing a lead officer to coordinate AI activity across teams. In a company of any size, that means naming one person who keeps the business cases, the results and the review dates in one place.

The practical route to an approved AI business case is short, and most of it happens in your own systems before you speak to any supplier. Work through these steps in order:

1. Pick one process that passes the four tests: volume, a clear right answer, an existing record and one owner.
2. Export the baseline from the system that holds the record, with a stated date range.
3. Run a sample of real items through a model to measure tokens per item, then price it from the vendor's own list.
4. Get a quote for build work, and estimate review time from payroll.
5. Write the expected and cautious savings, and name an owner for each risk.
6. Fill in the one-page table and ask for a limited, time-bound pilot.

Keep the first case small enough that the result arrives within the pilot period. A measured result on one queue of tickets will carry the second business case further than any forecast.

If you want to see how an AI step sits inside your existing tools, read the guide to building AI into the systems you already use. When you are ready to scope the pilot itself, the page on AI automation for growing businesses sets out how that work is delivered.