Automation agency · Delivery
Automation build and client handover
Take a client automation from signed statement of work to an accepted handover without building on guesses or going live after one good test. The client grants access and accepts the result through a shared link, and nothing reaches production before the solutions architect approves it.
- Duration: 3 to 5 weeks
- How often: For every client automation project
- Steps: 12 steps
- AI agents: 2 AI agents
- Approvals: 2 approvals
Free plan, no credit card needed.
What changes with this template
Without it
Engineers build on guesses until the client's IT team sends access and real sample files.
The automation goes live the moment the happy path works once.
How the automation works, and how to pause it, lives in one engineer's head.
Solution designs and runbooks are written from scratch on every project.
With it
The client grants access and shares sample data through one link, and the run shows what is still missing.
Go-live waits for the full test checklist and the solutions architect's approval.
Every client gets a checked runbook and accepts it on the shared link.
AI agents draft the design and the runbook, and a person on the team checks both.
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
The client signs the statement of work. The delivery manager starts a run with the client name, the process to automate and the target go-live date.
- 1
Share the run link and book the discovery session
Day 1Delivery manager · Team
Send the client contact the shared run link, so they see which access and sample data you need, and book the discovery session.
Checklist
- Shared link sent to the client contact
- Discovery session booked
- Solutions architect and engineer assigned
Fields to fill in
- Client name (required)
- Process to automate (required)
- Client contact email (required)
- Target go-live date (required)
- 2
Map the current process in a discovery session
Week 1Solutions architect · Team
Walk through the process with the client: inputs, systems, volumes, known exceptions and who owns each part. Agree what the automation will not do.
Checklist
- Inputs, systems and volumes noted
- Owner of each part named
- Out-of-scope cases agreed
Fields to fill in
- Discovery notes (required)
- Exceptions the automation must handle (required)
- Out of scope
- 3
Grant test access and share sample data
Week 1Client contact · Shared link
Through the shared link, the client grants access to a test workspace for each system and shares a link to real sample files, including examples of the known exceptions.
Checklist
- Test workspace access granted
- API or service account access granted
- Samples include the known exceptions
Fields to fill in
- Link to the sample files (required)
- Systems you granted access to (required)
- Technical contact for access questions
- 4
Draft the solution design and test cases
Week 1Design drafter · AI agent
The design drafter turns the discovery notes and exceptions into a first solution design: trigger, data mapping, error handling, alerts, and a test case for the normal path and each exception.
Fields to fill in
- Draft solution design (required)
- Draft test cases (required)
Checked by: The solutions architect corrects and approves the design in step 5.
- 5
Approve the design before the build
Hidden from the shared linkWeek 2Solutions architect · Team
Correct the design and test cases, and test the client's access yourself. If access or samples are missing, mark the run blocked and note what is missing.
Checklist
- Every exception has a test case
- Error handling and alerts defined
- Test access works
Fields to fill in
- Missing access or samples
Approval: The build stays locked until the solutions architect approves the design.
- 6
Build the automation in the test workspace
Weeks 2 to 3Automation engineer · Team
Build against the approved design, with logging, retries on every external call and an alert when a run fails.
Checklist
- Logging on every step
- Retries on external calls
- Failure alert goes to the agreed channel
Fields to fill in
- Build notes (required)
- Link to the workflow export or repository (required)
- 7
Run every test case, including failure paths
Week 3Test lead · Team
Run each test case from the approved design on the sample data and record what passed and what failed, with a link to the evidence.
Checklist
- Normal path passes
- Bad input is rejected and flagged
- Duplicates are caught
- Retries and failure alerts work
Fields to fill in
- Test results (required)
- Link to the test evidence (required)
- 8
Approve go-live
Week 4Solutions architect · Team
Review the test results, the build notes and the rollback plan, then approve the move to production.
Checklist
- Every test case passed
- Rollback plan is realistic
- Client knows the go-live date
Fields to fill in
- Rollback plan (required)
Approval: Production, client acceptance and handover stay locked until the solutions architect approves go-live.
- 9
Draft the runbook
Week 4Runbook writer · AI agent
The runbook writer turns the build notes, test results and rollback plan into a runbook: what the automation does, how to spot a failure, how to pause and restart it, and who to contact.
Fields to fill in
- Draft runbook (required)
Checked by: The automation engineer checks the runbook against the build in step 10.
- 10
Go live and finish the runbook
Week 4Automation engineer · Team
Check the draft runbook against the build and correct it, switch the automation on in production, watch the first live runs and email the client the final runbook.
Checklist
- Runbook matches the build
- Automation switched on in production
- First live runs checked
Fields to fill in
- Go-live date (required)
- Link to the final runbook (required)
- 11
Run real cases and accept the automation
Week 4Client contact · Shared link
The client checks real cases in their own systems and reads the runbook the engineer emailed them, then records their decision through the shared link, with what still needs to change if they do not accept yet.
Checklist
- Real cases checked in your own systems
- Runbook read
- You know how to pause the automation
Fields to fill in
- Decision (required)
- What still needs to change
- 12
Hand over and start support
Week 4Delivery manager · Team
Confirm the support terms with the client, book the first check-in and reduce the agency's access to what support needs.
Checklist
- Support terms confirmed
- Client knows how to report a failure
- Agency access reduced to what support needs
Fields to fill in
- Support start date (required)
- First check-in date (required)
Done when
The automation runs in production, the client has accepted it, and their team has a checked runbook for the day something fails.
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.
Design drafter
Turns the discovery notes into a first solution design and a set of test cases.
What it does
- Reads the discovery notes and exceptions filled in on the run
- Follows the design format in its step instructions
- Writes the draft design and a test case for each exception
- Completes its step, so the review can start
Checked by: The solutions architect corrects and approves the design in step 5.
Runbook writer
Turns the build notes, test results and rollback plan into a first runbook for the client.
What it does
- Reads the build notes, test results and rollback plan on the run
- Writes what the automation does, how to spot a failure and how to pause it
- Records the draft runbook in its step
Checked by: The automation engineer checks the runbook against the build in step 10.
Questions this template answers
Give the client a runbook that says what the automation does, how to spot a failure, how to pause it and who to contact, and have them accept it. Step 9 drafts that runbook from the build notes and test results, step 10 checks it against the build and emails it to the client, and in step 11 the client accepts it through the shared link.
Make go-live depend on a full set of test cases, including bad input, duplicates and failures, and on a named approver. Step 7 holds the test checklist for every failure path, and step 8 is an approval gate that keeps production locked until the solutions architect approves the results.
Ask for every access and sample file in one place, with the exceptions you need examples of, before the build starts. In step 3 the client grants access and shares links to sample files through the shared link, and in step 5 the solutions architect marks the run blocked and notes what is still missing.
A runbook covers what the automation does, what triggers it, how a failure shows up, how to pause and restart it, how to reprocess failed records and who to contact. Step 9 drafts those sections from the build notes, test results and rollback plan, and the automation engineer corrects them in step 10.
Let AI turn the discovery notes into a first design and test cases, and keep the decision with the solutions architect. In step 4 the design drafter writes the trigger, data mapping, error handling and a test case for each exception, and step 5 is where the solutions architect corrects and approves it.
Record the test results, the approval and the client's acceptance on the project itself, not in chat threads. Step 7 records the results with a link to the evidence, step 8 records the go-live approval with name and time, and step 11 records the client's decision.
Run this workflow in OKiDO
Set up the steps, owners and approvals once, then start a run for every new case.