Automation projects rarely collapse because the technology fell short. They collapse because of edge cases nobody wrote down.
When an automation project falls over, the technology is usually not what broke.
What breaks is the part nobody wrote down. The invoice process runs beautifully for eleven months, then a supplier sends a credit note, and it turns out the only person who knew how those were handled left in April. The rule lived in her head. Now it lives nowhere.
Almost every automation failure I have seen traces back to the same thing. Somebody automated the version of the process that people describe, rather than the version people actually perform.
The described version is clean. Four steps, one path, no exceptions. The real one has a step where Mark checks something on Tuesdays, a category that gets handled differently for one customer because of an argument in 2023, and a monthly case that everyone deals with by sending an email and hoping.
Automate the clean version and you get a system that works until the first exception, then fails in a way that is harder to unpick than the manual process ever was.
So before automating anything, watch it happen. Properly. Sit with whoever does the task and count how many times they make a judgement call. Every one of those is a decision the automation will have to make or escalate, and you want to find them now rather than in production.
Then automate the boring middle first. Not the whole thing. The part that is high volume, low judgement, and identical every time. Data entry between two systems that should already talk to each other. Renaming and filing. Chasing the same overdue reminder for the fourth time.
Leave the judgement calls with a person, at least at first, and give the system a clear way to hand them over. A workflow that handles eighty percent and cleanly escalates the rest is worth far more than one that claims a hundred percent and quietly gets it wrong.
This applies whether you are a solo freelancer with a folder of scripts or a company rolling out something across departments. The scale changes. The failure mode does not.
The other thing worth saying plainly. If a process is genuinely broken, automating it just produces bad results faster. Fix it on paper first, run it manually for a few weeks, and only then automate it. That order costs you a month and saves you a rebuild.