Why I Say No to Most Automation Requests

When someone asks me to automate something, my first instinct is to say no.

This probably sounds strange. I build systems for a living. Automation is a significant part of what I do. You’d think I’d be eager to take on automation projects.

But most automation requests shouldn’t be automated. At least not yet.

What I Actually Hear

When someone says “I want to automate X,” what I hear is one of several things:

“X is painful and I want the pain to stop.” Fair enough. But automation isn’t the only way to reduce pain. Sometimes the process is painful because it’s broken, and fixing the process eliminates the pain without adding automation complexity.

“I heard automation saves time.” It can. But the time saved needs to exceed the time spent building, testing, and maintaining the automation. For low-frequency tasks, this equation rarely works out.

“We should be more modern.” Modernity isn’t an operational goal. The question isn’t whether something is modern. The question is whether it works better than the alternative.

“I’m trying to solve a problem I imagine having in the future.” This is the most common one. Someone anticipates growth, volume, or complexity that doesn’t exist yet, and wants to prepare. But automating for problems you don’t have is expensive insurance.

The Three Conditions

I’ll take on an automation project when three conditions are met:

The process is stable. If the workflow changes frequently, automation becomes maintenance burden. Every process change requires automation change. You’re not saving time — you’re multiplying your update workload.

Stable means: the process has been running the same way for at least a few months. The rules are clear. The exceptions are documented and handled consistently. If someone asks “how does this work?” the answer doesn’t involve “well, it depends.”

The ownership is clear. Someone needs to own the automation. Not just build it — maintain it. When it breaks, who fixes it? When the business changes, who updates it? When edge cases appear, who handles them?

If the answer is “we’ll figure it out” or “whoever’s available,” the automation will decay. Clear ownership means a specific person who understands both the automation and the business process it supports.

The ROI justifies the complexity. Automation isn’t free. Building it takes time. Testing it takes time. Maintaining it takes time. The benefits need to outweigh these costs.

I do simple math: How much time does this task take manually? How often does it happen? What’s the annual time cost? What will the automation cost to build and maintain? Is the payback reasonable?

If the payback is over a year, I’m skeptical. Too much changes in a year. The automation might be obsolete before it pays for itself.

When I Say No

Here are the specific situations where I decline:

The process isn’t documented. If you can’t describe the process in clear steps, it can’t be automated. Automation requires explicit logic. “We just kind of handle it” isn’t automatable.

Different people do it differently. If five people would describe the process five different ways, there’s no single thing to automate. First standardize, then consider automation.

The exceptions outnumber the rules. If most cases require special handling, automation creates more work than it saves. You end up maintaining complex logic for edge cases while still handling exceptions manually.

The volume is too low. If the task happens once a week and takes ten minutes, automating it rarely makes sense. Even if automation saves 80% of the time, you’re saving eight minutes weekly. That’s seven hours per year. Is that worth building and maintaining automation?

Nobody will own it. If there’s no clear owner, the automation becomes orphaned. It will break and nobody will notice. It will drift from reality and nobody will update it. Orphaned automation is worse than no automation.

The real problem is something else. Sometimes automation is proposed to avoid addressing a harder issue. The process is painful because it’s poorly designed, or because people aren’t following it, or because there’s a skills gap. Automation doesn’t fix these problems — it encodes them.

The Conversation That Follows

When I say no to an automation request, I explain why. Usually this leads to a more useful conversation.

“The process isn’t stable enough” leads to: “What would need to be true for it to be stable?” This often surfaces process issues that need attention regardless of automation.

“The ROI doesn’t work” leads to: “What would make it worth automating?” Sometimes this reveals that a smaller, simpler automation would be worthwhile even if the grand vision isn’t.

“The ownership is unclear” leads to: “Who would own this if we built it?” Sometimes this reveals that nobody actually wants responsibility, which is a signal that the project shouldn’t happen.

These conversations are often more valuable than the automation would have been. They clarify what the business actually needs, rather than what someone imagined they wanted.

What I Say Yes To

I take on automation projects when:

• The task is truly repetitive — happening daily or multiple times daily
• The rules are clear and documented
• The exceptions are few and well-defined
• Someone specific will own the result
• The math works out to clear time savings
• The process has been stable for months

These projects tend to succeed. The automation gets built, maintained, and used. It actually saves time. It makes the work more reliable.

The pattern is clear: automation works best when it’s applied to mature, stable processes with clear ownership. It works poorly when it’s applied to chaotic, undefined processes that nobody fully understands.

The Meta-Point

Saying no to bad automation requests is part of doing good work.

A consultant who says yes to everything isn’t serving the client — they’re serving their own invoice. The value isn’t in building automation. The value is in building automation that works.

Sometimes the most valuable thing I can do is explain why the automation shouldn’t be built. That saves the client money. It saves everyone time. It prevents the creation of maintenance burden that would accumulate for years.

Knowing when not to automate is as important as knowing how to automate.

---

Related

• Article: Why Automating a Broken Process Makes Things Worse — The sequence that matters: fix first, automate second
• Deep Dive: Pricing, Boundaries, and When to Walk Away — How saying no protects outcomes