Automation agency · Support
Automation failure response
Handle a failed or misbehaving client automation the same careful way every time. The client hears facts the same day, affected records are reprocessed only under an approved plan, and the client confirms their data through a shared link before the run closes.
- Duration: 1 to 5 days
- How often: For every failed client automation
- Steps: 11 steps
- AI agents: 2 AI agents
- Approvals: 1 approval
Free plan, no credit card needed.
What changes with this template
Without it
The engineer fixes the bug quietly and the client finds the bad data a week later.
Failed records are rerun by hand, and some end up in the client's system twice.
Nobody knows exactly which records were affected.
The same failure comes back after the next change in a connected app.
With it
The client gets a checked update the same day and confirms their data at the end.
Reprocessing follows an approved plan with a duplicate check.
The engineer lists the affected records, and the client checks them in their own systems.
Every failure ends with prevention actions that have an owner, and an updated runbook.
The template, step by step
Each step says who does it: someone on your team, an AI agent, or the client through a shared link. An approval keeps every later step locked until it is given.
- Done by your team
- Done by an AI agent
- Done by the client, through a shared link
Starts when
A failure alert fires for a client automation, or the client reports wrong or missing data. The automation engineer starts a run with the client, the automation and what failed.
- 1
Log the failure and pause the automation if needed
Hour 1Automation engineer · Team
Record what failed and since when. If the automation is writing wrong data, pause it so no more records are affected.
Checklist
- Failure confirmed in the run history
- Automation paused if it writes wrong data
- Delivery manager informed
Fields to fill in
- Client name (required)
- Automation (required)
- What failed (required)
- Severity (required)
- 2
Find the affected records and the cause
Hours 1 to 4Automation engineer · Team
Use the run history and logs to list every record that failed, was skipped or was written wrongly, and note the cause or what you have ruled out.
Checklist
- Time window of the failure set
- Affected records listed
- Cause found or narrowed down
Fields to fill in
- Number of affected records (required)
- Link to the list of affected records (required)
- Cause (required)
- Type of cause (required)
- 3
Draft the client update
Hour 4Client update writer · AI agent
The client update writer turns the failure notes into a plain message: what happened, which records are affected, what has been done and what happens next.
Fields to fill in
- Draft client update (required)
Checked by: The delivery manager corrects the update and sends it in step 4.
- 4
Send the client update
Hour 4Delivery manager · Team
Correct the update so it states facts only, then email it to the client with the list of affected records and the shared run link.
Checklist
- Facts match the engineer's notes
- No guesses about the cause
- Shared link sent to the client contact
Fields to fill in
- Update as sent (required)
- 5
Confirm the impact on your side
Day 1Client contact · Shared link
After checking the emailed list against their own systems, the client notes through the shared link which records they see as wrong or missing and whether anyone has already acted on wrong data.
Checklist
- Affected records checked in your own systems
- Workarounds in place noted
Fields to fill in
- Records you see as wrong or missing (required)
- Has anyone acted on wrong data? (required)
- Workarounds in place
- 6
Fix the cause and plan the reprocessing
Days 1 to 2Automation engineer · Team
Fix the cause in the test workspace, test the fix with the failed records, and write how the affected records will be reprocessed without creating duplicates.
Checklist
- Fix tested with the failed records
- Duplicate check in the reprocessing plan
- Expired credentials or connections renewed
Fields to fill in
- Fix notes (required)
- Reprocessing plan (required)
- 7
Approve the fix and the reprocessing plan
Day 2Solutions architect · Team
Check that the fix removes the cause and that the reprocessing plan cannot create duplicates or overwrite good data.
Checklist
- Fix removes the cause, not only the symptom
- Reprocessing cannot create duplicates
- Previous version can be restored
Approval: Restarting the automation and reprocessing stay locked until the solutions architect approves the fix and the plan.
- 8
Restart the automation and reprocess the records
Day 2Automation engineer · Team
Release the fix, restart the automation, reprocess the affected records and check each one against the list.
Checklist
- Fix released
- Automation restarted
- Every affected record reprocessed or corrected
Fields to fill in
- Records reprocessed (required)
- Records corrected by hand
- 9
Confirm your data is correct
Days 2 to 3Client contact · Shared link
Through the shared link, the client checks the reprocessed records in their own systems and confirms the data is correct, or notes what is still wrong.
Fields to fill in
- Data is correct (required)
- What is still wrong
- 10
Draft the incident review
Day 3Incident review writer · AI agent
The incident review writer summarises the run: timeline, cause, impact, fix and proposed prevention actions.
Fields to fill in
- Draft incident review (required)
Checked by: The solutions architect corrects the review and agrees the prevention actions in step 11.
- 11
Agree the prevention actions
Hidden from the shared linkDays 3 to 5Solutions architect · Team
Correct the review, decide which prevention actions to take and who owns each, and add the new failure case to the runbook.
Checklist
- Review corrected
- Each prevention action has an owner
- Runbook covers the new failure case
Fields to fill in
- Prevention actions and owners (required)
- Link to the updated runbook (required)
Done when
The automation runs correctly again, every affected record is fixed, the client has confirmed their data, and the prevention actions have owners.
Make it yours. Rename steps, change owners and add checklist items, fields or approvals. The template is a starting point for the way your team works.
The AI agents in this template
An agent only works on its own steps, and a person on your team checks what it did. Anything an agent writes to a connected app waits for approval unless you allow it.
Client update writer
Turns the engineer's failure notes into a plain update for the client.
What it does
- Reads the failure, the cause and the affected records filled in on the run
- Writes what happened, what is affected and what happens next
- Records the draft update in its step and completes it
Checked by: The delivery manager corrects the update and sends it in step 4.
Incident review writer
Summarises the whole run into a short incident review.
What it does
- Reads the values and checklists of every earlier step
- Writes the timeline, cause, impact and fix
- Proposes prevention actions for a person to decide on
- Records the draft review in its step
Checked by: The solutions architect corrects the review and agrees the prevention actions in step 11.
Questions this template answers
Pause the automation if it writes wrong data, find every affected record, tell the client what you know, and only then fix and reprocess. Steps 1 and 2 pause the automation and list the affected records, and step 4 sends the client a checked update before any fix is released.
Write a reprocessing plan with a duplicate check and have a second person approve it before anything runs again. Step 6 asks for that plan next to the fix, and step 7 is an approval gate that keeps the restart locked until the solutions architect approves both.
Send facts the same day: what happened, which records are affected, what you have done and when they hear from you next. Step 3 drafts that update from the engineer's notes, and in step 4 the delivery manager removes any guesses and emails it to the client with the shared link.
Set the time window of the failure, list every record that failed, was skipped or was written wrongly, and let the client check their side. Step 2 lists the affected records, step 4 emails that list to the client, and in step 5 the client confirms through the shared link what they see as wrong or missing.
Review every failure for its cause and give each prevention action an owner. Step 10 drafts the incident review, and in step 11 the solutions architect agrees the prevention actions and adds the new failure case to the runbook.
Let AI write the client update and the incident review from the engineer's notes, and keep a person between the AI and the client. Step 3 drafts the update for the delivery manager to correct in step 4, and step 10 drafts the review for the solutions architect to correct in step 11.
Run this workflow in OKiDO
Set up the steps, owners and approvals once, then start a run for every new case.