Automation fails at the handover, not the build

Every morning a workflow I’d built sent a summary email saying it had run. Every morning, it had.

Months later I found out someone in the office had quietly gone back to doing the job by hand. A field had been renamed upstream, the step that mattered was passing an empty set through and the workflow was reporting that outcome as a success, daily.

Nothing had broken. That was the problem.

Automation almost never fails at the build. It fails at the handover. Building the thing is the cheap, enjoyable part, and it’s the only part anyone plans for.

The build is the part you can see

An automation is a small piece of software with none of the support a piece of software normally gets. No owner on an org chart. No test suite. No on-call. No changelog. It sits between 2 systems that belong to other companies, and it depends on both of them not changing.

Then it gets handed over, which usually means a demo, a screen recording and a sentence in a status update.

That’s the moment it starts dying. Not because the logic is wrong. The logic was fine on the day. It’s because everything that keeps software alive is organisational, and none of it got assigned.

How it actually dies

What happens	What it looks like from the outside	What it costs
A field is renamed upstream	Runs, reports success, moves nothing	You pay for the tool and for the manual work
The person who built it leaves	Still running, nobody will touch it	Frozen. It can’t improve, so it slowly stops fitting
Volume grows past a rate limit	Partial runs, no error	Gaps in the data, found months later in an audit
Nobody owns it	Alerts go to a channel nobody reads	The failure is reported to you by a customer

There’s a fifth one, and it’s the one that does the real damage.

Someone finds the output is wrong, so they do the task by hand that day. Faster than raising it. The next day they do it again. Within a few weeks the manual version is the process, and nobody has logged a fault, because raising it now means admitting they’ve been working around it for a month.

When someone outside the business built it, this is worse. The engagement ends, the builder moves on and you’re left holding something you can’t read, can’t change and won’t turn off in case something depends on it.

You end up paying 3 times. For the tool. For a person to do the work anyway. And for a report that says it’s handled.

What to do about it

None of the fixes are clever. All of them are cheap, and all of them have to happen before the build, because afterwards nobody has budget for them.

Name an owner before you write a line. A person, not a department. They don’t need to be technical. They need to be the one who notices. If nobody in the business will put their name against it, that’s your answer. Don’t build it.

Document it in the language of the business, not the tool. “Zap 3 posts to the webhook” tells nobody anything in a year, and it’s worthless the day you change tools. “When an invoice is approved, the customer gets a receipt and the job moves to scheduling” survives everything. One page. The test: someone who has never opened the tool reads it and can tell you what stops happening if it stops running.

Make silence as loud as an error. Most monitoring alerts on failure, which is the state that isn’t dangerous. The dangerous state is success with nothing in it. Alert on the thing that should have happened not happening. If the workflow normally moves records and today it moved zero, that’s an alert, not a green tick.

Decide what happens at 2am before it’s 2am. There are 2 acceptable answers. Here’s the manual fallback and here’s who runs it. Or it waits until morning and here’s who gets told. Both are fine. What isn’t fine is discovering at 2am that nobody ever decided, because the default in that moment is always the most expensive option available.

Put a review date in a calendar. Every integration is a standing dependency on somebody else’s roadmap. APIs get deprecated with 90 days’ notice and the email goes to an address nobody monitors. Once a quarter, the owner opens it and confirms it still does what the one-page description says.

That’s the entire list. It costs an afternoon and it’s the difference between an automation that’s still running in 3 years and one that’s a line item nobody can explain.

The uncomfortable part

The reason this keeps happening isn’t ignorance. It’s that the build is the fun bit and the handover is admin, and the person who’s good at the first is rarely enthusiastic about the second.

So it gets skipped, every time, by people who know better. Including me, which is how I know what the failure looks like from the inside.

An automation nobody owns isn’t automation. It’s a bill with a good story attached.