Published
Agency website acceptance checklist: a worked pilot pack
A worked acceptance pack for an agency website pilot, covering repeatable tests, approval owners, launch blockers and the handover.
Agree how the agency, client and developer will decide a website is ready to launch before reviewing the finished build.
An acceptance pack connects each important requirement to a repeatable check. It records the result, names the person who can make the next decision and sets out what must be handed over.
The worked example below is hypothetical. It describes a small service website, not a Kyln client project or evidence of completed work.
Define what the pilot includes
In this example, the client needs visitors to find a service and submit an enquiry. The agency supplies approved designs and copy. The developer builds the agreed layouts, editing fields and enquiry route.
The first release includes:
A homepage.
Service pages using one layout.
A case-study layout.
Editing of existing content and the ability to add a case study.
Online booking and a customer login are excluded. Put these boundaries in the agreed scope before testing starts. An acceptance pack cannot resolve a disagreement about what was sold.
Name who can approve each decision
Someone who can comment on a preview may not have authority to accept delivery or authorise launch. Record the names and contact routes for the roles below.
| Decision or task | Hypothetical pilot owner |
|---|---|
| Confirm technical checks and record results | Developer |
| Review the build against the approved design | Agency design lead |
| Check copy and factual content | Client content owner |
| Combine feedback and confirm which requests change scope | Agency account lead with developer |
| Accept the agreed delivery | Named agency approver, after required client approval |
| Authorise public launch | Named client approver through the agency |
| Carry out deployment and launch checks | Developer |
| Receive handover and operate the site afterwards | Named agency or client owner, with the agreed support supplier |
One person may hold several roles. Keep acceptance of delivery and permission to launch as separate recorded decisions, even when the same person is involved in both.
Write checks someone can repeat
For each check, record the tested version, environment, date, tester and result. Link the evidence and any issue that needs resolving. A failed check needs enough detail for someone to repeat it and confirm the fix.
These are the functional checks for the hypothetical pilot:
| Requirement | Repeatable check | Evidence to retain |
|---|---|---|
| Service content can be edited | An authorised editor changes a service description, previews it and publishes it. Confirm the public page shows the approved text. | Tested page, result and editing notes |
| A case study can be added | An editor creates a case study using the agreed fields. Confirm it appears in the correct listing and opens at its own address. | Test content and resulting pages |
| Enquiries reach the agreed destination | Submit a test enquiry for each routing option. Confirm receipt and the expected fields at the destination. | Test reference and receipt record, without unnecessary personal data |
| Invalid submissions are handled | Leave a required field empty and enter an invalid email address. Confirm no request is submitted, a field-specific message appears and valid entered values are retained. | Test results |
| Editing is restricted | Check that a signed-out visitor and a non-editor test account cannot save content changes, including through direct requests. Confirm editing controls are available only to the agreed roles. | Permission-test results |
| Failed delivery is handled | Simulate the agreed delivery failure. Check the visitor message, retained request if applicable, and notification to the responsible person. | Failure scenario and observed result |
| Old addresses redirect correctly | Visit every address on the agreed redirect list and confirm its approved destination. | Completed redirect list |
| The agreed design works on target devices | Review the agreed pages and interactions on the specified browser and device set. | Results and linked issues |
Add the project's accessibility, performance and security acceptance checks. This is a worked functional example, not a complete testing standard for every website.
Record blockers, deferred work and scope changes
For this hypothetical pilot, an enquiry that disappears without a visible failure is a launch blocker. An unauthorised user being able to change content is also a blocker.
A minor spacing issue may be deferred if the approver accepts it. Record the issue, its impact, the person responsible and the agreed resolution date. A request for online booking is new scope here because booking was explicitly excluded.
Keep one open-items register. Resolve disagreements about severity before asking for launch approval. Do not turn unresolved issues into a blanket “approved” status.
The acceptance record should make clear which checks passed, which issues remain and who accepted any deferral. Keep requests that change scope visible so they can be agreed separately.
Repeat launch checks on the public site
A passing preview does not prove the live configuration is correct. Repeat the agreed launch checks on the public site, including the enquiry route and important addresses.
Before deployment, agree who makes the decision if a critical check fails and what the rollback or recovery action is. If a rollback could affect live data, agree how that data will be handled before launch.
Record the launch result and any remaining actions.
Hand over access and responsibility
The handover pack should identify the agreed source files and account ownership, deployment instructions, editing guidance and support arrangement. Include the acceptance results and open-items register.
List accounts and their owners in the pack. Pass access through the agreed secure route and keep credentials out of the document.
The recipient should confirm that they can access what they are taking responsibility for. Agree who handles faults and changes from the handover date, particularly if someone else supplies ongoing maintenance.
Use the pack before the build starts
Start with the agreed scope and fill in the named owners. Agree the checks and evidence before testing, then keep the results and open items with the launch decision and handover record.
You can adapt this pack to a first project with Kyln. Bring the pilot brief, and we can agree the delivery and acceptance scope before the build starts.
Hypothetical website pilot acceptance worksheet
Adapt these checks to the agreed scope. The roles and requirements are hypothetical, not a record of completed work. Record the tested version, environment, date, tester and result alongside each check, with evidence and linked issues.
| Decision or check | Example owner | Evidence or question to record |
|---|---|---|
| Confirm the pilot scope | Agency account lead with developer | Are the homepage, service layout, case-study layout, editing fields and enquiry route agreed? Record online booking and customer login as excluded in this example. |
| Confirm editing and case-study creation | Developer with authorised editor | Can the editor change, preview and publish service content, then create a case study that appears in its listing and at its own address? |
| Test enquiries and invalid submissions | Developer | Record receipt for every routing option. Check required fields and invalid email handling, including field-specific messages and retention of valid entered values. |
| Test permissions and delivery failure | Developer | Confirm signed-out visitors and non-editors cannot save changes, including through direct requests. Record the agreed delivery failure, visitor message and responsible person's notification. |
| Review design and content | Agency design lead and client content owner | Record review against approved design and copy on the agreed browser and device set. Link any issues. |
| Complete project-specific checks | Developer | Add the agreed accessibility, performance and security acceptance checks. Record the result for every address on the redirect list. |
| Resolve open items and accept delivery | Named agency approver, after required client approval | Identify blockers, accepted deferrals and scope changes. Each deferred issue needs its impact, responsible person and agreed resolution date. |
| Authorise public launch | Named client approver through the agency | Record launch permission. Who decides if a critical live check fails? What is the rollback or recovery action, including handling of affected live data? |
| Check the live site | Developer | Repeat the agreed public-site checks, including the enquiry route and important addresses. Record the launch result and remaining actions. |
| Confirm handover | Named agency or client owner with agreed support supplier | Confirm access to agreed files and accounts, deployment instructions and editing guidance. Include acceptance results and open items. Agree who handles faults and changes from handover. |