Who finds out when the automation breaks

Every automation pitch sounds the same at the start: here's the manual step, here's how it disappears. What almost never comes up in that first conversation is what happens the day the automation itself fails — a third-party API changes its response format, a spreadsheet gets renamed, a form field gets added upstream. That gap is where a lot of automations quietly turn from a win into a liability, because the business stops doing the manual version and nobody finds out the automated one stopped too.

Decide who gets the failure before you build the happy path

Before we build anything, we ask where a failure actually lands if the automation stops running tonight. Sometimes it's obvious — a missed lead just sits unrouted. Sometimes it's not, because the failure is invisible until someone notices a number looks wrong three weeks later. Naming the person who needs to know, and what "knowing" looks like for them, is part of the design, not an afterthought you bolt on once the flow already works.

Make the failure loud, not silent

A step that fails quietly is worse than no automation at all, because it looks like the work is still happening. We build failures to be noisy by default: a Slack message, an email, a dashboard flag — something that puts the problem in front of a person without them having to go looking for it. Logs that nobody reads are not monitoring. If checking whether something broke requires remembering to check, it will eventually not get checked.

Not every failure needs a person right now

Loud doesn't mean urgent. A failed nightly sync that can retry in an hour is a different kind of problem than a missed inbound lead. We sort failures by how much it costs to wait, not just by whether something went wrong, and route accordingly — some go straight to a person, some get one automatic retry first, some just need to be visible in a weekly review. Treating every failure as a fire is how alerts get ignored.

Build the fallback at the same time as the automation, not after the first outage

The honest fallback for most automations is "someone does it manually again until it's fixed." That only works if the manual version hasn't been forgotten — if the person who used to do the task still knows how, and the data the automation was touching is still visible to them without it. We keep that path alive on purpose, even after the automation's been running fine for months, because the first outage is a bad time to discover the manual process quietly died with the task it replaced.

None of this changes what the automation does when things go right — that part is still the main event. But an automation that's only been tested against the happy path hasn't actually been finished, it's just been started. The businesses that keep trusting their automations years in aren't the ones that never had a failure; they're the ones who knew about it within minutes and had a clear next step instead of finding out from a customer.