AI & automation
What happens when a business automation fails?
Plan failure records, alerts, safe retries and a manual fallback before an automated handover goes live.
An automation will eventually meet missing data, a changed connection or a service that is unavailable. The important design question is what happens to the work in progress. A reliable workflow leaves a visible record, tells the right person and provides a safe route to continue.
Use a small example
Imagine a website enquiry should create a record in a business tracker. This is an illustrative design, not a description of a deployed client system. The form receives the enquiry, but the tracker rejects the request because a required field is missing.
The business should still be able to find the original enquiry. The customer should not be told that the tracker was updated if it was not. A named owner should see the failure and decide whether to complete the field, contact the customer or use the manual route.
| Question | Proposed answer for this example |
|---|---|
| What is retained? | The accepted enquiry and a reference to the failed tracker action. |
| Who is alerted? | The person responsible for the enquiry workflow. |
| What can retry automatically? | A temporary connection error, within a limited number of attempts. |
| What needs review? | Missing or conflicting customer data. |
| What is the fallback? | Create the tracker entry manually from the original enquiry. |
Do not retry every error
A temporary timeout may be worth retrying after a short wait. A rejected field value will probably fail again until someone corrects it. A payment or customer message needs special care: blind retries can cause duplicate charges or repeated emails. Use an identifier that lets the receiving system recognise a repeat request where the system supports it, and verify the action's outcome before trying again.
Decide when the workflow stops retrying and who owns the next action. “It will retry later” is incomplete if no one knows how long later is or whether the task eventually succeeded.
Make failure visible and recoverable
A useful failure record includes the task reference, time, step that failed, a safe error summary, retry count and current owner. It should avoid copying unnecessary personal information into logs. A small dashboard, notification or daily review queue can be enough when someone is responsible for checking it.
Test at least three cases before launch: the destination is unavailable, a required field is missing, and the destination accepts the action but the confirmation is lost. For each, confirm the original work is still accessible and the manual fallback does not create a duplicate.
This planning is part of business automation, not an optional feature to add only after the first failure. A good first workflow can recover from a bad day without leaving a customer request invisible.
Put the thinking into practice
Make the next step clearer.
Explore how I can help with AI and automation, or tell me what you have in mind.
Explore ai & automation