Most organisations approach this backwards. They start with the technology — a licence, a platform, a demonstration — and then look for somewhere to apply it. That sequence produces pilots, and pilots produce a general sense that AI has not lived up to expectations.
The better sequence starts with the work.
Five characteristics of a task worth automating
When we assess candidates, we score them against five properties. A task that scores well on all five is almost always worth building. A task that fails two or more usually is not, regardless of how appealing it sounds.
Volume. How many times does this happen? Weekly is rarely enough. Several times a day is promising. The build and maintenance cost is largely fixed, so volume is what amortises it.
Repeatability. Does it follow a recognisable pattern? Not identical every time — variation is fine, and handling it is precisely what these systems are good at. But there needs to be a describable shape.
Tolerance for error. What happens if it is occasionally wrong, given a human review step? If the answer is “a small correction”, good. If the answer is “a regulatory breach” or “we lose the client”, the task needs a different design or no automation at all.
Clarity of input and output. Can you state what goes in and what comes out? Tasks where the output is “a good decision” are hard to automate and harder to evaluate. Tasks where the output is “these six fields, extracted from this document” are straightforward.
Someone cares. There is a named person who currently does this work and would rather not, and a manager who would notice the time released. Automation with no internal owner falls out of use within a quarter.
The arithmetic
Before building anything, do this calculation properly. It takes twenty minutes and it prevents most bad decisions.
Current cost: how many times per month, multiplied by minutes per instance, multiplied by the loaded hourly cost of the person doing it. Add the cost of errors — rework, corrections, the occasional expensive mistake.
Future cost: the build, plus running costs (API usage, licences, hosting), plus maintenance — assume something meaningful each year, because upstream systems change — plus the time still spent by people reviewing exceptions.
Then be honest about two things. First, the time released is only a saving if it goes somewhere useful. Four hours a week returned to a team that was already at capacity is real; four hours returned to a role that was not busy is not. Second, add contingency: first automations take longer than expected, and the exception rate in month one is always higher than in month six.
If the numbers only work under optimistic assumptions, they do not work.
Where the value actually appears
Across the engagements we have run, the returns cluster in a few places.
Document-heavy processes. Invoices, purchase orders, applications, claims, contracts, tender documents. Anything arriving as a PDF that a person currently reads and retypes. Consistently the strongest category, because volume is high, structure is recognisable, and errors are correctable.
Information trapped in systems that do not talk to each other. Where a person’s job includes looking something up in one system and entering it in another, that transcription is pure cost. Removing it does not require sophisticated AI, and it frequently produces the largest measured saving.
Shared inboxes. Classification, routing, extracting the key details and drafting the routine replies. High volume, clear rules, and the exception cases genuinely need a person — a good shape.
Internal knowledge retrieval. “Where is the current version of this policy?” “What did we agree with this client in 2023?” Hard to quantify but consistently valued, because the alternative is interrupting a colleague. Requires your permissions to be in order first.
Recurring reporting. Any report assembled from the same sources every month. The assembly is automatable; the interpretation is not, and should not be.
Where it disappoints
Anything requiring judgement with real consequences. These systems are good at pattern recognition and poor at accountability. Where a decision needs a person to own it, automation can prepare the ground but cannot take the decision.
Low-volume, high-variation work. The classic example is bespoke client work. Every instance is different, volume is low, and the effort of describing the process exceeds the effort of doing it.
Processes that are already broken. Automation executes an unreliable process faster. Fix it first — and note that fixing it often delivers most of the benefit on its own, at which point the automation may become unnecessary.
“Improving communication” and similar. Genuine problems, but not automation problems. AI-drafted internal updates that nobody reads are the same as human-drafted internal updates that nobody reads, produced more efficiently.
Three failure patterns
The horizontal deployment. Buy a per-user assistant licence for everyone and hope value emerges. Some will use it well, most will try it for a fortnight, and you will have no way of establishing whether it was worthwhile. This can work, but only where permissions are in good order and it follows a specific win rather than substituting for one.
The six-pilot portfolio. Running several proofs of concept simultaneously to see which works. It sounds prudent and it means none of them get the attention needed to reach production. Pick the strongest and build it properly.
The unmeasured success. Deploying without a baseline, then being unable to say whether it helped. Measure the current state before you change it — how long the task takes now, how many errors, what the turnaround is. Without that, you have anecdote.
A reasonable first project
For most SMEs, the sensible starting point looks like this: one document-heavy or transcription-heavy process, high volume, currently consuming a meaningful share of somebody’s week. Six to ten weeks from discovery to production. A human approval step retained. Measured against a baseline captured before you started.
It will not transform the business, and it should not be sold as though it will. What it will do is release real time, prove the approach in your specific environment, and give you an informed basis for the next decision — which is worth considerably more than a portfolio of interesting pilots.