What should not be automated?
Do not automate anything that runs rarely, anything still changing shape, anything requiring genuine judgement, or anything where being wrong is expensive and the automation cannot tell when it is wrong. Also do not automate a process that should simply be deleted — automating waste makes it permanent and faster.
The most reliable warning sign is that nobody can write down the rules. If the person who does the work cannot explain when they do X instead of Y, the process is not ready. Document it first; automate it later, if at all.
Processes that should be deleted, not automated
The most valuable finding in any audit, and the one clients least expect to pay for.
Every business accumulates work that exists for reasons that have expired. A weekly report nobody opens, produced because a director asked for it in 2021. An approval step that has never once resulted in a rejection. A spreadsheet maintained in parallel with the system that now holds the same data. A form field nobody has read since it was added.
Automating these is worse than leaving them alone, for a specific reason: automation makes them permanent. A manual process that wastes an hour a week is visible, and someone eventually questions it. An automated one is invisible, costs nothing obvious to run, and will still be running in five years — along with the maintenance burden of keeping it working.
Before asking "can we automate this," ask "what happens if we simply stop doing it?" Surprisingly often the answer is: nothing.
The test: turn it off for a month and see who complains. If nobody does, you have your answer, and you have saved a five-figure build.
Work that needs judgement
Not "work that is complicated" — complicated is fine, complicated is just more rules. Work where the right answer genuinely depends on context that is not written down anywhere.
- Deciding whether to make an exception. A good customer asks for something outside the terms. Whether to say yes depends on the relationship, the account's history, what else is in flight, and what precedent it sets.
- Pricing that is not a formula. If your pricing genuinely reflects a read of the client's situation and your appetite for the work, encoding it flattens exactly the thing that makes it work.
- Hiring assessments. Automate the scheduling, the acknowledgements, the offer paperwork. Do not automate the judgement of whether someone is right for the role.
- Anything discretionary about people. Performance, promotion, discipline, redundancy.
- Escalation decisions. Whether an unhappy customer needs a refund, a call, or a manager is a judgement about the specific person and relationship.
A useful distinction: automate the administration around a judgement, never the judgement. Gather the information, present it clearly, route it to the right person, record what they decided, and act on it automatically afterwards. The human keeps the decision; the machine removes everything else.
Anything still changing
If the process has changed twice in the last quarter, it will change again during the build.
This is common in growing businesses and it is not a failure — it means you are still working out how you want to operate. But automating an unsettled process means encoding a shape you are about to abandon, and then paying again to change it.
The exception worth noting: sometimes a process keeps changing because it is badly designed, and the discipline of writing it down for automation is what forces it to settle. In that case the audit is valuable even though the build should wait. That is a legitimate outcome and a good use of the money.
Low-frequency work
Frequency is what turns a small per-run saving into something worth paying for. The arithmetic is unforgiving.
| Frequency | 30 min saved per run | Annual value at $45/hr | Payback on a $10,000 build |
|---|---|---|---|
| Daily | ~11 hrs/month | ~$5,900 | ~20 months |
| Weekly | ~2 hrs/month | ~$1,170 | ~8.5 years |
| Monthly | 0.5 hrs/month | ~$270 | Never, realistically |
| Quarterly | ~0.17 hrs/month | ~$90 | Not worth discussing |
A quarterly board pack that takes two hours is eight hours a year. No build pays that back. The right answer for low-frequency work is usually a good template and a checklist, which costs an afternoon.
The exception is when frequency is low but the cost of an error is very high — a regulatory filing, a payroll run. There you are buying accuracy and auditability, not time, and the arithmetic is different.
High stakes with no error signal
This is the subtlest category and the one that causes real damage.
Some tasks are high-consequence and produce no signal when they go wrong. Nothing errors, nothing looks unusual, and the mistake surfaces weeks later through an audit or a complaint. Financial coding, regulatory classification and data deletion all have this shape.
These can be automated, but only with genuine verification built in: cross-checks against a second source, reconciliation that would catch a discrepancy, and a human review step on anything unusual. If that verification cannot be built, the task should stay manual regardless of how repetitive it looks.
"If this automation started doing the wrong thing today, how would we find out, and how long would it take?" If the honest answer is "an audit, in about six months," do not automate it without independent verification. See what happens when an automation breaks.
Where the human contact is the point
Some interactions carry value precisely because a person chose to make them. Automating them does not reduce that value to zero — it makes it negative, because the recipient can tell.
- Apologies. An automated apology reads as an insult. If something went wrong enough to warrant one, a person should send it.
- Sensitive news. Cancellations, price rises, service withdrawal, anything with employment consequences.
- Relationship check-ins. An automated "just thinking of you" is transparently not thinking of anyone.
- High-value sales conversations. Automate the research and the scheduling. Do not automate the conversation.
- Recognition. Automated congratulations are worse than silence.
The workable pattern is draft-and-send rather than generate-and-fire: the system prepares the message, gathers the context, and puts it in front of a person who reads it, edits it, and chooses to send it. The human intent is preserved; the ten minutes of assembly is not.
The better answer is usually partial
Almost nothing in this article means "leave the whole process alone." It means the boundary is in a different place than people first assume.
Take handling a customer complaint. Automate: logging it, categorising it, pulling the account history, checking the order record, drafting a first response, setting a follow-up reminder, and updating the CRM afterwards. Keep human: reading it, deciding what to offer, and sending the reply.
That removes perhaps 70% of the elapsed time while keeping 100% of the judgement. It is a less impressive claim than "fully automated complaint handling," and it is the version that actually works.
When we run an audit, "do not automate this" is a normal and expected finding, written into the report with the reasoning. Some audits conclude that a process should be simplified or dropped rather than built. Those are good outcomes, not failed sales.
Want an honest read on your process?
We will tell you if the answer is "do not automate this." It happens more than you would expect.