Processes everybody complains about are often exhausting precisely because they demand constant case-by-case judgement. Every complaint is different, every exception has its reason, every customer request needs someone to think. That is exactly what cannot be turned into rules — and software is nothing but rules written down.

What pays off is the quiet process: the one somebody runs forty times a month, always the same way, without thinking about it. It annoys nobody because everyone has got used to it. It still costs hours every week.

The first automation also decides the second. If it fails, you will not get budget for anything like it for two years. So you pick the first candidate by likelihood of success, not by how much it hurts.

A good first candidate is frequent, rule-based, has one clear owner and produces a result you can check. If one of the four is missing, move to the next.

Walk through your processes with these four questions. A candidate that meets all four is rare and almost always a hit.

• Frequency. How many times a month does it run? Below ten, the setup rarely pays for itself. The benefit comes from repetition, not from complexity.
• Fixed rules rather than individual cases. Can you explain the process to a new colleague in one sentence per step without saying “it depends”? Then it is suitable. Every “it depends” becomes an exception somebody handles by hand later.
• One clear owner. There has to be a person allowed to say what the process will look like in future. If three departments share it, the project turns into a series of alignment meetings.
• A result you can check. At the end there must be something you can look at and tell whether it is right: a document, a record, an approval. Processes whose output is a matter of taste do not get automated — at best they get supported.

Approvals and sign-offs. Leave requests, purchase orders, invoice approvals above a threshold: frequent, rule-based, with a clear result. In many companies this runs over email, and it becomes a problem exactly where nobody can reconstruct who approved what and when.

Recurring documentation. Inspection records, defect reports, maintenance evidence, handovers. Today often paper plus phone photos plus a spreadsheet. Digitising this rarely saves the capture step — it saves the hunting around afterwards.

Data moving between two systems via a spreadsheet. Somebody exports from system A, re-sorts it in Excel and imports it into system B. That is the least conspicuous and most rewarding candidate there is: high frequency, fixed rules, checkable result — and usually done in days rather than months.

Three situations where we advise against touching it — and we advise against it more often than people expect:

• It runs four times a year and costs an afternoon. Then it stays on the spreadsheet. The setup, the training and the upkeep will cost you more than the afternoons you save.
• The process is currently changing. New responsibilities, new requirements, a reorganisation under way: settle it first. Software that captures an interim state gets built twice.
• Nobody owns it. Without a person allowed to decide, every detail becomes a meeting. That is not a technical problem, and no tool solves it.

Writing the process down — who does what, how often, with which data, and where the decisions happen — is the cheapest part of the whole undertaking and the only one you can do without a supplier. One page is enough.

That one page usually answers the four questions above by itself. And it prevents the most common expensive mistake: buying a tool before anyone knows the process it is supposed to replace.