01 / UNDERSTAND
What is an operational readiness checklist?
An operational readiness checklist helps a team examine whether a service can be run, supported and recovered when it becomes available. It connects the user experience with people, processes, systems, monitoring and ownership. Readiness is a judgement supported by evidence, not the percentage of boxes completed.
A functioning interface can still lead to an unsupported service. This review asks what happens after submission, outside normal hours, when a dependency fails or when demand differs from the plan. It complements Release Planning and Design Handoff Checklist; it does not replace security, accessibility or other specialist assessments.
Why use an operational readiness checklist?
A launch changes the work of people who may not have been involved in designing the screens. GOV.UK’s live phase guidance includes preparing support staff, performance measurement, accessibility and ongoing operation. Google SRE describes tailored launch reviews covering dependencies and failure modes. This worksheet uses those concerns as background, with original questions focused on the service promise and the people who must sustain it.
When to use it
USE IT WHEN
A new service or substantial change is approaching a pilot, rollout or transfer to another operating team.
The experience depends on staff actions, external systems or support outside the product team.
A test has shown that the interface works but recovery, escalation or ownership is unclear.
When to choose another method
Use Service Blueprint when the team cannot yet explain the work behind the experience.
Use Release Planning to decide the first scope and rollout sequence before reviewing readiness.
Use Accessibility Audit (WCAG) or specialist security assessment for their specific requirements; a general readiness review cannot certify them.
What you’ll need
Bring the release scope, a Service Blueprint or equivalent flow, dependency owners, support arrangements, monitoring and existing test evidence. Include staff who will operate the service, not only people authorised to approve it. Decide who can accept residual risk and who can pause a rollout. For a small MVP, a concise evidence log is enough; do not borrow a large organisation’s entire checklist.
What operational readiness should cover
Keep the elements that help answer your question and support a decision.
The outcome and time expectations people reasonably rely on.
Normal operation, cover, escalation, authority and handover.
External services, staff workload and known limits on demand.
Help routes, staff guidance, accessibility evidence and assisted alternatives.
Signals of failure, alert ownership, rehearsed recovery and rollback.
Blockers, mitigations, accepted limits and the next review.
02 / PUT IT INTO PRACTICE
How to review operational readiness
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Bound the review
Name the release, first audience and service promise. Identify which risks are in scope and which require separate specialist review.
Review a one clinic appointment change pilot, including confirmation and support.
02
Follow the work behind the screen
Trace a normal case across systems and staff. Record the owner of each handover and any waiting time that affects the user.
A pending request must be visible to clinic staff and the person who submitted it.
03
Ask for evidence of capability
For each relevant concern, link a rehearsal, test result, runbook or named operational agreement. Mark an untested claim as unknown.
Ask support staff to trace a sample request using the actual support process.
04
Rehearse failure and exclusion
Walk through unavailable dependencies, absent staff, duplicate requests and people unable to use the default channel. Include the responsible operators.
What happens when confirmation fails after the user leaves the page?
05
Separate blockers from managed limits
Identify failures that would break the service promise. For a manageable limit, record the mitigation, accountable owner and when acceptance expires.
An untraceable request blocks the pilot. A restricted staffed pilot window may be acceptable if clearly communicated.
06
Make an explicit launch decision
Record proceed, restrict or hold, including reasons and authority. Never infer approval from a mostly green checklist.
Restrict access to staffed hours until the cover and escalation path have been rehearsed.
07
Review after first use
Check actual service demand, exceptions and support experience. Revisit assumptions and retire obsolete checks as the service changes.
Review unresolved requests with clinic and support owners before expanding the pilot.
Example: checking an appointment change pilot
Illustrative service scenario, not an actual launch review: a team plans an appointment change pilot at one clinic. The interface passes its basic tests, but a rehearsal shows that support cannot find a pending request if confirmation fails. There is also no named cover outside the clinic’s staffed hours.
The review records request traceability as a blocker because the team cannot reliably explain whether an appointment changed. Engineering and support agree an evidence check for that path. The first pilot is restricted to clearly communicated staffed hours while the team tests cover and escalation. The existing appointment remains active unless a replacement is confirmed.
The decision is to hold the pilot until the failed confirmation case can be traced, then consider a restricted rollout with a named service owner. The diagram separates a blocker from a managed limit. These are invented conditions for explaining the method, not a recommended operating threshold for healthcare services.
03 / BELOW THE SURFACE
Below the surface: readiness can expire
A service can be ready for one audience and operating window without being ready for wider access. The launch decision has conditions, even when a checklist hides them.
BOUNDARY
For which audience and operating conditions is this ready?
Keep a limited pilot distinct from general availability.
EVIDENCE
What demonstrates the recovery path actually works?
Distinguish a written runbook from a rehearsed capability.
EXPIRY
What change invalidates the current decision?
Assign an owner and trigger for reviewing accepted limits.
A checked item often captures capability at one moment. A trained colleague may leave, a supplier may change its behaviour or demand may exceed the staffing assumption. If the original decision does not record its boundary, a limited pilot can quietly become an unsupported general service.
For every accepted limit, ask which change would invalidate the decision. Expansion to a new location, a different audience or a longer operating window may require another rehearsal. Record the evidence owner and the condition that triggers review alongside the mitigation.
A risk accepted by a team may be experienced by a user. Ask who bears the consequence if the mitigation fails, and whether that person can understand or avoid the limitation. This is an original editorial lens for reviewing readiness, not a replacement for formal risk management or regulatory approval.
Operational Readiness Checklist template
The original two page operational readiness template captures the service promise, owners, dependencies, support, monitoring and recovery. Page two records rehearsal evidence, blockers, managed limits and the launch decision. Its PDF fields are editable and a CSV is included for a shared evidence log. Adapt the prompts to the service; it is not a formal compliance or safety approval.
Practical tips
Invite the people who will handle exceptions and support.
Link evidence to checks rather than writing “done” without a reference.
Record the operating boundary and review trigger for every accepted limit.
Common mistakes
Treating the number of completed items as an objective readiness score.
Accepting a recovery plan that the responsible people have never rehearsed.
Expanding a pilot without revisiting staffing, inclusion and dependency assumptions.
What you’ll get
A reasoned proceed, restrict or hold decision with evidence, blockers, mitigations and accountable owners. Use it to protect a clear service promise, then review actual operation after launch. Keep specialist findings visible and revisit the decision when the audience, operating conditions or dependencies change.