Operations
Part of Running productivity software as a dependable service with an operating charter
A quality checklist for a productivity workflow before launch and after every material change
Check a productivity workflow before launch and after material changes, covering real tasks, access, data, integrations, exceptions, recovery and evidence.
Use this business productivity software quality checklist before a controlled launch, after a material configuration change and when recurring defects suggest that the workflow no longer fits. Mark each item pass, fail, not applicable with a reason, or not yet evidenced.
The checklist is a starting control for organisations in England, not certification. Accessibility, privacy, cyber security and legal compliance require competent assessment against the actual service and users. The checklist itself is jurisdiction-neutral; only the compliance references below are UK-specific.
What to take away
- Use this checklist before launch, after configuration changes, and when recurring defects show the workflow no longer fits.
- Mark each item pass, fail, not applicable with a reason, or not yet evidenced.
- The checklist is a starting control, not certification; accessibility, privacy, security and legal compliance need competent assessment.
- A short checklist with evidence is stronger than a long one filled from memory.
- If a critical item cannot be shown as checked, its honest status is not yet evidenced.
Purpose and route
- The service purpose, users and excluded work are written in ordinary language.
- A realistic request enters through the documented route without private intervention.
- Required fields affect a decision, and optional fields are identified as such.
- Accepted, rejected and incomplete submissions produce understandable next steps.
- Every workflow state has an entry rule, owner and exit rule.
- Urgent work and complaints follow defined paths rather than improvised labels.
- Completion requires the stated check, record and communication.
Run these with examples taken from genuine work but remove or protect personal data used in testing. Government guidance on exploratory testing, the Service Manual page 'Exploratory testing', recommends a clear charter and notes about features, issues and questions. It is written for public digital services, yet its disciplined record is also useful for a configured business workflow.
Submission route and next steps
- Realistic request enters documented route
- Required fields affect a decision
- Accepted submissions get clear next steps
- Rejected submissions get clear next steps
- Incomplete submissions get clear next steps
- Urgent work follows defined path
- Completion needs check, record, communication
People and accessibility
- A new user can complete the main journey with the agreed instructions.
- Someone unfamiliar with the setup can distinguish priority, status and owner.
- Keyboard, zoom, screen-reader and other relevant accessibility checks have named assessors.
- Error messages explain recovery without exposing confidential information.
- Deputies can perform time-sensitive actions when the usual owner is absent.
- Training covers exceptions and support, not only the ideal route.
Do not claim accessibility from an automated scan alone. GOV.UK's quality-assurance guidance, the Service Manual page 'Quality assurance testing your service regularly', combines human and automated work and asks teams to test normal and unusual conditions. Its service standard applies in government contexts; an organisation should choose proportionate checks for its own users.
People and accessibility checks
- New user completes main journey
- Priority, status, owner distinguishable
- Accessibility checks have named assessors
- Error messages explain recovery safely
- Deputies cover time-sensitive actions
- Training covers exceptions and support
Access, data and administration
- Default permissions match role need, and elevated access needs approval.
- Joiner, mover, leaver and guest procedures work end to end.
- An administrator can identify dormant, external and privileged accounts.
- Restricted fields, attachments and exports are visible only to intended roles.
- Collection, retention, deletion and subject-rights handling have been reviewed.
- Important admin actions and access events can be investigated where required.
The NCSC's secure SaaS guidance, the guidance 'Using SaaS securely' in its cloud security collection, covers customer responsibilities for identity, administration, data, logging and response. Apply those questions to the chosen supplier and configuration. The checklist itself does not prove a control is effective.
Access and admin control areas
Control area
- Permissions
- Default matches role
- Lifecycle
- Joiner, mover, leaver, guest
- Accounts
- Dormant, external, privileged
- Data visibility
- Restricted fields, exports
- Retention
- Collection, deletion, rights
- Investigation
- Admin and access events
What to verify
- Permissions
- Elevation approved
- Lifecycle
- Accounts
- Data visibility
- Retention
- Investigation
Connections, failure and recovery
- Each integration has an owner, expected frequency and failure alert.
- A duplicate, late or malformed input produces a controlled result.
- The team knows which system is authoritative when records disagree.
- Priority work can continue through an accessible fallback during an outage.
- A representative export opens, preserves necessary fields and reconciles to a source total.
- Contact, escalation, communication and restoration steps are stored outside the affected service.
Do not test destructive recovery in production without an approved plan. Use a safe environment, reversible sample or supplier-supported method selected by the technical owner.
Evidence and release decision
Record tester, date, environment, input, expected result, observed result and evidence location. Assign every defect a severity, owner and decision. "Known" is not the same as accepted; material residual risk needs a person authorised to accept it: the role accountable for the service outcome, such as the service owner, not a job title.
For example, the item on default permissions is marked fail when a test account can open a restricted export. The evidence record gives tester, date, environment, the account used, the export opened, and stores the screenshot in the release folder.
Before release, check that failed items are fixed, deliberately deferred with safeguards, or make the service unsuitable. Note product edition, configuration version and dependencies so the result can be reproduced. Set the next review trigger, including supplier change, permission redesign, new data use or a serious incident.
Before you act
- Run checks with genuine examples but protect personal data.
- Do not claim accessibility from an automated scan alone.
- Do not test destructive recovery in production without an approved plan.
- Record tester, date, environment, input, expected result, observed result and evidence location.
- Assign every defect a severity, owner and decision.
- Set the next review trigger after release.
Common questions
When should this checklist be used?
Use it before a controlled launch, after a material configuration change, and when recurring defects suggest the workflow no longer fits.
How should each checklist item be marked?
Mark each item pass, fail, not applicable with a reason, or not yet evidenced.
What should be recorded as evidence?
Record tester, date, environment, input, expected result, observed result and evidence location.
