# Service Assessment Report: [Service name], [Phase] assessment

> A service assessment report records how a public digital service was
> judged against a service standard at a phase gate (usually the end of
> alpha, beta and before going live): the evidence the team showed for
> each point, the panel's rating, what must change and by when. The
> structure works with any point-based digital service standard. The
> worked mapping uses the UK Government Service Standard (14 points, as
> published on GOV.UK) and the GOV.UK Service Manual page "What happens
> at a service assessment" (updated 7 September 2026), which rates each
> point green, amber or red. Replace every `[bracketed]` value and every
> row marked *Example*. Check the current standard and assessment rules
> of your government or department before each assessment.

<!--
Guidance: How to use this template
- Two audiences use it. The delivery team fills sections 2 to 4 before
  the assessment as a self-assessment and evidence pack. The panel fills
  sections 5 to 8 after the assessment as its report. Keep both in one
  file so the evidence and the verdict stay linked.
- Rate each point on what the team showed, not on what it promised.
  "We will" is not evidence; a research report, a metric or a demo is.
- Expectations rise by phase. At alpha the panel looks for learning and
  the riskiest assumptions tested; at beta for a working service used by
  real users; at live for sustained operation and improvement.
- The worked example follows a fictional public body, the Lakemoor
  Waters Agency, and its beta service "Apply for a recreational fishing
  permit". Every name and figure marked *Example* is invented.
- Related documents: Public Sector Digital Service Architecture
  (`industry/public-sector-digital-service-architecture`), Accessibility
  Checklist (`design/accessibility-checklist`), Accessibility Statement
  (`legal-lite/accessibility-statement`), DPIA (`compliance/dpia`), UX
  Research Plan (`design/ux-research-plan`), Usability Test Report
  (`design/usability-test-report`), Go-Live Readiness Review
  (`project/go-live-readiness-review`), Policy Brief
  (`public-sector/policy-brief`).
-->

## Document control

<!-- Guidance: Name the phase, the panel and the assurance route. Departments may run their own panels with a met or not met outcome instead of green, amber and red; record which applies. -->

| Field | Value |
|---|---|
| Document ID | [SAR-2026-001] |
| Version | [0.1] |
| Status | [Self-assessment draft / Panel draft / Fact-checked / Published] |
| Service name | [Verb-based name, e.g. Apply for a ...] |
| Service owner | [@service-owner] |
| Department or agency | [Organisation] |
| Phase assessed | [Alpha / Beta / Live / Reassessment] |
| Assessment type | [Cross-government panel / Departmental panel / Peer review] |
| Rating scheme | [Green, amber, red / Met, not met] |
| Assessment date | YYYY-MM-DD |
| Owner | [@lead-assessor] |
| Approvers/reviewers | [@service-owner], [@departmental-assurance-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Official / Public after publication] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Lead assessor | [@name] | [Report issued] | YYYY-MM-DD |
| Service owner | [@name] | [Fact check complete] | YYYY-MM-DD |
| Assurance lead | [@name] | [Outcome recorded] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Team self-assessment and evidence pack |
| 0.2 | YYYY-MM-DD | [@name] | Panel ratings and recommendations |
| 1.0 | YYYY-MM-DD | [@name] | Fact-checked, approved for publication |

## Contents

1. Assessment summary
2. Service description
3. Team and assessment arrangements
4. Evidence pack index
5. Assessment against each point of the standard
6. Recommendations and conditions
7. Amber tracking
8. Decision and next steps
9. Glossary and references
10. Standard and licence note

## 1. Assessment summary

<!-- Guidance: Write this after the ratings are agreed. A reader should see the overall outcome, the count of ratings and the two or three points that matter most. Keep the counts identical to section 5. -->

| Item | Result |
|---|---|
| Overall outcome | [Green / Amber / Red] or [Met / Not met] |
| Points green or met | [n of 14] |
| Points amber | [n] |
| Points red or not met | [n] |
| May the service move to the next phase? | [Yes / Yes, with amber actions / No] |
| Deadline for amber actions | YYYY-MM-DD |
| Reassessment needed? | [Yes, date / No] |

*Example*: the Lakemoor Waters Agency beta assessment of "Apply for a
recreational fishing permit" rated 10 points green, 4 amber and none
red. Overall outcome: amber. The service may move into public beta
while the amber actions (points 3, 5, 10 and 12) are completed within
three months.

## 2. Service description

<!-- Guidance: Describe the service from the user's point of view: who uses it, what they are trying to do, what happens before and after the online part. Avoid describing the technology here. -->

| Item | Description |
|---|---|
| What users are trying to do | [Outcome in the user's words] |
| Users | [Main user groups, with numbers per year] |
| Channels | [Online, phone, paper, face to face, intermediaries] |
| Start and end of the whole journey | [Where users start and finish, including other organisations] |
| Volumes | [Transactions per year, share by channel] |
| Policy or legal basis | [Law or policy the service delivers] |
| Phase history | [Discovery dates, alpha dates, earlier assessment outcomes] |

*Example*:

| Item | Description |
|---|---|
| What users are trying to do *(Example)* | Get permission to fish in agency-managed waters for a day, a season or a year |
| Users *(Example)* | About 180,000 anglers per year, plus 240 tackle shops that sell permits in person |
| Channels *(Example)* | Online, phone line, tackle shops |
| Volumes *(Example)* | 260,000 permits per year; 71% online in private beta |

## 3. Team and assessment arrangements

<!-- Guidance: Show the team that will run the service in the next phase, not only the team that built it. Panels look for a multidisciplinary team with a named service owner who has authority to make decisions. -->

### 3.1 Service team

| Role | Name or vacancy | Permanent, contractor or supplier | Time on the service |
|---|---|---|---|
| Service owner | [@name] | [Type] | [Share] |
| Product manager | [@name] | [Type] | [Share] |
| Delivery manager | [@name] | [Type] | [Share] |
| User researcher | [@name] | [Type] | [Share] |
| Designers (service, interaction, content) | [@names] | [Type] | [Share] |
| Developers and technical architect | [@names] | [Type] | [Share] |
| Performance analyst | [@name] | [Type] | [Share] |

### 3.2 Panel and observers

| Role | Name | Organisation |
|---|---|---|
| Lead assessor | [@name] | [Organisation] |
| User research assessor | [@name] | [Organisation] |
| Design assessor | [@name] | [Organisation] |
| Technical assessor | [@name] | [Organisation] |
| Performance analysis or AI specialist (if relevant) | [@name] | [Organisation] |
| Observers (do not ask questions) | [@names] | [Organisation] |

GOV.UK practice (check the current page): a cross-government
assessment usually lasts about four hours, starting with a short
service overview and a demonstration of the user journey, followed by
panel questions. The page updated on 7 September 2026 says the panel
may include an AI specialist when the service includes AI, and may ask
how AI tools were used to design or build it.

## 4. Evidence pack index

<!-- Guidance: List every artefact the panel can open before or during the assessment. Give each an ID so section 5 can cite it. Send the pack in advance so the session is spent on questions, not reading. -->

| Evidence ID | Artefact | Phase produced | Link |
|---|---|---|---|
| EVD-01 *(Example)* | User research plan and findings, 42 sessions incl. 9 with assistive technology users | Alpha and private beta | [Link] |
| EVD-02 *(Example)* | End-to-end journey map including tackle shop and phone channels | Alpha | [Link] |
| EVD-03 *(Example)* | Accessibility audit against WCAG 2.2 AA and draft accessibility statement | Private beta | [Link] |
| EVD-04 *(Example)* | Performance framework and dashboard: completion rate, cost per transaction, satisfaction, digital take-up | Private beta | [Link] |
| EVD-05 *(Example)* | Architecture overview, threat model and DPIA | Beta | [Link] |
| EVD-06 *(Example)* | Public code repository and licence | Beta | [Link] |
| EVD-07 *(Example)* | Service level indicators, incident runbook and on-call rota | Beta | [Link] |

## 5. Assessment against each point of the standard

<!-- Guidance: For each point, write what the team showed (with evidence IDs), what the panel found, and the rating. Use the point titles of the standard your service is assessed against. The GOV.UK point titles below are cited as published; replace them if your government uses another standard. Write findings as observations, not instructions on how to build. -->

### 5.1 Ratings overview

| Point | GOV.UK Service Standard point | Rating *(Example)* |
|---|---|---|
| 1 | Understand users and their needs | Green |
| 2 | Solve a whole problem for users | Green |
| 3 | Provide a joined up experience across all channels | Amber |
| 4 | Make the service simple to use | Green |
| 5 | Make sure everyone can use the service | Amber |
| 6 | Have a multidisciplinary team | Green |
| 7 | Use agile ways of working | Green |
| 8 | Iterate and improve frequently | Green |
| 9 | Create a secure service which protects users' privacy | Green |
| 10 | Define what success looks like and publish performance data | Amber |
| 11 | Choose the right tools and technology | Green |
| 12 | Make new source code open | Amber |
| 13 | Use and contribute to open standards, common components and patterns | Green |
| 14 | Operate a reliable service | Green |

Count check *(Example)*: 10 green, 4 amber, 0 red, 14 points.

### 5.2 Findings per point

Repeat this block for each of the 14 points.

#### Point [n]: [Point title]

| Item | Content |
|---|---|
| Rating | [Green / Amber / Red] |
| What the team showed | [Summary with evidence IDs] |
| What went well | [Panel observations] |
| What the team needs to explore | [Gaps, risks, missing evidence] |
| Linked recommendation | [REC-nn] |

*Example*:

#### Point 1: Understand users and their needs *(Example)*

| Item | Content |
|---|---|
| Rating | Green |
| What the team showed | 42 research sessions across day, season and annual permit holders, including 9 with assistive technology users and 6 with low digital confidence (EVD-01) |
| What went well | Research shaped the decision to let users buy a permit for someone else, a need found in alpha |
| What the team needs to explore | Needs of the 240 tackle shop staff who sell permits in person |
| Linked recommendation | REC-01 |

#### Point 3: Provide a joined up experience across all channels *(Example)*

| Item | Content |
|---|---|
| Rating | Amber |
| What the team showed | Journey map covering online, phone and tackle shop channels (EVD-02) |
| What went well | The phone team uses the same permit record as the online service |
| What the team needs to explore | Tackle shops still issue paper permits that do not reach the permit record for up to 10 days, so enforcement officers cannot check them |
| Linked recommendation | REC-02 |

#### Point 5: Make sure everyone can use the service *(Example)*

| Item | Content |
|---|---|
| Rating | Amber |
| What the team showed | WCAG 2.2 AA audit with 3 open issues on the date picker and a draft accessibility statement (EVD-03) |
| What went well | Assisted digital route by phone tested with users |
| What the team needs to explore | Fix the open date picker issues before public beta and publish the accessibility statement |
| Linked recommendation | REC-03 |

#### Point 10: Define what success looks like and publish performance data *(Example)*

| Item | Content |
|---|---|
| Rating | Amber |
| What the team showed | Dashboard for completion rate, satisfaction and digital take-up (EVD-04) |
| What went well | Clear link between metrics and the policy aim of reducing illegal fishing |
| What the team needs to explore | Cost per transaction is not yet measured, and no data is published |
| Linked recommendation | REC-04 |

#### Point 12: Make new source code open *(Example)*

| Item | Content |
|---|---|
| Rating | Amber |
| What the team showed | Repository exists but is private (EVD-06) |
| What went well | Secrets are held outside the code base |
| What the team needs to explore | Publish the code with an open licence, or record the reasons for keeping specific parts closed |
| Linked recommendation | REC-05 |

## 6. Recommendations and conditions

<!-- Guidance: Each recommendation names the point it addresses, what must be shown (the outcome, not the solution), the owner and the deadline. Separate conditions (must be met to pass) from advice (would improve the service). -->

| ID | Point | Type | What must be shown | Owner | Due |
|---|---|---|---|---|---|
| REC-01 *(Example)* | 1 | Advice | Research findings on tackle shop staff needs | [@user-researcher] | Before live assessment |
| REC-02 *(Example)* | 3 | Condition | Permits sold in shops appear in the permit record within 24 hours | [@product-manager] | YYYY-MM-DD |
| REC-03 *(Example)* | 5 | Condition | No open WCAG 2.2 AA issues on the core journey; accessibility statement published | [@designer] | YYYY-MM-DD |
| REC-04 *(Example)* | 10 | Condition | Cost per transaction measured; performance data published | [@performance-analyst] | YYYY-MM-DD |
| REC-05 *(Example)* | 12 | Condition | Code published under an open licence, or exceptions recorded | [@technical-architect] | YYYY-MM-DD |

## 7. Amber tracking

<!-- Guidance: GOV.UK practice expects amber issues to be fixed within a reasonable time, usually up to three months, with progress kept in a live tracking document. Update this table at each review and attach the evidence. -->

| Recommendation | Status | Evidence of completion | Date checked | Checked by |
|---|---|---|---|---|
| REC-02 *(Example)* | [Open / In progress / Done] | [Evidence ID] | YYYY-MM-DD | [@name] |
| REC-03 *(Example)* | [Status] | [Evidence ID] | YYYY-MM-DD | [@name] |
| REC-04 *(Example)* | [Status] | [Evidence ID] | YYYY-MM-DD | [@name] |
| REC-05 *(Example)* | [Status] | [Evidence ID] | YYYY-MM-DD | [@name] |

```mermaid
stateDiagram-v2
    [*] --> Assessed
    Assessed --> Green: standard met
    Assessed --> Amber: not met, issues not critical
    Assessed --> Red: not met, critical issues
    Amber --> Tracking: next phase continues
    Tracking --> Closed: all amber actions evidenced
    Red --> Reassessment: issues fixed
    Reassessment --> Assessed
    Green --> NextPhase
    Closed --> NextPhase
    NextPhase --> [*]
```

## 8. Decision and next steps

<!-- Guidance: Record what the outcome allows the team to do (for example start public beta, publish on the main government website, decommission a legacy channel) and what it does not allow yet. -->

| Item | Decision |
|---|---|
| Allowed next step | [e.g. Move to public beta] |
| Not yet allowed | [e.g. Close the paper channel] |
| Next assessment | [Phase, expected date] |
| Report publication | [Date and location; team fact check completed YYYY-MM-DD] |

GOV.UK practice: GDS publishes outcomes in its list of Service Standard
reports after the team has had a chance to fact check, and
cross-government panels usually send the report within three to five
working days.

## 9. Glossary and references

<!-- Guidance: Define phase names and rating terms for readers outside the digital profession, such as finance or policy approvers. -->

### 9.1 Glossary

| Term | Meaning |
|---|---|
| Discovery | Short phase to understand the problem and whether to build anything |
| Alpha | Phase to test riskiest assumptions with prototypes |
| Beta | Phase to build and run a real service with real users (private, then public) |
| Live | Phase where the service runs and keeps improving |
| Green | Standard met, service may continue |
| Amber | Standard not yet met, issues not critical, continue while fixing them |
| Red | Standard not met, critical issues, stay in phase until reassessed |
| Assisted digital | Support for people who cannot use the online service on their own |

### 9.2 References

| Reference | Date | Use |
|---|---|---|
| Government Service Standard, GOV.UK Service Manual | Page last substantively updated 2019-06-07 (checked 2026-10-30) | The 14 point titles: https://www.gov.uk/service-manual/service-standard |
| What happens at a service assessment, GOV.UK Service Manual | Updated 2026-09-07 | Format, panel, green, amber and red ratings, amber tracking, reports: https://www.gov.uk/service-manual/service-assessments/how-service-assessments-work |
| Web Content Accessibility Guidelines (WCAG) 2.2, W3C | Recommendation | Accessibility evidence for point 5 |

## 10. Standard and licence note

Based on the UK Government Service Standard and the GOV.UK Service
Manual guidance on service assessments, published by the Government
Digital Service. Point titles are cited as published, for
identification; GOV.UK content is available under the Open Government
Licence v3.0 except where otherwise stated. The report structure,
guidance and example are original text. Other governments publish their
own digital service standards; replace the point list with the standard
that applies to you, and check the current GOV.UK pages before use, as
assessment rules change more often than the standard.

Template licence: MIT.