What happens when an automation breaks or my business process changes?

Some failures look successful

A workflow may create a duplicate customer, send incomplete information, use an old price, or stop reading one source while still reporting that it ran. Quiet failures are dangerous because the team assumes the work is complete. For each important step, decide what evidence proves the intended result.

For a scheduling flow, success is not “request sent.” It may require a confirmed calendar event with the correct service, time, customer, and staff assignment. For a lead flow, it may require a readable record in the monitored queue rather than a log entry in a tool nobody opens.

Protect the exception path

If a destination is unavailable or a record is incomplete, keep the original request—or a safe reference to it—in a protected exception store. Restrict access, define retention and deletion, and make retries safe against duplicates. An email alert should identify the affected work and next action without copying sensitive customer information into inboxes or logs.

Assign failures to a person or a queue the team actually monitors. A dashboard, alert, and recovery instruction are different controls; the process needs all three in a form appropriate to the consequence of failure.

• Show the last confirmed step and the step that failed.
• Redact alert content and link authorized staff to the protected record.
• Preserve enough evidence to recover without keeping data indefinitely.
• Test retries for duplicate messages, bookings, charges, and records.

Keep a manual route available

Write down how the team receives and finishes work while the automation is paused. A plumbing company might route after-hours calls back to voicemail and a shared callback list; an office might use a manual calendar request until its scheduling connection is restored.

Practice the fallback with test data. Turn off a connection, submit incomplete information, and confirm that staff can locate the request, explain the delay honestly, and finish the work without the original builder.

Treat business changes as releases

New service areas, prices, team members, forms, or approval policies can make yesterday's correct workflow wrong. Name the business changes that require review and keep important rules in one maintainable source instead of copying them into several tools.

Test representative cases before releasing a change. Preserve a known working configuration or manual process when customers, money, or restricted information could be affected, and record who approved the change.

Review failures for patterns

A one-off outage and a recurring design problem need different responses. Review exception volume, age, cause, recovery time, and duplicate or incorrect outcomes. If staff constantly correct the same automation, the work has moved rather than disappeared.

Use that evidence to fix one cause, narrow the workflow, or retire it. Reliability is not a promise that nothing will fail; it is the ability to see what happened, contain the impact, and recover responsibly.