Good Services Service Design

Good Services Service Design

This skill helps you design, diagnose, and improve services end-to-end using the _Good Services_ model: define the service from the user's perspective, map the steps/tasks across channels and operations, and then assess and improve using the 15 principles of good service design.

A service here means: something that helps someone to do something — defined by the user's goal, not your org chart.

When to use

Use this skill when the user asks for any of the following:

• “Design a service” / “redesign a service” / “fix our service”
• “Service audit” / “service review” / “why is our service failing?”
• “Service blueprint” / “journey map” / “service map”
• “How do we make this service easier to find / understand / use?”
• “Apply the Good Services principles” / “the 15 principles”

When NOT to use

• Pure UI styling/visual design requests (unless tied to a service journey or ops)
• Marketing/copywriting that isn't part of explaining the service purpose/expectations
• Narrow technical debugging with no service context (use engineering/debug skills instead)

Operating modes

Choose the lightest mode that fits the user's need.

1) Quick audit (30–60 min)

• Output: principles scorecard + top issues + recommended fixes/backlog
• Best when: user wants fast prioritisation or a “why is this broken?” diagnosis

2) Full design / improvement plan

• Output: service definition + journey map + service blueprint + scorecard + prioritised backlog + service standard
• Best when: user is (re)designing a service or needs cross-team alignment

3) Workshop facilitation

• Output: agenda + exercises + artefacts to fill live (templates)
• Best when: multiple stakeholders need to align on scope, ownership, and priorities

Inputs to collect (progressive)

Start with the minimum and expand only as needed.

Minimum (always ask):

• What is the service (in one sentence) and what outcome does the user want?
• Who are the primary users? (2–3 groups is enough)
• What channels exist today? (web/app/phone/post/in-person/physical)
• What is the main problem you're trying to solve? (symptoms + suspected causes)

Helpful (ask if doing more than a quick audit):

• Known constraints (policy/legal/technical/budget/SLAs)
• Current volume + failure points (drop-offs, call deflection, complaint themes)
• Any research, analytics, or frontline insights you already have
• Where support happens today (humans, scripts, escalation routes)

If information is missing, make assumptions explicit and provide a “data needed next” list.

---

Core workflow

Step 1 — Define the service (user-first)

Goal: anchor on what the user is trying to achieve, and where the service starts/ends.

Use: references/templates/service-definition-canvas.md

Do: 1. Rewrite the service name as a verb phrase users would search for. 2. Define start trigger and done condition (what does “complete” mean?). 3. Identify user groups + accessibility needs. 4. List channels and key touchpoints. 5. Capture success measures (user + organisation + societal).

Output: a filled Service Definition Canvas.

Step 2 — Map the journey (steps and tasks)

Goal: describe the service as one continuous set of actions towards the user's goal — across org boundaries and channels.

Use:

• references/templates/service-map.md (journey map)
• references/templates/service-blueprint.md (frontstage/backstage/support)

Do: 1. Break the service into steps (major decision points / moments needing visibility). 2. Break steps into tasks (individual actions). 3. Note channel(s) per step/task and any handoffs between teams/orgs. 4. Capture pain points, drop-offs, and where users seek help.

Output: a journey map (minimum) and blueprint (if ops matter, which they usually do).

Step 3 — Assess against the 15 principles

Goal: identify where the service violates universal good-service needs.

Use:

• references/templates/principles-scorecard.md
• references/15-principles.md (detailed guidance + checks)

Do: 1. Score each principle (0–2) and record evidence. 2. List the top failure modes and where they appear in the journey. 3. Highlight cross-cutting root causes (language, data silos, incentives, policy).

Output: completed principles scorecard + summary of top 5 issues.

Step 4 — Design improvements and prioritise

Goal: turn findings into a realistic plan.

Use: references/templates/improvement-backlog.md

Do: 1. Propose fixes that directly address failures (avoid “nice-to-haves”). 2. Prefer changes that reduce user effort, clarify purpose/expectations, and remove dead ends. 3. Prioritise by user impact, risk, frequency, and implementation effort. 4. Write acceptance criteria in user-outcome language.

Output: prioritised backlog (Now / Next / Later).

Step 5 — Define the service standard and measurement

Goal: make the service operable and improvable over time.

Use: references/templates/service-standard.md

Do: 1. Define what “good” looks like: promises, service levels, accessibility bar, support model. 2. Define key measures (not just what’s easy to count). 3. Make incentives explicit: what behaviours are you encouraging in users and staff?

Output: service standard + measurement plan.

Step 6 — Validate and iterate

Goal: ensure improvements work for real users and real staff.

Do: 1. List the riskiest assumptions (who/what/when/why/how). 2. Propose a lightweight validation plan (research, prototype, pilot, operational test). 3. Plan for change: what user circumstances can change, and how will the service respond?

Output: validation plan + “unknowns / next evidence to collect”.

---

The 15 principles (as checks)

1. A good service is easy to find 2. A good service clearly explains its purpose 3. A good service sets the expectations a user has of it 4. A good service enables a user to complete the outcome they set out to do 5. A good service works in a way that’s familiar 6. A good service requires no prior knowledge to use 7. A good service is agnostic to organisational structures 8. A good service requires as few steps as possible to complete 9. A good service is consistent throughout 10. A good service should have no dead ends 11. A good service is usable by everyone, equally 12. A good service encourages the right behaviours from users and staff 13. A good service should respond to change quickly 14. A good service clearly explains why a decision has been made 15. A good service makes it easy to get human assistance

(Use references/15-principles.md for practical tests and improvement moves.)

---

Output format (recommended)

When delivering results, structure the response like this:

1. Service definition (1–2 paragraphs + canvas) 2. Journey map (table) 3. Service blueprint (if relevant) 4. Principles scorecard (table + top issues) 5. Prioritised backlog (Now/Next/Later) 6. Service standard + measures 7. Validation plan (what to test next)

Keep everything in plain language, using the user's terms (verbs), not internal acronyms.

---

Quality checklist (before finalising)

• The service name is a verb users would search for (not an internal noun/acronym).
• Purpose is clear in the first 10 seconds of the journey.
• Time/cost/eligibility expectations are set at the right moments.
• The journey supports the full user outcome (including aftercare and exceptions).
• Patterns and language are familiar and consistent across channels.
• No step assumes prior knowledge of your organisation or process.
• No user is stranded: every “no” has a next step (alternative, referral, appeal, human help).
• Accessibility is treated as a baseline, not a bolt-on.
• Metrics and incentives encourage the right behaviours (users + staff + organisation + society).
• The service can handle change (user details, circumstances, policy, operational variance).

---

Examples

Example 1 — Quick audit

User: “Can you audit our online appointment booking service? Drop-off is high.” Actions: 1. Collect minimal context (users, outcome, channels, evidence). 2. Produce journey map + scorecard (0–2 per principle). 3. Identify top 5 root causes and propose a Now/Next/Later backlog.

Example 2 — Blueprint + improvement plan

User: “Design an end-to-end ‘cancel my subscription’ service across web + phone.” Actions: 1. Define service boundaries (start, done, aftercare). 2. Map journey and blueprint (frontstage/backstage/support). 3. Check dead ends, expectations, and human assistance. 4. Produce a service standard (what “good” means) + measures.

Example 3 — Workshop

User: “We need a workshop agenda to align teams around our service redesign.” Actions: 1. Use references/workshop-agenda.md. 2. Provide templates to fill and facilitation notes. 3. End with an agreed backlog and ownership map.

---

Troubleshooting

The request is too broad (“fix our whole customer experience”)

• Narrow to one user outcome and define service boundaries.
• If needed, split into multiple services (each with its own “done”).

The org is siloed / no single owner

• Run Step 2 (map) explicitly across handoffs.
• Use Principle 7 guidance to propose shared standards/goals/incentives.

Users keep calling / staff are overwhelmed

• Check Principle 3 (expectations), 10 (dead ends), and 15 (human help model).
• Look for incentive problems (Principle 12).

Not enough data

• Make assumptions explicit.
• Provide a “minimum evidence to collect next” list: top drop-off steps, complaint themes, frontline pain points, accessibility issues.

The 15 principles of good service design — practical guide

Use this as a working checklist when auditing or designing a service. For each principle you'll find:

• Intent: what “good” means
• Quick checks: questions you can answer quickly
• Failure modes: common ways services break
• Improvement moves: practical design and operating changes
• Evidence: what to look at (research/analytics/ops signals)

---

1) Easy to find

Intent People can find the service when they need it, using the words they use — not your internal terminology.

Quick checks

• What would a user type into a search engine to find this?
• Is the service name a verb/outcome (“do X”), not a noun/programme/acronym?
• If the service is offline, is the entry point still discoverable online?

Failure modes

• Acronyms and internal product names
• “Portal/hub/platform” naming that describes technology, not user outcome
• Users call support because they can’t locate the right service

Improvement moves

• Rename using user language (verbs). Avoid legal/technical jargon where possible.
• Optimise entry points: search snippets, landing pages, navigation labels, in-product routing.
• Ensure related services cross-link using the user’s mental model (e.g., “moving house” links to “change address”, “redirect post”, “update payment details”).

Evidence

• Search terms and internal-site search logs
• Call-centre/CS “how do I…” contacts
• Drop-offs at “choose service” / “which option do you need?” screens

---

2) Clearly explains its purpose

Intent Within moments, a user with no prior knowledge can tell: what this service will do for me and roughly how it works.

Quick checks

• Can a first-time user explain the service back to you in one sentence?
• Is there a crisp value statement, not instructions or policy text?
• Do UI cues make the model obvious (paid/free, subscription, approval decision, etc.)?

Failure modes

• The service title is clear but the service promise is vague
• Users self-select into the wrong flow (because they’re “not sure”)
• Explanations are long and read like a manual

Improvement moves

• Tighten purpose copy: outcome, who it’s for, what happens next, what it doesn’t do.
• Use lightweight signals: progress indicators, eligibility hints, “takes ~5 minutes”, “requires documents X/Y”.
• Put explanations at the point of need (not a wall of text at the start).

Evidence

• Misrouted submissions / wrong form choice
• Users abandoning early steps
• Repeated questions in support logs (“what is this for?”)

---

3) Sets expectations

Intent Users understand what they need to do and what they’ll get in return — including time, cost, eligibility, and next steps.

Quick checks

• Does the service tell users how long each part takes and what happens after submission?
• Are requirements clear (documents, proof, appointments, payment)?
• Are status updates provided where waiting is involved?

Failure modes

• Users chase updates because they don’t know what “normal” looks like
• Hidden constraints (cooling-off periods, verification delays, review queues)
• Important complexity appears late, surprising users

Improvement moves

• Surface assumed expectations early, then reinforce at key moments.
• Provide transparent status + “what happens next” messaging.
• If a universal expectation can’t be met (e.g., outage), tell users fast and offer alternatives.

Evidence

• “Where is my…” contacts and complaints
• Rework/duplicates from users repeating steps
• Queue metrics and status visibility gaps

---

4) Enables the user to complete their outcome

Intent The service supports the full journey to “done” — including exceptions and aftercare — not just a single touchpoint.

Quick checks

• What is the “done” condition? Is it unambiguous?
• Does the service cover the steps users actually need to finish, not just what you own?
• Are there clear handoffs when another org/team completes part of the outcome?

Failure modes

• Beautiful onboarding, broken completion
• The service stops at “submit” with no next steps
• Users are bounced between channels/teams to finish

Improvement moves

• Design end-to-end (from “considering” to “resolved/achieved”, plus support after).
• Make handoffs explicit: ownership, timings, what the user should do next.
• Ensure the service works front-to-back: user-facing journey and internal processes.

Evidence

• Completion rates vs “submission” rates
• Escalations at the last step
• Manual workarounds by staff to finish outcomes

---

5) Works in a familiar way

Intent Where there are established conventions that help users, follow them. Don’t invent novelty where predictability is needed.

Quick checks

• Does the interaction model match similar services users already know?
• Are patterns consistent with platform conventions (web/mobile/phone)?
• Are there any “clever” interactions that require learning?

Failure modes

• Users make basic mistakes because controls behave unexpectedly
• The service needs instruction signs / guides for standard tasks
• “We changed it to be innovative” but usability drops

Improvement moves

• Use common patterns first; innovate only when evidence shows conventions are failing users.
• Prefer clear affordances and feedback (what happened? what will happen next?).
• Remove customs that exist only for organisational convenience and harm users.

Evidence

• Usability tests: repeated misclicks/errors on basic tasks
• Training burden for staff/users
• High rates of “I didn’t realise…” complaints

---

6) Requires no prior knowledge

Intent A first-time user can succeed without understanding your organisation, jargon, or process history.

Quick checks

• What do you assume users already know? (documents, terms, eligibility, steps)
• Could someone who has never used a similar service complete it unaided?
• Is expert help required only because the service is confusing?

Failure modes

• Services that reward “insider” knowledge
• Long policy explanations instead of designing complexity out
• Emergence of “helper services” and intermediaries just to navigate the process

Improvement moves

• List presumptions explicitly; remove as many as you can; explain the rest at the moment they matter.
• Use plain language and progressive disclosure.
• Make the service navigable without knowing which team provides which part (see Principle 7).

Evidence

• Drop-offs clustered around jargon-heavy steps
• Differences in success rates between experienced vs new users
• High support demand for “how does this work?” questions

---

7) Agnostic to organisational structures

Intent Users can complete the service without being exposed to internal silos, departments, or ownership boundaries.

Quick checks

• Where does the user have to “figure out who owns this”?
• Are users asked for the same data multiple times because teams don’t share it?
• Do policies/processes between steps conflict (timelines, eligibility rules, naming)?

Failure modes

• Data silos cause repeated form-filling
• Broken handoffs: incompatible timelines or requirements
• Different teams use different words for the same thing

Improvement moves

• Map end-to-end data: who collects what, who needs access, where duplicates occur.
• Align processes and criteria across steps (timelines, eligibility, required artefacts).
• Create a permissive environment for collaboration: shared standards, shared goals, shared incentives.

Evidence

• Rework caused by missing/duplicated data
• Complaints about being “passed around”
• Staff time spent compensating for handoff failures

---

8) As few steps as possible

Intent Minimise user effort without removing necessary decision points. Design the number and pace of steps deliberately.

Quick checks

• Which steps exist only because of internal constraints or historic habits?
• Where should the user pause to make a decision (and where should they not)?
• Is the tempo right for the risk/complexity of the service?

Failure modes

• Extra steps that add no user value (“because we’ve always done it”)
• Mandatory waits inserted in the wrong place (confusing users)
• Services that are too fast for high-stakes decisions, or too slow for simple transactions

Improvement moves

• Remove steps that don’t provide user visibility/control.
• For involved/high-stakes parts, slow down with deliberate pauses and clearer guidance.
• For transactional parts, streamline and automate where safe (including proactive fulfilment).

Evidence

• Step-by-step drop-off analysis
• Time-to-complete vs perceived effort
• Users calling for help because they’re forced to decide without context

---

9) Consistent throughout

Intent The service feels like one coherent service across the journey, across channels, and over time — while allowing appropriate variation by context.

Quick checks

• Do the same terms mean the same things everywhere?
• Are patterns and messages consistent between web/app/phone/post/in-person?
• Do updates in one place create mismatches elsewhere?

Failure modes

• “Desert island” MVP: one polished touchpoint with no end-to-end service
• Inconsistent language creates confusion and errors
• Different channels give different answers

Improvement moves

• Design a minimum viable service (an end-to-end path most users can complete), not just an MVP screen.
• Create shared content/style standards across channels.
• Treat operational communications (letters, emails, scripts) as part of the design system.

Evidence

• Channel-switching complaints (“website says X, phone says Y”)
• Inconsistent terminology in artefacts
• Release notes creating new mismatches across the journey

---

10) No dead ends

Intent No user is stranded. Even if they’re ineligible, stuck, or missing something, they get a clear next step.

Quick checks

• What happens when something goes wrong (wrong details, lost device, no documents)?
• If the user can’t proceed, do they get alternatives or only a hard stop?
• Are there non-digital routes for users who can’t use the primary channel?

Failure modes

• Two-factor auth / account recovery traps
• Hard stops with no appeal, referral, or human contact route
• Services that presume everyone has: phone/email/bank account/ID/proof of address/internet

Improvement moves

• Provide fallback routes and backups for critical requirements.
• Distribute complexity evenly: don’t hide the hardest requirements at the end.
• Design explicit “no” journeys: explain why, what to do instead, and how to get help.

Evidence

• Abandonment at error states
• Spike in support contacts after “no” decisions
• Manual rescues by staff

---

11) Usable by everyone, equally

Intent Everyone can use the service regardless of ability, access needs, or circumstances. Accessibility is baseline.

Quick checks

• Does the service work for users with different abilities, languages, devices, connectivity?
• Can users complete tasks without relying on memory, perfect vision/hearing, or fine motor control?
• Are there safe alternatives for people at risk?

Failure modes

• Accessibility treated as “later”
• Key steps require abilities some users don’t have (reading long IDs, complex instructions)
• Unsafe support routes (e.g., requiring sensitive disclosure without protection)

Improvement moves

• Design for: safe, perceivable, understandable, operable, robust.
• Include accessibility checks early (content, interaction, support, physical environments).
• Test with diverse users; don’t rely only on automated checkers.

Evidence

• Accessibility audits + user testing
• Disproportionate failure rates for certain groups
• Complaints about exclusion (“I can’t use this”)

---

12) Encourages the right behaviours (users + staff)

Intent The service nudges users and staff towards behaviours that are safe, productive, and mutually beneficial — supported by incentives and measures.

Quick checks

• What behaviour are your metrics/incentives actually rewarding?
• Do staff targets push them to rush or deflect users?
• Does the service normalise risky user behaviour (oversharing, unsafe shortcuts)?

Failure modes

• Perverse targets (“average handling time” causing poor resolutions)
• Users gaming the system because it’s the only way to succeed
• Sustainability ignored (cost, capacity, environmental impact)

Improvement moves

• Define four behaviour sets: benefit the user, benefit staff, sustain the organisation, do no harm.
• Measure outcomes, not just throughput.
• Align incentives across channels (and across org boundaries where relevant).

Evidence

• Staff workarounds and moral injury stories
• KPI dashboards vs user outcomes mismatch
• Policy breaches and “shadow processes” emerging

---

13) Responds to change quickly

Intent When a user’s circumstances change, the service updates quickly and consistently across channels and operations.

Quick checks

• What user attributes can change (name, address, phone, identity details)?
• If a user updates info in one channel, does every channel reflect it?
• Does the service handle indirect changes (tone/wording, safeguarding, context) appropriately?

Failure modes

• Data updates propagate slowly or not at all
• Identity is anchored to the wrong attribute (hard to change)
• Staff and digital channels disagree because systems are out of sync

Improvement moves

• Identify direct vs indirect changes and design for both.
• Choose stable identity anchors and plan safe change processes.
• Treat data synchronisation and operational readiness as part of service design.

Evidence

• Repeat contacts after “I updated this already”
• Channel mismatches after account changes
• Incident reports caused by stale data

---

14) Explains why decisions are made

Intent When the service makes a decision (eligibility, pricing, acceptance/rejection), users understand why and have a route to challenge it.

Quick checks

• Is it clear what data was used and why it matters?
• Is the decision communicated at the moment it happens (not discovered later)?
• Is there an appeal/escalation route and clear evidence requirements?

Failure modes

• “Computer says no” decisions with no rationale
• Decisions appear retroactively (surprising users)
• Staff can’t explain the rules because they’re opaque

Improvement moves

• Validate decisions for dead ends and bias.
• Make decision logic legible: what factors, what thresholds, what users can do next.
• Provide an appeal path (human review, additional evidence, correction route).

Evidence

• Complaints about unfairness/lack of transparency
• High rework and repeated applications
• Escalations driven by “why was I rejected?”

---

15) Easy to get human assistance

Intent Users can reach a human when they need one — especially for complex, risky, high-value, or physical-world services — and humans are empowered to help.

Quick checks

• For which steps is human help essential (complexity/risk/value/physical constraints)?
• Is human contact discoverable and fast enough when time-critical?
• Are staff empowered to resolve issues, or only to repeat scripts?

Failure modes

• Help hidden behind dead ends or long queues
• Human support only available after repeated failures
• Staff lack authority to make exceptions or solve root causes

Improvement moves

• Design a support model: tiers, escalation, response times, and handoffs.
• Use humans proportionally: enough for complex needs, sustainable at scale.
• Make human assistance consistent with the rest of the service (shared info, shared language).

Evidence

• Escalation rates and repeat contacts
• Cases that “die” because no one can intervene
• Staff frustration about lacking authority

---

Using this guide during an audit

A practical loop:

1. Map the journey (steps/tasks). 2. For each step, ask: which principles are at risk here? 3. Capture evidence and score (0–2). 4. Turn failures into backlog items with acceptance criteria.

Core concepts (Good Services)

These are the minimal shared definitions used by this skill.

Service, steps, tasks

• Service: something that helps someone to do something. The user's goal defines the service boundary — it can cross multiple organisations and channels, but to the user it feels like one continuous journey.
• Steps: the major parts of the service that give users visibility and control at important decision points (for example: “choose a plan”, “prove identity”, “confirm details”).
• Tasks: the individual actions a user (or staff/system) performs to complete a step (for example: “upload a document”, “enter address”, “review confirmation email”).

Design implication: don't optimise a single touchpoint at the expense of the end-to-end outcome. A “great” step inside a broken service is still a broken service.

Channels are part of the service

Assume services are multi-channel unless proven otherwise:

• Digital (web/app)
• Phone
• Post/email
• In-person (appointments, retail, reception)
• Physical artefacts (letters, cards, forms, devices)

A “digital service” often still depends on physical and human steps. Treat these as first-class parts of the design.

Frontstage vs backstage (service blueprint)

A simple way to think about operational design:

• User actions: what the user does
• Frontstage: what users see (interfaces, staff interactions, messages)
• Backstage: what staff/systems do that users don't see (verification, routing, casework)
• Support processes: upstream/downstream systems and policies (databases, payment rails, legal requirements, staffing)

If your blueprint fails backstage, the user experience fails regardless of how polished the UI is.

Naming principle: prefer verbs

Users search for actions and outcomes. Organisations often name services with internal nouns (programmes, departments, acronyms).

Heuristic:

• Good service name: “get help with court fees”, “change my address”, “cancel my subscription”
• Risky service name: “Fee Remission”, “CRM Portal”, “SORN”

“Good” is three-way

A service is “good” when it is:

• Good for users: helps them achieve outcomes safely and without unnecessary effort
• Good for the providing organisation: sustainable to run (cost, risk, capacity) and aligned with goals
• Good for society: does not create avoidable harm (exclusion, environmental damage, perverse incentives)

Use this triad when choosing measures and prioritising improvements.

Example (fictional): “Cancel my subscription” service audit

This is a made-up example to show the artefacts and level of detail, not a real organisation.

Service definition (short)

• Service name (verb): Cancel my subscription
• User outcome: Stop future charges and receive confirmation that access ends on a specific date.
• Start: User decides to cancel and searches the help centre.
• Done: Subscription is cancelled, refund/credit policy is applied, user has a confirmation record.
• Channels: Web/app + email confirmation + optional human chat.

Journey map (abridged)

Principles scorecard (abridged)

Backlog (Now/Next/Later)

Notes

• Most failures here are expectation-setting + dead ends, not “UI polish”.
• Fixes require content, policy clarity, and authentication ops — not just design tweaks.

Improvement Backlog (template)

Prefer backlog items framed as user outcomes, linked to failed principles.

Backlog table

Notes

• Flag items that require policy/legal change vs design/ops change.
• For cross-org items, note required shared standards/goals/incentives (Principle 7).
• For “no” decisions, always include: rationale + next step + appeal/human support (Principles 10 + 14 + 15).

Principles Scorecard (template)

Score each principle 0–2:

• 0 = failing / significant harm or friction
• 1 = partial / inconsistent / only works for some users
• 2 = solid / works reliably end-to-end

Add evidence. If you can't cite evidence, mark as an assumption and note what to measure/test.

Summary

• Top 5 principle failures (by harm/impact):
• Most systemic root cause (language, data, incentives, policy, capacity, tooling):
• Quick wins (high impact / low effort):

Service Blueprint (template)

Use this when operational processes, data, or staff work are key to success (they usually are).

Blueprint table

Operational risks checklist

• Data handoffs (duplication, mismatch, latency)
• Policy/process misalignment between teams/orgs
• Capacity constraints (queues, staffing)
• Exception handling (what happens off the happy path?)
• Auditing and traceability (for decisions)

Service Definition Canvas (template)

Fill this in before mapping or proposing changes. Keep it user-first and plain-language.

1) Service name (user language)

• Current name(s):
• Proposed user-facing name (verb phrase):
• Search terms users would use:

2) Purpose and outcome

• User outcome (“done” means…):
• Organisation outcome (why provide this service?):
• Societal outcome / harm constraints:

3) Users

• Primary user groups (2–3):
• Secondary users / proxies (carers, parents, assistants, staff acting for users):
• Access needs / constraints (language, disability, devices, connectivity, safety):

4) Scope and boundaries

• Start trigger (when does the service begin for the user?):
• End condition (when is it finished?):
• What’s explicitly out of scope:
• Key assumptions:

5) Channels and touchpoints

List all channels that exist today (or will exist):

• Digital:
• Phone:
• Post/email:
• In-person:
• Physical artefacts / devices:

6) Expectations to set

• Time (how long each stage usually takes):
• Cost/fees:
• Eligibility/criteria:
• Evidence needed (documents, IDs, proof, appointments):

7) Operational reality (high level)

• Teams/orgs involved:
• Key systems/data sources:
• Known policy/legal constraints:

8) Measures of success

Pick a small set of measures that reflect outcomes:

• User measures (completion, time/effort, confidence, accessibility):
• Operational measures (cost-to-serve, rework, error rates, SLA):
• Trust/fairness measures (appeals, complaints, bias signals):
• Sustainability measures (if relevant):

9) Risks and unknowns

• Top 5 risks:
• Top 5 unknowns / evidence needed next:

Service Map / Journey Map (template)

Use this to map the service from the user's perspective. A “step” is a decision point or moment where the user needs visibility/control. A “task” is an individual action.

Tip: start with ~6–12 steps. Too many usually means you're mixing steps and tasks.

Journey overview

• Service:
• User group:
• Start:
• Done:
• Channels in scope:

Journey table

Cross-cutting notes

• Top 3 drop-off points:
• Top 3 causes of contact:
• Known accessibility issues:
• Known policy/operational constraints:

Service Standard (template)

A service standard turns “we should improve this” into an operational contract.

1) Service promise (plain language)

• What users can achieve:
• Who it’s for:
• Key constraints (what it doesn’t do / where to go instead):

2) Service levels (examples)

Define targets that match user needs (not just internal throughput).

• Response times (digital + human)
• Time-to-complete (by journey stage)
• Error/rework targets
• Accessibility bar (e.g., WCAG level, plus non-digital support)

3) Communication standard

• Purpose statement (first 10 seconds)
• Expectation-setting moments (time/cost/eligibility)
• Status updates and “what happens next”
• Tone rules for high-stress situations

4) Decision policy (Principle 14)

• What decisions the service makes:
• Inputs used and why they matter:
• How decisions are explained:
• How users appeal / correct data:
• How staff override / escalate safely:

5) Human assistance model (Principle 15)

• Entry points to human help (where shown, how found)
• Triage and escalation rules
• Empowerment (what staff can decide/do)
• Knowledge base / scripts alignment with digital journey

6) Data and operational integrity (Principles 7 + 13)

• System-of-record for key user data
• Sync expectations across channels
• Change handling (name/address/phone/etc.)
• Audit trails and traceability

7) Measurement and incentives (Principle 12)

Pick a small set of measures that drive the right behaviour:

• User outcomes:
• Operational outcomes:
• Fairness/trust outcomes:
• Sustainability outcomes:

8) Ownership and review cadence

• Service owner:
• Key teams/orgs:
• Review cadence:
• How changes are tested and rolled out:

Workshop agenda: Good Services audit + improvement plan

This is a lightweight format you can run with 4–10 stakeholders (design, ops, engineering, policy, support).

Prep (before the session)

Ask participants to bring:

• Top 10 support contacts/complaint themes
• Any analytics: drop-offs, completion rates, time-to-complete, escalation rates
• Known policy/legal constraints
• A frontline representative (calls/appointments/casework)

Print or share templates:

• templates/service-definition-canvas.md
• templates/service-map.md
• templates/principles-scorecard.md
• templates/improvement-backlog.md

2-hour version (fast alignment)

0:00–0:10 — Opening

• Agree the outcome: “At the end we will have a shared service definition, top problems, and a prioritised backlog.”
• Set ground rules: user-first, plain language, be explicit about assumptions.

0:10–0:30 — Define the service

• Fill the Service Definition Canvas.
• Confirm start/done boundaries and the primary user group.

0:30–1:05 — Map the journey (happy path + key exceptions)

• Build a 6–12 step journey map.
• Mark: drop-offs, handoffs, and “where users seek help”.

1:05–1:30 — Principles scan

• Rapidly score the 15 principles (0–2).
• Capture evidence and disagreements as “unknowns to test”.

1:30–1:55 — Backlog & ownership

• Convert top failures into backlog items (Now/Next/Later).
• Assign an owner and first next step per item (research, prototype, policy check, ops change).

1:55–2:00 — Close

• Confirm: what will be shared out, and when the next review is.

1-day version (deeper)

Add:

• Service blueprinting (frontstage/backstage/support)
• Accessibility review and inclusion risk mapping
• Decision transparency audit (Principle 14)
• Support model design (Principle 15)
• Measures/incentives review (Principle 12)

Outputs to produce after the workshop

• Filled templates (definition, map, scorecard, backlog)
• A short narrative summary (1 page)
• “Top unknowns / evidence needed next” list