BUILD / AI & Software
The best automation is the ritual that disappears
Most automation projects start by asking how to make a repetitive task faster. A better question is whether that task should still exist at all.
Most automation projects start by asking how to make a repetitive task faster. A better question is whether that task should still exist at all.
In short
01 / The point
The best result is surprisingly unglamorous
No new dashboard. No extra workflow. No “automation control centre” glowing ominously in a browser tab you now have to remember exists.
Something that used to happen every Tuesday at 3pm just… stops happening.
That is the point.
02 / Rituals
We have accidentally turned work into rituals
Most workplaces have them.
Someone downloads a CSV.
Someone else copies three columns into another spreadsheet.
A Slack message appears:
Numbers updated 👍
Another person checks the numbers.
Then somebody moves a card to Done.
None of these individual steps are particularly difficult. Together, they have become a ritual.
And rituals are dangerous because repetition makes them look necessary.
After enough Tuesdays, nobody asks why Sarah exports the report, why Ben checks it, or why the spreadsheet called FINAL_REPORT_v4_USE_THIS_ONE.xlsx is apparently part of the organisation’s critical infrastructure.
It is simply what happens on Tuesday.
This is where automation gets interesting. Because the obvious approach is to automate Sarah downloading the CSV.
The better approach is to ask:
Why is Sarah downloading it in the first place?
03 / Reproduction
Automating a bad process creates a faster bad process
There is a familiar temptation when building internal tools:
- Find the repetitive steps.
- Automate every step.
- Add a dashboard so people can monitor the automated steps.
- Add notifications from the dashboard.
- Hold a meeting because the notifications are confusing.
We have somehow automated our way back to the meeting.
The problem is that software is very good at reproducing processes exactly as they already exist. That does not mean those processes deserve to survive.
If a workflow currently has nine steps, the first design question should not be how do we automate nine steps? It should be why are there nine steps?
Sometimes the correct automated workflow has three.
Sometimes it has one.
Sometimes the entire thing can disappear.
04 / Subtraction
Remove steps before automating them
Imagine a team manually checks new customer accounts every morning. The process looks like this:
Open dashboard → filter yesterday’s accounts → export data → compare against another system → identify unusual records → message operations → mark the spreadsheet as reviewed.
You could automate all of that.
Or you could notice that the team only cares about unusual records. That changes the problem completely.
The system does not need to reproduce the morning review. It needs to detect the conditions that matter and surface the exceptions.
The new workflow becomes:
Something unusual happens → the right person is notified.
Seven steps become one event. The morning ritual disappears.
The distinction
05 / Candidates
What should you automate first?
Look for recurring work where the normal outcome requires no human judgement. Good candidates often sound like:
- “Every morning I check whether…”
- “Whenever this happens, I copy…”
- “At the end of the week we update…”
- “Before sending this, someone confirms…”
- “We keep this spreadsheet so everyone knows…”
That language is useful. It exposes the ritual. Then ask:
What information are we actually trying to learn?
What decision is the human actually making?
What would happen if everything were normal?
If the answer is nothing, there is a good chance the workflow can become exception-driven.
06 / Reality
Design for exceptions, not imaginary perfection
This is where many automations become annoying.
The happy path is immaculate. The weird path has apparently been left for Future Us, a highly competent individual who never arrives.
Imagine automatically processing invoices. Most might be straightforward:
- supplier recognised,
- amount within expected range,
- purchase order matches,
- payment details unchanged.
Great. Automate them.
But eventually somebody submits an invoice with:
- a changed bank account,
- a duplicate invoice number,
- a suspiciously enormous amount,
- a missing purchase order,
- or a PDF photographed sideways on what appears to be a Nokia from 2006.
The quality of the automation is not determined by how elegantly it handles the first 900 invoices. It is determined by what happens to invoice 901.
If we are not sure
That might mean:
- stop and ask for approval,
- route the item to the right person,
- explain exactly what triggered the exception,
- preserve the original information,
- make the action reversible,
- or do nothing until someone checks it.
The goal is not to eliminate humans. It is to stop spending human attention on cases where humans add nothing. That leaves more attention for the ones where they do.
07 / Attention
The exception inbox is often better than the automation dashboard
There is a subtle product-design difference here.
A traditional automation dashboard says: here are all the things the system has done.
An exception-based system says: here are the three things that need you.
The second is usually much closer to how people actually want to work.
Quiet trust
Does every automated process need a dashboard?
No. A dashboard is useful when people genuinely need oversight, investigation or control. It should not exist merely because an automation exists.
Sometimes you need audit history, performance monitoring, approvals, error investigation, compliance records, or manual controls. Those are real needs.
But there is a difference between having visibility when required and creating a new place somebody must check every day.
If your automation removes a spreadsheet but creates a dashboard that someone now has to inspect every morning, the spreadsheet may have reincarnated. It just has rounded corners now.
08 / Deletion
A better mental model: automation as deletion
People often describe automation as a machine doing work for you. That is useful, but incomplete.
A stronger mental model is: automation deletes obligations.
It deletes remembering, checking, copying, chasing, reconciling, reporting, updating, and wondering whether somebody else remembered to do the thing.
That last one matters more than it sounds. A surprising amount of work is not work at all. It is coordination about whether work happened.
When a system can reliably perform an action, record what happened and surface only meaningful problems, an entire layer of organisational ceremony can disappear with it. That is more valuable than saving six clicks.
The disappearing-calendar test
Better answers sound like:
- Nobody needs to compile the Friday report anymore.
- Operations no longer checks every transaction. They only investigate unusual ones.
- Customers automatically receive the correct information, and the team only gets involved when something cannot be resolved.
That is automation doing its actual job.
09 / Method
How do you automate a workflow without making it worse?
Start with subtraction. Before building anything:
Remove unnecessary steps.
Ask why each step exists and what would break if it disappeared.
Identify the actual decision.
Separate information gathering from human judgement.
Automate the normal path.
Routine, predictable work is usually the safest place to begin.
Define exceptions before launch.
Decide what happens when information is missing, contradictory, risky or unusual.
Give humans context, not homework.
When something needs attention, explain what happened and why it was surfaced.
Keep important actions observable and reversible.
Especially when automation can change customer data, financial records, permissions or external systems.
Measure what disappeared.
Not just how many automated actions ran. Ask whether people now spend less time checking, chasing, copying and remembering. That is the metric that matters.
The slightly uncomfortable part
Removing rituals can expose an awkward truth. Sometimes a process exists partly because the process itself makes us feel in control.
The spreadsheet feels reassuring. The weekly review feels responsible. The status meeting feels like visibility. The dashboard feels like governance. And sometimes those things genuinely are useful.
But sometimes we are watching work happen because we do not yet trust the system enough to stop watching it. That means good automation is partly a software problem and partly a trust-design problem.
People need to know:
- what the system will do,
- what it will never do,
- when it will ask for help,
- how they can inspect what happened,
- and how mistakes can be corrected.
Once that trust exists, something interesting happens. People stop checking. The ritual dies. Nobody misses it.
10 / Memory
What to remember
The most useful automation is rarely the one with the most workflows, integrations or blinking status indicators. It is the one that makes a piece of repetitive work quietly unnecessary.
So before automating a process, ask:
What can we remove?
Then:
What should happen when reality refuses to follow the happy path?
Build those two things well and automation starts feeling less like another system people have to operate. It starts feeling like something they no longer have to think about.
Which, for a surprising amount of workplace software, would be a fairly revolutionary feature.