Delivery · 5 min read · October 2026
What happens when an automation fails?
Every automation works in the demo. The ones worth paying for are designed around the day an invoice arrives as a blurry photo, a connected system changes a field name, or a customer asks something nobody planned for.
Design the failure first.
Write down the failure before you build the success
For every production workflow we document the same nine things: the trigger, the inputs, the decisions, the permitted actions, the approval thresholds, the output, the retry behaviour, the escalation path and the audit trail. Look at that list again. Most of it describes what happens when something goes wrong, not when it goes right. That is deliberate. The happy path is easy to build and easy to demo; the rest is the part you are actually paying for.
Decide what the system may do alone
Drafting a reply is different from sending a refund. Small, reversible actions can run on their own. Actions that move money, change a customer record or cannot be undone wait for a person. The threshold is a business decision, so it should be written down as a rule your team can read and change, not left as an impression of what the system seems comfortable doing.
Retries first, then a person
Connected software times out, rate-limits and occasionally changes. Automatic retries absorb the temporary problems. For everything else, a named person should receive the item with the context attached: what came in, what the system tried, and why it stopped. A generic error email at 3 a.m. is not escalation.
Leave a trail
A log of what came in, what the system decided, what it did and who approved it lets you answer “what happened to that invoice?” in a minute rather than an afternoon. It also lets us improve the workflow from evidence instead of guesses.
Takeaway
A good automation is not one that never fails. It is one where a failure is small, visible and owned by a named person.