What's Worth Automating: The Filter I Use

Most of what people ask me to automate should stay manual. That is my honest starting point, and it is the opposite of what most automation content tells you.

I run 26 content pipelines in production, and I build custom automations for the tools businesses already use. The first question on any project is never “can we automate this.” Almost anything can be automated. The real question is whether it should be, and that is a filter, not a yes. Here is the exact filter I run before I quote a single hour of build time.

The short answer: automate the boring, repeatable, rule-shaped middle

Automate work that repeats on a schedule and follows rules you can write down. Leave anything that needs human judgment, happens rarely, or would be expensive to get wrong. My rule of thumb: if your team does it twice a week by hand and can explain how, it can probably run itself.

Everything below is just that sentence, taken apart into checks you can run on a real task today.

The filter: five gates a process has to clear

A process is worth automating only if it clears all five gates: it repeats often, the rules fit on one page, the inputs are already digital, a mistake is cheap to catch, and the process will still exist in six months. Fail one and it stays a human task, for now.

1. It repeats often enough to pay back

Frequency is what pays back the build. A weekly invoice run, a daily report, lead follow-ups that happen twenty times a day: yes. A task you do twice a year: no, no matter how annoying it is. The build cost is roughly fixed, so the more often a task runs, the sooner the automation earns its keep. Count the reps before anything else.

2. The rules fit on one page

If the person doing the task can explain their decisions on a single page, a machine can follow them. If the honest answer is “it depends, I just know,” that part stays human. This is the judgment gate, and it is where most automation dreams quietly die. You are not automating a task, you are automating a decision. Write the decision down first. If you cannot, you have found the human part of the job.

3. The inputs are already digital

Automation moves and reshapes data between systems. If step one is “read a scanned form” or “call the supplier to ask,” you are automating the easy 20 percent and leaving the hard part sitting on someone’s desk. Structured digital inputs are what make a build stick: a form submission, an API, a spreadsheet, an inbox with a predictable format. When the input is messy or offline, fix the input before you touch the workflow.

4. A mistake is cheap and catchable

Think about blast radius. A wrong draft caught by a review step costs you a minute. A wrong invoice mailed to 400 customers costs you a week and some trust. High stakes do not mean “do not automate.” They mean build the checkpoint before you build the speed. Every one of my pipelines has a human gate for exactly this reason. The gate is not a nice-to-have, it is the thing that lets you automate scary work at all.

5. It will still exist in six months

Stability matters. If you automate a process that gets redesigned next quarter, you get to rebuild the automation next quarter. When a workflow is mid-change, wait until it settles. The best automation targets are boring and old: the stuff nobody has touched in a year because it just works, by hand, over and over.

The ROI check most people skip: automation has a maintenance tail

An automation is not free once it runs. It needs monitoring, error handling, and fixes when a service changes its API on a Tuesday. Count that upkeep. The real math is build cost plus maintenance, weighed against hours saved times frequency times how long the process lives.

The demo is easy. Anyone can wire a few nodes together and make a workflow run once. The version that runs every day for months is mostly the unglamorous parts: rate limits, inputs that arrive malformed, a login that expires, a format that drifts. That is why I keep monitoring and fallbacks on every build instead of shipping a happy path and walking away.

So when you do the sum, do not only count the hours you save. Subtract the hours the automation will ask back from you over its life. Say a task takes 15 minutes and someone runs it 8 times a day. That is two hours a day, close to 500 hours a year, and an automation that runs daily for two years clears the bar without breaking a sweat. A quarterly report that saves an afternoon four times a year almost never does. Same task shape, opposite verdict, and the only thing that changed was frequency and lifespan.

The honest no: when automation is the wrong answer

Some things should stay manual: one-offs, judgment calls you cannot write down, broken processes, and anything a human relationship should own. A filter that never says no is not a filter, it is a sales pitch.

Here is my actual kill list, the cases where I tell a client not to build:

• One-offs and rare tasks. A one-page checklist beats a workflow you will forget how to fix.
• Judgment you cannot write down. Pricing a strange deal, deciding who to hire, choosing your positioning. These need a person, and pretending otherwise just produces confident nonsense.
• A broken process. Automating a broken process only industrializes the mess. I wrote more about this in the content pipeline build: fix it by hand first, then automate the version that works.
• A process about to change. If it is being redesigned, wait. You cannot automate a moving target cheaply.
• Work a relationship should own. The personal note to your biggest customer should come from you, not from a scheduled send. Some things lose their whole point the moment they run themselves.

This is the part of the job clients thank me for later. Sometimes the deliverable is a short “here is why we are not automating this yet,” and that saves a build they would have resented paying for.

A 60-second scorecard you can run right now

Score any task against the five gates. If you cannot answer yes to all five, do not build yet. Fix the failing gate first, or leave the task manual.

Gate	Ask yourself	Pass =
Repeats	How often does this run?	Weekly or more
Rules	Can I write the decision on one page?	Yes
Inputs	Is the data already digital and structured?	Yes
Mistakes	If it goes wrong, is it cheap and catchable?	Yes
Stability	Will this process exist, unchanged, in 6 months?	Yes

Five yes answers and you have a build worth quoting. One no and you have found the exact thing to fix before you automate anything around it. The scorecard is deliberately strict, because the cost of automating the wrong thing is not zero, it is a system you now have to maintain that never should have existed.

What this looks like for content, specifically

Content is the process I automate most, so if you want to see the filter applied end to end, that is where to look. The blog pipeline I run for clients passes all five gates: it repeats weekly, the editorial rules fit on a page, the inputs are digital, a review gate catches mistakes, and publishing a blog is a stable process. I broke down how that pipeline is built in n8n and what the service actually delivers. Same filter, one specific process, run for real.

The filter is the first thing I run on any workflow automation project, before scope and before a quote. Often the answer is yes and the build pays for itself fast. Sometimes the answer is no, and hearing it early saves you money. If you have a process you think might run itself, tell me what it is and I will run it through these five gates with you. If it fails one, I will tell you which, and why.