The Automation That Stays On

The Zap you’re afraid to open

You built it over summer. A form comes in, a row gets added to a spreadsheet, and a message pops up in Slack. It worked, and you showed someone.

Then it stopped working in June, and you found out in August, when a client asked why nobody had replied to their enquiry. You opened the editor, saw fourteen steps you don’t remember writing, and closed the tab again. It’s still off. You’ve been doing that job by hand for five weeks, telling yourself you’ll fix it on a quiet Friday.

I don’t think the tool is the problem here. There were four decisions made before you built it, and they’re the reason it’s off. The good news is that all four are fixable next time.

Automations tend to die for four fairly boring reasons

It was chosen for being impressive, not for being frequent. A lead-scoring workflow with an enrichment step makes a better story than one that renames files. But the file-renaming one might run 40 times a week, while the clever one runs nine times and then breaks when something it connects to changes.

Nobody owned it. You built it, so technically it’s yours, but it isn’t in your calendar or anyone’s job description. An automation with no name attached tends to rot at about the speed the tools around it change.

It failed silently. This is the one that costs you clients. Nothing in that build was set up to tell anyone it had stopped. Five weeks of enquiries going nowhere, and the only alarm was an annoyed client.

The process underneath was already broken. If enquiries were being handled inconsistently by hand, automating them just gives you inconsistent handling, faster and in writing. Automation amplifies whatever you give it. It doesn’t have opinions about what that is.

Score the candidates before you build anything

List every repetitive task you did last week, and score each one out of 5 on four things.

Factor	Question	What a 5 looks like
Frequency	How often does it run?	Daily, or many times a week
Tedium	How much of it is copying, pasting, renaming, forwarding?	No thinking at all, just moving
Rule clarity	Could you write the rules on a sticky note?	Written in one sentence with no “unless”
Cost of error	What happens if it does the wrong thing?	Nothing. Someone notices and fixes it

Add up the four scores. Anything at 16 or above is a real candidate. Below 12, I’d leave it alone for now.

The cost-of-error column comes with a rule that overrides the total. If cost of error scores 1 or 2, don’t fully automate it. Automate it up to a human checkpoint. That means invoices, anything that goes to a client, anything touching payroll or a legal deadline. The automation prepares everything, and a person presses send. You keep nearly all of the time saved, and none of the disasters.

Every automation has five parts

People usually think about the first three. The last two are what decide whether it’s still running at Christmas.

1. Trigger. The thing that starts it. A form submission, a new row, a set time, an email arriving with a particular label.
2. Condition. The check that decides whether it keeps going. “Only if the enquiry value is over $2,000.” Without conditions, you automate every case, including the ones that really need a human.
3. Action. The actual work. Create, update, send, file, rename. One automation can include several.
4. Notification. How a person finds out it did something. Not a log nobody reads, but a message somewhere they already look.
5. Failure path. What happens when it breaks, how you find out, and who fixes it. This is the part that’s almost always missing.

A worked build: the enquiry that gets answered in minutes

The task: enquiries from the website form get read, sorted and replied to by whoever happens to spot them first. Frequency 5, tedium 4, rule clarity 4, cost of error 3. That’s 16, so it’s worth building.

1. Trigger: a new submission on the website enquiry form.
2. Condition: if the message mentions “invoice”, “account” or “refund”, send it to billing and stop there. Everything else carries on.
3. Action one: add a row to the enquiries sheet with the name, email, message, date and a status column set to New.
4. Action two: send an acknowledgement email from the shared inbox. Real words, signed by a real person, with a promise you can keep. “Thanks Sam. I’ve got this and I’ll come back to you by Thursday.”
5. Action three: post in the team channel with the person’s name, the first couple of lines of their message, and a link to the row.
6. Notification: that channel post is the notification. Someone sees every enquiry within minutes.
7. Failure path: see below. Please don’t skip it to ship faster.

Allow an afternoon to build it, including the twenty minutes you’ll inevitably lose to email formatting.

The failure path is most of the job

Answer these five questions in writing before you switch it on. Copy the block into a doc, keep it next to the automation, and fill in every line.

FAILURE PATH: [automation name]

1. How do we find out it stopped?
   Scheduled check: if nothing has run in [72 hours], alert [person]
2. Where do errors go?
   Error notifications go to: [one person's email, not a shared channel]
3. Who fixes it?
   Owner: [name, also written into the automation's title]
4. What do we do meanwhile?
   Manual fallback: [e.g. check the form inbox twice a day until it's back]
5. When do we check it's still right?
   Monthly check: [first Monday], five minutes, last thirty runs succeeded?

Here’s the thinking behind each one. Silence is the failure you can’t see, so the scheduled check makes silence noisy. Errors go to one person because a shared channel is where alerts go to be ignored. The owner’s name goes in the title, like Enquiry intake: Priya, so whoever opens it knows who to ask. The fallback is written down so nobody has to invent it in the middle of an outage. And five minutes on the first Monday of each month is twelve checks a year, which is nothing.

Automating a task isn’t the same as automating a decision

A task has one correct result, given what went in. Rename this file, put it in that folder, add this row, send that acknowledgement. Those you can automate.

A decision weighs things that aren’t in the inputs. Whether this client gets the discount. Whether this candidate gets an interview. Whether this complaint needs a phone call. What you can automate is the preparation for the decision, which is usually where the time goes anyway: gather the information, format it, put it in front of the right person, and wait.

The tool matters less than the failure path

Zapier connects to a huge range of apps, and its builder reads top to bottom, one step after another. It’s usually the quickest way to get something running.

Make builds on a visual canvas, which suits branching and looping through lists. The first hour is a bit steeper.

n8n can be self-hosted, which keeps your data on infrastructure you control, and it lets you drop into code when you need to. It’s worth a look if where your data lives matters, or you expect to build a lot.

All three change how they charge from time to time, so work out your own monthly volume and check it against each pricing page before you commit.

Honestly, I’d pick based on how you think rather than on a comparison table. The build above works the same way in all three.

When not to bother

• It needs judgement every time. If you’d have to write “unless” more than twice, it’s a decision. Build the preparation, not the decision.
• The rules change every month. You’ll spend more time maintaining it than doing the job.
• It happens twice a year. For rare work, a written checklist is the right kind of automation.
• The process is broken. Fix the process by hand first, run it that way for a month, then automate the version that works.
• Only one person understands it. That’s not a reason to skip automating, but it is a reason to write the process down first. Automating knowledge that isn’t written down just hides it somewhere harder to reach.

What you’ve got now

A scoring sheet that stops you building the impressive one first. The five parts of an automation, including the two most builds skip. A worked example to copy, and a failure-path block that decides whether it’s still running next year.

On Monday, score last week’s tasks. Then build the top one this week, and write the failure path first.