What is worth automating
Three tests, and a task has to pass all three. Frequency, rules, and a checkable output.
- Frequency. It happens at least several times a week. Automating a monthly task costs more than doing it.
- Rules. Somebody could write down how to do it. If the answer is "it depends, you just know", that is judgement and it does not automate.
- Checkable. You can tell whether the output was right. Without this you cannot evaluate it, and an automation nobody can evaluate is one nobody should trust.
Tasks that pass all three, in the order I would build them: routing and filing incoming enquiries, extracting data from documents, enriching product records, drafting routine replies for approval, and turning call or meeting transcripts into actions.
What it costs, and what it saves
| Scope | Typical build | Running |
|---|---|---|
| One workflow, two systems | £2,000 – £5,000 | Tens of pounds a month |
| Several workflows, shared logic | £5,000 – £15,000 | Low, scales with volume |
| Operations pipeline with reporting | £15,000+ | Depends on volume |
| Cybrial | Priced on application, from the hours | Your own accounts |
Source: UK market ranges, September 2026.
The arithmetic worth doing before you commission anything: how many times a week does this happen, how long does it take, and what is that hour worth? A task done ten times a week taking fifteen minutes is two and a half hours — call it £100 a week, £5,000 a year. A £3,000 build pays back inside eight months and keeps going. A task done twice a week does not.
How automation projects fail
- Automating a broken process. The automation makes the mess happen faster. Fix the process first, and sometimes that is the whole engagement.
- No error handling. It works for three weeks, then an input changes shape and it fails silently. Nobody notices until something downstream is wrong.
- Nobody owns it. The person who commissioned it leaves and the thing runs unattended until it breaks.
- The model was used where a rule would do — slower, dearer, less predictable, and harder to debug.
- No evaluation. Nobody can say whether it is doing the job correctly, so trust erodes and people quietly go back to doing it by hand.
The last one is the most common ending: the automation still runs, nobody relies on it, and the work happens twice. Which is why an evaluation set and an alert on failure are part of the build here rather than an upsell.
