SOP Format and Writing Style: How to Structure and Write an SOP

This is part four of our seven-part series on the SOP lifecycle. By this stage you have defined the SOP’s scope and purpose and worked through choosing your audience and authors. Now it is time to decide what the procedure will look like on the page and how it will be written.

Format and writing style are not cosmetic. A procedure that is hard to scan is a procedure people stop opening, and a procedure people stop opening is one they stop following. The goal of this stage is simple: someone who has never done the task should be able to complete it correctly by following the written instructions alone.

If you are new to the topic, start with our complete guide to standard operating procedures, and see where procedures sit alongside policies and processes.

Start with the simplest thing that works

Before you draft anything, ask whether a document is the best answer. Sometimes a change to the environment does the job better than written instructions:

• Arrows on the floor and clear signage for a one-way flow
• Numbered stations for a fixed sequence of tasks
• Required fields and validation rules built into a form, instead of a separate document explaining how to fill it in

Write an SOP when you need the detail, the evidence that the task was done correctly, or both.

Common SOP formats and when to use each

There is no single correct SOP format. The right one depends on how long the task is, how many decisions it involves and how familiar the reader is with it.

Format	Use it when	Watch out for
Checklist	Short, familiar tasks that are repeated often, such as opening a store, closing a shift or issuing equipment	Assumes the reader already knows how to do each item. Poor for training someone new.
Simple step-by-step	Linear tasks with few or no decisions, which covers most administrative and IT procedures	Readers lose their place in long lists. If you pass 10 to 15 steps, split the procedure or move to a hierarchical format.
Hierarchical steps	Longer procedures where experienced staff need the main steps and newer staff need the detail underneath	Numbering becomes hard to follow beyond three levels (for example, 2.3.1).
Graphic or visual	Physical tasks where a photo, diagram or annotated screenshot explains a step faster than words	Images must be kept current when equipment or screens change, and they need alt text for accessibility.
Flowchart	Procedures where the outcome depends on decisions, such as approvals, escalations and triage	A diagram alone rarely carries enough detail. Pair it with written steps and make sure it can be read by people using screen readers.

You can mix formats in one document. A common pattern is a flowchart for the overall decision path, with numbered steps for each branch.

Questions to settle before you write

• Does this procedure already exist? Search your library first. Two versions of the same SOP is worse than none.
• Do we have a house format? If so, use it. If not, agree one before you write the first SOP, not after the tenth.
• How many routes are there through the task? One route suits a checklist or simple steps. Several routes point to a flowchart.
• How many audiences are involved? If different roles do different parts, consider splitting the SOP or labeling each section by role.
• Where will it be read? At a desk, on a phone on the shop floor, or printed and posted at a workstation. This affects layout, font size and image use.
• What will you need to prove later? If an auditor or regulator may ask for evidence, build the records you need into the procedure.

SOP structure: what goes in the document

Most well-run SOP libraries use the same sections in the same order, so readers always know 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 anything deliberately excluded
Roles and responsibilities	Named roles, not named people, and what each is accountable for
Definitions	Acronyms, system names and any terms the reader may not know
Prerequisites	Access rights, equipment, materials, training or approvals needed before starting
Safety and compliance notes	Warnings and cautions, placed directly before the steps they relate to
Procedure	The numbered steps, in the format you have chosen
Records	What the task produces, where it is filed and how long it is kept, in line with your records retention policy
References	Related policies, forms, work instructions and external standards
Revision history	Version, date, author and a plain description of what changed

To save time, start from our free Word template for policies and procedures, and download the free SOP manual for the full lifecycle in one place.

SOP writing style rules that make procedures usable

• One action per step. If a step contains “and then”, it is probably two steps.
• Start each step with a verb. “Enter the asset tag”, not “The asset tag should be entered”.
• Use role names, not pronouns. “The line manager approves the request”, not “they approve it”.
• Put conditions before actions. “If the request is urgent, call the service desk”, so the reader knows before acting.
• Use “must” for requirements. “Should” reads as optional. Save it for genuine recommendations.
• Name systems and fields exactly as they appear on screen. Match the labels, including capitalization.
• Define jargon once, then use it consistently. Do not switch between “ticket”, “case” and “request” for the same thing.
• Write numbers as numerals and include units. “Wait 5 minutes”, not “wait five”.
• Break up long text. Use tables, screenshots and diagrams where they explain something faster than a paragraph.
• Keep numbering stable. Readers and reviewers refer to steps by number, so avoid renumbering without recording it in the revision history.

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.”	1. Confirm the manager’s approval is recorded on the request. 2. Enter the asset tag and serial number in the Asset Register. 3. Release the equipment to the employee. 4. If approval is missing, do not release the equipment. Email the IT service desk within 1 business day.

The rewrite is longer on the page, but each step can be followed, checked and audited on its own.

SOP vs work instruction: getting the level of detail right

An SOP describes how a task or process is carried out and who is accountable for each part. A work instruction goes one level deeper, describing exactly how one role completes one task, often at a single workstation or on a single screen. If your SOP is filling up with keystroke-level detail, move that detail into a work instruction and link to it from the relevant step. This keeps the SOP readable and means you only update the work instruction when a screen changes.

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 help. Every question they ask marks a gap in the writing, not a gap in the reader. Fix the gaps, then test again. We cover this stage in detail in testing and adjusting a new SOP.

Write it with your contributors, not around them

Most SOPs have more than one author: the people who do the task, the manager accountable for it, and reviewers from compliance, safety or IT. Drafting in a shared location such as Microsoft SharePoint and Microsoft 365 lets everyone work on the same file, keeps a version history, and allows decisions to be discussed in a Microsoft Teams channel rather than lost in email threads.

Keep the format consistent across every SOP

Once you have a template, a numbering scheme and a short style guide, use them for every SOP. Consistency helps readers find information quickly and makes reviews faster, because reviewers know exactly where to look. Treat any departure from the standard format as an exception that needs a reason. Many of the common reasons SOPs fail in practice come back to inconsistent format and unclear writing.

From final draft to the people who need to read it

A well-formatted SOP only helps if the right people read it, and in many organizations you also need to show that they did. That means putting the approved version in one controlled library, assigning it to the roles that need it, and keeping a record of who has read and acknowledged it.

DocRead for Microsoft 365 and SharePoint Online does this inside your existing SharePoint libraries. You can assign procedures by role, department, location or group, set deadlines, send automated reminders and escalations, and report on who has and has not acknowledged each SOP. For more on this stage, read our guide to distributing SOPs and training staff, or see these ten steps for rolling out SOPs with SharePoint.

Frequently asked questions

What is the best SOP format?

The one that matches the task. Use a checklist for short, familiar tasks, simple steps for linear tasks, hierarchical steps for longer procedures, visuals for physical tasks and a flowchart where the outcome depends on decisions.

What should an SOP include?

At a minimum: a header block with ID, version, owner and dates, a purpose, a scope, roles and responsibilities, the numbered procedure steps, records and a revision history. Add definitions, prerequisites, safety notes and references where they are needed.

How long should an SOP be?

As long as the task requires and no longer. If a procedure runs to many pages or has more than 10 to 15 top-level steps, split it into linked SOPs or move the detail into work instructions.

What is the difference between an SOP and a work instruction?

An SOP describes the process and who is accountable for each part. A work instruction describes exactly how one role performs one task, often at a specific workstation or screen.

Should SOPs include screenshots?

Yes, where a screen is hard to describe in words. Crop screenshots to the area that matters, highlight the field or button, add alt text, and update them when the system changes.

Who should approve the SOP format?

Document owners approve the content of each SOP. The format itself should be agreed once, centrally, by whoever governs your document library, so every SOP follows the same standard.

Next in the series

With the format and writing style settled, the next stages are testing and adjusting the draft, distributing the SOP and training staff, and reviewing and updating SOPs so they stay accurate over time.