Software agency · Delivery
Software delivery and client acceptance
Get every milestone from agreed requirements to a client sign-off on record. The client confirms the acceptance criteria and signs off through a shared link, and no build reaches them before QA and the engineering lead approve it.
- Duration: 4 to 8 weeks
- How often: For every milestone
- Steps: 11 steps
- AI agents: 2 AI agents
- Approvals: 3 approvals
Free plan, no credit card needed.
What changes with this template
Without it
The client remembers a must-have feature during the sprint demo.
A build lands on staging the night before the client demo, half tested.
Acceptance is a thumbs-up on a call that nobody can find a month later.
QA writes every test plan from scratch.
With it
The client confirms the acceptance criteria before development starts, so the team builds against one list.
Client testing stays locked until QA and the engineering lead approve the release.
The client signs off on the run, with the ticked checks, their name and the time.
An AI agent drafts the test plan from the criteria, and the QA engineer reviews it.
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 milestone from the statement of work is ready to start. The product manager starts a run with the client name and the milestone.
- 1
Write the scope and acceptance criteria
Week 1Product manager · Team
Turn the milestone in the statement of work into user stories with testable acceptance criteria, list the questions the client still has to answer, and email both with the designs to the client product owner.
Checklist
- Every story has acceptance criteria
- Out of scope items listed
- Criteria and designs sent to the client
Fields to fill in
- Milestone (required)
- Acceptance criteria (required)
- Questions for the client
- Link to the designs (required)
- 2
Client confirms the requirements
Week 1Client product owner · Shared link
The client product owner reads the acceptance criteria, designs and questions the product manager emailed, then answers the questions and confirms the scope through the shared link. The team builds and tests against what is confirmed here.
Checklist
- Acceptance criteria read
- Designs reviewed
- Open questions answered
Fields to fill in
- Answers to the open questions
- Link to business rules or examples
- I confirm the acceptance criteria (required)
- 3
Draft the test plan
Week 1Test plan writer · AI agent
The test plan writer turns each confirmed acceptance criterion into test cases with steps and expected results, and adds regression checks for the features the milestone touches.
Fields to fill in
- Draft test plan (required)
Checked by: The QA engineer reviews and completes the test plan in step 4.
- 4
Review the test plan
Hidden from the shared linkWeek 2QA engineer · Team
Check that every acceptance criterion has a test case, add the edge cases the draft missed and link the final test plan.
Checklist
- Every criterion has a test case
- Edge cases added
- Test data ready on staging
Fields to fill in
- Link to the final test plan (required)
- 5
Build and review in sprints
Weeks 2 to 5Engineering lead · Team
Build the stories in sprints and review every change before it is merged. If the team is waiting on a client answer, mark the run blocked and note the question.
Checklist
- Every change reviewed before merge
- Sprint demos held with the client
- No open client questions
Fields to fill in
- Planned release date (required)
- Sprint notes (required)
- Link to the merged work (required)
- What the team is waiting for
- 6
Test on staging against every criterion
Hidden from the shared linkWeek 6QA engineer · Team
Run the test plan on staging, log defects in the issue tracker and retest the fixes until no critical or major bug is open.
Checklist
- Every criterion tested
- Regression checks run
- No open critical or major bugs
- Known minor issues listed
Fields to fill in
- Link to the test report (required)
- Known issues
Approval: The release approval stays locked until the QA engineer approves the test results.
- 7
Draft the release notes
Week 6Release notes writer · AI agent
The release notes writer drafts client-facing release notes from the acceptance criteria, the sprint notes and the known issues: what is new, what changed and what is still open.
Fields to fill in
- Draft release notes (required)
Checked by: The engineering lead corrects the notes and approves the release in step 8.
- 8
Approve the release for client testing
Week 6Engineering lead · Team
Read the test report, correct the release notes and check that staging runs the tested build. Then approve it and email the client product owner the staging link and the release notes.
Checklist
- Test report read
- Release notes corrected
- Staging runs the tested build
Fields to fill in
- Staging link sent to the client (required)
Approval: Client testing stays locked until the engineering lead approves the release.
- 9
Client tests on staging and signs off
Week 7Client product owner · Shared link
The client product owner tests the staging build from the link the team emailed against the acceptance criteria, then ticks each check and records their decision through the shared link. Problems go in the field below, with links to screenshots or recordings.
Checklist
- Every acceptance criterion tested
- Release notes read
Fields to fill in
- Decision (required)
- Problems found
- Links to screenshots or recordings
- 10
Decide on the client's findings
Week 7Product manager · Team
Go through the decision and every finding with the engineering lead. If a finding blocks acceptance, mark the run blocked with the reason until the fix is verified and the client agrees, then approve the production release.
Checklist
- Every finding marked blocking or not
- Blocking findings fixed and verified
- Other findings planned for a later milestone
Fields to fill in
- Findings moved to a later milestone
Approval: The production release stays locked until the product manager approves it.
- 11
Release to production and close the milestone
Week 7DevOps engineer · Team
Deploy the accepted build with the rollback plan ready, run the smoke tests and record the released version.
Checklist
- Rollback plan ready
- Smoke tests passed
- Monitoring checked after release
Fields to fill in
- Released version (required)
- Released on (required)
Done when
The client has signed off the milestone against the agreed criteria, and the release is live with its test report, approvals and sign-off on the run.
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.
Test plan writer
Turns the confirmed acceptance criteria into a draft test plan.
What it does
- Reads the acceptance criteria and the client's answers on the run
- Writes test cases with steps and expected results
- Adds regression checks for the features the milestone touches
- Completes its step, so the QA engineer can review
Checked by: The QA engineer reviews and completes the test plan in step 4.
Release notes writer
Drafts client-facing release notes for the build that goes to client testing.
What it does
- Reads the acceptance criteria, sprint notes and known issues
- Writes what is new, what changed and what is still open
- Keeps the notes in plain language for the client
- Completes its step, so the release approval can start
Checked by: The engineering lead corrects the notes and approves the release in step 8.
Questions this template answers
Ask for the sign-off against the acceptance criteria the client confirmed at the start, not against a demo. In step 9 the client product owner tests on staging, then ticks each check and records their decision through the shared link, with their name and the time on the run.
Agree on testable acceptance criteria before development starts, and have the client confirm them on record. In step 2 the client product owner answers the open questions and confirms the criteria through the shared link, so the team builds and tests against one agreed list.
Make client testing depend on approved test results, not on the demo date. Steps 6 and 8 are approval gates: client testing stays locked until the QA engineer and the engineering lead have both approved the release.
Keep the acceptance criteria, the test results and the client's decision on one record. The run shows the criteria confirmed in step 2, the test results and approvals from steps 6 and 8, and the sign-off from step 9 with name and time.
Let AI draft the test plan and the release notes from what your team already wrote, and keep the review with people. In step 3 the test plan writer drafts test cases for the QA engineer to review in step 4, and in step 7 the release notes writer drafts notes the engineering lead corrects in step 8.
Separate the bugs that block acceptance from the issues that can wait, and let a person make that call. In step 10 the product manager marks every finding as blocking or not, keeps the run blocked until blocking fixes are verified, and only then approves the release.
Run this workflow in OKiDO
Set up the steps, owners and approvals once, then start a run for every new case.