Most organizations we talk to have already tried AI. There was a pilot, it demonstrated something interesting, and then it stopped. Nobody cancelled it exactly — it just never found a reason to become part of how the business runs.
The reflex explanation is that the technology was not ready. Usually it was. The use case was chosen for how impressive it would look rather than for how much repetitive work it removed, and impressive is not a business case.
The four properties that make a use case pay back
Work that AI reliably takes cost out of has a recognisable shape. When all four of these are present, the case is usually strong. When two or more are missing, the pilot tends to stall regardless of how well the model performs.
High volume. The saving is per-instance, so it scales with instances. A process that runs four hundred times a day is a different proposition from one that runs twice a week, even if the second one is more annoying.
Rule-bound, not judgement-bound. The task should have a right answer that a trained person would agree on. "Extract the invoice total" qualifies. "Decide whether we should extend this customer's credit" does not — not because a model cannot produce an answer, but because you cannot tell whether the answer was correct.
Already measured. If you know how long the process takes today, you can prove the saving. If you do not, you will be arguing about whether the pilot worked, and that argument has no end.
Tolerant of a review step. The cases where AI removes the most cost are the ones where it can handle the routine majority and hand the uncertain remainder to a person. Use cases that require the automation to be right every single time, with no review path, are far harder and much less common than they appear.
The categories that keep working
Across the engagements and products we have built, the same few patterns account for most of the realised saving.
Document and paperwork processing
The clearest case, because it has all four properties. Invoices, forms, claims, contracts, scanned correspondence — high volume, rule-bound extraction, usually already timed because someone is doing it manually, and naturally suited to confidence scoring with a review queue.
The mistake to avoid is trying to handle every document type at once. Automate the highest-volume format completely, prove the saving, then widen. A pilot that covers everything shallowly is harder to evaluate than one that covers one thing properly.
Internal knowledge retrieval
Not a customer-facing chatbot. The expensive version of this problem is your own staff spending time locating policy, precedent, specification, or case history across systems that do not talk to each other.
Retrieval over internal knowledge addresses that directly, and it has a useful property: the failure mode is mild. A support agent given a poor answer notices and searches manually, which costs a few seconds. The same poor answer delivered straight to a customer costs considerably more. Starting inside the organization is both cheaper to build and much lower risk than starting at the front door.
Drafting the repetitive parts of skilled work
Skilled people spend a surprising share of their time producing the predictable scaffolding around their actual expertise: the standard sections of a report, the first draft of a routine reply, the summary of a case someone else needs to read.
This is not automating the judgement. It is removing the typing that surrounds it. The saving is real and it is well tolerated by the people doing the work, because nobody enjoyed that part.
Triage and routing
Deciding where something goes — which queue, which team, which priority — is high-volume, rule-bound, and normally done by a person reading enough of the item to classify it. It is also easy to evaluate, because you can measure misroutes before and after.
Where the money does not come from
Two categories consume disproportionate effort for disproportionately little return.
Anything whose value is "insight". If the deliverable is a dashboard, a summary, or a recommendation that a human then has to act on, the saving depends entirely on whether the action changes. Usually it does not, because the constraint was never information.
Public-facing conversational interfaces, as a first project. They are the most visible form of AI and the least forgiving. The reputational downside of a bad answer is real, the evaluation surface is enormous, and the cost being removed is often smaller than it looks. This is a reasonable third or fourth project. It is a poor first one.
Cost that arrives with the solution
One thing that consistently gets left out of the business case: AI in production is a recurring cost, not a fixed one. Inference, storage, retrieval infrastructure, and the engineering time to keep evaluation honest all continue after launch.
That does not make the case worse — it makes it a case rather than a hope. A process costing a measurable amount in labour today, against a measurable inference cost tomorrow, is a comparison you can actually make. The pilots that stall are usually the ones where neither side of that comparison was ever quantified.
How to choose the first one
Inventory the repetitive work, not the AI capabilities. Ask which processes run most often, roughly what they cost in time, and whether a trained person would agree on the right answer for each instance.
Score that list against the four properties above. Some processes will be worth automating now, some will not be worth it at any price, and being clear about which is which is the whole value of the exercise. That answer is useful whether or not anything gets built afterwards.