The processes you should not automate

Automation demand rarely arrives as a question. It arrives as a list, sent by a business department, with the note "here is what we would like to automate". A significant part of that list should not be, and saying so early is a service.

1. Processes that are too infrequent

A process run once a month for twenty minutes amounts to four hours a year. No development, however simple, is paid back by four annual hours, and it will need maintaining.

The practical threshold sits around two runs per week, or a high unit volume.

2. Processes whose rules change every quarter

Every rule change is another development. On a process whose business logic evolves with each sales campaign or regulatory update, maintenance cost quickly exceeds the gain.

The exception: if the rules change but their structure is stable, externalising the parameters into a table the business can edit solves the problem. That is not always possible, and it must be checked before committing.

3. Processes that do not really exist

Sometimes no two people do the same thing the same way. Each has their method, their checks, their shortcuts. That is not a process, it is a practice.

Automating means freezing one version, and therefore arbitrating between practices. That harmonisation work is legitimate and useful, but it is an organisational project, not an automation project. Confusing the two guarantees both fail.

4. Processes that would bypass an internal control

Some manual processes include a human verification step that exists precisely because it must be human: approving an amount, checking segregation of duties, taking a decision that carries liability.

Automating that step is sometimes technically trivial and always problematic. The subject must go to internal control before any development, not after an audit.

5. Processes nobody can explain the reason for

"We have always done it this way" is the most frequent and most worrying answer. A process whose purpose is no longer understood is an excellent candidate for deletion, not automation.

Automating a pointless process makes it permanent: it no longer costs enough for anyone to question it, and it will still be running in ten years.

6. Processes at end of life

If the target application is due for replacement in eighteen months, a robot built today will be thrown away before it pays back. That information is rarely in the initial request: you have to seek it from the IT department, which knows the application roadmap.

What a well-documented refusal produces

A one-page note per rejected process, explaining the criterion not met and the associated figure. That document then circulates internally and is used to arbitrate later requests without a new study.

It is often the most reused deliverable of an automation assignment, and paradoxically the one that never appears in commercial proposals.