What this covers
- Model elapsed time and capacity, not headcount, unless you genuinely intend to reduce headcount.
- Use a baseline measured from your own systems before deployment, not an estimate collected afterwards.
- Include the costs that are usually omitted: the exception queue, the rule-writing, and the internal time.
- Revenue effects are real in quoting but harder to attribute, so state them separately rather than blending them in.
There is a specific way AI business cases fail, and it is not that the numbers were too optimistic. It is that they were not the organization's own numbers. A percentage from a vendor deck, multiplied by a headcount figure, produces a total that is impossible to verify and therefore impossible to defend.
A case built from your own systems is smaller, harder to argue with, and much more likely to get approved.
Measure the baseline before you need it
This is the step that is almost always skipped and almost always regretted, because after deployment nobody can agree what the before looked like.
Take one workflow. Pull the last three months from the systems that already hold the timestamps.
- Volume: how many cases, by month, and how that varies.
- Elapsed time: from the customer's timestamp to the outcome, not from when somebody opened it.
- Touch time: how long the work actually takes when someone is doing it, sampled honestly rather than estimated.
- Exception rate: what share needed something unusual, and what the unusual thing was.
- Rework: how often the outcome had to be corrected afterwards.
Model capacity, not headcount
A business case that assumes headcount reduction has to be defended by somebody who is willing to make that reduction. If nobody intends to, the case is fiction and the operations team knows it, which is a bad way to start a deployment that depends on their cooperation.
The more defensible framing in a growing business is capacity: the same team handling materially more volume without adding people, and spending the recovered hours on work that is currently not getting done. Both are quantifiable, and neither requires anyone to be dishonest about intentions.
| Framing | Defensible when | Fails when |
|---|---|---|
| Headcount reduction | There is a real, named intention to reduce | Nobody will act on it, and everyone knows |
| Capacity without hiring | Volume is growing and hiring is planned | Volume is flat and nobody was going to hire |
| Time redeployed | You can name what the hours go to instead | The recovered time has no stated destination |
| Error and rework reduction | You measured rework beforehand | You are estimating it after the fact |
| Revenue from faster response | Quoting, with win rate tracked | Stated as a blended percentage with no attribution |
The costs that get left out
A case that only counts the license fee will be challenged, correctly, by anyone who has run a deployment before. Four costs belong in the model.
- 01The exception queue
Cases the agent holds still need a person. Model that queue at a realistic rate rather than assuming it is zero, and remember it is largest in the first months.
- 02Writing the rules
Establishing tolerances, thresholds and coding rules takes time from the people who own them, and they are usually busy people. This is real internal cost even though it produces a permanently useful artifact.
- 03Systems work
Making live pricing and availability reachable, agreeing the service identity, and validating the write path. Small in most estates, occasionally not.
- 04Ongoing ownership
Somebody reviews the held cases, adjusts thresholds and watches the correction rate. A few hours a month rather than a role, but not nothing.
Revenue effects, stated honestly
In quoting there is a genuine revenue argument: faster responses win more work. The mechanism is real and any sales team will confirm it. The problem is attribution, because win rate moves for many reasons at once.
The defensible treatment is to state it separately and conditionally, rather than blending an assumed uplift into the total. Give the cost case on its own, and present the revenue effect as an additional upside with the mechanism explained and the measurement named. A finance reviewer will trust the whole document more for the separation.
A smaller number you can defend line by line beats a larger number that collapses under one question.
What about published figures
This site publishes two customer outcomes: 52% faster quote preparation at a B2B service provider, and 40% faster ticket routing at a European logistics company. Both are measured, both are anonymized at the customer's request, and neither belongs in your business case as an assumption.
They describe what happened in a specific operation with specific data quality and specific rules. Using someone else's result as your projection is exactly the error this article is arguing against. Use them as evidence that the mechanism works, and use your own baseline for the model.
A structure that gets approved
- 01The workflow, in one paragraph, with the volume from your own system.
- 02The baseline: elapsed time, touch time and exception rate, with the source named for each.
- 03What changes, specifically: which steps the agent takes and which stay with people.
- 04The cost model, including the exception queue and the internal time.
- 05The benefit, framed as capacity or elapsed time, with revenue effects stated separately if relevant.
- 06The measurement plan: which numbers, from which system, reviewed on which date.
- 07What would make you stop, stated in advance.
The seventh point is unusual and it is the one that most improves the document's credibility. A proposal that names its own failure condition reads as an assessment rather than a pitch.
Choosing your first workflow covers which workflow to model, and a Workflow Review produces the baseline trace the case is built on.