How My Team and I Decide What Actually Gets Automated in a Business

The obvious way to pick automation candidates is to look for repetition — anything that happens often, automate it. That instinct gets a surprising number of calls wrong, in both directions: some repetitive tasks are poor automation candidates, and some tasks that don't look repetitive on the surface turn out to be excellent ones. My team and I use a different test before recommending anything, and it has produced a meaningfully different, more accurate list every time it's been applied.

The appeal of the obvious test is its simplicity — frequency is easy to measure, easy to rank, and easy to explain in a single sentence. That simplicity is exactly what makes it unreliable, because frequency alone says nothing about whether the thing happening frequently is actually the same decision repeated, or a different decision disguised as the same task.

Why "it happens often" isn't the right test on its own

Something can happen constantly and still require a different judgment call every single time — in which case automating it just produces the same answer regardless of which situation actually called for a different one.

A task can occur fifty times a week and still require genuinely different handling each time, if what varies between instances is the judgment required, not just the surface mechanics. Automating a task like that doesn't save time — it produces a uniform answer applied to situations that actually needed to be told apart, which tends to create more cleanup work than it saves, because someone now has to catch and correct the cases where the uniform answer was wrong for that specific instance.

The actual question my team and I ask instead

The real test isn't frequency. It's whether the same input reliably deserves the same output — and if the answer is yes, frequency just determines how much time compressing it is worth.

The question that actually predicts a good automation candidate is: does the same input reliably deserve the same output, regardless of who's handling it or when. If the answer is genuinely yes, frequency becomes a multiplier on how much time is worth saving by compressing it. If the answer is no — if two people would reasonably handle the same input differently based on context — frequency doesn't matter, because automating it just locks in one answer where several were legitimately correct, and the business loses the flexibility that correctness required.

A concrete pair of examples that illustrate the difference

"Send a reminder three days before an appointment" passes the test easily. "Decide how to respond to a customer complaint" usually doesn't, even though both happen just as often.

Sending an appointment reminder three days in advance happens constantly and passes the test cleanly — the same input (an upcoming appointment) reliably deserves the same output (a reminder, sent on the same schedule, worded the same way) every single time. Responding to a customer complaint also happens constantly, but it fails the same test — two complaints that look superficially similar can call for very different responses depending on the customer's history, the severity of the issue, and context a template can't capture. Both tasks happen often. Only one of them is a strong automation candidate, and frequency alone would never have revealed which.

Why this test catches things the obvious approach misses

Some tasks that look judgment-heavy on the surface turn out to have a consistent, learnable pattern underneath — and some tasks that look purely mechanical turn out to hide real judgment once you look closely.

Applying this test consistently turns up surprises in both directions. Some tasks that feel like they require a person's judgment — because they're described in judgment-heavy language, like "handling a client concern" — turn out to follow a genuinely consistent pattern once examined closely. Other tasks that look purely mechanical on the surface turn out to hide a real judgment call buried inside them that was easy to miss at a glance, such as a "simple" data-entry step that actually requires deciding which of several overlapping categories a borderline case belongs to.

Why running this test requires actually watching the work, not just describing it

A task's name rarely reveals whether it passes this test — the only reliable way to know is watching several real instances and checking whether the outputs were actually consistent given consistent inputs.

Because a task's label is a poor guide to its actual shape, running this test properly requires observing several real instances of the task being done and checking, honestly, whether the output varied in ways that genuinely tracked differences in the input, or whether it varied simply because different people handled it slightly differently despite facing essentially the same situation. That observation step takes real time, which is part of why it gets skipped in favor of the faster, less reliable frequency-based shortcut.

What this means for how a business should actually prioritize

The right starting list isn't "everything repetitive." It's everything where the same input reliably deserves the same output — ranked by how much volume is sitting behind it.

Rather than starting from "what happens a lot," the more reliable starting point is "where does the same input reliably deserve the same output," then ranking that list by volume. That ordering tends to produce a meaningfully different — and more accurate — automation roadmap than simply automating whatever looks repetitive from a distance, and it avoids both failure modes: automating a task that actually needed judgment, and overlooking a task that looked judgment-heavy but wasn't.