What Your System Should Do When It Fails

Every specification describes the happy path. The enquiry arrives, it gets read, it gets routed, somebody replies.

Almost none describe what happens when the enquiry arrives and the other system is down, or the document is unreadable, or the answer is genuinely unclear. That gap is where automation earns its bad reputation.

Silent failure is the expensive one

There are three ways a system can fail and they are not equally bad.

It stops loudly. Somebody notices within the hour, work reverts to manual, it gets fixed. Annoying and cheap.

It refuses a case and says so. The best outcome available when something genuinely cannot be handled. A person picks it up with the reason attached.

It carries on and produces something wrong. Nobody is told. The wrong figure goes to a client, the enquiry is routed to the wrong person, the record is written incorrectly. Discovered weeks later, by a customer.

The third is worse than having no automation at all, because the manual process had a person who would have noticed. This is the failure that makes a business distrust the whole idea.

The four rules

Retry, then stop. Transient problems are common and most resolve on a second attempt. But a system that retries indefinitely is a system that has failed without telling anybody. Three attempts, then escalate.

Escalate to a name, not a mailbox. A shared inbox is where alerts go to be ignored. It has to reach a person who is expected to act, and that expectation has to be explicit.

Say what to do, not just what happened. An alert reading integration timeout is a technical fact. One reading three invoices could not be posted, they are in the queue, post them by hand or wait for the next run at four is an instruction. The second gets acted on.

Leave the work recoverable. Whatever failed should still be somewhere retrievable. The unforgivable version is losing the input entirely, because then nobody knows what was missed.

Let it refuse

The single most important design decision in anything with an AI step, and it is worth insisting on before a build starts.

The system must be able to say it is not confident, and that has to route to a person rather than produce a guess. A step permitted to decline can be trusted with everything else. One that always produces an answer cannot be trusted with any of it, because you have no way of knowing which outputs were guesses.

The refusals are also your early warning. A rising rate of escalations means the world has moved and the rules no longer match, and that is a signal you only get if refusing is allowed.

Decide which direction is safer

Failure is rarely symmetrical, and the design should reflect which error costs more.

On invoice approval, wrongly passing something is expensive and wrongly holding it costs five minutes. On lead routing, sending to the wrong person costs a day and holding an enquiry costs you the client. On a compliance check, a false pass is a legal exposure and a false fail is an inconvenience.

Write down which direction to fail in, per process, before anybody builds. It is a business decision and it is frequently made by default in the code otherwise.

Test it on purpose

Nobody tests failure paths, because the happy path is more satisfying to demonstrate.

Before go-live: disconnect the other system mid-run. Send a blank document. Send the same record twice in four seconds. Send something in the wrong format. Then check three things: did anybody get told, was the work recoverable, and did the message say what to do.

Once a year afterwards, trigger a real failure and confirm a human being receives it. Alerts break silently when people leave, and a system whose only warning mechanism is disconnected is running unsupervised without anybody knowing.

Failing back to a person who has stopped watching

The design assumption underneath every escalation is that somebody is available to catch it. After a year of a system working well, that assumption quietly stops holding.

The person who used to do the task has been reassigned. Nobody has seen a failure in eight months, so the alert has become background. And the knowledge of how to do it manually has decayed, because nobody has done it since the system was built.

Two cheap protections. Keep the manual instructions with the system, written at build time, so a fallback does not depend on somebody remembering. And make sure at least one person handles a real case by hand every few months, deliberately.

What AI adds to the failure path

Conventional software fails on conditions somebody anticipated. Anything unanticipated tends to become a crash or, worse, a wrong answer produced confidently.

An AI step behaves differently in a way that helps here. It can recognise that a case does not resemble anything it has handled before, and say so, without anybody having written a rule for that specific situation. That is a category of protection rules based systems cannot offer at all.

It also produces a readable explanation rather than an error code. This document is a photograph of a screen showing a spreadsheet, and I cannot identify a supplier or an invoice number is something the person receiving it can act on immediately. That difference is most of what makes an escalation useful rather than another thing in a queue.

Every system we build is designed to fail in that direction: refuse, explain, and hand over cleanly.

The question to ask your supplier

Before anything is built, ask what happens when it cannot do its job, and expect a specific answer covering all four rules.

A supplier who has thought about production answers immediately. One who talks about accuracy rates and does not mention escalation has built demonstrations rather than systems, and you will find out in month two.

AI Optimize builds the failure path first, and every system we deliver is allowed to say it is not sure. That work sits under Custom AI Integrations.