The seven most common process automation mistakes

Process automation is one of the few investments whose benefit can be calculated in advance. Yet many attempts fail — rarely spectacularly, mostly quietly: the automation still runs but nobody trusts it; or it was switched off because it generated more questions than it saved work. The following seven mistakes explain most of those cases.

1. The disorder gets automated along with everything else

Automation does not make a bad process better, it makes it faster at being bad. If a job currently passes through four approvals, two of which nobody can justify any more, you end up automating two superfluous approvals — permanently, and with maintenance effort attached.

The countermeasure costs less than a week: while capturing the workflow, ask for every step what would happen if it disappeared. Surprisingly often the answer is "nothing". Only the cleaned-up workflow gets automated.

2. The wrong starting point

The workflow selected is frequently the one that irritates people most. That is understandable but rarely right. The most irritating workflow often has the most exceptions — and exceptions are the most expensive part of any automation.

Benefit comes from frequency times time spent. Effort comes from the number of special cases. The best entry point maximises the first and minimises the second.

In practice: a simple workflow running 300 times a month is a better start than a complicated one running twenty times — even if the latter gets more emotional attention.

3. No error handling

This is the mistake with the largest consequences. An automation that silently does nothing when something breaks is more dangerous than no automation at all: everyone relies on it, and nobody notices that no invoice has been forwarded for eleven days.

Every production automation therefore includes four components:

• Logging. What ran, when, and with what result?
• Notification. Errors go to a named person, not to a shared mailbox.
• Repeatability. A failed run can be restarted after correction.
• Fallback. A documented manual route in case the automation is down for longer.

4. Special cases surface only in production

Testing tends to use the model case: the fully completed order, the cleanly scanned invoice, the customer with complete master data. Daily reality looks different. An empty mandatory field, an umlaut in a file name, an amount in a foreign currency, a duplicated customer record — each of those decides whether the automation survives everyday use.

A short parallel run is effective: for two to four weeks the automation runs alongside real cases while the existing route continues. The differences between the two are the list of special cases — and it is the complete one.

5. Nobody is responsible

Automations are not furniture; they need care. Interfaces change, access keys expire, forms gain a field. If nobody is named, that only gets noticed when something breaks.

This does not require a new position, just a clear role: that person receives the error notifications, knows the documentation and knows who to call in. Ideally they were involved in the implementation — as a participant, not an observer.

6. The benefit is never measured

Without a baseline every assessment stays an opinion. And without figures the argument for the next automation is missing — which is why many companies stall after their first success.

The effort is small. Two to four weeks before the start, three values are recorded: number of runs, average handling time, number of corrections. The same values are measured again four weeks after go-live. That is enough to prove or disprove the effect.

7. Dependency on a single person or firm

The last mistake shows up late: the automation has been running for two years but nobody in the company knows how. The implementer is unreachable, the credentials sit in a private account, and the logic exists only as a click-path with no description.

Simple agreements made before the project starts prevent this: credentials run on company accounts, not on individuals. Documentation covers purpose, workflow, credentials and error handling. Names are meaningful. And the automation is built so that somebody else can take it over.

A short checklist before you start

• Has the workflow been cleaned up — or is disorder being automated along with it?
• Was the starting point chosen by frequency and exceptions rather than by irritation?
• Are logging, notification, retry and fallback provided for?
• Is a parallel run with real cases planned?
• Is there a named responsible person inside the company?
• Has the baseline been recorded?
• Do credentials run on company accounts, and does documentation exist?

Conclusion

None of these seven mistakes is technical, and avoiding them requires no special expertise. They occur because the unglamorous parts of an automation project — tidying up, measuring, documenting, assigning ownership — get less attention than the visible build. Take them seriously and you end up with more than a running automation: you end up with the basis for the second one.