The question is almost never whether a process can be automated. Nearly everything can. The question is whether doing so will change any number you care about.
A process is worth automating when it runs often, takes real time, follows rules you can state out loud, has an owner, has a measurable outcome and produces something a person will actually use.
Miss one and you can usually still proceed. Miss three and you will build something that works and changes nothing.
Frequency multiplies everything. A task taking twenty minutes twice a year is not worth a system, however irritating. The same twenty minutes twice a day is thirty working days a year for one person.
Count the repetitions before anything else. It is the cheapest test and it removes a surprising share of candidates.
Ask how long a task takes and you will be told how long it feels. The two differ, usually in both directions: the annoying five minute task is genuinely five minutes, and the invisible one nobody mentions is forty.
Measure it once, properly, before deciding. Anything else is automating a story.
If the person doing the work can explain what they decide and why, a system can be built to do it. If the explanation ends in "you just get a feel for it", something real is happening that has not been articulated yet, and the honest move is to sit with them until it is or to leave that step with a person.
This is the condition most often waved through, and it is the one that produces systems that are right most of the time in ways nobody can predict.
A named person, not a department. Processes change, sources change format, and edge cases arrive. Without an owner the system quietly diverges from reality and then people stop trusting it, which is worse than not having built it.
If nobody will own it, that is not a reason to build it better. It is a reason not to build it.
Not an activity, an outcome. Hours returned, errors avoided, days taken out of a cycle, revenue attributable. If the only thing you can measure is that the system ran, you will never know whether it was worth it, and neither will anyone deciding on the next one.
Write the number down before you build, along with what it is today. Nobody ever regrets having the baseline.
The most common failure is not technical. It is a system producing a correct output into a screen nobody opens, or a report nobody reads, or a queue nobody works.
Ask where the output lands, who sees it and what they do next. If the answer is vague, fix that before writing any code, because no amount of engineering will fix it afterwards.
| Conditions met | What to do |
|---|---|
| All six | Build it. This is the straightforward case and it is rarer than people expect |
| Five | Build it, and fix the missing one first if it is the owner or the audience |
| Four | Proceed carefully, with a smaller version, and be willing to stop |
| Three or fewer | Do not build. Either fix the conditions or spend the money elsewhere |
Conditions four and six, the owner and the audience, are not questions about the process at all. They are questions about your organisation, and they are the ones that decide whether anything survives the first quarter.
They are also the two nobody asks in a sales meeting, because the answers are awkward and the awkwardness belongs to the buyer. Ask them of yourself before somebody sells you anything.
Often the right answer is to simplify or stop the process rather than automate it. A step that exists because of a system that was replaced four years ago does not need a machine to do it faster. It needs deleting.
That is not a satisfying outcome to sell, which is precisely why it is worth checking for before anyone is paid to build.