Quality assurance procedures are documented steps for managing how work meets defined quality requirements. A useful procedure identifies the task, responsible people, checks, evidence and response when something fails. It helps a team perform the work consistently and investigate recurring problems.
This guide explains how to write and introduce a procedure, with a copyable template and an illustrative customer-support example. The same structure can be adapted to software delivery, service operations or production, using the requirements and qualified reviewers appropriate to that work.
Quality assurance procedures, policies and plans
A quality policy states the organization’s intentions and expectations. A quality plan describes how quality will be managed for a particular project, product or service. A procedure explains how to perform a specific activity within that system.
For example, a support policy might require customers to receive accurate, approved guidance. A quality plan might define the review program, resources and reporting for the support team. A procedure might explain how an agent verifies an answer and escalates an unresolved technical question.
ASQ’s quality-plan guidance connects objectives, responsibilities, procedures, verification and measurement. Use that broader plan to decide which procedures you need, rather than writing a separate document for every minor action.
| Document | Question it answers | Illustrative support example |
|---|---|---|
| Policy | What do we expect? | Provide accurate guidance and protect customer information |
| Plan | How will the team manage quality? | Assign reviewers, define sampling and report recurring failures |
| Procedure | How is this activity performed? | Verify a proposed troubleshooting answer before sending it |
| Work instruction | How is one detailed action done? | Reproduce a reported error in a controlled test account |
| Record | What actually happened? | Review notes, evidence and the decision on a ticket |
Quality assurance versus quality control
ASQ distinguishes quality assurance and quality control by their focus. QA builds confidence that requirements will be met through planned activities. QC focuses on fulfilling requirements, including inspection and other operational checks. The activities can overlap.
Do not treat QC as something that happens only after all work is finished. A check can happen during production or while a service is being delivered. In a support workflow, designing an answer-review process is a QA activity; checking a specific answer against the criteria is an operational quality check.
Neither a checklist nor a passed inspection guarantees that every future result will be correct. Use findings to improve the process, while retaining checks for important failure modes.
What an effective QA procedure contains
A person using the procedure should be able to tell when it applies, what to do and who can make the next decision. Keep the operational steps short enough to use during the task, and link detailed instructions instead of burying them inside a long overview.
- Scope: the activity covered, its starting point and any exclusions.
- Requirements: observable criteria for an acceptable result, with their source.
- Ownership: who performs the work, reviews it and authorizes exceptions.
- Sequence: actions and decision points in the order they occur.
- Evidence: what is recorded, where it is kept and who can access it.
- Failure response: how to contain a problem, correct the result and investigate recurrence.
- Maintenance: the document version, approval and triggers for review.
A requirement such as “provide excellent support” leaves too much to interpretation. “Confirm the affected product version before recommending version-specific steps” is observable. A reviewer can point to the recorded version and compare the advice with the relevant documentation.
How to create quality assurance procedures in seven steps
1. Choose a process and define its requirements
Start with a process where failure has a meaningful effect on the customer, product or operation. Review complaints, rework, incidents and known gaps. Choose one bounded workflow for the first procedure so the team can try it and improve it before expanding the program.
List what the result must satisfy and where each requirement comes from: an agreed service commitment, product specification, internal policy or another applicable source. Separate mandatory acceptance criteria from improvement goals. A response-time target should not encourage an agent to send an unverified answer just to close a ticket quickly.
2. Map the actual workflow
Ask the people performing the work to walk through a recent example. Record inputs, handoffs, dependencies, decision points and the completed output. Include what happens when information is missing or a dependency is unavailable.
Compare the intended process with the real one. If a reviewer is routinely unavailable, writing “obtain approval” does not solve the gap. Define a backup owner or an appropriate route for holding the work until review is available.
3. Assign responsibilities and authority
Name the role responsible for completing each stage. Distinguish the person who does the work from the person who approves a decision where separate approval is needed. Define who can accept an exception, what evidence they need and how that decision is recorded.
For an external supplier, specify the expected input, acceptance check and escalation contact. If a vendor supplies a dataset, for example, identify the required fields and what the team does when a file fails validation. Do not assume the supplier’s own quality program removes the need to check your dependency.
4. Write steps and decision rules
Use action verbs and observable completion conditions. Replace “ensure accuracy” with the particular comparison or verification the person should perform. Put a failure route beside the relevant check, so a user does not need to search another document to find the next action.
Include exceptions that occur often enough to matter. A support procedure might require escalation when the suggested fix conflicts with current documentation, when the issue cannot be reproduced or when a customer-impacting change requires approval. Link the relevant escalation procedure rather than inventing approval authority inside the QA document.
5. Define evidence and review coverage
Decide what record demonstrates that a check occurred. That might be a ticket note, measurement result, review decision or test evidence. Keep enough context to understand the result later: the item reviewed, procedure version, reviewer, date and reason for a failure or exception.
For repeated work, decide whether to inspect every item or use a sample. High-risk items may require individual review. A sample should have a defined population and selection rule; choosing only easy cases or known successes will distort the result. Keep targeted incident reviews separate from a routine sample when reporting rates.
6. Pilot and train
Try the procedure on a small set of representative cases. Ask a person who did not write it to follow it. Check whether they can identify the right starting point, apply the criteria and find the failure route without informal explanations.
Training should include a completed example and a case that fails a criterion. Ask the learner to explain the decision, then review the evidence together. A short video can demonstrate a visual action, but retain written requirements and decision rules. Our customer service training manual guide provides a structure for turning procedures into training modules.
7. Review results and revise the process
Review findings on a cadence appropriate to the workflow, and also when a product, dependency or requirement changes. Repeated failures may indicate missing training, unclear instructions, a poor handoff or a tool limitation. Investigate before assuming that every issue is individual noncompliance.
ISO’s quality management principles emphasize customer focus, a process approach, improvement and evidence-based decisions. In practice, connect each procedure change to a finding, assign an owner and check whether the change addresses the original problem.
Copyable quality assurance procedure template
Adapt this template to one activity. It is an operational starting point; using it does not demonstrate compliance with a particular standard or certification requirement.
Procedure title and ID: Version / effective date: Owner / approver: Purpose: Scope and exclusions: Trigger / starting input: Requirements and reference sources: Required tools / access / training: Steps: 1. Action / responsible role / completion evidence 2. Action / responsible role / completion evidence 3. Decision / acceptance criterion / next action Checks and review coverage: - Item or population reviewed: - Reviewer and timing: - Acceptance criteria: - Evidence location and access: If a check fails: - Immediate containment or hold: - Correction owner: - Escalation and exception authority: - Follow-up verification: Records to retain: Related instructions and procedures: Review cadence and change triggers: Change history:
Publish the approved version where the team already works. Archive or clearly supersede earlier instructions so people do not follow conflicting versions. A video walkthrough should identify the procedure it demonstrates and be reviewed when those steps change.
Example: quality assurance for a technical support answer
The following is a fictional procedure for a team answering product configuration questions. Its checks illustrate a method; they are not a universal standard or evidence of a measured improvement.
| Stage | Action and acceptance criterion | Record or failure route |
|---|---|---|
| Intake | Confirm the affected feature, version and reported behavior | Record missing details; request clarification before giving version-specific advice |
| Investigation | Compare the issue with current documentation and, where appropriate, reproduce it in a controlled account | Link the reference and evidence; flag uncertainty rather than claiming a confirmed cause |
| Draft | Provide ordered steps, prerequisites and an observable expected result | Check that the steps match the customer’s environment |
| Review | Check accuracy, permissions, private information and any required approval | Hold advice that fails a required check; route it to the defined reviewer |
| Send and follow up | Explain what the customer should try and how to report the result | Record the answer and follow-up; do not mark the issue resolved without the required evidence |
Suppose the review finds that the proposed answer uses an option removed in the customer’s version. The immediate correction is to revise the answer before sending it. The process investigation asks why the agent reached an obsolete instruction: was the knowledge-base page unversioned, the procedure unclear or the product information missing?
A process change might add a version check and retire the outdated article. The owner then reviews later cases to see whether the same failure still occurs. That verification matters more than simply recording that the document was edited. Use a structured issue report when the finding needs work by another team.
Measure quality without hiding failures in an average
Define the unit being reviewed, the eligibility rules and the observation period before calculating a rate. Report sample size and sampling method beside results. A small targeted review cannot establish the failure rate for all work.
| Measure | Definition | Interpretation check |
|---|---|---|
| Items passing all required checks | Passing items divided by reviewed items, multiplied by 100 | An average score can conceal a critical failed criterion |
| Rework rate | Items requiring correction divided by the defined completed-item population, multiplied by 100 | Use a consistent correction definition and observation window |
| Repeat failure count | Number of observed findings with the same defined failure type | Check exposure and reporting coverage before comparing periods |
| Correction verification | Whether a completed action was checked against its intended result | Closing an action is different from demonstrating effectiveness |
For an illustrative calculation, a routine review covers 20 eligible answers and 17 pass every required check. The all-checks pass rate is 17 / 20 × 100 = 85%. That describes the reviewed sample. It does not prove that 85% of all answers pass, or that the procedure caused an improvement.
Keep critical failures visible even when the overall score looks acceptable. Review quality alongside workload, response time and customer outcomes; the operational efficiency measurement guide explains how to define useful comparisons.
Use automation as a check, with a defined failure response
Automation can validate required fields, run repeatable checks or route a finding to an owner. Document what a check covers, when it runs, where results are stored and what happens if it fails or cannot run. A green status supports only the behavior the check actually examines.
A failed automated check does not necessarily halt delivery unless the workflow is configured to enforce that rule. Likewise, automatically generated test cases or summaries need review for missing requirements and incorrect assumptions. Avoid treating automation as proof that all defects have been prevented.
Use human review where judgment matters: ambiguous customer requirements, usability, unusual failures and decisions that need authorization. Keep the procedure useful when a tool is unavailable by documenting the hold or fallback route.
Quality assurance procedure FAQs
What should a small team document first?
Choose a recurring activity where errors affect customers or create substantial rework. Define its requirements, owner, steps, evidence and failure route. Pilot that procedure before documenting a much larger system.
How often should a QA procedure be updated?
Set a review cadence based on risk and how often the workflow changes. Also review after relevant product changes, repeated findings, incidents or changed requirements. Record what changed and tell affected users which version applies.
Does every task need a separate QA procedure?
No. Group related activities where one coherent procedure is usable. Use linked work instructions for detailed actions and separate documents where the scope, owner or decision authority differs.
Does a written procedure establish ISO 9001 compliance?
No. A procedure is one part of a management system. Any conformity or certification claim needs evidence against the applicable requirements and scope. This template does not assess that claim.
