Nobody notices when an automation stops working. That’s the problem.
A form field gets renamed in the CRM. An API key expires. A supplier changes their invoice layout and the parser stops matching. None of these are dramatic failures — no error message pops up on someone’s desk, nothing crashes. The workflow just quietly stops doing its job, and the business slides back to doing the task manually without anyone deciding that’s what should happen.
We see this constantly with new clients coming into the Foundation Client Program. They already have automations — someone set up a Zapier flow eighteen months ago, or a contractor built a script that used to sync two systems. Half of them aren’t running anymore. Nobody killed them on purpose; nobody was watching closely enough to notice they’d died.
The gap isn’t technical, it’s organisational
Most businesses that automate a process focus entirely on building it. Getting the logic right, connecting the right tools, testing the happy path. All necessary. None of it answers the question that actually determines whether the thing survives: whose job is it to notice when this breaks?
If the answer is “nobody’s, really,” the automation has an expiry date. It might be a good one — some workflows run untouched for years — but the businesses that get burned are the ones where the automation touched something important (invoicing, client communication, lead follow-up) and nobody found out it had stopped until a client complained or a payment got missed.
Documentation doesn’t fix this on its own. A wiki page explaining how the workflow is supposed to work is useful when something breaks, but it doesn’t make anyone notice that it broke in the first place. Ownership is a different thing to documentation, and it’s the piece most businesses skip.
What ownership actually looks like
It’s smaller than it sounds. Owning an automation doesn’t mean being able to rebuild it from scratch. It means three things:
Someone knows it exists, and knows roughly what it’s supposed to do. Not the technical detail — just “this is the thing that pulls new enquiries into our tracker” is enough.
Someone gets told when it fails. Most tools that power business automations — Zapier, Make, n8n, even a lot of custom scripts — can send a notification on failure. That notification needs to land somewhere a person actually looks, not a shared inbox nobody checks.
Someone has a standing reason to glance at the output occasionally, even when nothing’s flagged as broken. Silent failures are the dangerous kind — the workflow runs without erroring, it just produces the wrong result. A weekly thirty-second check (“does this list look right?”) catches those long before a client does.
None of this requires technical skill. It requires a name attached to the workflow, and a habit.
Build it in before you build the automation
The fix is cheap if you do it at the start and expensive if you bolt it on later. When we scope an automation for a Foundation Client, assigning an owner is part of the build, not an afterthought tacked on at handover. We ask who on the team will get the failure alert, and we set that up before the workflow goes live — not after it’s already broken once.
If you’re automating something in-house, ask the same question before you build: when this breaks — not if — who finds out, and how long before they do? If you can’t answer that in one sentence, you don’t have an automation yet. You have a machine that will run unsupervised until it doesn’t, and nobody will know for a while.