Writing procedures employees can use: start with the task, not the template
Practical guide · Educational reading
A practical workflow for turning process knowledge into clear procedures: map the task, choose the right format, explain decisions and test the result with users.
Audience / jurisdiction: International; practical guidance for quality-management and process owners, not a statement of legal obligations.
Start with the task and its intended result
A useful procedure starts with the work people need to complete, not with an empty template. ISO’s paper on the process approach connects documentation choices to process complexity, criticality and interactions. It identifies several possible formats, including written instructions, checklists, flowcharts, visual media and electronic methods. That gives practitioners a useful starting question: what information will help someone achieve the intended result?
The following workflow is a suggested implementation method, not an ISO-prescribed template. It draws on a paper explaining ISO 9001:2015 and does not establish requirements for another edition. Use it to improve a selected task while checking any applicable organizational, contractual or sector-specific requirements separately.
Sources: [1]
Map the work before drafting instructions
The process-approach paper links activities, inputs, outputs and interactions. As a practical first step, walk through the task with someone who performs it. Ask what starts the work, what information or materials must be available, which decisions occur and who receives the result. Capture these points in a short outline before writing detailed instructions.
Next, identify where an unclear instruction could affect the outcome. Suggested questions include: Can the wrong input enter the process? Is there a decision that depends on experience nobody has written down? Does a handoff leave responsibility uncertain? Concentrate the procedure on those points rather than giving every activity equal space.
Define success in observable terms. For example, a receiving task might aim to produce an identifiable delivery record and route discrepancies to the responsible person. This is a hypothetical objective, not a prescribed acceptance criterion.
Sources: [1]
Choose a format that supports the decisions
Because the source recognizes multiple documentation methods, selecting a format need not mean defaulting to several pages of prose. As a suggested rule of thumb, use a checklist for repeat checks, a flowchart where decisions branch, and short sequential instructions where order matters. Visual material may help when a condition is easier to recognize than describe.
Keep the format proportionate to complexity and criticality. A short task may need only a compact checklist; a task involving several teams may benefit from a flowchart showing handoffs. These are practical choices, not fixed ISO rules. Avoid repeating the same instruction in several places unless there is a clear way to keep the copies aligned.
Sources: [1]
Make actions, decisions and exceptions explicit
The source connects process management with responsibilities and controls. Translate that principle into direct instructions: identify who acts, what they check, how they recognize an acceptable result and where they refer an exception. Where a decision depends on a separate specification, direct the user to the relevant information rather than inventing a threshold.
Hypothetical example: replace “check incoming goods and report problems” with a receiving checklist covering the order reference, quantity comparison, visible-damage check, discrepancy contact and receiving-record location. The organization would still need to determine its own acceptance criteria and responsibilities.
A useful drafting check is to underline vague expressions such as “as appropriate” or “notify management.” Keep them only where the user has enough information to make the decision consistently.
Sources: [1]
Test usability and follow the results
The process-approach paper links ownership, controls and monitoring with evaluating outputs against objectives. A suggested way to apply that principle is to ask a trained user other than the author to try the draft. Observe where they pause, seek clarification or rely on explanations that are absent from the procedure.
Revise those points before release. Then identify who will maintain the instructions and how users will find the approved version. After use, review whether the task produces its intended result, not merely whether the document has been approved. Repeated questions, missed handoffs or recurring discrepancies are useful prompts to investigate whether the instructions, resources or process itself need improvement.
Sources: [1]
Sources
Your experience
Which procedure in your organization still needs an experienced colleague to explain what its instructions actually mean?
Worth sharing?
Pass this on to a colleague or your community.
Questions, experience & feedback
Join with an email-verified AdviseISO account to share your perspective. Reader comments are reviewed before publication. Your email address will not be displayed.
Be the first to share a question or experience.
Join the discussion
Create an account and verify your email, or sign in to your existing account.
Sign in Create account