How to identify business workflows worth automating
A practical filter for separating the workflows where AI pays for itself from the ones that merely look automatable.
2 May 2026
Ask a leadership team where AI could help and you will get a list of everything that is annoying. Annoyance is a poor predictor of return. Some of the most irritating work in a company is irregular, low-volume and rich in judgement — exactly the profile that automates badly.
Here is the filter we use in discovery, in the order we apply it.
1. Volume before ambition
The first question is not how sophisticated the work is, but how often it happens. A task performed forty times a day by six people is worth automating even if the saving is small each time. A task performed twice a month is usually not, however painful it is.
This is unglamorous and it eliminates most of the initial list. It also explains why the best first AI project in a company is often something nobody described as strategic: intake, triage, classification, drafting from precedent.
2. Is the input already digital and reachable?
There is a large practical difference between data that exists and data you can get to. Documents in a system with an API are workable. Documents in an email archive nobody has permission to export are a six-week negotiation before a line of code runs.
Ask specifically: where does the input live, who owns access, and what has to happen for a system to read it? If the answer involves a data migration, that migration is the project — and it should be costed as one.
3. Is “correct” definable by someone who is available?
Every workflow worth automating has an expert who can say whether an output is right. If that person cannot be named, or cannot give you two hours a week during the build, the workflow is not ready. You will be building against a guess.
The strongest signal here is whether the expert can produce twenty worked examples. If they can, you have an evaluation set and a specification. If they cannot, the process is less standardised than the org chart suggests, and standardising it is the first piece of work.
4. What is the cost of being wrong, and who catches it?
Workflows differ enormously in how much error they tolerate. Drafting a proposal that a partner will review tolerates a lot. Posting a journal entry tolerates almost none.
This is not a reason to avoid high-stakes workflows — it is a design input. In low-tolerance work, the system’s job is usually to prepare and flag rather than to decide, and the value comes from the reviewer spending their attention where it matters. Decide this before building, because it determines the shape of the system, not just its settings.
5. Does anything downstream actually change?
The last filter is the one most often skipped. If the output of the automated step lands in a document that then sits in an inbox waiting for the same person as before, the cycle time does not improve. You have automated a step inside a queue.
Follow the work to its end. The workflows that produce real results are the ones where a faster step changes what happens next — a decision made sooner, a customer answered the same day, a review that no longer batches.
Applying the filter
Score candidate workflows on the five questions and the list usually collapses from twenty items to three or four. Those three or four are worth a week of proper discovery each.
It is worth noticing what this filter does not reward: novelty, visibility, and how impressive the demo would be. Those are the criteria that produce pilots. Volume, access, a definable standard, an appropriate error budget and a downstream consequence are the criteria that produce systems people keep using.