Just Because It Can Run Itself Doesn't Mean It Should

By Chris Daily

Automation looked beautiful on the diagram. Then I tested the assumptions underneath it.

Originally published at christopherdaily.com.

A home-services owner I know had reached the exact stage every enthusiastic AI user eventually reaches. He wanted the system to just handle things by itself.

New leads were coming in through the website, and he pictured a clean chain: AI reads the inquiry, identifies which service it's for, scores the lead, figures out urgency, estimates the job, sends a response, books the next step, and updates the customer record. All of it, automatically, no one touching it.

It looked genuinely beautiful on a diagram. Then he tested the assumptions underneath it, one at a time.

Some customers used the wrong name for the service they needed. Some described urgent situations poorly, in ways that would have been scored as routine. Some lived just outside the normal service area, in a gray zone the rules didn't quite cover. Some needed a service the company didn't actually provide. A few requests touched safety-sensitive information that shouldn't be handled casually. And estimates depended on details that were almost never complete in that first inquiry.

The workflow, as a whole, was genuinely automatable. The entire decision inside it was not. That's a distinction worth sitting with, because it's the one almost everyone skips.

Automation Is the Last Design Decision, Not the First

Automation should show up after you actually understand the job — the context it needs, what the normal path looks like, what the exception path looks like, who has decision rights, and how you'll measure whether it's working. Do it in that order and the technology stays downstream of how your business actually operates. Do it backwards, and an integration ends up quietly defining how your company works, which is a much worse position to be in than it sounds.

Automation Is a Permission Decision, Not a Capability Question

The word "automation" makes a workflow sound mechanical, almost inevitable. In practice, it's something much more specific: you're deciding what a system is allowed to observe, infer, communicate, modify, schedule, spend, approve, or trigger without a person doing every step personally.

Which means the real question was never "can the technology do this?" Technology can do an enormous amount at this point. The actual question is: under what conditions should the business let this action happen without a person directly involved? That's a governance question dressed up as a technical one, and treating it as purely technical is how businesses end up automated further than they ever actually decided to be.

The Five-Way Decision, in Order

Before anything gets automated, run every candidate step through five options, in this specific order. Eliminate — should this step even exist? Simplify — is it more complicated than it needs to be? Assist — should AI prepare information or a draft while a person still acts? Automate — should a system execute this specific step under defined controls? Keep human — does the judgment, relationship, accountability, or consequence here need to stay directly human, full stop?

Automate is fourth on that list, not first. Most people jump straight to it because it's the most exciting option, and skip the three questions that would have told them the step didn't need automating at all — it needed eliminating, or simplifying, or just a better-prepared draft with a person still making the call.

The Automation Readiness Scorecard

For any step you're still considering after that five-way filter, score it on these: how often does it actually happen — frequently enough to justify the setup? Can you clearly describe what "acceptable behavior" looks like here? Are the inputs it needs consistently available, or do they show up incomplete half the time? Can you actually tell when it fails, or would it fail silently? If it does something wrong, can that be undone? How often does the normal path break down into an exception? What's the real impact if it gets something wrong? What sensitive information does it touch as it crosses systems? Does it communicate with someone, spend money, modify a record, or create a commitment on the business's behalf? And will maintaining it remain worth the ongoing effort, or will it quietly become expensive to keep working?

High scores aren't universally good news here — that's the part people misread. A high consequence score is a warning sign, not a green light. This scorecard is meant to structure a real conversation about risk, not hand you an automatic approval.

How the Lead Workflow Actually Got Broken Apart

Going back to that lead-response chain — reading the inquiry, identifying urgency, estimating, responding, booking, updating the record — almost none of it survives as one single automated action once you look closely. Reading and organizing the inquiry: assist, easily. Identifying urgency when the description is ambiguous or the situation sounds serious: keep human, because getting that wrong has real consequences. Estimating when details are incomplete, which is most of the time: assist, with a clear escalation path when the gaps are too large. Sending an initial acknowledgment with basic information: automate, because it's low-consequence, reversible, and easy to observe when it's wrong. Booking a confirmed appointment once everything checks out: could be automated under fairly narrow, well-tested conditions. Updating the record: automate, because it's low-risk and easy to verify.

One diagram. Six genuinely different governance decisions once you actually look at each piece honestly instead of automating the whole chain because it looked clean on a whiteboard.

The Honest Caveat

This process is slower than just turning something on. It requires you to sit with your own workflow long enough to find the parts that don't fit the clean version — and there's almost always at least one, hiding in the step that looked most obviously automatable at first glance. That's not a flaw in the process. That's the entire point of doing it before you flip the switch instead of after something goes wrong in front of a customer.

Key takeaways

• A workflow can be automatable as a whole even when one specific decision inside it genuinely isn't — find that decision before you automate anything.
• Automation should be the last design decision, made after you understand the job's context, normal path, exceptions, and decision rights — not the first.
• Automation is a permission decision: what a system may observe, communicate, modify, spend, or trigger without a human — not just a technical capability question.
• Run every candidate step through five options in order: eliminate, simplify, assist, automate, keep human. Automate is fourth, not first.
• A high score on the automation readiness scorecard's consequence dimension is a warning sign, not approval — the scorecard structures a conversation about risk, not a green light.

Frequently asked questions

How do I know if a business process is ready to be automated with AI?

Run each step through five options in order — eliminate, simplify, assist, automate, or keep human — before assuming automation is the right answer. Then score genuinely automatable steps on frequency, rule clarity, input stability, observability, reversibility, exception rate, consequence, data sensitivity, external effect, and maintenance burden. A high consequence score is a warning, not a green light.

What's the difference between automating a workflow and automating a decision?

A workflow can involve several steps, and often only some of them are safe to automate. A step like sending a basic acknowledgment might be low-risk and automatable, while a step like judging urgency from an ambiguous description carries real consequences and should stay a human decision, even within the same overall workflow.

Why is automation described as a 'permission decision' rather than a technical one?

Because the real question isn't whether the technology can perform an action — it usually can. The real question is what a system should be allowed to observe, communicate, modify, spend, or trigger without a human directly involved, which is a governance decision the business has to make deliberately rather than default into.

Should automation happen before or after understanding how a business process actually works?

After. Automation should be the last design decision, made once you understand the job's context, the normal path, the exception path, who holds decision rights, and how success will be measured. Automating before that understanding exists lets the technology define how the business works instead of the other way around.

---

Where this goes deeper

The full Automation Readiness Scorecard and the Five-Way Decision framework are in the Automation chapter of my book, The One-Person AI Department, along with a worked example of breaking a real lead-response workflow apart step by step.

Get the book