Your automation needs a bad-day plan.

The demo never has a bad Tuesday

The automation reads a request, checks a record, and prepares the right response. In the demo, every document is legible, every account exists, and the external service answers immediately. The system looks ready because the happy path is ready.

Then a supplier changes a document format. A service times out after accepting a request. A holiday produces three times the normal volume. Forty exceptions land in a queue nobody owns. The automation is still technically running, but the business has acquired a second job: discovering which work did not happen.

A small team does not need an elaborate operations department to avoid this. It needs a bad-day plan: a definition of acceptable failure, a route for exceptions, a limit on repeated attempts, and a person who can stop the workflow before its backlog becomes the customer’s problem.

Google’s SRE workbook describes error budgets as a way to connect reliability targets with operational decisions. When reliability falls outside the agreed allowance, work shifts toward restoring it. ^[1] The workflow below adapts that idea to business automation. It is a proposed management pattern, not a claim that a support queue and a distributed service have identical reliability requirements.

Define success at the business boundary

“The model returned valid JSON” is an intermediate check. “The right customer received an accurate response within the promised time” is an outcome. A workflow can satisfy the first while failing the second in several expensive ways.

Write the completion condition in terms a customer or operator could verify. For an invoice assistant, success might mean the correct invoice is matched, the proposed action is within authority, and the case is either completed or routed to a named reviewer before its deadline. A well-routed exception can be a successful system outcome even when automation does not complete the whole task.

Separate severity classes. An unclear description that needs review is different from a duplicate charge or a message sent to the wrong person. Do not allow a high volume of harmless successes to compensate for a critical error. Some events should stop the affected action immediately, regardless of the monthly average.

Then define a realistic service objective for the routine work. For example, a team might aim to complete or correctly route 98% of eligible cases within one business day. That target needs a precise denominator, a clock, and a way to identify ineligible cases. It is not a magic number and should not be copied without understanding the workload.

Budget review capacity, not just model calls

Suppose a hypothetical workflow handles 2,000 requests per week. Two percent require human review: forty cases. At four minutes per case, that is 160 minutes of review. The team has set aside 400 minutes per week, equivalent to one hundred ordinary cases. Under those assumptions, the normal queue fits with room for variation.

Now the exception rate reaches 5%. One hundred cases consume the full 400-minute allowance. The automation can still advertise a 95% automatic-completion rate, but there is no spare review capacity. A staff absence, a complicated case, or a small burst creates a backlog.

At fifteen percent, three hundred cases require 1,200 minutes. That is twenty hours of review against less than seven hours reserved. Buying more model capacity does not solve that bottleneck. Neither does hiding the exception queue behind a success percentage.

These figures are illustrative, and the four-minute average conceals variation. A few difficult cases can dominate the week. Track queue age, oldest unresolved deadline, and the distribution of handling times as well as the count. If urgent cases matter more than routine ones, give them an explicit priority rule rather than relying on whoever notices them first.

The design question is therefore not only “How often does the system fail?” It is also “Can the business absorb the failures when they arrive together?”

A retry is an action with consequences

Some failures are safe to retry. Others are ambiguous: the request may have succeeded, but the confirmation was lost. Repeating a read is usually a different risk from repeating a payment, booking, or customer message.

AWS’s discussion of idempotent APIs explains a useful pattern: a caller supplies a unique request identifier so repeated attempts can be recognized as the same intended operation. It also explains why identical parameters alone may not identify intent; a caller can legitimately want two similar actions. ^[2]

For a proposed order-status assistant, assign an action identifier before sending a message. If the external service times out, check the recorded operation or delivery status before asking the system to send again. When the service cannot establish the result, route the ambiguity for review rather than assuming that silence means failure.

Put a ceiling on automatic retries and distinguish temporary faults from invalid requests. Retrying malformed input fifty times produces fifty failures, not resilience. Record the reason for stopping so the reviewer can continue from a known state.

Most importantly, do not let the model decide its own authority after an error. A fallback route should have the same or narrower permissions than the normal route. “The usual tool failed” is not a reason to bypass approval or send sensitive data to a different service.

Give the system a stop rule before it needs one

Choose operational triggers tied to the risks that matter. A critical wrong-recipient event might disable outbound messages immediately. A rising ordinary exception rate might pause new intake, switch to drafts, or reduce the workflow to a smaller well-understood task. An aging queue might trigger reassignment before customer deadlines are missed.

Write who owns each decision. A dashboard with a red number is not a response plan. Someone needs to know whether to stop the worker, continue read-only processing, notify an operator, or restore the previous version. Keep the stop control accessible outside the model itself.

Test one bad-day scenario before expanding volume. Remove a required field from a sample document. Simulate a service timeout. Feed the workflow an already-completed case. Check whether the result lands in the right place with enough context to resolve it. These are targeted operational exercises, not proof that every possible failure has been covered.

After an incident, separate the triggering event from the design weakness. A supplier changed its template; the weakness may be that the system continued acting on low-confidence extraction without a review path. Fixing only the new template leaves the same failure mode waiting for the next supplier change.

Earn the right to remove a manual step

Start with a bounded job and observe its exception pattern. An assistant that prepares drafts can reveal the workload’s ambiguity before it gains the ability to send them. A system that suggests a record match can be evaluated before it modifies the record. This is not a permanent requirement to keep a human in every loop; it is a way to learn where the useful boundaries belong.

The AI workflow evaluator can help document the job, cost, and acceptance conditions. Pair that with a simple operating record: requests received, outcomes completed, exceptions by cause, oldest open case, and actions stopped. The record should explain where work went, not merely how many tokens were consumed.

As performance improves, reduce review where the evidence supports it. Preserve checks around high-consequence actions and unfamiliar cases. If a new document type or integration changes the workload, treat the old success rate as historical evidence rather than a guarantee.

A useful automation gives the team more capacity on an ordinary day and leaves it in control on a bad one. If the system saves two hours while creating an unowned exception queue, the business has not eliminated the work. It has made the work harder to see.