
01
The business problem
Teams usually automate the task that annoys them most, which is not the same as the task that costs most. The result is a clever automation saving ten minutes a week that nobody can fix when it breaks.
02
Context
A first automation sets expectations for everything after it. If it is chosen well, it is visible, reliable and easy to explain, and the next one is easier to fund.
The criteria that matter are frequency, rule-clarity and consequence of failure — not technical interest.
03
Options and recommended approach
Building it
- 1
Choose a high-frequency, rule-based task
Something that happens daily or weekly, follows the same rules every time, and does not require judgement. Frequency is what creates the return.
- 2
Write the rules out in full first
Including the exceptions. If the rules cannot be written unambiguously, the process needs fixing before it is automated.
- 3
Keep the chain short
Fewer steps and fewer connected systems. Long chains fail more often and are harder to diagnose.
- 4
Decide what happens when it fails
Where the error goes, who sees it and what the manual fallback is. An automation with no failure path becomes an invisible problem.
- 5
Run it alongside the manual process first
For a short period, do both and compare. This catches the exceptions nobody remembered.
- 6
Document it and name an owner
One page: what it does, what triggers it, which accounts it uses and who maintains it. Undocumented automation is a liability when someone leaves.
04
Practical use case
A professional services team spent part of every morning copying new enquiries from a web form into a spreadsheet, then chasing whoever was on duty. The rules were unambiguous and the task happened many times a day.
The automation created the record, assigned an owner by rota and posted a single notification to a shared channel — three steps, one fallback address for failures, and a named owner. The value was less in the minutes saved than in enquiries no longer sitting unassigned overnight.
05
Benefits
- Time returned on work that repeats, where the return compounds
- Fewer handover errors between systems and people
- Consistent response times, because the trigger does not depend on someone remembering
- A visible, explainable first success to build on
06
Limitations and risks
- Automating an unclear process embeds the confusion and makes it harder to see
- Automations built on one person's personal account break when that person leaves
- Silent failures are worse than manual work; error handling is not optional
- Platform pricing based on task volume can rise sharply as usage grows
07
Responsible AI and data considerations
Where an automation moves personal data between systems, it is a processing activity like any other: record what data moves, where it lands and how long it is kept.
- Use service accounts with least-privilege access rather than personal logins
- Avoid routing special-category data through third-party automation platforms without checking the processing terms
- Where an AI step drafts or classifies something, keep a named human review point before it reaches a client
08
Conclusion
The best first automation is boring, frequent and well documented. Ambition is better spent on the second one, once the team trusts the first.
Design automation that lasts
ATJ works vendor-neutrally to identify where automation pays back and to build it so your team can maintain it.
