Someone built you an automation. It worked. Everyone was pleased. Six weeks later it is off, or it is on and quietly doing the wrong thing, and nobody can say exactly when that started. So you go back to doing it by hand, and you file automation under things that did not work here.
I have walked into this a lot. The automation is almost never the problem. The process was broken before it was automated. An automation does one thing well: it repeats a decision quickly. If the decision was fuzzy, you now have a fuzzy decision happening two hundred times a week instead of twice.
A client had a Zap that created a project every time a deal closed in the CRM. Sensible. Except "closed" meant three different things to three different people. One marked it closed at verbal agreement, one at signature, one when the deposit landed. The automation fired on the CRM stage, so projects appeared for work that had not been paid for, and the delivery team started ignoring the ones that showed up. Within a month they were creating projects by hand again, alongside the ghosts. Nothing was wrong with the Zap. The stage definition was wrong, and no automation fixes that.
Before automating anything, get one sentence agreed: what has to be true for this step to have happened. If the team cannot agree on that sentence, you are not ready to automate. You are ready to have a conversation.
Nobody owned it. Ask who owns an automation and you often get a name that has left, or an agency that finished the project, or a shrug. Automations fail silently by design. That is the whole point of them. So when one stops, there is no missed deadline and no angry email.
There is just an absence, and absences do not raise their hand. Two things fix most of this. Put a name against it, and not the person who built it: the person whose week gets worse if it stops. Then make failure loud. Most automation tools can send a message when a step errors. Turn that on, point it somewhere a human actually reads, and include enough detail to act on. An alert that says "Zap failed" is barely better than silence.
It was tested on the happy path. Almost every automation I inherit was tested once, with clean data, by the person who built it. Real life is not clean. Someone types a phone number into the email field. A client name has an apostrophe in it. Two records arrive in the same second. Somebody edits the sheet the automation reads from and renames a column because it looked untidy. Test with the ugliest real record you can find, not a made-up one. Then test what happens when the automation runs twice on the same input, because at some point it will.
It lived in someone else's account. This one costs real money. A contractor builds the automation in their own Zapier or Make account, hands over a demo, and leaves. Nine months later something breaks, they are unreachable, and you cannot even see the thing that is running your business. Build in accounts the business owns, with contact details the business controls. Anyone who resists that is telling you something useful about how the engagement will end.
Nothing was written down. Not documentation in the heavy sense. One page. What triggers it. What it touches. What it does when it fails. Who to tell. That page is the difference between a thirty minute fix and a two week archaeology project. It takes twenty minutes to write on the day you build the thing, and it is almost never written, because on that day everything is obvious.
The order that actually works. Map the process as it really runs, with the people who run it. Not as the org chart describes it. Cut the steps that exist only because someone once asked for them. Agree the definitions. What counts as closed, complete, approved, ready. Then automate, in accounts the business owns, with error alerts on and a one-page note written. It sounds slower. It is faster than doing it twice.
One useful test. Before you automate anything, ask what happens if this runs wrong two hundred times before anyone notices. If the answer is a bit of tidying up, go ahead. If the answer is a client gets billed twice or a contract goes out unsigned, slow down and fix the process first. Most automation regret sits in the gap between those two answers.
