Every discovery engagement produces two lists. The one everybody expects is what to automate. The one that earns its fee more often is what to leave alone.
That is an awkward thing for a business that gets paid to build automations to say, so it is worth being clear about why we say it. A build that saves less than it costs does not just fail to pay back. It adds a thing to maintain, a thing to document, a thing that breaks when a supplier changes a form and it spends the goodwill you needed for the next project. The cheapest automation is the one you correctly decided not to build.
Four tests catch most of them.
It does not run often enough
This is the big one and the arithmetic is not subtle.
A process that takes forty minutes and runs eleven times a year costs about seven hours annually. Automating it properly means understanding it, building it, testing it, documenting it, then maintaining it as the systems around it change. That will not come in under seven hours. It will not come in under seven hours in the second year either.
People routinely misjudge this because the forty minutes is painful and the pain is memorable. Frequency, not unpleasantness, is what makes automation pay. The quarterly task everyone dreads is usually a worse candidate than the two-minute task nobody notices doing thirty times a day.
It is about to change anyway
You are replacing the practice management system next year. The award is being restructured. The supplier is retiring the portal that half the process runs through.
Automating a process on its way out means building against an interface with a known expiry date. You will pay twice: once now, once when it moves.
The useful question is not whether the process is changing but whether the shape of it is. If the same information moves between the same parties in the same sequence and only the software underneath is being swapped, much of the work survives. If the sequence itself is being rethought, wait. You will build a better thing afterwards and you will build it once.
The exceptions are most of the volume
This is the one that quietly sinks projects, because it does not show up until you are committed.
The conversation goes: it is straightforward, you take the order, check stock, raise the invoice, book the freight. Then you sit with the person doing it. It is straightforward, except when the customer is on account terms, except when it is a partial shipment, except when it is going to New Zealand, except when it is one of the three customers with their own pricing, except when the item is drop-shipped.
Now count. If the exceptions are five per cent of volume you can automate the main path and route the rest to a person. That is a good outcome. If they are forty per cent you are not automating a process, you are building a rules engine for a business that has not decided its own rules.
Sometimes the right answer there is not software at all. It is a decision. Someone senior picking one way of doing it and removing four of the five exceptions is worth more than anything we could build around them.
A person is doing it for a reason
Some steps look like data entry and are not.
The staff member who eyeballs every invoice over a certain value before it goes out is not checking arithmetic. They are catching the job that got coded to the wrong client, the quantity that is off by a factor of ten, the thing that is technically correct and obviously wrong. That judgement rarely appears in a process map because the person doing it does not think of it as a step.
Automate the assembly around them. Keep the look.
What the second list is worth
A shortlist of eight things to automate is a proposal. A shortlist of four things to automate, with four explicitly ruled out and the reasoning attached, is a decision you can actually take to a board.
The second document is shorter, cheaper to act on and considerably harder to write. It is also the one clients come back and thank us for, usually about a year later.