
Operations
Part of Landing page software operations: gates and rollback
How to write landing page software service standards as events, clocks and evidence
A UK guide to writing landing page software service standards as auditable service cards, with blank thresholds, clock rules, evidence, owners and review triggers.
Landing page software service standards should define observable events before anyone chooses a target. A statement such as "respond quickly" cannot be audited. The record needs a population, unit, clock rules, evidence source, owner and remedy. The buyer then enters an approved threshold or quotes a value from the executed supplier contract.
No standard or response time below is a benchmark. Every threshold is intentionally blank. The relevant reviewer approves each blank threshold, and the service card records the value, approver and date. Legal, data-protection, security, accessibility, commercial and operational reviewers must approve their separate definitions.
What to take away
- Never copy a supplier's headline promise without checking the contract, scope and exclusions.
- Each standard needs an accountable owner, escalation authority and a safe action.
- Review service cards after supplier changes, incidents, contract amendments or failed recovery exercises.
Write a service card
Create one card for each standard with these fields:
Service card fields
- Service event and eligible population
- Measurement unit and reporting period
- Clock start, timezone, pauses, stop event
- Exclusions and who may authorise them
- System of record, query or log version
- Buyer-approved thresholdblank
- Contractual source, clause, edition, date
- Accountable owner, escalation authority, safe action
- service event and eligible population;
- measurement unit and reporting period;
- clock start, timezone, pauses and stop event;
- exclusions and who may authorise them;
- system of record, query or log version;
- buyer-approved threshold
________; - contractual source, clause, edition and date, if applicable;
- accountable owner, escalation authority and safe action;
- recovery evidence and review trigger.
A marketing page, support policy and executed agreement may describe different obligations.
Derive each threshold from the risk of the event, the current data source and the buyer's approved policy. The accountable owner proposes the value, the relevant reviewer approves it, and the card records the source and date.
Worked example cards:
| Standard | Event | Clock | Evidence | Owner |
|---|---|---|---|---|
| Candidate-to-release | Candidate enters specialist review and receives a release, hold or return decision. | Starts at logged hand-off in Europe/London; pauses only for missing buyer evidence; stops at the recorded decision. | Brief, evidence pack, reviewer log and decision record. | Release controller |
| Access removal | Authorised leaver or integration no longer needs access. | Starts at the approved removal event; pauses for a documented approval delay; stops when revocation is verified. | Revocation log, access review and ticket. | Access administrator |
| Correction | A designated channel records a sufficiently described issue. | Starts when the issue is logged; pauses for qualified legal review; stops when the safe action is verified. | Issue record, correction note and verification. | Correction owner |
| Recovery | Instruction to restore the approved fallback. | Starts at the instruction; pauses for an approved infrastructure hold; stops when checks pass. | Restore log, check results and sign-off. | Recovery lead |
| Exit | Approved supplier or page closure. | Starts at approval; pauses for retention or legal hold; stops when deletion evidence is complete. | Export, redirect, access removal and deletion records. | Exit manager |
Clock illustration: a page form failure is logged at 14:00 Europe/London. The clock starts then, pauses while the buyer supplies the missing error message, and stops when the correction owner records the fix. The card stores the timezone and pause reason.
Candidate-to-release standard
Event: a candidate enters specialist review and either receives a release decision or returns for correction.
Population: candidates with a complete brief and evidence pack. Exclude drafts that never met the entry condition, but report them separately as intake failures.
Clock: start at the logged hand-off; stop at a recorded release, hold or return decision. Define permitted pauses, timezone and missing-evidence treatment. Owner: release controller. Threshold: ________.
The ASA CAP Code and its substantiation guidance support an evidence-before-distribution gate for objective UK advertising claims. Neither supplies an approval time or excuses an unsupported release.
Accessible-critical-task standard
Event: a nominated critical journey completes with the expected state, or produces a recorded defect.
Population: declared browser, viewport and assistive-technology combinations for the specific release. State what is not covered.
Evidence: test script, build ID, observed result and defect record. Owner: accessibility reviewer. Acceptance threshold: ________.
WCAG 2.2 input assistance defines criteria for labels, error identification and related help. It supplies testable technical requirements, not a universal service target or legal verdict.
Access-removal standard
Event: an editor, integration or administrator no longer needs access, followed by verified revocation.
Population: all identities and service identities connected to the page, domain, data stores and recovery route. The clock starts at the authorised removal event and stops when evidence shows access has ended. Threshold: ________.
The NCSC's SaaS security guidance recommends reviewing permissions, removing access that is no longer needed and retaining activity logs. Choose the target according to risk and the organisation's approved policy, not an invented industry average.
Correction and withdrawal standards
Create distinct cards for unsupported claims, broken forms, rights complaints, tracking faults and suspected security incidents. The eligible event starts when the designated channel records a sufficiently described issue, not when someone happens to read an informal message. Define the safe action: correct, pause traffic, disable a component, withdraw the page or invoke the incident plan.
For personal-data concerns, the decision about regulatory or individual notification depends on facts and qualified review. The NCSC incident management guidance supports prepared response and recovery, but does not set the organisation's legal outcome. Threshold: ________; incident authority: ________.
Recovery and exit standards
Recovery event: instruction to restore the approved fallback, ending when the domain, page, form destination, tags and permissions pass the agreed checks. Record whether content alone was restored or the whole journey worked. Threshold: ________.
Exit event: approved supplier or page closure, ending only after authorised exports, redirects, access removal, retention actions and deletion evidence are complete. The ICO's controller and processor contract guidance covers end-of-contract provisions and audits. It is under review following the Data (Use and Access) Act, and it does not settle commercial terms.
Review the definitions
Review a card after a supplier change, incident, contract amendment, workflow change or failed recovery exercise. Preserve the old definition and effective date. Otherwise a changed denominator or clock can make performance appear better without any service improvement.
Before you act
- Write one service card per standard with all required fields.
- Leave every threshold blank until the buyer approves a value.
- Check the executed contract, scope and exclusions before accepting a promise.
- Define clock start, timezone, pauses and stop event for each standard.
- Name an accountable owner and escalation authority for every card.
- Review cards after supplier changes, incidents or failed recovery exercises.
Common questions
How should a correction or withdrawal standard begin its clock?
The eligible event starts when the designated channel records a sufficiently described issue, not when someone happens to read an informal message. Define the safe action: correct, pause traffic, disable a component, withdraw the page or invoke the incident plan.
When should a service card be reviewed?
Review a card after a supplier change, incident, contract amendment, workflow change or failed recovery exercise. Otherwise a changed denominator or clock can make performance appear better without any service improvement.



