Where AI Automation Actually Pays Off (And Where It Does Not)

Start from hours, not from capability

The failed automation projects we are asked to rescue almost all began the same way: someone chose an impressive capability and went looking for a use case. The ones that work start from a timesheet.

Before building anything, measure. How many times per week does this happen, how long does it take, and who does it? A task performed twice a month for ten minutes cannot repay a two-week build, however good the demo looks.

What consistently returns hours

First-pass triage. Sorting inbound enquiries, support tickets or applications into categories and routing them. High volume, clear rules, and a human still makes the actual decision.

Data movement between systems. Copying details from an email into a CRM, reconciling two spreadsheets, generating the same weekly report. Tedious, error-prone, and unambiguous.

Drafting from a template. Proposals, follow-ups and reply drafts built from your own past documents. The model produces a first draft; a person edits and sends. Typically cuts the task by half to three quarters.

Search over your own documents. Retrieval across contracts, documentation and past tickets, answering with citations. This turns institutional knowledge trapped in one person into something the whole team can query.

What usually disappoints

Anything requiring genuine judgement about people: hiring decisions, performance assessment, handling an upset customer. These are exactly the tasks where being wrong is expensive and where the value was in the human attention to begin with.

Fully unsupervised customer-facing output. Autonomous replies to customers work until the day one goes badly wrong in public. Keep the approval step; it costs seconds and prevents the incident that ends the programme.

Genuinely novel work. Anything done for the first time has no pattern to learn from, and you spend longer specifying the task than doing it.

Low-frequency tasks, whatever their complexity. The maintenance burden alone exceeds the saving.

The costs people forget

Token spend is the visible cost and rarely the largest. Integration maintenance is bigger: every system an automation touches will change its API, its auth or its data shape eventually, and something has to be repaired when it does.

Then there is verification. If a human must check every output carefully, you have moved the work rather than removed it. Automations pay off when the check is faster than the task: reviewing a draft, not redoing it.

Set spend caps and failure alerts from day one. The two failure modes are a runaway loop burning budget over a weekend, and an automation that silently stopped working a month ago while everyone assumed it was fine.

A sane way to start

Pick the single most repetitive workflow you can measure. Record the current baseline in hours per week. Build the narrowest version that handles the common case and escalates everything else to a person.

Run it for a month and compare against the baseline. If it saved meaningful time, widen it. If it did not, you learned that for the cost of a pilot rather than a programme, and that is a good outcome, not a failure.