A post on r/n8n made the rounds this week with a decent instinct: figure out whether a process deserves automation before you open the builder, not after. The original poster's filter came down to three things — how often the task runs, whether the rules are predictable, and whether there's a clean if-this-then-that trigger. That's most of the test. It's missing the question that actually kills half the automation projects we scope with clients.
Here's the answer first, then the reasoning: a process is worth automating when it happens often enough to matter, follows rules you can write down without a dozen exceptions, and — the part that gets skipped — nobody needs to double-check the result before it goes out. Miss that third one and you'll build something that runs perfectly and saves nobody any time.
Frequency times predictability, minus review time. That's the whole test.
Frequency is the easy filter, and it's not enough by itself
Start with how often the thing happens. A five-minute task you handle twice a year isn't worth touching, no matter how tedious it feels in the moment — you'll spend more hours building and maintaining the automation than you'd ever get back. A five-minute task you do twenty times a week is a different animal. That's roughly a hundred minutes a week disappearing into a job a computer finishes in seconds, and the gap compounds every week you leave it alone.
Predictability matters just as much as volume. The rule needs to look like "if X, do Y" — mechanical, not judgment-based. A lead form that always needs a reply within the hour is automatable. A lead form where every third submission needs someone to read between the lines and decide how much attention it deserves isn't ready yet, or it needs a narrower slice carved out first.
The question the thread skipped: does someone check it anyway?
This is the one that gets missed most, and it's the one that actually determines whether an automation pays for itself. If a person has to review the output before anything happens — read the drafted email before it sends, eyeball the report before it reaches a client — you haven't removed the work. You've relocated it. Checking a machine's attempt at a judgment call can take just as long as making the call yourself, sometimes longer, because now you're also watching for the specific ways it gets things wrong.
The fix is to automate the right half of the task instead of skipping it.
Automate the draft, not the decision.
Build the piece that gets a person most of the way there, and let a human handle the last step — the send button, the approval, the exception. We wrote a longer breakdown of where that line should sit in a framework for AI agent approval gates if the fuller version is useful.
The invoice chaser test
The clearest example we've got is one we run on our own accounts receivable. An invoice hits seven days past due, and the system sends a polite nudge. At day fourteen, a firmer one goes out. The moment payment lands, a webhook cancels whatever's still queued so nobody gets chased after they've already paid. It took an afternoon to build, and it's the one automation in our own stack we've never once switched off.
Run it through the filter: it fires every week (frequency), the rule is the same three steps no matter which client owes money (predictability), and nobody reads the reminder before it sends because a polite nudge isn't a judgment call (no hidden review step). All three, cleanly. That's why it stuck instead of quietly getting turned off after a month.
When it's not worth it
The processes that fail this test usually fail on the third question, not the first two. Anything involving an action you can't take back — refunding money, canceling a contract, the first message a new client ever gets from your business — probably needs a person in the loop no matter how predictable the rule looks on paper, at least until the automation has a track record behind it. The same goes for anything genuinely rare. A task that happens four times a year almost never earns back the hours spent building and maintaining it, even when every single run of it is annoying.
Once something has gone through the filter and still doesn't clear it, the honest move is to leave it alone. Not every repetitive task needs a workflow behind it. The ones that do pass tend to be worth more than they look, mostly because nobody got around to building them yet.
This is the same filter our automation and workflow builds start with — we scope it because it clears the bar, not because it's an interesting demo. If you've got a process you keep meaning to automate and can't decide whether it earns the build, walk us through it and we'll tell you honestly.
— Cole
Sources
- r/n8n, "Before opening n8n, this is how I decide whether a business process is actually worth automating" — the discussion that prompted this post
- Genesis Web Digital, Where your AI agent should stop and ask: a framework for approval gates — the fuller framework for where human review belongs in an automated workflow