Almost every automation project that doesn't stick has the same root cause, and it's rarely the tool. It's the order things happened in.
The pattern goes like this: a process is painful, someone decides to "automate it," and three weeks later the automation is doing exactly what the old process did — just faster, and now with less human judgement catching the parts that were already broken.
A process, not a task
Take invoice chase-ups, since almost every small team has some version of this. The process usually looks like: an invoice goes out, someone remembers to check who hasn't paid, someone else sends a reminder, and if there's no response, it gets escalated — eventually.
The obvious fix is to automate the reminder emails. So a rule gets built: three days after an invoice is sent, fire a reminder.
Except the due dates live in the invoicing tool, the client contact details live in a separate CRM that's half up to date, and "has this actually been paid" sometimes only gets recorded two days after the payment lands, because someone was busy. So the automation fires a reminder to a client who already paid. Or it reminds the wrong contact, because the CRM still has the old accounts contact listed. Or it just — doesn't fire, because the two systems don't actually talk to each other and nobody noticed until a client complained about a duplicate reminder.
None of that is a failure of the automation. It's a faithful reproduction of a process that was never reliable to begin with, now running without anyone there to quietly catch the exceptions the way a person used to.
Fix first, then automate
The useful order is the opposite of the instinct: find where the actual friction is, simplify the process until there's one clear source of truth and no unnecessary steps, and only then build the automation on top of it.
For the invoice example, that usually means before any automation gets built: pick one system as the actual record of "has this been paid" — not two, not a spreadsheet someone updates when they remember. Fix the handoff so a payment gets marked the same day, not two days later. Make sure the contact who receives reminders is the one who's actually looked at recently, not whoever was entered eighteen months ago.
That's not exciting work. It's also the entire difference between an automation that quietly saves a few hours a week and one that quietly generates client complaints until someone switches it off.
What this means before you automate anything
If you're looking at a process and thinking "we should automate this," it's worth asking first: if a careful, unhurried person did this process by hand every single time, would it work? If the honest answer is "mostly, except for that one part where things fall through," that's the part to fix before anything gets automated — not the part to automate around.
The tools that do the automating are the easy part. Getting the process underneath them into a state worth automating is the actual work, and it's the part that gets skipped most often because it's less satisfying than shipping something that runs on its own.
If you want a second pair of eyes on where a specific process is actually breaking down, a Systems Health Check is built for exactly that — mapping what's costing you time before anything gets built.