How to tell when a process is actually ready to automate

Most automation projects don't fail because the tooling was wrong. They fail because the process underneath it wasn't actually ready to be automated — it just looked ready from the outside, because someone had been doing it well enough that nobody noticed how much judgment was baked into each step. Before we build anything, we run a process through a few plain checks. Most of them have nothing to do with software.

Ask how many different ways it's currently done

If you ask three people who run the same process and get three different answers, that's not a workflow yet — it's a set of personal habits that happen to produce similar results. Automating it locks in whichever version you encode, and if that version skips a step one person always does out of habit, you won't find out until something breaks downstream. The fix isn't to automate around the inconsistency; it's to get the team to agree on one version first, even if that just means writing down what already works and cutting what doesn't.

Check what share of cases are actually exceptions

Every process has a happy path and a pile of edge cases, and the ratio between them tells you more than the volume does. A process that's the same ten steps 95% of the time is a good automation candidate with a clear handoff for the rest. A process where a third of cases need a judgment call — a discount, an unusual request, a customer who doesn't fit the template — isn't ready for full automation yet, no matter how much volume it has. Those need a narrower first version: automate the clear majority, route everything else to a person, and only widen the automated slice once you've seen enough exceptions to know what they actually look like.

See if anyone can explain it without opening the software

A real test of whether a process is documented enough to automate: ask the person who owns it to explain it out loud, away from their screen, start to finish. If the answer includes "well, it depends" more than once without a clear rule attached, that's not a documentation gap to paper over — it's a sign the process itself hasn't been pinned down yet. We'd rather spend an extra hour in that conversation before writing a single workflow step than discover the gap after it's live and already wrong for a week.

Know what a mistake actually costs before it runs unattended

Not every automation needs the same level of supervision, and the deciding factor is what happens when it's wrong. A report that's late by an hour is a non-event. A reply sent to the wrong customer, or a record updated with the wrong value, is not. We scope the first few runs of anything new to stay supervised — a person reviewing before it acts, not after — until we've seen it handle enough real cases to trust it unattended on the ones that are actually low-stakes.

None of this is a reason to wait indefinitely. Most processes get more consistent, not less, once you start asking these questions, and the act of checking often fixes half the problem before any automation touches it. The point isn't to find reasons not to build — it's to build the right first version instead of a convincing-looking one that breaks on the first case nobody thought to ask about.