The booking form says “Thanks, we received your request.” The integration behind it stopped working six hours ago. No lead reached the schedule, and nobody knows which customers need a call.
An automation needs an outage plan before it earns control of important work.
List the workflows that can hurt the day
Start with automations tied to revenue, customer promises, money, or safety. Record the tool, owner, input, output, and manual alternative.
| Workflow | Normal result | Owner | Manual fallback |
|---|---|---|---|
| Website inquiry | Lead and callback task | Office manager | Check form mailbox and create task |
| Appointment reminder | Customer confirmation | Dispatcher | Call next-day appointments |
| Invoice import | Draft bill in accounting | Bookkeeper | Enter from invoice queue |
Do not document every convenience script. Focus on the failures that can lose a customer, miss a deadline, or corrupt a record.
Decide whether each workflow fails open or closed
Some workflows should stop when a dependency fails. A quote should not send without confirmed pricing. A payment workflow should not retry charges without clear rules.
Other workflows should accept the input and queue it for later. A contact form can store the request and alert the office that normal routing failed.
Write the choice beside each workflow. Developers call these fail-open and fail-closed decisions. Your team can use plainer labels: “keep collecting” or “stop and ask for help.”
Make failure visible
Silence causes the worst outages. The system needs to tell a named person when:
- no successful run occurs inside the expected window
- a connection rejects requests
- queued items pass a limit
- records fail validation
Send one actionable alert with the workflow name, first failure time, affected item count, and fallback instructions. Do not send the same error every minute.
The owner should not receive every technical alert. Route the first response to the person who runs the process. Escalate when customers or money face a deadline.
Keep a manual kit
Store the fallback checklist where employees can reach it without the failed tool. Include:
- how to confirm the outage
- where new inputs remain available
- how to record manual work
- which customer promises need attention
- who can approve recovery
Keep a blank intake sheet or export template with the checklist. During an outage, the team should record stable IDs, timestamps, and actions. Those details prevent duplicate work during recovery.
Protect the queue
Confirm where the system stores work that cannot reach the next tool. A retry log on one employee’s laptop is not a business queue.
Set a retention period long enough to cover a weekend or vendor outage. Restrict access because queued forms and invoices may contain customer information.
Test whether the queue preserves the original item, failure reason, attempt count, and time. Those fields help the team decide whether to retry, correct, or cancel each record.
Reconcile before you restart
When service returns, do not push every queued item through at once.
Compare the queue with the records employees handled by hand. Mark each item as processed, canceled, duplicate, or ready. Send customer messages only after checking whether a person already replied.
Restore the workflow in batches. Watch for duplicate appointments, repeated invoices, and messages that arrive out of order.
Run a short recovery drill
Choose one workflow and pretend its connection failed for 30 minutes. Ask the process owner to use the fallback without help from the person who built it.
Time how long the team takes to notice the failure, find the queued work, and resume. Fix missing passwords, stale screenshots, and unclear ownership while the exercise costs nothing.
Repeat the drill after a major tool or staffing change. A runbook with the former office manager’s name does not count as a plan.
Review the cause without hunting for blame
Record the dependency that failed, how the team noticed, which work waited, and which safeguard would reduce the next impact.
You may need a health check, a larger queue, a second notification path, or a simpler integration. Fix the smallest control that addresses the observed failure.
Automation should make the business less dependent on memory. An outage plan keeps the automation from becoming a new single point of failure.
If one broken connection can hide a day of customer requests, book a free Opportunity Scan. We can map the fallback before the next outage finds it for you.