Create a practical quality-assurance plan for this work. It must be usable by the people doing the work and by the person approving it. Process or deliverable: [PROCESS OR DELIVERABLE] Quality risks and past failure modes: [RISKS AND FAILURE MODES] Acceptance requirements or standards: [ACCEPTANCE REQUIREMENTS] People, roles, and handoffs: [ROLES AND HANDOFFS]
Volume, timing, and tools: [OPERATING CONTEXT]
Begin with a short scope statement and define what is in and out of the QA plan. Then produce a table with these columns: checkpoint, exact criterion, method of verification, evidence to retain, owner, timing, severity if failed, and corrective action. Make criteria observable and testable; replace phrases such as “high quality” or “review carefully” with thresholds, comparisons, or pass/fail conditions.
Include checks at the right stages: input validation before work starts, in-process checks where errors are cheapest to fix, final acceptance before release, and a sample-based or trend review after release if relevant. Distinguish blocker defects from issues that can be corrected later. Specify who can approve an exception and how it is documented.
After the table, provide: a 6–10 step runbook, an escalation path for a failed blocker, and a weekly metrics section with defect rate, rework rate, turnaround time, and the most useful leading indicator for this process. If a requirement is unclear, label it as a decision needed rather than inventing a standard.
Before answering, self-check that each checkpoint has one accountable owner and evidence that can be inspected later. Also check that the plan catches the listed failure modes before they reach the customer or downstream team. Ask up to 3 clarifying questions only if a required input is missing.Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PROCESS OR DELIVERABLE] | Describe the work being checked, its start and end points, and what the final output is. | Publishing client payroll reports each Friday from imported timesheets through a secure portal. |
| [RISKS AND FAILURE MODES] | List errors that have happened before or errors that would cause material harm. | Duplicate employee rows, incorrect overtime rate, report sent to the wrong client folder, and approval after the Friday cutoff. |
| [ACCEPTANCE REQUIREMENTS] | Provide customer commitments, internal standards, regulations, or measurable definitions of done. | Reports must reconcile to approved timesheets, use the client’s rate table, be in the correct portal folder, and be released by 3 p.m. Friday. |
| [ROLES AND HANDOFFS] | Name the roles that create, check, approve, receive, or remediate the work. | Payroll analyst prepares; senior analyst checks; account manager confirms client exceptions; operations lead approves release exceptions. |
| [OPERATING CONTEXT] | State work volume, deadlines, systems used, and any sampling or staffing constraints. | About 40 reports weekly, processed in Workday exports and Google Sheets; Friday deadline is fixed; two senior analysts cover QA. |
How to use
- List real defects from incident notes or customer complaints before pasting the inputs; they are the best source of useful checkpoints.
- Replace broad standards with measurable criteria, such as a required reconciliation or a named source of truth.
- Assign one accountable owner per check even when several people participate in the handoff.
- Follow up with: “Convert this runbook into a one-page checklist for the [ROLE], with a separate exception log template.”
Variations
Software release QA
Use this when a product team needs test coverage and a release gate.
Create a release QA plan for [FEATURE OR RELEASE]. User flows and acceptance criteria: [USER FLOWS]. Known regression risks: [REGRESSION RISKS]. Environments, devices, and integrations: [TEST CONTEXT]. Roles: [ROLES]. Produce a test matrix with scenario, precondition, expected result, test type, owner, evidence, and release-blocking status. Include smoke tests, edge cases, rollback criteria, and post-release monitoring. Do not claim a test passed or invent test results. Check that every acceptance criterion maps to at least one test. Ask up to 3 questions only if required input is missing.
Content QA checklist
Use this when a publishing team needs consistent editorial and production checks.
Build a content QA checklist for [CONTENT TYPE]. Audience and purpose: [AUDIENCE AND PURPOSE]. Editorial rules: [EDITORIAL RULES]. Required links, approvals, and legal constraints: [REQUIRED ELEMENTS]. Publishing workflow: [WORKFLOW]. Create a pre-draft, pre-publish, and post-publish checklist with owners and evidence. Include factual support, attribution, link destinations, accessibility basics, formatting, metadata, and scheduled-time checks where relevant. Flag standards I have not supplied rather than making them up. Check that each required approval occurs before publication. Ask up to 3 questions only if needed.
Vendor acceptance
Use this when goods or services need inspection before acceptance or payment.
Write a vendor acceptance QA plan for [PURCHASE OR SERVICE]. Contract or order requirements: [REQUIREMENTS]. Inspection points and likely defects: [DEFECTS]. Receiving roles and timeline: [RECEIVING CONTEXT]. Produce an acceptance checklist with measurable pass/fail criteria, photo or document evidence, sample size where supplied, nonconformance steps, and who can accept a deviation. Separate receipt confirmation from final acceptance. Do not invent contractual tolerances or authorize payment. Check that every requirement has an evidence method. Ask up to 3 questions only if required.
Tips
- Build checkpoints around the places an error can be prevented or detected, not around department names or meeting cadence.
- Keep evidence proportional to risk: a timestamped reconciliation may be enough for a routine report, while a regulated or safety-critical task may need retained source records and approval signatures.
- Sampling only works when the population, sample rule, and escalation threshold are defined; “spot check” is not a control.
- Review recurring defect categories monthly and change the upstream process when the same correction keeps appearing.
FAQ
What is the difference between QA and final approval?
QA is the planned system of checks that prevents and detects defects across the workflow. Final approval is one decision point within that system.
How detailed should a QA checklist be?
It should let a trained person make a consistent pass or fail decision without guessing. Split complex work into checkable stages instead of making one enormous final checklist.
Can AI create compliance requirements for my process?
It can organize requirements you provide and identify gaps, but it should not be treated as the source of legal, regulatory, or contractual obligations.