Automation projects usually begin with a tool. Somebody sees a demonstration, the business buys it, and the search begins for processes to point it at.
That order produces a predictable outcome: the processes that get automated are the ones that were easiest to automate, not the ones where automation was worth most. Some of them should have been simplified first. A few should have been eliminated.
The tool question is genuinely secondary. What decides whether automation pays is which processes are selected and whether anyone would notice when one of them stops.
Automate, simplify, or eliminate
Every candidate process falls into one of three categories, and getting this wrong is the most expensive error available because the work is done correctly on the wrong target.
| If the process... | Then | Because |
|---|---|---|
| Exists only to reconcile two systems that disagree | Fix the integration | The reconciliation is a symptom |
| Exists only because a form is badly designed | Fix the form | Automating rework preserves the rework |
| Produces a report nobody reads | Eliminate it | Automating it makes it cheaper to keep not reading |
| Has fourteen steps because of past incidents | Simplify, then automate | Automating the accumulation preserves it |
| Is genuinely necessary, repetitive, rule-based | Automate | This is the actual case |
| Requires judgement on most instances | Do not automate | Rules that cover 60% produce exceptions nobody handles |
The first row is the most common and the least often recognised. A great deal of manual work in growing businesses exists purely to make two systems agree with each other — copying figures, checking totals, correcting records that arrived wrong. Automating the copying leaves the underlying disagreement in place and makes it faster to propagate.
Choosing what is actually worth it
Where automation is the right category, not every process is worth the effort. Four factors decide it, and only the first is usually considered.
- Frequency times duration. A ten-minute task done daily is worth more than a two-hour task done quarterly, and the quarterly one feels more painful.
- Error rate and error cost. A task that is quick but occasionally wrong may be worth automating for correctness rather than for time.
- Delay cost. Work that waits for a person until Monday morning may cost more in delay than in labour, and automation removes the waiting rather than the effort.
- Stability. A process that changes every few months will need the automation rebuilt every few months, which frequently exceeds the saving.
The last is the one that turns positive business cases negative. An automation that has to be rewritten each time a supplier changes a form or a report layout can consume more maintenance than the manual work it replaced, and nobody revisits the original justification.
The failure modes that decide the outcome
Silent failure
This is the defining risk of automation and it is specific. A person performing a task notices when the input looks wrong, when a system is down, when the numbers do not make sense. An automation does not notice; it either fails or, worse, produces confidently wrong output.
Worse still, the common failure is not an error. It is stopping. A workflow that errors sends an error. A workflow that never triggers sends nothing, and nothing looks exactly like everything working.
- Alert on absence — nothing processed in the expected window — not only on errors.
- Route failures to a person, not to a log file that nobody reads.
- Make partial failure visible. Ninety records processed and ten failed must not report success.
- Design for reruns. An automation that cannot safely be run twice makes recovery from any failure a manual reconciliation.
Brittleness
Automations that depend on things not designed as interfaces break whenever those things change. Screen scraping, parsing a report layout, reading a specific spreadsheet cell, or relying on an email arriving with an exact subject line all work until someone makes an ordinary change elsewhere.
Where a real interface exists, use it. Where none exists, expect maintenance and factor it into the business case rather than discovering it later.
Orphaning
Automations are frequently built by one capable person and understood by nobody else. When that person leaves, the business is running processes it cannot modify, cannot debug, and in some cases cannot locate.
- Maintain a register: what exists, what it does, what it touches, who owns it.
- Keep definitions in version control, not only in a tool's interface.
- Store credentials in a secret store rather than embedded in the workflow.
- Review annually, and delete what is no longer needed. Automations outlive their purpose silently.
Doing it in a sensible order
- 1
Write the process down as it actually runs
Including the exceptions and the workarounds. The exceptions are usually where the difficulty is, and they are what a demonstration never covers.
- 2
Categorise it — automate, simplify, or eliminate
Honestly. This step saves more than any other and is the one most often skipped.
- 3
Simplify before automating
Remove the steps that exist because of a past incident that no longer applies. Automating an accumulated process preserves the accumulation permanently.
- 4
Decide what happens when it fails
Before building. Who is told, what the fallback is, and whether the process can safely be rerun.
- 5
Build the smallest useful version
One workflow, in production, monitored. A large automation programme built before anything runs is a large amount of work validated by nothing.
- 6
Instrument it and watch it for a month
Both that it runs and that its output is correct. Correct-looking output from a broken automation is the failure that persists longest.
- 7
Document and hand it over
At the point of building, while it is understood, rather than when the person who built it is leaving.
On tooling, briefly
The tool matters far less than the selection and the monitoring, but two properties are worth insisting on.
First, the workflow definition should be exportable and version-controllable. A definition that exists only inside a hosted interface is a definition you cannot review, cannot diff, and cannot restore.
Second, error handling should be a first-class feature rather than something bolted on. If the tool makes it awkward to route a failure to a person, failures will end up in a log, and the log will not be read.
Where the process is genuinely complex enough to need modelling before building, BPMN is the established notation and is a published standard rather than a vendor format. Most business automations do not need it; the ones spanning several departments and many decision points benefit.
What should be automated first?
Whichever process scores highest on frequency multiplied by duration, error cost, and delay cost — provided it is stable enough that the automation will not need rebuilding every few months. Instability is what turns positive business cases negative: an automation rewritten each time a supplier changes a form can consume more maintenance than the manual work it replaced, and nobody revisits the original justification.
Should a bad process be automated?
No. Automating a bad process produces the same bad outcome faster and with less opportunity for a human to notice something is wrong. Processes that exist only to reconcile two systems that disagree should have the integration fixed instead; processes with many steps accumulated from past incidents should be simplified first, because automating the accumulation preserves it permanently.
What is the main risk with business process automation?
Silent failure. A person performing a task notices when input looks wrong or a system is down; an automation does not, and either fails or produces confidently wrong output. The common failure is not an error but stopping, and a workflow that never triggers sends nothing — which is indistinguishable from everything working. Alerting on absence rather than only on errors is the control that addresses it.
Why do automations break so often?
Because many depend on things that were never designed as interfaces — screen scraping, parsing a report layout, reading a specific spreadsheet cell, or an email arriving with an exact subject line. All work until someone makes an ordinary change elsewhere. Where a real interface exists it should be used; where none exists, the maintenance should be priced into the business case rather than discovered afterwards.
What happens when the person who built the automations leaves?
In most businesses, the automations become processes nobody can modify, debug, or in some cases locate. Preventing that requires a register of what exists and what each touches, definitions kept in version control rather than only inside a tool's interface, credentials in a secret store rather than embedded in workflows, and an annual review that deletes what is no longer needed — since automations outlive their purpose silently.
Sources and further reading
- n8n workflow automation for modern businesses— the implementation layer, and silent failure in practice
- AI integration without replacing existing systems— where judgement-heavy processes fit, and where they do not
- API integration for modern businesses— the real interfaces that make automations durable
- CRM integration best practices— fixing the disagreement that reconciliation work exists to paper over
- Infrastructure monitoring that works— alerting on absence, which is the control this depends on
- Secrets management for business systems— credentials out of workflow definitions
- BPMN 2.0 — Object Management Group— the published process modelling standard, for the cases that genuinely need modelling
Services This Relates To
Written by KYCONNECTS Engineering. Client names are withheld under confidentiality.