Operations
A web agency workflow that moves work through explicit evidence states
Run an England web agency workflow through owned evidence states, exception queues, acceptance, release, support and exit without invented delivery claims.
A workable agency process is a state machine, not a row of optimistic dates. Each item moves only when its owner supplies the required evidence. Failed work enters a visible exception queue; it does not quietly travel towards launch.
Research for this England workflow closed on 6 September 2026. It contains no delivery result, staffing assumption or universal timetable. A typical England commission, such as a district council or NHS trust site, sits under a statement of work governed by English law.
Government Digital Service material below applies to public services, but its evidence habits can inform a private commission. Specialist reviewers must adapt them to the actual site.
What to take away
- One record per page, integration or migration batch.
- Evidence hold applies when purpose, source or authority is unclear.
- Privacy, accessibility, security, rights and claims stay separate.
- A release needs a named artefact, rollback point and support cover.
- The statement of work should cover change control, IP assignment and exit duties.
Open an evidence-controlled intake
Create one record for every page, integration and migration batch. Give it an owner, intended users, acceptance evidence, dependencies, rights source and current state. Research findings should link to evidence rather than become unsupported requirements.
An item starts in intake, then moves to evidence hold if purpose, source or authority is unclear. Only the owner may move it to ready for production, after recording scope and exclusions.
This catches an unlicensed image, unexplained analytics tag or unsubstantiated claim before production effort makes challenging it harder. CAP's misleading-advertising rules require evidence for objective claims before publication, within the code's remit.
Move work through explicit states
Use the following transition record. The labels may change, but the proof should not.
| Transition | Permitted input | Required output | Recorded by | Failure route |
|---|---|---|---|---|
| Ready to production | Approved brief and source pack | Versioned design, content or code | Owner | Return to evidence hold |
| Production to specialist review | Complete artefact and change note | Reviewable build plus disclosed limitations | Producer | Assign defects to the relevant lane |
| Review to acceptance | Closed mandatory findings and test evidence | Named accept, reject or conditional decision | Specialist reviewer | Rework queue with an owner |
| Accepted to release-ready | Signed acceptance and migration plan | Identified release version and rollback point | Delivery lead | Release hold |
| Release-ready to live | Authorised change window and support cover | Deployment record and immediate checks | Release manager | Cancel or invoke rollback |
| Live to change | Approved incident, defect or improvement record | Traceable amendment and fresh evidence | Support lead | Keep the existing version |
The owner named in the intake record records the first output. Later outputs go to the role shown in the table.
Worked example: a contact page for an England housing association. Intake records the owner, purpose and a signed statement of work. Evidence hold catches an unlicensed map image, so the owner adds a licence receipt. Ready for production records scope and exclusions. Production to specialist review produces a GitHub pull request and a change note.
Review to acceptance closes an accessibility finding and a privacy record. Accepted to release-ready names illustrative version 1.4 and a rollback point. Release-ready to live records the change window and a deployment log. Live to change logs a support request against version 1.4.
The GDS page on quality assurance separates goals, user testing and technical checks. Its reliability standard says testing should be overseen by the team and performed in an environment resembling live operation. Those are public-service expectations, not proof that an England agency project passed them.
Keep specialist lanes independent
Privacy and PECR review must inspect the actual data flow and storage or access technologies. The ICO's cookies guidance covers more than conventional browser cookies; a consent banner screenshot cannot establish the treatment of every tag.
Accessibility evidence needs manual work as well as automation. GDS guidance on frontend accessibility describes manual checks and assistive-technology testing for government services. Security has a separate owner: the NCSC's development collection frames secure development as continuing activity and does not guarantee a secure product.
Rights clearance, claims review and commercial acceptance remain separate too. One rule covers the rest: an item cannot reach live while a mandatory lane is unresolved, and no favourable test in one lane offsets a failure in another.
Control release, operation and exit
Deploy the identified artefact first to the agreed non-live environment. GDS deployment guidance describes auditable versions, staging, smoke tests and rollback for government software. A private buyer should specify its own authorised route, test fixtures and restart authority.
After release, log support requests and changes against live version. Keep service level blank unless the contract defines its event, clock, evidence and remedy.
Exit is a controlled transition: obtain code, content, media, configuration and data exports; verify access transfer; record deletion duties. If an agency processes personal data, the ICO's processor-contract guidance identifies return, deletion and audit subjects that may need contractual treatment.
For a 2027 launch, recheck sources, contracts, product behaviour and review assignments near the release date. The year in the plan is not a forecast that the work will be ready.
Release checklist
- Create one record for every page, integration and migration batch.
- Record owner, intended users, acceptance evidence, dependencies, rights source and current state.
- Move items through explicit states only when required evidence is supplied.
- Keep privacy, accessibility, security, rights and claims review lanes independent.
- Deploy the identified artefact first to the agreed non-live environment.
- Log support requests and changes against the live version after release.
Common questions
What happens to work that fails a required check?
It moves to the exception queue named for that transition. The owner either returns it to evidence hold or assigns defects to the relevant lane. It cannot go live while a mandatory lane is open.
How should specialist reviews be handled?
Keep them separate. Privacy checks the actual data flow, accessibility needs manual testing, security has its own owner, and rights and claims are separate.
What should be done before and after release?
Before release, deploy the named artefact to the non-live environment and record the rollback point. After release, log support requests against the live version. Leave service level blank unless the contract defines event, clock, evidence and remedy. Exit needs code, content, media, configuration and data exports.
