Choosing AI use cases that move money means ranking candidate processes by three factors — how much they leak in time or margin today, how often the task repeats, and whether the data to run a model already exists — and then deliberately declining the ones that only demo well. The strongest first use case is rarely the most visible one. It is usually a dull, high-volume, repetitive back-office process with a clear owner and a metric you can already put a number on. A customer-facing chatbot is the opposite: easy to show a board, hard to connect to a line on the P&L, and unforgiving when it gets an answer wrong in public.
Why do most AI use case lists start in the wrong place?
Most shortlists are built from what is exciting or what a vendor demoed last quarter, not from where the business actually loses money. That is how organisations end up with a chatbot pilot while a twelve-person team keeps rekeying invoices by hand. The demo wins the meeting; the invoice team keeps the leak.
A use case list should start from the operation, not the technology. Before asking what AI could do, ask where the business currently loses time, margin, and judgment — which processes are slow, error-prone, repetitive, or dependent on one overloaded expert. Those leaks are the candidate pool. Everything else is a solution looking for a problem, and solutions looking for problems are a large part of why enterprise AI pilots fail before they reach production.
What are the three tests a good AI use case passes?
A candidate worth building passes three tests. Miss any one and the project tends to stall, regardless of how good the model is.
Does it leak real money or time?
The process has to cost something measurable now — labour hours, error and rework, delay, or margin lost to slow decisions. If you cannot express the current cost in rupees, dirhams, or hours, you have no denominator for a business case and no way to know whether the system paid off. High-value leaks that recur are where AI earns its keep; a clever application on a process that barely costs anything is a hobby.
Does the same task repeat often?
AI pays back through volume. A decision or extraction that happens thousands of times a month — invoices, purchase orders, KYC checks, tender documents landing on GeM, CPPP, or Etimad — amortises the build cost across every repetition. A task that happens twice a quarter almost never justifies a model, no matter how tedious each instance feels. Frequency, not difficulty, is what turns a working model into a return.
Does the data already exist in usable form?
The model needs something to read. If the documents, records, or labels it depends on are scattered across email, shared drives, and three systems that do not talk to each other, most of the project will be data plumbing, not AI. Use cases where the data is already flowing through one place — an inbox, an ERP, a document management system — are dramatically cheaper to build and far more likely to survive contact with production.
How do you rank the candidates that pass?
Once you have a pool that passes the three tests, rank it rather than debating it. A simple, honest scoring beats a long argument.
- Estimate annual leakage for each process — loaded labour cost, error cost, and delay cost. Vague-but-defensible is fine; invented precision is not.
- Multiply by frequency and stability. A high-value, high-volume, unchanging process scores far above a high-value one-off or a process that is about to be redesigned anyway.
- Discount for data readiness and ownership. Halve the score where the data is messy or scattered, and halve it again where no single person owns the outcome. An unowned use case has no one to accept the system, feed it exceptions, or defend its budget.
- Set aside the highest-risk answers. Where a wrong output is expensive and hard to catch, the use case is not disqualified, but it needs a human decision point built in from the start rather than bolted on later.
What usually rises to the top of this ranking is unglamorous: accounts payable, document intake, compliance checks, first-pass tender review. What sinks is the customer-facing chatbot, the "AI strategy assistant," and anything whose value is described in adjectives rather than a metric.
Why is a chatbot so often the wrong first project?
A chatbot fails the money test more often than teams expect. Its value is diffuse — a slightly nicer support experience — and it rarely moves a hard operational metric like cost per transaction or cycle time. It also sits in the highest-visibility position possible, in front of customers, where every wrong or hallucinated answer is public and attributable to the brand. High risk, diffuse value, and a weak link to money is a poor combination for a first project, even though it is the easiest thing to put on a slide.
This is the judgment call at the centre of use case selection: deploy AI where it changes the outcome, and decline it where it only makes a demo. Knowing what to say no to is a skill in itself, and when not to use AI is worth treating as a real decision rather than an afterthought. The point is not that chatbots are always wrong — it is that they are almost never the use case that moves the most money first.
What this approach does not do
This is a prioritisation method, not a guarantee. It will not tell you whether a specific model will hit the accuracy the process needs — that takes a scoped test on your own data. It does not remove the risk that a high-scoring use case still stalls in the gap between a working proof of concept and a production system, which has its own causes worth understanding on their own terms in the PoC-to-production gap. And it assumes you can estimate leakage honestly; if no one has ever measured the current process, your first task is measurement, not model selection.
It also deliberately favours boring, internal, high-volume work over visible, strategic-sounding projects. If your goal this quarter is a headline rather than a return, this method will point you the wrong way — which is the point.
Where to start
Start by listing your five most expensive repetitive processes, not your five most exciting AI ideas. For each, write down what it costs today, how often it runs, and where the data lives. Rank them by leakage times frequency, discount the ones with messy data or no owner, and pick the top candidate that has a clear owner willing to stand behind the outcome.
Then scope that one use case properly before committing — decide where a human stays in the loop, so operators trust the system enough to actually use it, a design problem covered in keeping human judgment in the loop. Selection is only the first stage; turning a chosen use case into something that runs every day follows a repeatable sequence for operationalizing AI. Choose the process that moves money, and let the chatbot wait for a quarter when it is the answer to an actual question.