The Question That Gets Skipped

Most conversations about automation start with "can this be automated," which is almost always yes. Nearly any repeated task can be scripted. The more useful question, and the one that gets skipped far more often, is whether it should be - and what happens the first time the task doesn't fit the pattern the automation was built around.

A repeated task and a rule-based task aren't the same thing. Something can happen every day and still require a judgment call every single time.

Where the Exceptions Actually Live

The tasks worth automating tend to share a trait: the correct output can be fully defined in advance, for every input that will ever show up. A confirmation email after an order. A file moved to the right folder based on its type. The rule doesn't change based on context nobody wrote down.

The tasks worth leaving alone tend to share the opposite trait: the "correct" answer depends on something that isn't fully captured in the data the automation would see - a customer's tone in a complaint, a judgment call about whether an unusual order looks like a mistake or a legitimate large purchase, a decision that trades off two things a rule can't weigh the way a person actually would in that specific case.

The Cost of Automating the Wrong Half

Automation applied to a judgment-call task doesn't fail loudly. It applies the same rule to every case, including the ones where that rule was always the wrong answer, and it does so confidently and consistently every time. The exceptions don't get flagged as exceptions - they just get handled wrong, at scale, without anyone noticing until a customer says something.

That's a worse failure mode than a manual process handling the same edge case inconsistently. A person who isn't sure what to do tends to hesitate, ask, or flag it. A script that isn't built to recognize the edge case doesn't hesitate at all.

A Better Split Than "Automate Everything"

The useful split isn't automated versus manual. It's rule versus judgment. Automate the part of a process that's genuinely rule-based, all the way through, and leave the judgment-call part to a person - including building the automation to hand off cleanly the moment it hits a case outside what it was built to handle, rather than guessing.

Common Questions

How do you know if a task is really rule-based or just looks that way?

Ask whether every past exception could have been predicted and written down as a rule in advance. If the exceptions kept surprising the person handling them, the task likely depends on judgment the automation won't have either.

Isn't leaving something manual just avoiding the harder build work?

Sometimes, but often it's the more accurate assessment of the task itself - some decisions genuinely depend on context that doesn't exist anywhere in structured data, and no amount of additional development changes that.

Can a task move from manual to automated over time?

Yes - once enough real cases have been seen to define the rule confidently, a task that started as a judgment call can often be narrowed down and automated later. Starting manual isn't a permanent decision.

What's a reasonable middle ground?

Automating the routine majority of a task while routing anything outside a defined set of conditions to a person - rather than forcing every case through the same automated path regardless of fit.

Automation Where It Belongs, Judgment Where It's Needed

If a process has an edge case nobody's fully mapped out yet, that's usually the part worth leaving to a person a while longer.