Not every repetitive task is worth automating. A framework for telling the ones that are from the ones that just feel like they should be.

---

Every automation pitch has the same shape: find a repetitive task, build something to do it instead of a person. That framing is true often enough to be dangerous, because it makes almost anything sound like a good candidate. The actual question isn't "is this repetitive?" It's "does removing the human here save more than it costs to build, maintain, and eventually fix when it breaks?" Those are very different questions, and skipping straight to the first one is how automation projects end up more expensive than the problem they solved.

The Tell: "We Do This Every Week Anyway"

The phrase that should trigger automation interest isn't "this is annoying" — it's "this is annoying, high-volume, and the rules don't change." A weekly export that gets emailed to a supplier is a great candidate: fixed format, fixed cadence, fixed destination. A monthly report that gets reformatted slightly differently depending on who's asking is a worse one, because the "automation" ends up being a person maintaining a script that's more fragile than just doing the task by hand.

The volume matters as much as the repetition. A task that takes five minutes once a month costs an hour a year. Building and maintaining something to handle it can easily cost more than that in the first year alone, before you've saved a single minute. The math only works in one direction, and it's worth doing before committing to build anything.

Where the Real Cost Hides

The build is rarely the expensive part. The expensive part is everything after: what happens when the input format changes, when an API the automation depends on gets deprecated, when an edge case nobody anticipated shows up in month four. An automation that runs unattended needs monitoring, a way to fail loudly instead of silently, and someone who still understands what it's doing well enough to fix it. None of that shows up in the initial "how long would this take to build" estimate, and all of it is real cost.

This is why the honest first conversation about automating something isn't "can this be automated" — almost anything can — it's "is this worth owning as a piece of infrastructure, indefinitely, instead of a task someone does by hand." A lot of things clear the first bar and fail the second.

A Simple Filter Before Building Anything

Before automating a process, it's worth being able to answer these plainly:

1. How often does this actually run? Weekly-or-more is a different conversation than quarterly.
2. How stable are the rules? If the process changes shape every time it runs, you're not automating a task — you're automating a moving target.
3. What happens when it's wrong? A miscategorized internal spreadsheet row is a shrug. A misrouted customer refund is not. The tolerance for silent failure should shape how much you invest in catching it.
4. Who notices if it stops working? If the answer is "nobody, for weeks," that's not a strength — it's a sign the automation could quietly be doing the wrong thing for weeks too.

Restraint Is Part of the Service

It would be easy to say yes to every automation request — it's more work, and more work sounds like more revenue. But an automation that costs more to keep alive than the task it replaced isn't a favor to anyone, and a client who feels oversold on the second one won't come back for the third. The honest answer, often, is "not yet" — do it manually until the volume or the stakes justify the investment, then build it properly when it does.

The goal was never to automate everything that could be automated. It's to automate the handful of things that are actually worth turning into infrastructure — and say so plainly about the rest.