The Automation Reflex Is Broken
You see a repetitive task and think: “We should automate this.”
It’s instinct now. Repetitive work exists. Technology exists. Seems obvious.
It’s not. And that instinct is costing companies hundreds of thousands of dollars in wasted automation projects.
I’ve watched managers spend six months building a system to automate something that takes one person four hours a week to do manually. They didn’t save money. They didn’t save time. They just moved the problem from “one person doing it” to “one person maintaining the system that does it.”
The difference between a good automation and a waste of time isn’t the technology. It’s the framework you use before you decide to automate.
Most companies don’t have one.
What Gets Automated (And Why It Usually Fails)
The pattern is consistent.
Managers look for:
- High-volume tasks (“We do this 1,000 times a month”)
- Repetitive tasks (“It’s the same thing every time”)
- Time-consuming tasks (“This takes hours”)
These seem like the right criteria. They’re not.
High-volume + repetitive + time-consuming is actually the worst combination for automation. Here’s why:
If something is truly the same every time, it’s also the easiest thing for a human to do on autopilot. Which means it’s also the easiest thing for humans to notice when it’s wrong.
I watched a logistics company automate their order routing system. Orders came in. The system routed them automatically based on geography and capacity.
On paper: perfect. High volume. Repetitive. Time-consuming.
In reality: The system routed orders correctly 94% of the time. But that 6% failure rate meant:
- Wrong warehouse assignments
- Delayed shipments
- Angry customers
- Manual intervention required
- Someone had to monitor and fix the mistakes
They spent $120K building a system that eliminated four hours of work per week but created eight hours of monitoring and fixing work.
The math didn’t work. But nobody did the math before they built it.
The Real Framework (What I Actually Use)
Here’s what I ask before I automate anything.
Question 1: Does This Actually Repeat?
Not “is it theoretically repetitive.” Actually repeats.
You’d be shocked how many things people describe as “we do this all the time” that actually happen inconsistently.
I worked with a real estate company that said they had a “high-volume repetitive task” around lease renewal processing. “We process 200 lease renewals a month.”
So I asked: Do they all follow the same process?
Answer: No. Some are simple renewals. Some involve renegotiation. Some involve property improvements. Some involve new tenants. They look the same on the surface but they’re completely different processes.
They weren’t processing 200 of the same thing. They were processing 200 variations of a thing.
That’s not automatable. Not yet anyway. Not without building something custom, which defeats the purpose.
The test: Can you write down the exact steps that happen every single time? If you can’t, or if there are more than 2-3 exceptions, it doesn’t repeat enough to automate.
Question 2: What’s the Cost of Failure?
This is where most frameworks fail. They ignore this completely.
Automating a task that never fails is different from automating a task that fails occasionally.
If a human processes an invoice and makes a mistake, they catch it (usually). The system prevents the error from propagating.
If an automated system processes 1,000 invoices and makes mistakes on 1%, you now have 10 wrong invoices in your system. You might not catch them for weeks. By then, they’ve created downstream problems.
The cost of that failure compounds.
I watched a company automate their customer data entry from web forms. The automation was 98% accurate. Sounds great. But 2% of customer records were corrupted (bad phone numbers, addresses in the wrong fields, etc.).
2% of 5,000 records = 100 corrupted customer records.
They discovered this when their customer service team started seeing broken data. By that point, it had cascaded into their reporting, their billing, their communications.
The cost to fix: 40K.Thesavingsfromautomation:30K per year.
Not a good trade.
The test: If this automation fails 2% of the time, what happens? Can you catch it quickly? How expensive is the fix? Is the downside bigger than the savings?
If yes, don’t automate it yet.
Question 3: Are You Removing Thought or Just Speed?
This is the one nobody talks about.
Some tasks are repetitive but they require judgment. Not much. Just… observation.
“Is this invoice legitimate?” Repetitive task. But it requires a human to notice something’s off. A weird amount. A vendor we don’t know. A timing that seems wrong.
Automating this means you’re removing the human observation layer.
If you do that, you need to build in detection for all the things a human would have caught. Which means you need to define all the edge cases.
And you can’t. You can’t think of everything.
A company I worked with automated their expense approval process. Most expenses were straightforward. But sometimes there were red flags: high amounts, unusual vendors, timing that didn’t match the project.
A human approver would notice and ask questions.
The automation would just approve them if they fit the criteria.
They saved three hours of human approval time per week. They also approved $50K in fraudulent expenses over six months before they noticed.
The test: Does this task require judgment or just speed? If it requires judgment, automation might remove the safety layer. Don’t do it.
Question 4: Is This Saving Time or Saving Money?
These are different. And you need to know which one you’re actually optimizing for.
Saving time: The task takes 10 hours per week. Automation reduces it to 1 hour per week. Net savings: 9 hours.
That’s real. But what happens to those 9 hours? Does the person do higher-value work? Or do they just have less to do?
Most companies build automation that saves time and then… the person has downtime. Or they get assigned more work to fill the gap. Or they get fired.
None of those scenarios are as good as they seem.
Saving money: The task costs 50Kperyear(person′s salary allocation for that work). Automationcosts10K per year. Net savings: $40K.
That’s also real. But you need to ask: What’s the person doing with the freed time? If they leave the company, you save 40K.Iftheystayandyouredeploythem,youdon′tsave40K—you shift the cost.
I watched a company automate a back-office process that cost 60Kperyearinlabor.Theautomationcost25K per year to run and maintain.
Sounds like $35K savings. Except the person who was doing that work got reassigned to handle the automation’s failures and edge cases. So the labor cost didn’t go away. It just shifted.
Net savings: $0.
The test: If you automate this, what actually happens to the person and the budget? If you can’t articulate it clearly, you don’t understand the economics yet.
Question 5: What’s the Maintenance Cost?
This is the cost that kills most automations.
Every automated system requires:
- Someone to monitor it
- Someone to fix it when it breaks
- Someone to update it when circumstances change
- Someone to handle the edge cases it can’t solve
This isn’t free. And it’s usually bigger than the savings.
I worked with a company that automated their lead qualification process. They fed it their CRM data. It ranked leads by likelihood to convert.
The automation worked. It reduced the manual work of lead scoring from eight hours per week to two hours per week.
But now someone needed to:
- Monitor lead quality (are the scores accurate?)
- Fix the model when it drifted
- Update criteria when the business changed
- Handle the leads it marked as “uncertain”
All of that took six hours per week.
Net savings: None. Actually worse. Because now the work was more technical and required more specialized skills.
They should have just kept doing it manually.
The test: Add up the time to monitor, maintain, and fix this automation. Subtract it from the time savings. Is there still a net benefit? If not, don’t automate.
What NOT to Automate (The Real Insight)
Most frameworks tell you what to automate. That’s backwards.
You should decide what NOT to automate first. Then automate everything else.
Don’t Automate Judgment Calls
If it requires someone to think “does this feel right?” it needs a human in the loop.
This includes: fraud detection, quality checks, customer exceptions, priority decisions, anything involving edge cases.
You can assist with automation (show the human relevant data, highlight red flags). But the decision needs a human.
Don’t Automate Things That Happen Once a Month or Less
The setup cost doesn’t pay back. The person remembers how to do it last time they did it (usually). Automating something that happens 12 times a year is often more expensive than just doing it manually.
Real example: A company spent $30K automating their quarterly reconciliation process. It happened four times a year. Automation time: 3 hours per quarter.
Manual time was: 12 hours per quarter.
Net savings: 9 hours per quarter. That’s 36 hours per year.
Cost per hour saved: $833.
They should have hired a contractor for four days per quarter at 150/hour.Wouldhavebeen2,400 per year.
Don’t Automate Things With High Failure Costs
If a mistake is expensive or hard to detect, manual is safer.
This includes: financial reconciliation, security decisions, customer-facing communications (that could be interpreted wrong), anything that requires nuance or context.
Don’t Automate Things Humans Should Decide About
Some tasks are so tied to business judgment that automating them removes decision-making from people who should be making decisions.
I watched a company automate their customer credit limit decisions. System was 95% accurate. But the 5% of cases where it was wrong were often cases where a human salesperson knew the customer and could justify a higher limit.
By automating, they removed the salesperson’s ability to exercise judgment and make exceptions. They gained speed and consistency. They lost flexibility and relationship management.
Was it worth it? For them, no. The edge cases mattered more than the speed.
The Uncomfortable Truth
Most automations should never have been built.
Not because automation is bad. Because companies automate the wrong things for the wrong reasons.
They automate because:
- It’s trendy
- They think it’ll save money (but don’t verify)
- They want to look modern
- They have a consulting budget that expires
They don’t automate because:
- They’ve actually done the math
- They’ve considered the downside
- They’ve talked to the person doing the work
- They’ve understood what happens to that person afterward
I worked with a founder who wanted to automate their entire customer onboarding process. “Make it fast. Make it frictionless.”
We got into the details. The onboarding actually required judgment. The team asked questions that revealed what the customer actually needed (not what they asked for). They built relationships that kept customers around.
Automating that would have been faster and more efficient and terrible for retention.
So we didn’t. We optimized it. We made it less repetitive. We kept the judgment calls human.
They saved time without losing what mattered.
The Framework Simplified
Before you automate anything, answer these five questions:
1. Does this actually repeat?
Can you write down the exact steps that happen every time? If there are more than 2-3 exceptions, stop.
2. What’s the cost of failure?
If this fails 2% of the time, what happens? Is the downside bigger than the savings?
3. Does this require judgment?
Or is it just speed? If it requires judgment, keep a human in the loop.
4. What’s the real economics?
Savings minus maintenance cost. Is there still a net benefit?
5. What happens to the person?
If you automate this, what does that person do? Is that better or worse for the company?
If you can answer all five clearly, and the answers still point to “automate,” then you probably should.
If you can’t answer them, or the answers are mixed, you’re not ready.
When Automation Actually Works
It’s not magic. It’s specific.
Automation works when:
- The task repeats without exception (truly repeats, not “mostly repeats”)
- The failure cost is low (if it breaks, it’s easy to catch and fix)
- There’s no judgment involved (it’s mechanical, not thoughtful)
- The economics are clear (you’ve actually done the math)
- You have a plan for the person (what happens to their time/role)
- Maintenance is accounted for (you know who’s monitoring it)
This is rare. Maybe 20% of what companies think they should automate actually meets all six criteria.
But when it does, automation is powerful. It’s scalable. It’s reliable. It works.
The companies that get this right don’t automate everything. They’re strategic. They automate the things that truly deserve it.
Everything else, they optimize. They improve. They streamline. But they keep the human in it.
The Question You Should Actually Be Asking
Forget “should we automate this?”
Ask instead: “What should we not automate?”
Because the thing that looks like it should be automated is often the thing that’s keeping your business functional.
The thing that looks too complex to automate is often the thing that matters most.
Start there. Figure out what humans need to decide. Then automate everything around it.
That’s the framework that actually works.