When to automate a workflow, and when to leave it manual
Automation saves time on the right tasks and creates new work on the wrong ones. Four questions sort one from the other before anyone builds anything.
Almost any repeated task can be automated now. Tools like Zapier and n8n connect most business software with little or no code, and AI models can handle steps that used to need a person to read something and decide. So the harder question is whether a task should be automated, and the answer is no more often than people expect.
We ask four questions before building anything.
How often does it happen, and how long does it take?
This is the arithmetic, and xkcd did it best. Is It Worth the Time? is a table showing how long you can spend automating a routine task before you lose time overall across five years, based on how often you do the task and how much time you'd shave off it. A five-minute task you do every day is worth hours of building. An hour-long task you do twice a year usually isn't.
Count the whole cost of building, though. The build itself is the obvious part. Testing it, fixing it when a connected tool changes, and explaining it to whoever maintains it next all come on top.
Has the process stopped changing?
Automating a process that's still moving locks in whatever version you automate. If the team is still debating the steps, write the SOP first and run it by hand for a few weeks. Automate once it has settled. (That's the order we follow, and the SOP side is covered in how to write SOPs people use.)
What happens when it breaks?
Every automation breaks eventually. An API changes, someone renames a field, a login expires. What matters is what happens next. If the failure is loud, because someone gets an alert or a task lands in a queue, you're fine. If it's silent, a broken automation can run wrong for weeks: invoices that never go out, leads nobody gets assigned. For anything that touches money or customers, we build the failure alert before we build the automation.
Does the task need judgment?
Moving data between systems, sending the same notification, setting up the same folder structure every time: those are good candidates. Deciding whether a complaint deserves a refund, or whether a video is on brand, still benefits from a person. AI can help with the judgment steps by drafting a reply or flagging likely problems. For anything a customer sees, though, we keep a person approving the output until the error rate is low enough that you'd trust it unsupervised.
Picking the tool
For most small teams a no-code tool is the right place to start. Zapier's building blocks, a trigger followed by one or more actions, are easy to read for someone who didn't build the workflow, and that matters when you aren't the one maintaining it. n8n suits workflows with more branching logic, or teams that want to host their own. Custom scripts make sense when the volume is high or the tools involved don't have integrations. The best choice is usually the one your team can understand and fix without calling us.
Document an automation like any other process
An automation is a process that runs itself, and it needs the same documentation as one. Write down what triggers it, what it does, where it logs its activity, what it looks like when it breaks, and who owns it. Six months from now someone will need to know why a spreadsheet updates itself at 2am, and the person who built it may not be around to ask.