In short
Automate a process only once it is stable, documented and high-frequency. In practice that means: fix or delete the process first, then automate the parts with clear rules and low exception rates, in this order — notifications and reminders, then data movement between systems, then rule-based decisions, then multi-step orchestration. Never automate a process whose rules change often, whose exceptions exceed roughly one in five cases, or where a wrong output is expensive and hard to detect.
Key takeaways
- Automation amplifies whatever it is applied to. Amplifying a broken process is worse than leaving it slow.
- Frequency times stability is the qualifying test. Rare or volatile processes fail both parts.
- Start with notifications, then data movement, then rules, then orchestration. Skipping ahead is how projects stall.
- Exception rate above roughly 20% means you are automating the exception-handling, which is the expensive part.
- Every automation needs a named owner, visible failure alerts, and a documented manual fallback.
Automation is an amplifier, not a fix
The most expensive automation projects are the ones applied to processes that should have been redesigned or deleted. The automation works exactly as specified, which is the problem: it now performs the wrong thing reliably, at volume, without the human friction that used to catch errors.
Three concrete versions of this, all common:
- A report is automatically generated and distributed weekly to eleven people. Nobody had checked whether anyone reads it. Now it is permanent, because deleting something automated feels like a bigger decision than deleting something manual.
- Data is synced automatically between two systems that should never both have held it. The divergence that a person used to notice and correct now propagates silently.
- An approval reminder fires every day until someone acts. The approval was never necessary; the automation has made an unnecessary step feel official.
Ask what happens if you delete this process before asking what happens if you automate it. The delete question is cheaper and it is answered correctly more often than people expect.
The order that works
Delete, then simplify, then document, then automate. Each step reduces the scope of the next. A process that survives deletion and simplification and is then documented is usually much smaller than it was, and automating the smaller version is faster, cheaper and far more likely to survive contact with reality.
The qualifying test: frequency times stability
Two properties determine whether a process has earned automation. Both are required.
Frequency
How often does it run? Automation has a fixed build cost and an ongoing maintenance cost, and both are recovered per execution. A process running twice a year almost never repays it. A process running forty times a week repays it quickly even if the build is imperfect.
Stability
How often do the rules change? A process whose logic shifts every quarter will spend its life being rebuilt. Automation locks in the current rules, so volatility converts a one-off build into a permanent maintenance obligation.
| Stable rules | Volatile rules | |
|---|---|---|
| High frequency | Automate. This is the whole target zone. | Fix the volatility first. Usually a missing policy decision, not a technical problem. |
| Low frequency | Document it well. Automation rarely repays here. | Leave it human. Trying to encode this wastes money twice. |
The exception rate
A third test, applied to candidates that pass the first two. What proportion of cases go down the standard path?
A practical ceiling. Once more than about one case in five is an exception, most of the build effort goes into exception handling — the hardest, most brittle part — and the automation delivers little of the benefit while carrying all of the maintenance.
When the exception rate is high, the productive move is nearly always to investigate why. Frequently the “exceptions” are three or four recurring variants that were never formally recognised as separate paths. Naming them turns one unautomatable process into three automatable ones.
The automation ladder, in order
Four rungs. Each builds capability and confidence for the next, and businesses that skip ahead usually stall.
Rung 1: notifications and reminders
The cheapest possible automation and the most underrated. Nothing is decided or moved — a human is simply told, at the right moment, that something needs attention.
- Alert when an item has been waiting longer than the agreed decision window
- Notify the next owner automatically at a handoff instead of relying on someone remembering
- Flag records missing required fields before they reach the step that needs them
Low risk, immediate benefit, and it removes a large share of the chasing that consumes time between steps.
Rung 2: data movement
Moving information between systems without retyping. Higher value, higher risk, and it requires the groundwork covered in the integration audit — specifically a declared system of record. Automating data movement without one spreads disagreement faster.
Rung 3: rule-based decisions
Letting the system decide, within explicit boundaries: auto-approving discounts within policy, routing enquiries by type, applying standard terms below a threshold. This is where automation starts returning real time, because it removes the queue at a decision step rather than just the labour at a doing step.
The prerequisite is a written rule that a person could apply consistently. If two experienced people would decide differently given the same inputs, the rule is not ready to be encoded — you have a policy gap, not an automation opportunity.
Rung 4: orchestration
Chaining multiple steps end to end, with branching and error handling. Genuinely valuable and considerably harder to maintain. Attempt it only where the earlier rungs are working and someone owns the result.
What to leave human on purpose
Some work should stay manual permanently, and saying so explicitly protects you from a second attempt at it every eighteen months.
Judgement under ambiguity. Where the right answer depends on context, relationship history or an unstated priority, encoding a rule produces confident wrong answers. Rules are appropriate where the recurring pattern is genuinely settled — not where a plausible-looking rule can be written.
Rare, high-consequence decisions. Low frequency fails the qualifying test anyway, and the cost of an automated error is highest precisely here. Document these thoroughly instead.
Anything where a wrong output is expensive and hard to detect. This is the critical asymmetry. Automating something that fails loudly is fine; you find out. Automating something that fails quietly — a subtly wrong figure, a slightly incorrect record — means the error accumulates undetected until it surfaces somewhere costly.
The first client interaction after something has gone wrong. A perfectly worded automated apology is worse than a slightly clumsy human one, and every recipient can tell the difference.
| Keep human when | Because |
|---|---|
| The rule cannot be written down | Encoding an unwritten rule encodes your guess at it |
| Errors are silent | You lose the human check without gaining a system check |
| The step exists to build trust | The step's value is that a person did it |
| The process changes every quarter | You will maintain it forever and never finish |
Running automation without accumulating liabilities
Automations become infrastructure very quickly, and unmanaged infrastructure becomes risk. Four requirements, none negotiable, all cheap if applied from the start.
1. A named owner. One person per automation, responsible for it working. Automations built by whoever had the idea and owned by nobody are the most common form of hidden key person risk in a modern small business.
2. Visible failure. Silent failure is the characteristic automation risk. It ran for six weeks, it stopped, nobody noticed, and now three weeks of records are wrong. Every automation needs failures routed somewhere a human actually looks, and a periodic check that it is still running at all — not just that it has not errored.
3. A documented manual fallback. For anything business-critical, write down how to perform the process by hand. You will need it during an outage or a vendor change, and you will need it at the worst possible moment.
4. An inventory. One list: what it does, which systems it touches, who owns it, what the fallback is, when it was last verified. Without this, a stack of thirty automations built over three years by five people becomes genuinely unmappable, and nobody can safely change anything.
Review on events
Automations break for external reasons — a vendor changes an API, a form field is renamed, a permission is revoked. Review the inventory whenever a system in it changes, and verify rather than assume.
What automation maturity actually looks like
Maturity is not the number of automations. Businesses with dozens of fragile, unowned automations are less mature than businesses with six reliable ones.
The markers worth aiming for:
- Every automation has an owner and a fallback, and both are written down where someone else could find them.
- Failures are noticed by the system, not by a customer. This is the single clearest dividing line between mature and immature automation.
- Automation follows documentation. Nothing is automated that has not first been written down, which means every automation has a human-readable description of what it should do.
- Retirement happens. Automations get switched off when the process changes. If nothing has ever been retired, the inventory is accumulating liabilities.
- The decision to leave something manual gets recorded. With the reason, so it is not re-argued annually.
The goal is not maximum automation. It is that nobody is doing repetitive, rule-following work that a system could do reliably — and that everything a system does, someone owns.
The Mayim Ops assessment scores automation maturity as one of ten dimensions, and reports which of your processes are genuinely ready for automation against which need documenting or simplifying first.
Frequently asked questions
What should a small business automate first?
Notifications and reminders. They are the cheapest to build, carry almost no risk because nothing is decided or moved automatically, and they remove a large share of the chasing that happens between workflow steps. Data movement between systems comes second, once you have declared a system of record for each data type.
When is a process ready to be automated?
When it is high-frequency, stable, documented, and has an exception rate below roughly one in five cases. Frequency determines whether the build cost is recovered, stability determines whether you will spend its life rebuilding it, and the exception rate determines whether most of your effort goes into handling edge cases rather than delivering benefit.
Why do automation projects fail?
Most commonly because the underlying process was never fixed, so automation amplifies a broken workflow rather than improving it. The other frequent causes are silent failure with no alerting, no named owner, and no documented manual fallback for when the automation or the vendor stops working.
What should never be automated?
Judgement under genuine ambiguity, rare high-consequence decisions, anything where a wrong output is expensive and hard to detect, and interactions whose value comes specifically from a person having done them, such as the first contact after something has gone wrong. Record these decisions with the reason so they are not revisited every year.
How many automations should a business have?
The count is not the measure. Six reliable, owned automations with documented fallbacks represent more maturity than thirty fragile ones nobody can map. Better indicators are whether failures are detected by the system rather than by a customer, and whether automations are ever retired when the underlying process changes.