Automation agency · Delivery
Change request for a live automation
Handle every change to a delivered automation as a small, controlled release instead of a quick fix in production. The client describes and approves the change through a shared link, billable hours are agreed before work starts, and nothing reaches production before the solutions architect approves the test results.
- Duration: 3 days to 2 weeks
- How often: For every change to a live automation
- Steps: 11 steps
- AI agents: 1 AI agent
- Approvals: 2 approvals
Free plan, no credit card needed.
What changes with this template
Without it
Change requests arrive in chat and get built straight in production.
Small changes pile up as work nobody bills.
The runbook still describes the automation as it was at handover.
The client notices a change when something behaves differently.
With it
Every change gets an impact check, a test run and a release approval.
Each change is marked included or billable, and the client approves the hours first.
The runbook is updated with every release.
The client approves a change summary and confirms the result on the shared link.
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 client asks for a change to an automation that is already live. The delivery manager starts a run with the client name and the automation concerned.
- 1
Log the change request
Day 1Delivery manager · Team
Record which automation the change is for and send the client contact the shared run link, so they can describe the change in their own words.
Checklist
- Shared link sent to the client contact
- Current runbook found
Fields to fill in
- Client name (required)
- Automation to change (required)
- Client contact email (required)
- 2
Describe the change and share examples
Days 1 to 2Client contact · Shared link
Through the shared link, the client describes what should change and why, and shares a link to example records of the new case.
Checklist
- Example records shared
- Person who decides on the change named
Fields to fill in
- What should change (required)
- Why it is needed
- Link to example records
- Needed by
- 3
Assess the impact and estimate the work
Hidden from the shared linkDays 2 to 3Automation engineer · Team
Check which steps and systems the change touches, what could break for existing runs, and whether the support terms cover it.
Checklist
- Affected steps and systems listed
- Risk to existing runs noted
- Regression test cases chosen
Fields to fill in
- Impact notes (required)
- Estimated hours (required)
- Billing (required)
- 4
Draft the change summary
Day 3Change summary writer · AI agent
The change summary writer turns the request and the impact notes into a short summary for the client: what changes, what stays the same, the estimate and the test plan.
Fields to fill in
- Draft change summary (required)
Checked by: The delivery manager corrects and approves the summary in step 5.
- 5
Approve the change summary
Hidden from the shared linkDay 3Delivery manager · Team
Correct the summary, check the estimate and billing against the support terms, set the planned release date, and email the approved summary to the client.
Checklist
- Summary matches the impact notes
- Billing matches the support terms
- Release date is realistic
Fields to fill in
- Planned release date (required)
Approval: The client's decision and the build stay locked until the delivery manager approves the change summary.
- 6
Approve the change and its cost
Days 3 to 5Client contact · Shared link
The client reads the change summary the delivery manager emailed, then records their decision through the shared link, including any billable hours.
Checklist
- Change summary read
- Billable hours accepted, if any
Fields to fill in
- Decision (required)
- Purchase order or reference
- 7
Build and retest the change outside production
Week 2Automation engineer · Team
Once the client has approved, make the change in the test workspace and rerun the chosen regression test cases plus a new test case for the change.
Checklist
- Change built in the test workspace
- New test case passes
- Regression test cases pass
Fields to fill in
- Test results (required)
- Link to the updated workflow export (required)
- 8
Approve the release
Week 2Solutions architect · Team
Review the test results and the release notes, and check that you can return to the previous version.
Checklist
- Regression results reviewed
- Previous version can be restored
- Client knows the release time
Fields to fill in
- Release notes (required)
Approval: The production release stays locked until the solutions architect approves the test results.
- 9
Release the change and update the runbook
Week 2Automation engineer · Team
Release the change in production, watch the first live runs, and update the runbook with what changed.
Checklist
- Change released in production
- First live runs checked
- Runbook updated
Fields to fill in
- Release date (required)
- Link to the updated runbook (required)
- 10
Confirm the change works
Week 2Client contact · Shared link
Through the shared link, the client checks real cases in their own systems and confirms the change works, or describes what is still wrong.
Fields to fill in
- Works as agreed (required)
- What is still wrong
- 11
Record the hours and close the change
Hidden from the shared linkWeeks 2 to 3Delivery manager · Team
Record the hours spent, pass billable hours to invoicing and close the run.
Checklist
- Hours recorded
- Billable hours passed to invoicing
Fields to fill in
- Hours spent (required)
- Billable hours
Done when
The change runs in production, the runbook is updated, the client has confirmed the result, and any billable hours are recorded for invoicing.
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.
Change summary writer
Turns the client's request and the engineer's impact notes into a change summary the client can approve.
What it does
- Reads the change request and the impact notes on the run
- Writes what changes, what stays the same, the estimate and the test plan
- Records the draft summary in its step and completes it
Checked by: The delivery manager corrects and approves the summary in step 5.
Questions this template answers
Treat every change as a small release with its own impact check, client approval, test run and release approval. Step 3 checks what the change touches before anything is promised, and the client approves the change summary in step 6 before any work starts.
Decide for every change whether the support terms cover it or it is billed separately, and get the client's approval before the work starts. In step 3 the engineer marks the change as included or billable with an estimate, and in step 6 the client approves the summary and any billable hours through the shared link.
Make the change in a test workspace, rerun the existing test cases next to a new one for the change, and let someone else approve the release. Step 7 builds and retests the change outside production, and step 8 is an approval gate that keeps production locked until the solutions architect approves the results.
Let AI write the change summary the client has to approve, from the request and the engineer's impact notes. In step 4 the change summary writer drafts what changes, what stays the same, the estimate and the test plan, and in step 5 the delivery manager corrects and approves it.
Make the runbook update part of every release instead of a separate task for later. Step 9 has the runbook update on its checklist and asks for a link to the updated runbook before the client confirms the change in step 10.
Email them a short summary with the estimate and let them record their decision where the work is tracked. Step 5 emails the approved change summary, and in step 6 the client records their decision through the shared link, so the run shows who completed that step and when.
Run this workflow in OKiDO
Set up the steps, owners and approvals once, then start a run for every new case.