How to Identify AI Opportunities in Your Business

The usual starting point is a list of ideas gathered from a workshop, ranked by enthusiasm. It produces a portfolio of proofs of concept that all work in a demo and none of which reach production, because feasibility was never the filter.

A better starting point is to stop looking for AI opportunities and start looking for expensive variation: work where the shape changes every time, where the cost is people re-deciding things, and where the knowledge required already exists somewhere in writing. That is the terrain where these systems earn their cost. It is findable by looking, and the looking does not require a data scientist.

Four qualifying criteria

A candidate process has to clear all four. Three out of four is not a project, it is a pilot that will stall — and it is worth knowing which one it fails on, because that tells you what to fix first.

1. 1 — Volume, or the cost of being slow

   Either it happens often enough that time saved compounds, or each instance is slow in a way that costs you something specific — a deal that cools, an SLA that breaches, a clinician waiting. If neither is true, a successful build produces a rounding error and will never justify its own maintenance.

2. 2 — Real variation

   The work differs case to case in ways nobody has managed to reduce to rules. If it does not vary, you want automation, and it will be cheaper, faster and more reliable than anything with a model in it. Variation is the only thing that makes the expensive option the right one.

3. 3 — The knowledge exists and is reachable

   The judgement being applied is written down somewhere — policies, past cases, documentation, ticket history, contracts — or is at least recoverable from records rather than living only in one person’s head. If it exists only as intuition, your first project is capturing it, and that is a documentation project with a different name.

4. 4 — Mistakes are survivable and visible

   You can define what wrong looks like, catch it before it does damage, and correct it. A process where errors are silent, or where the first sign of one is a regulator, is not where to learn this.

Volume makes it worth doing. Variation makes it worth doing with AI. Available knowledge makes it possible. Survivable errors make it safe to start.

A workflow audit you can run yourself

This takes a few days across a handful of teams and needs no technical input. Its output is a shortlist you can defend to a finance director.

Step one — find the waiting

For each team, ask one question: what are you waiting for? Not what takes you longest — what blocks you. Waiting for approval, for someone to look something up, for a specialist to be free, for a document to be read. Queues are where cost accumulates and they are visible to the people sitting in them.

Step two — follow one real case end to end

Pick a single recent instance and trace it from trigger to completion. Every system it touched, every person, every handoff, every wait. Do this from records rather than from memory — the documented process and the actual one differ, and the difference is usually the interesting part.

Step three — mark each step

Go through the trace and label every step as one of four things. This is the whole method, and it is unglamorous on purpose.

Two patterns fall out immediately. Retrieval steps clustered together are usually one knowledge system, not four projects. And a long run of mechanical steps that everyone assumed needed AI is generally the cheapest win available.

Step four — cost the waiting, not the task

Estimate what each queue costs — in hours, in delay, in cases that fall over. Use your own numbers and keep them conservative; the point is a comparison between candidates, not a business case you would defend to a board. Candidates that cannot be costed at all should be treated with suspicion, because a benefit nobody can size is a benefit nobody will notice.

What disqualifies a process outright

Some candidates should be removed from the list regardless of how attractive they look. Each of these is a reason a project fails late, after money has been spent.

• Nobody owns it. A process spanning three departments with no single accountable owner will not survive its first disagreement about scope.
• The rules are contested. If two experts disagree about the correct handling, you have a policy problem. Building a system on top of an unresolved disagreement encodes one side of it and calls it software.
• The inputs are not accessible. The knowledge sits in a system nobody can get an export from, or in a format nobody has parsed. Check this early; it is the most common late surprise.
• An error is unrecoverable. Irreversible financial, clinical or legal consequences with no review point. These are not permanently off the table, but they are the wrong place to start.
• It is being replaced anyway. Building against a process scheduled for migration next year is work with a known expiry date.
• The real goal is headcount you have not discussed. If the benefit case depends on a change nobody has been told about, the project has a political dependency that will surface at the worst moment.

Sequencing the first three projects

Order matters more than selection. The first three projects are not chosen to maximise value; they are chosen so that each one makes the next cheaper and so that the organisation learns to run these systems while the stakes are low.

1. First — something internal that finishes

   Internal users, a clear owner, a measurable queue, and errors that are visible and cheap. It should ship in weeks and be genuinely used. Its real output is not the saving; it is that your organisation now has an evaluation set, a monitoring habit, an approval pattern and a group of people who have used one of these in anger.

2. Second — build on what the first one exposed

   The first project will have surfaced a knowledge source that turned out to be more valuable than expected, or a data problem that has to be fixed anyway. Take that. The second project is where compounding starts, and it is why the first should be chosen partly for what it uncovers.

3. Third — the customer-facing one

   Now, and not before. External exposure demands the guardrails, monitoring and escalation paths that the first two taught you to build. Teams that start here usually build all of that under deadline pressure, in front of customers.

The pattern to avoid is three parallel pilots in three departments, each proving feasibility and none reaching production. It looks like momentum and produces nothing that operates, because feasibility was never the thing in doubt.

If you run the audit and nothing clears all four criteria, that is a legitimate result and a useful one. The right conclusion is usually that the groundwork — documentation, access, a baseline measurement — is the first project, and it is worth doing regardless of what gets built on top of it.