What a procedure is for
A standard operating procedure, often shortened to SOP, is a written description of how a repeatable task is done. It exists so the work gets done the same way regardless of who does it, and so that knowledge does not live only in one person’s head.
Many procedures are written and then ignored. They are too long, too vague, out of date, or stored where nobody looks. The goal of this article is to help you write the kind people actually follow.
Choose what deserves one
Not every task needs a procedure. Writing and maintaining them takes effort, so aim them where they help most. Good candidates tend to be tasks that:
- Are repeated regularly, or are rare but important enough that nobody remembers the steps
- Have a cost if done wrong, such as errors, delays, security exposure or customer impact
- Are done by different people or handed over
- Involve several steps in a particular order
- Are used to train new people, such as in remote onboarding
Tasks that are simple, rarely repeated or highly variable usually do not merit a full procedure. A short checklist may be enough. Tasks that are frequent and mechanical may be better suited to automation than to documentation, though it is wise to write the manual version down first, so you know what you would be automating. Automation candidates covers how to spot them.
Write it for the person doing the task
The reader is usually in the middle of the work, with part of their attention elsewhere. They need to find the right step quickly and understand it without interpretation. Several principles follow.
One procedure, one task. If a document covers “month-end” in general, break it into the specific tasks it contains. A narrow title makes it easy to find and keep current.
State the purpose and scope in two lines. What is this for, when do you use it, and who does it? This lets a reader confirm they have the right document.
List what is needed first. Access, tools, files, approvals or information. Discovering a missing item on step six is frustrating.
Number the steps and keep each to one action. Start each with a verb: “Open the order list,” “Select the date range,” “Send the confirmation.” If a step has two actions joined by “and,” consider splitting it.
Include the decisions. If the path branches, say so plainly: “If the amount is above the approval limit, go to step 8. Otherwise, continue.” Avoid hiding exceptions in long paragraphs.
Say what done looks like. Include a check at the end, such as what the screen should show or what record should exist.
Add screenshots or examples only when they clarify. Visuals go out of date when software changes, so use them where words are genuinely not enough, and expect to update them.
Keep it short and plain
A page or two is usually plenty. If a procedure runs much longer, consider whether it is really several procedures, or whether background explanation should be moved into a separate reference page. Use plain words and avoid jargon, or define terms the first time. Write in the active voice and the present or imperative tense.
Do not try to capture every unusual case. Cover the normal path well, list the most common exceptions, and say who to contact for anything else. A list of contacts is often the most useful addition, since procedures cannot predict everything.
Test with someone who has not done it
The author is the worst judge of whether a procedure is clear, because they already know the task. Ask someone unfamiliar, or less familiar, to follow the document exactly while you watch, without helping. Note where they hesitate, ask a question or do something different from what you meant. Each of those points is a flaw in the text. Fix them and test again.
Testing also reveals steps you do automatically and forgot to write down, such as logging in to a particular system or checking something first.
Assign an owner and a review date
A procedure goes out of date quietly. Software changes, roles shift, and old steps stop being right. Put a named owner and a last-reviewed date at the top. Decide on a review interval that fits how often the process changes, and review sooner when something changes.
Encourage users to flag problems. A simple comment mechanism, or a standing rule that whoever notices an error corrects it or tells the owner, keeps procedures honest. When a procedure involves significant risk or policy, the sign-off method in document approval applies.
Put it where people will look
The best-written procedure fails if nobody can find it. Store them together in one place, such as a team wiki, with clear titles that match how people describe the task. Link or reference them where the work happens, for example in a task template or the checklist for a recurring project. Consistent layout through document templates helps readers move between procedures quickly.
Mention the procedure when you assign the task or onboard someone. Habits form when people are pointed to the document, not when it merely exists.
Treat procedures as support, not control
Staff follow procedures more willingly when they help rather than police. Involve the people who do the work in writing and revising them, since they know the real steps and shortcuts. Be open about the reasons behind rules, particularly for security or compliance steps. A short note explaining why a step exists makes it less likely to be skipped.
Procedures also should not replace judgment. Where a task requires discretion, say so and describe the principles rather than pretending every case is covered.
Safety and compliance
If a procedure concerns safety, legal obligations, finances or regulated activity, the content may need review by someone qualified, and the requirements vary by industry and location. A general guide like this cannot substitute for that review. Treat the procedure as a record of how your organization intends the work to be done, and confirm that the intent meets whatever rules apply.
A minimal template
A workable layout fits on one page:
- Title
- Purpose and when to use it
- Owner and last reviewed date
- What you need
- Numbered steps, with decisions marked
- How to check it worked
- Who to contact if something goes wrong
Start with the most important or error-prone task on your team, write it using this layout, test it with a colleague, and see whether it gets used. If it does, repeat for the next one.