Most automation projects fail before anyone writes a line of code or opens n8n. They fail at the decision stage: someone picks a task that's visible and annoying, builds something clever to handle it, and six months later realizes it didn't move anything that mattered.
I've seen this from both sides — inside a large ops org, and building automation systems myself. The pattern repeats. The problem is almost never the tooling. It's that nobody stopped to ask whether the task was worth automating in the first place.
Here's the sequence I use before I build anything.
1. What's the actual constraint, not just the annoying task?
The instinct is to automate whatever's in front of you — the report you rebuild every week, the manual step that eats an afternoon. But the task that annoys you most is rarely the one holding the business back.
Ask two questions, in this order. First: what would break if volume doubled tomorrow? Second: where is money or time already leaking, right now, at current volume? The first question finds fragility. The second finds waste. Both matter, but the first one first — a system that can't survive growth is a bigger risk than one that's merely inefficient today.
If you can't point to a specific bottleneck after asking both questions, you're not ready to automate anything yet. You're just looking for something to build.
2. Should this be eliminated, automated, or delegated?
Before building anything, ask whether the process should exist at all. A lot of recurring manual work exists because nobody's questioned it in years, not because it's necessary. If a step exists only to compensate for a decision made somewhere else — a data entry step that only exists because a form doesn't capture a field correctly — fix the upstream problem and the manual step disappears on its own.
Only once you've eliminated what shouldn't exist should you ask whether what's left should be automated or simply handed to someone else. Automating a broken process doesn't fix it. It just makes the dysfunction run faster and with less visibility.
3. Does the tool actually match the size of the problem?
It's tempting to reach for the most powerful available option, especially with AI, because it feels forward-looking. Most of the time it's the wrong call. Buy before you build. Build the smallest thing that solves the actual problem, not the most impressive thing you could build.
A three-step n8n workflow that does one job reliably beats an elaborate multi-agent system that does five jobs unreliably. Complexity is a cost, not a feature.
4. Have you actually mapped the process?
For each step in the process: what triggers it, where the data comes from, what transforms along the way, where a decision has to be made, where the output goes, and who or what has the authority to act at each point.
This step is tedious and it's the one people skip most often. It's also where most of the real decisions live. If you don't know where a decision needs a human and where it doesn't, you'll find out the hard way — in production, when something ambiguous comes through and there's no rule for handling it.
Default every decision point to the smallest authority that gets the job done. A step that only needs to flag something for review shouldn't have the power to act on its own.
5. What's the one number that tells you it worked?
Before you build, name a single measurable outcome and capture the baseline. Not a dashboard, not a general sense of improvement — one number, tied to something the business actually cares about: more customers, higher value per customer, or lower cost.
Without a baseline captured before the build, the "after" number means nothing. You'll have a system that runs, and no way to tell whether it was worth building.
Set a date — 30 days out is usually enough — to check the number. If it moved, you've earned the right to invest further. If it didn't, that's useful information too. Better to know that early than to keep maintaining something that isn't earning its place.
None of this is about being anti-AI or anti-automation. It's the opposite — automation is worth doing, but only once you've done the harder work of deciding what's actually worth automating. The build is the easy part. The diagnosis is where the real value gets created or lost.
If you're weighing what to automate in your own operation and want a second set of eyes on the diagnosis before you build anything, I'd be glad to talk it through.
