What Should Happen When an Automation Fails?

Most automations are shown on a good day. The demo runs, the message goes out, the calendar fills in, and everyone nods. I think the more useful question comes later. What happens on the day it stops working?

I spent many years supporting enterprise systems, and a lot of that time went to the days things broke. One system I supported took in files from client organizations. Each file passed through several steps, and at the end the client received an acknowledgement saying it had been processed. When something went wrong, the call usually started the same way. The client said they had sent the file, and they had no acknowledgement.

That missing acknowledgement told us something had failed somewhere along the way. Finding the spot meant tracing each step, because the acknowledgement is the last thing to happen. The person who notices a problem is usually standing at the end of the chain.

Small business automations work the same way. In this article I share how I think about failure when I design an automation, and the questions I would ask about any automation a business already runs.

Automations have bad days

The causes are usually ordinary. A connected app changes how it works. A password or access key expires. Someone types a phone number into the email field. A platform the automation depends on goes down for an afternoon.

I saw a clear example of this in my enterprise work. A business process ran on a software robot, a tool that clicks through screens the way a person would. It could do the job, but it took two to four days, ran unreliably, and broke each time the platform was upgraded. I made the case to replace it with a small service that connected to the underlying system directly. A developer built it, and I tested that it produced the same results as the old process. The work dropped to about 30 minutes, and platform upgrades stopped breaking it.

The lesson I took from that is simple. How an automation is built decides how often it has a bad day. Planning for the bad day decides how much it costs.

The quiet failure costs the most

A failure that shows an error message gets attention quickly. Someone sees it, and someone fixes it. The failure that worries me more is the quiet one, where the automation stops and nothing tells anyone.

Here is a representative example. Imagine a realtor whose website contact form sends each new inquiry to her phone and starts an automatic reply. On the Friday evening before a long weekend, the connection between the form and her phone stops working. The form still looks fine to visitors. They fill it in and see a thank-you message. Their inquiries sit unread until Tuesday, when she wonders why the weekend was so quiet.

Nothing in that story is dramatic. It is three days of buyers and sellers waiting for a reply that isn’t coming. By Tuesday, some of them have already called another agent.

This is why I treat monitoring as part of the automation itself. In the file system I supported, we had alerts set up for when the workflow failed to start after a file arrived. That alert was the first place I checked when a client called. For a small business, the same idea can be simple. The owner gets a message when a workflow hits an error. A short daily summary shows how many inquiries came in. A summary showing zero on a busy weekend is a signal worth checking.

Plan for failure while designing

The best time to think about failure is before anything is built. When I design an automation, I go through each step and list the ways it could go wrong. What if the lead leaves out a phone number? What if the calendar is already full? What if the AI drafts a reply that misses the question? What if the email service is down?

Each answer becomes part of the design. Some problems get an automatic retry. Some get a sensible default. Some get sent to a person.

Then I test against that list. I test the normal run first. Next come the edge cases, like a name with an apostrophe or a booking request for a statutory holiday. Then I test the failures on purpose, by switching off a connection or sending a bad value, and I check that the automation responds the way the design says it should. All of this happens before the business owner sees it working.

Give it a person to hand off to

An automation handles the common cases well. The unusual ones need a person. A good design decides ahead of time who that person is and how the hand-off works.

Say an inquiry asks about a commercial property and the team sells homes. Or a booking request lands on top of an existing appointment. Or the AI has low confidence in the reply it drafted. In each case, the automation passes the item to a named person, with enough detail that they can pick it up without starting over.

This keeps a person in charge of the exceptions. It also builds the team’s trust in the automation, because they know the hard cases will reach them.

Slow down instead of stopping

Sometimes the problem sits outside the business. A platform the automation relies on has an outage, and the fix is in someone else’s hands. The goal then is to slow down gracefully and keep the work safe.

In practice, the work waits somewhere safe. New inquiries still get saved to a spreadsheet or the CRM while the automatic reply is paused. The owner gets a note saying replies are on hold, so someone can answer by hand for a few hours. When the platform comes back, the waiting items go through.

Account ownership matters here too. I prefer to set up the software on the business’s own accounts wherever possible. When something needs attention, the owner can log in, see what happened, and act right away.

Write down what to do when it breaks

The last piece is a short written guide. It covers what the automation does, the alerts it sends and what each one means, and the first steps to take when something stops. It also names who to call.

This page matters most on the day the person who built the automation is unavailable. A clear guide lets the team handle the common problems themselves, and it makes the bigger ones faster to fix.

Questions worth asking

If you run automations today, or you are thinking about adding one, these questions are a good place to start:

• If this stopped working tonight, how would we find out, and how soon?
• Which cases does it hand to a person, and who is that person?
• What happens to new work while it is down?
• Whose accounts does it run on, and can we log in ourselves?
• Is there a written page that tells the team what to do?

If some of these are hard to answer, that is normal. They are also a useful place to look before adding anything new. Mapping how a current workflow handles its bad days is part of the AI and Automation Readiness Assessment I offer, and I am happy to talk it through on a free call.