Why your automations keep breaking.
Take a purchase order at a mid-sized clinic. A department head submits a request in one system, a manager approves it by replying to an email, and someone in the finance office opens the attached PDF and types the PO number into the accounting software. On a whiteboard that looks like three steps and an obvious candidate for automation. Then someone builds it, it runs for two weeks, and one morning it stops. Nobody can say why until a person goes looking.
The software was built for a person at a keyboard.
Most of the tools an organization runs on were designed with a human operator in mind. They assume someone will log in, read the screen, click the right button and notice when something looks off. People are very good at that kind of improvising, and they do it so often that nobody writes it down.
An automation has none of that. It sees only what the system hands it, in the format the system chooses, through whatever door the vendor left open. When a person is quietly bridging two tools that were never meant to talk to each other, automating the steps on either side leaves the bridge out, and the bridge was the part doing the work.
Where the seams show.
The trouble tends to collect in the same few places. Each outside portal is its own custom system: the supplier's ordering site, the state reporting form, the insurer's claims screen. They change their layouts without notice, and a flow that relied on the old layout fails without saying so.
Permissions are the next seam. The person who built the flow connected it with their own login, which had more access than the job needed, or which expires when they change roles. Then there are the systems with no clean way in at all. Some have no connector, some have one that covers half the fields, and some export only to a spreadsheet someone has to download by hand.
The most common seam is data that lives in a document instead of a field. Invoices arrive as PDFs, approvals live in email threads, and intake details sit in a scanned form. AI is now quite good at reading those, which is real progress. It still means every run includes a step where a machine interprets something a human wrote however they liked that day.
Why a new tool rarely fixes it.
When a flow keeps failing, the instinct is to buy something that promises to handle it. Many of those products sit on top of the same systems your team already uses, so they inherit the same seams: the same missing connections, the same partial access, the same PDFs. The demo works because the demo data is clean. Your accounts payable inbox is not.
Some of those tools are good, and the breakage follows you into them anyway, because it lives at the seams. Before you sign for anything, ask the vendor to run it on a week of your own messy inputs and watch what happens at each handoff.
The demo works because the demo data is clean. Your accounts payable inbox is not.
Aim at the person who acts as a router.
The automations that hold up are usually smaller than the ones people first imagine. Instead of the whole purchase-to-payment process, look for the moments where a person's only job is to carry information from one place to another. Copying a number from an email into a record, checking that two lists agree, pulling three reports together before a Monday meeting: these are narrow and dull, and that makes them good targets.
A school district office, say, might spend an hour each week matching substitute requests against the timesheets that come back. Automating the match, and leaving the approval with a person, removes the tedious part without asking the flow to understand everything around it. When it does break, the failure is small and easy to spot.
Build the skill in house.
Organizations that keep automations running tend to have someone on staff who understands how their systems connect. That person doesn't need to be an engineer. Often it's an operations lead or an office manager who has learned a no-code tool, knows which systems export cleanly and which don't, and is allowed to try things.
Give that person time to prototype and to fail at small things. A broken flow that someone in the building understands is cheap to fix. One built by a contractor who has since moved on can cost far more than it ever saved, because the first step of every repair is working out what it was supposed to do.
Check the joints before you build.
Before anyone builds the next automation, walk through every point where work passes from one system, inbox or person to another. For each handoff, answer these:
- What format does the information arrive in at this step: a structured field, an email, a PDF, a screen?
- Does the receiving system have a supported way in, or would the flow be reading the screen or a downloaded file?
- Whose login does the flow use, and what happens to it when that person leaves or changes roles?
- Who owns the system on the other side, and would they tell you before changing it?
- If this step fails at 2 a.m., who finds out, and how long before they do?
- What does a person do at this step today that isn't written down anywhere?
Any handoff where the answers are "a PDF," "the screen," "my login," "they wouldn't" and "nobody" is where your automation will break. Either fix that joint first, or start the automation on the other side of it and leave that step to a person for now.
