How to Format and Write an SOP: Formats, Structure and Style
Last updated: September 2026
This is the fourth part of our series on the SOP lifecycle. By this point you have defined the scope and purpose of the procedure and agreed on the audience and the authors. Now comes the slice of the pie where most SOPs are won or lost: the format the procedure takes, and the way the steps are written.
Format and writing style are not cosmetic. A procedure that is hard to scan is a procedure people stop opening, and a procedure nobody opens is a control that exists on paper only. The goal of this stage is simple: someone who has never done the task should be able to complete it correctly by following what you wrote.
Start with the simplest thing that works
Before you open a blank document, ask whether a document is the right answer at all. Some procedures are better built into the environment than written down:
- If people need to move in one direction through a lab, warehouse or production line, floor arrows and wall signage may do the job better than a paragraph.
- If tasks have to happen in a fixed order, numbering and labeling the stations, bins or trays can enforce the sequence on its own.
- If a form must be completed the same way every time, building the rules into the form fields beats explaining them in a separate file.
Used in the right circumstances, an environmental control is more reliable than any written version, because it cannot be skipped, misfiled or left unread. Write the SOP when you need the detail, the evidence, or both, and reach for the document last rather than first.
Four SOP formats, and when to use each
Most procedures land in one of four formats. Choosing deliberately, rather than defaulting to whatever the last author used, is the single biggest improvement you can make at this stage.
| Format | Use it when | Watch out for |
|---|---|---|
| Checklist | The task is short, familiar and repeated often. Opening a store, closing a shift, issuing equipment to a new starter. | Checklists assume knowledge. They work badly as training material for someone doing the task for the first time. |
| Step-by-step | The task runs in a straight line from start to finish, with no real branching. Most administrative and IT procedures sit here. | Once you pass roughly 15 steps, readers lose their place. Split the procedure or move up to a hierarchical format. |
| Hierarchical | The process is long, spans several teams, or needs both a summary view and the detail. Main steps carry sub-steps beneath them. | Numbering gets unwieldy past three levels. If you are writing 4.2.7.1, the procedure probably needs to be two documents. |
| Flowchart | Outcomes depend on decisions. Approvals, escalations, incident triage, anything with “if this, then that” routes. | A diagram alone rarely carries enough detail. Pair it with written steps, and make sure the image is accessible to screen readers. |
Mixing formats within one document is fine, and often sensible: a flowchart at the top to show the routes, hierarchical steps underneath to explain each one, and a checklist at the end for people who only need the reminder.
Questions to settle before you write
- Does this already exist? If a working SOP covers the task, refresh it. Rewriting from scratch puts two versions into circulation and triggers a fresh round of retraining for no benefit.
- Do we have a house format? If your organization has a standard template, use it unless you can say why it fails in this case. Consistency is worth more than a locally optimal layout.
- How many routes are there through the process? More than two or three decision points pushes you toward a flowchart.
- How many audiences are involved? Several teams needing different levels of detail means hierarchical steps, or separate documents linked to each other.
- Where will it be read? A procedure followed on a phone at a loading dock needs shorter steps and larger headings than one read at a desk.
- What has to be provable later? If an auditor, regulator or insurer will ask who followed which version and when, the format has to carry version numbers, dates and a record of who acknowledged it.
What goes in the document
Whatever format you choose, readers and auditors expect the same building blocks in roughly the same order. Keep them consistent across every SOP you publish so people learn where to look.
| Section | What it contains |
|---|---|
| Header block | Title, document ID, version number, effective date, next review date, owner and approver. |
| Purpose | One or two sentences on why the procedure exists and what a correct outcome looks like. |
| Scope | Who it applies to, which sites or systems it covers, and what it deliberately excludes. |
| Roles and responsibilities | Named roles, not named people, and what each one is accountable for. |
| Definitions | Acronyms, system names and any term a new starter would have to look up. |
| Prerequisites | Access rights, equipment, materials, training or approvals needed before step one. |
| Safety and compliance notes | Warnings and cautions, placed immediately before the step they apply to, not collected at the end. |
| Procedure | The numbered steps themselves, in the format you chose. |
| Records | What the task produces, where it is filed and how long it is kept. |
| References | Related policies, forms, work instructions and external standards. |
| Revision history | Version, date, author and a plain description of what changed. |
If you want a starting point rather than a blank page, our downloadable Word template sets out this structure, and the free SOP manual walks through the full lifecycle in one document.
Writing style rules that make procedures usable
- One action per step. If a step contains the word “and” twice, it is really two or three steps.
- Start each step with a verb. “Open the ticket.” “Verify the serial number.” “Sign the release.” The imperative is short, unambiguous and easy to translate.
- Use role names rather than he or she. “The shift supervisor approves the exception” survives staff turnover and avoids awkward pronouns. Whether you address the reader directly as “you” is a house style decision: pick one convention and apply it everywhere.
- Put the condition before the action. “If the reading is above 40 psi, stop the line” beats “Stop the line if the reading is above 40 psi,” because the reader knows whether the step applies before they start acting.
- Say must, not should. “Should” and “may” read as optional. Reserve them for the things that genuinely are.
- Name systems and fields exactly as they appear on screen. “Select Submit for approval” is followable. “Send it for sign-off” is not.
- Define the jargon once, at the top. Then use the term consistently instead of cycling through synonyms.
- Write numbers as numerals and spell out units. 3 business days, 40 psi, 72 hours. Do not make the reader convert anything.
- Break up long stretches of text. Screenshots, diagrams and simple tables carry sequence and layout better than prose, as long as each one is captioned and has alt text.
- Keep steps visible. Number them, keep the numbering stable between revisions where you can, and avoid splitting a step across a page break.
What this looks like in practice
| Before | After |
|---|---|
| The requester should ensure that the appropriate approvals have been obtained and the relevant details are recorded in the system prior to the equipment being released, and any exceptions should be escalated as necessary. | Step 1. Confirm the manager’s approval is recorded on the request.
Step 2. Enter the asset tag and serial number in the Asset Register. Step 3. Release the equipment to the employee. Step 4. If approval is missing, do not release the equipment. Email the IT service desk within one business day. |
Test the draft before you publish it
Give the draft to someone who has never done the task and watch them work through it without helping. Every question they ask marks a gap in the writing, not a gap in the reader. Note where they hesitate, where they guess and where they go back a step, and fix those before the document goes anywhere near an approval workflow. The test and adjust stage of this series covers how to run that dry run properly and what to do with the feedback.
Write it with your contributors, not around them
SOPs rarely have a single author. The person who does the task, the manager accountable for it, and the compliance or safety reviewer all need a say, and collecting their comments over email produces five versions and no clear record of decisions.
Microsoft SharePoint and Microsoft 365 handle this well. A team site gives contributors one place to draft. Document libraries keep version history, so you can see what changed and roll back if you need to. Co-authoring in Word for the web lets several people work on the same file at once. Comments, task lists and a Teams channel keep the reasoning behind each decision attached to the document rather than buried in inboxes. Set the library to require check-out or approval if you want a hard gate between draft and published.
Keep the format consistent across every SOP
A house template does more than save time. When every procedure puts scope in the same place, numbers its steps the same way and shows its version and review date in the same corner, readers stop learning each document from scratch and reviewers can spot an out-of-date file in seconds. Agree the template, the numbering scheme and a short style guide once, store them where authors will find them, and treat departures as exceptions that need a reason.
From final draft to the people who need to read it
A signed-off SOP sitting in a document library is not a read SOP. Once the final version is agreed, it has to reach the right people, and you have to be able to show who has read it. That is what DocRead does inside SharePoint and Microsoft 365: assign the procedure to the groups it applies to, set a deadline, send automatic reminders as that deadline approaches, and report on who has acknowledged it and who has not. Because it runs on SharePoint Online or SharePoint Server, the SOP stays where your teams already work instead of moving to a separate portal.
If you are weighing up how to run this across policies as well as procedures, our overview of policy and procedure management for SharePoint covers the wider picture, and this guide to what happens when acknowledgment deadlines are missed explains why the evidence trail matters.
Frequently asked questions
What is the best SOP format?
The one that matches the task. Use a checklist for short, repeated work, step-by-step for linear tasks, hierarchical steps for long or multi-team processes, and a flowchart where decisions change the route. The format that fails most often is the one chosen out of habit.
How long should an SOP be?
As long as the task requires and no longer. If a single procedure runs past a few pages or roughly 15 top-level steps, it is usually covering more than one task and should be split, with the parts linked to each other.
What is the difference between an SOP and a work instruction?
An SOP describes how a process is carried out and who is accountable for each part of it. A work instruction sits below it and covers exactly how to perform one task, often for one role at one workstation. Many organizations reference work instructions from the procedure section of the SOP rather than folding all the detail in.
Should SOPs include screenshots?
Include them where the interface is hard to describe in words, and crop them to the part of the screen that matters. Screenshots date quickly, so note in the revision history which images were updated, and add alt text so the step still makes sense to anyone using a screen reader.
Who should approve the format?
The document owner approves the content. The format is normally set once, centrally, by whoever maintains the template and the SOP library. Deciding it per document is how libraries end up with 40 different layouts.
Next in the series
The next stage covers testing and adjusting the draft, followed by distribution and training and the review and update process that keeps the procedure current. You can also read the complete SOP guide from the beginning.