How to write an SOP: steps, template, example, review cycle — and where the SOP lives after it is written (2026)

A standard operating procedure, or SOP, is the agreed way one recurring job is done in your organization: the steps in order, who takes each, what each step leaves behind, and what to do when the normal path is blocked. Writing one is not a writing task. It is an observation task with a document at the end — the words are the easy part, and most SOPs that fail were written by someone who skipped the watching.

This guide is the writing process in order — which job to pick, how to watch it, how to draft the steps, how to test the draft, how to approve and publish it — then a one-page template, a worked example, and the review cycle that turns a first version into a procedure the team actually runs. The last part is where the document lives after it is written: in the tools your team already uses, and in the place the people who do the job already read. Because an SOP is judged on the Tuesday a new colleague opens it alone, not on the day it was approved.

Which jobs get an SOP — and which don't

Four signals say a job deserves a procedure. It recurs: weekly or daily, not once a year. More than one person does it, or will — a job done by one person for years is in their head, and the SOP is written the month before they go on leave. The cost of doing it differently is real: a complaint answered two ways, a shipment with the wrong documents, a patient file opened under the wrong name. And it has hand-offs — the moment the work passes from reception to the agent, from sales to logistics, is where the steps go missing.

Three things do not get an SOP. A job that crosses three teams end to end is a process; map it as stages, then write one SOP per stage and role. A single screen or form is a work instruction, which lives under the SOP step that uses it and is rewritten when the software changes, so that the SOP is not. And a judgment — pricing a custom order, deciding whether a complaint is justified — gets a policy with limits and a named decider, not numbered steps that pretend there is no judgment. The five kinds of document, side by side, are in the SOP template guide; what follows assumes you have picked one job, one role at a time.

How to write an SOP: seven steps

1. Pick one job and draw its edges. Name it with a verb and an object — "Onboarding a new distributor", not "Distributors" — and write two sentences before anything else: where it starts (the trigger: a signed agreement, a phone ringing, 07:30 on a weekday) and where it ends (the result that now exists: a first order confirmed, a complaint closed, the doors open). Everything between those two sentences is the SOP; everything outside them is another document. If the job has no clear end, it is two jobs. Leave the purpose sentence for later: you will know what the procedure is for once you have seen it done.

2. Watch the job being done — twice. By the person who does it, not the person who manages it, and at the real counter or screen, not in a meeting room. Write down what happens, including the spreadsheet on the side and the colleague who gets called at step 4; ask at every step, "and what do you do when this fails?" — the answers are the exceptions section, and nobody volunteers them unasked. Watch a second time with a different person or on a different day. Where the two runs differ is the reason the SOP exists; decide for each difference whether it is a step to fix in the document or a conversation to have with the team.

3. Draft the steps first, header last. Open the template at the procedure section and write the steps as you saw them: one action per step, in the order it happens, each starting with a role and a verb in the present tense — "Reception logs…", "The account owner sends…" — and each ending in a result a second person could check: the register entry, the sent email, the confirmed order. Three columns help: who, does what, result or record. A step that needs a paragraph is two steps or a work instruction. Aim for a document that reads in five minutes; the detail lives in the linked instructions. Choose the shape for the steps now — a numbered list for under ten steps with no branches, numbered steps with lettered sub-steps when a step has a sequence inside it, a flowchart when the branches matter more than the order, a checklist when the question is "did we" rather than "how".

4. Add the branches: exceptions, escalation, records. For every step, the condition under which it cannot be done as written, and what happens then — with a role or a person who decides, never "ask someone". Close the list with one line that covers what you missed: "Anything not covered here: the team lead decides, and the case is raised at the next review." Then the records: what exists at the end of the procedure that did not exist at the start, where it is kept, for how long. This is the section an auditor reads, and the one that tells you afterwards whether the procedure was followed.

5. Fill in the header and the sections around the steps. Now the purpose is one sentence you can write: what this procedure achieves and what goes wrong without it. Scope says when it applies and when it does not, naming the neighbouring SOPs by ID. Roles are the roles that appeared in the steps — roles, not names, so the document survives a hire. Prerequisites are what must be in place before step 1. The header is five fields: an ID people can cite, version 1.0, an owner who is one person, the effective date and the next review date. A procedure without a review date is reviewed when something goes wrong. The full eight-section format, with the longer template and the reasoning behind each section, is in SOP template.

6. Test it on someone who has never done the job. Give them the document and nothing else, and sit behind them. Every place they stop is a missing step, a missing definition or a missing exception; every place they ask you a question is a sentence to add. One test with a new person is worth three reviews by experienced ones, who fill the gaps without noticing them. If the first test produced more than three changes, test once more with someone else. The owner approves after the test, not before — a draft that has not been run is an opinion.

7. Approve, version, publish where the team reads — and date the review. The owner signs off, the version becomes 1.0, and the draft is kept, not deleted. Publish the SOP in the place the people who run the procedure already talk, not in a folder with forty others that only the people who already know the job can find; announce it with the three lines that matter most to the people reading it. The same day, put the next review date in the calendar, and write down the four events that bring the review forward: an incident the procedure did not prevent, a change in the tool or form the steps depend on, a change in the rule it implements, and three people doing a step differently from the document, which is a vote, not a discipline problem.

A one-page SOP template

[SOP ID] — [Procedure name]
v[1.0] · Owner: [name, role] · Effective: [date] · Next review: [date]

Purpose: [one sentence — what this procedure achieves, and what goes wrong without it]
Applies to: [trigger, situations, sites] · Not: [what another SOP covers, with its ID]
Roles: [Role] — [what it is accountable for] · [Role] — [what it is accountable for]
Before step 1: [access, tools, templates, lists]

Steps
1. [Role] [does what] → [result or record]
2. [Role] [does what] → [result or record]
3. [Role] [does what] → [result or record]
4. [Role] [does what] → [result or record]

If [condition]: [what to do, who decides]
If [condition]: [what to do, who decides]
Anything not covered here: [role] decides; the case is raised at the next review.

Records: [what exists at the end, where it is kept, for how long]
References: [policy it implements, related SOPs, work instructions]
History: v1.0 — [date] — first issue — approved by [name]

The template is plain text with bold labels, so it pastes into a Word file, a Google Doc, a wiki page, a Slack canvas or a chat note without reformatting. It is deliberately one page: the two sections most often skipped when a template is long are the exceptions and the review date, and those are the two that decide whether the document is still true in a year.

A worked example: onboarding a new distributor

An exporter with distributors in three countries; the job passes through four roles and ends when the distributor's first order is confirmed.

SOP-SA-03 — Onboarding a new distributor
v1.2 · Owner: Export manager, Chiara B. · Effective: 15 Oct 2026 · Next review: 15 Apr 2027

Purpose: A new distributor can place its first order within ten working days of the signed agreement, with prices, documents and a named contact on both sides.
Applies to: Every distributor agreement signed by the export manager. Not: agents on commission (SOP-SA-05); an existing distributor adding a territory (SOP-SA-04).
Roles: Export manager — signs, assigns the account owner, decides credit terms. Account owner — runs steps 3 to 7. Finance — credit check and customer record. Logistics — shipping profile.
Before step 1: the signed agreement in the contracts folder; the price list for the territory; the onboarding pack in the distributor's language.

Steps
1. The export manager assigns an account owner within one working day of signature → assignment noted in the distributor's record
2. Finance runs the credit check and opens the customer record → credit limit and payment terms in the record
3. The account owner sends the onboarding pack — price list, order form, product sheets, the two contacts on our side — in the distributor's language → pack sent; date and recipients logged
4. The account owner holds the kickoff call with the distributor's sales and order staff: how to order, lead times, who answers which question → call recap in the record; open questions with owners
5. Logistics sets up the shipping profile — incoterms, carrier, the documents the destination requires → profile active
6. The account owner places a test order with the distributor on the line → first order confirmed, or the blocking step named
7. The account owner books the 30-day review with the distributor → calendar entry, both sides invited

If the credit check fails: step 2 stops; the export manager decides prepayment or decline within two working days. If the pack does not exist in the distributor's language: send the English pack, raise the gap at the next review, do not postpone the kickoff call. If the test order fails: the blocking step is written into the record and fixed before the 30-day review.
Records: the distributor's record (kept for the life of the agreement plus five years), the kickoff call recap, the test order.
References: Export policy §2; SOP-SA-04; SOP-SA-05; WI-SA-03a "The distributor record".
History: v1.2 — 15 Oct 2026 — kickoff call added as step 4; test order moved before the 30-day review — approved by Chiara B. · v1.1 — 2 Jun 2026 — shipping profile made its own step — approved by Chiara B. · v1.0 — 10 Jan 2026 — first issue.

Notice what the example does. Every step starts with a role and a verb and ends in something a second person could check. Each exception names who decides. The history explains why the steps are in this order — step 4 exists because a reviewer found that distributors who never had the call placed their first order late. And one step is not a document at all: step 4 is a call, with the distributor's staff on the other side of it, and what that call leaves behind is the part of the procedure no template can hold.

The review cycle: the first version is a draft that worked once

An SOP is a claim about how work is done, and the work moves. Three things keep the claim honest after publication, and they belong to the writing process, not to some later maintenance phase.

A date, and the triggers that beat it. Six or twelve months is usual, shorter for anything regulated or safety-related; the four events from step 7 bring the review forward. The review is a twenty-minute meeting: the owner and two or three people who run the procedure, the current version on everyone's screen, the same four items every time — deviations since the last review, incidents the procedure touched, steps to change, add or delete with the reason, and the decision to reissue as a new version or confirm unchanged with a new date. The review agenda, written out, is in the SOP template guide.

A new version, with the old one kept. The edit becomes one line in the history — date, what changed, who approved — and the version number moves: a changed step is a minor version, a changed scope or a new role a major one. The previous version is marked superseded and kept; a colleague explaining what happened in March needs the procedure as it was in March. A review decision that changes a rule rather than a step is also an entry in the decision log, with the SOP ID in it.

The people who do the job hear about it. A reissued SOP that nobody announced is the old SOP with a new number. The change goes to the people who run the procedure, in the place they already read, with the lines that changed quoted — and the new review date goes in the calendar the same day. Where that place is, and what the review meeting leaves behind in it, depends on the tools the team runs on.

Where the SOP lives after it is written: the tools you already use

The document itself lives wherever the team's documents live — a Word file in a shared library, a Google Doc, a page in a wiki, a canvas in a channel. The review is a meeting, and each platform has a place for what the review meeting leaves behind; each stops at a different point. Documented behaviour only, from the vendors' own pages, with the month each page was checked:

Two things are the same everywhere. The SOP is a document in the one language it was written in, and what the review changed reaches it only when a person types it in afterwards. The translation these suites document belongs to the call, not to the document: Microsoft documents live translated captions in Teams meetings when the organizer holds a Teams Premium or Microsoft 365 Copilot license, and Google documents translated captions in Meet on eligible Workspace plans (both checked August 2026) — what each covers and where each stops is in Microsoft Teams live translation and Google Meet live translation. The procedure a colleague opens on Tuesday, and the review that changed it, are separate objects from those captions, and they are read in the language they were typed in.

How the SOP, its review and its history stay readable for every member

InterMIND is a communication space where a team's work lives in a channel, so the finished SOP has an obvious home: the channel of the team that runs the procedure. Posted as a note — a rich-text message with headings and numbered lists, edited later from its own menu — it is read by each member in their own language with the original a toggle away, and pinned so the current version is the first thing a new colleague finds; a reader who switches on edit history sees the earlier wording of a changed step as a word-level diff with its timestamp. Uploaded as a file — a PDF or a Word document — it carries, on every plan, an AI summary in the reader's language with each point linked to the paragraph it came from, so the five-minute read exists before anyone has written it; on paid plans the file itself opens translated into the reader's language (30 languages for documents). If the master copy stays in a document tool, its updates land in the channel by email: the channel's host gives it an address of its own, and a message sent there appears as a regular message with the sender named and attachments kept.

The review meeting starts from that channel, and so does the kickoff call in the example above. During the call, the current version goes on everyone's screen next to the video tiles with Share to conference — a note, or a Google Docs or OneDrive document linked in the chat — and each participant scrolls it independently and reads it in their own language; a shared note is edited live by the sharer while the room watches the changed step take shape. When the call ends, the recap is written from the meeting itself — a summary, the points marked agreed, open or disputed, the action items with owners, each line keeping its timestamp — and the documents shared during the session contribute their summaries alongside what was said. It arrives by email, as a message in the channel and as a link in the calendar event, and every signed-in member reads it in their own language: the record is translated per reader, not written once in the language the room happened to use. Any member can edit it, every edit keeps author and revision history, and the channel keeps the recap of every past session — so the review that produced v1.2 is one click from the note that is v1.2. A member's own assistant — Claude, ChatGPT, Copilot or Gemini, connected through the MCP connector — searches recaps, transcripts, chats and the text of shared files in one question, "what did we change in the distributor onboarding procedure, and why?", and reads the document itself; this runs for organizations with AI features on. Set next to the table above, the difference is a plain statement of fact: the captions those suites document translate the call while it runs; here the procedure, its review and its history are one record, read by each member in their own language.

The people who run a procedure are not always employees. A distributor's order staff, a contractor, a locum: an external member of the channel joins by email onto a free account and reads the SOP and its history like everyone else; a person without an account is a guest of one meeting — they join the kickoff or the review call by link, from a phone, at no cost, hear it live in their own language, and get no record afterwards. The host provides the space and, on a paid plan, pays only for the members active in the previous 28 days — joined a meeting, wrote in a chat or asked the assistant; members who go quiet keep their access at no cost.

• Open a complete recap — a real record rendered by the same code that writes yours.
• Try the live demo — no signup; speak, and hear the room translated per listener.

Writing an SOP as a craft survives every tool: somebody still has to watch the job being done, write the steps as actions a second person can check, and sit behind the new colleague on the first run. What doesn't have to survive is the second job — keeping a translated copy of every version by hand, and retyping what the review changed, in one language, for people who read others.

FAQ

How do you write an SOP?

Pick one recurring job done by one role and write where it starts and where it ends. Watch the person who does it, twice, and note every branch. Draft the steps first — one action per step, a role plus a verb in the present tense, a result a second person could check — then add the exceptions with a named decider and the records that exist at the end. Fill in the purpose, scope, roles and a header with an ID, a version, one owner and a review date. Test it on someone who has never done the job and fix every place they stop. Have the owner approve it, publish it where the team already reads, and put the review date in the calendar.

What should be included in an SOP?

A header with the ID, version, owner, effective date and next review date; the purpose in one or two sentences; the scope, including what the SOP does not cover; the roles involved; prerequisites; the numbered procedure; exceptions and escalation with a person or role who decides; the records the procedure produces and where they are kept; and references with a revision history. Templates that carry only the header and the steps are the ones that fall out of date without anyone noticing.

What is an example of an SOP?

Any recurring, multi-person job with a clear start and end: handling a customer complaint from logging to closure, opening a clinic or a shop in the morning, onboarding a new distributor from signed agreement to first order, releasing a batch, closing the month in finance. The worked example in this guide is distributor onboarding — seven steps across four roles, three exceptions, a history of three versions — and the complaint-handling and clinic-opening examples are in the SOP template guide.

How long should an SOP be?

Short enough to read in five minutes before doing the job: one to two pages for most procedures, under ten steps if the format is a simple numbered list. If it is longer, either the job is two jobs, or the document is carrying detail that belongs in a work instruction under one of the steps — screenshots, field names, button labels — or justification that belongs in the policy above it.

Who should write SOPs?

The person who does the job, with the owner of the procedure. The owner — a named person, usually the team lead or the manager of the area — is accountable for the document being true and for its review; the person who does the job is the co-author, because the SOP written about them instead of with them lives in a folder while the real procedure lives in their head. A newcomer to the job is the tester, not the author.

What is the difference between an SOP and a process?

A process describes how work flows across roles and teams in stages and hand-offs — intake, triage, resolution, closure. An SOP describes how one of those stages is done by one role, step by step, with a result per step. A process map tells you where the SOPs are needed; one SOP tells one person what to do on Tuesday morning. Writing an SOP for a whole cross-team process produces a manual nobody opens at the counter.

How often should an SOP be updated?

On the review date in its header — every six or twelve months is usual, shorter where the procedure is regulated or safety-related — and earlier when one of four things happens: an incident the procedure did not prevent, a change in the tool or form the steps depend on, a change in the rule it implements, or three people doing a step differently from the document. Each update is a new version with one line in the history saying what changed and who approved it; the old version is kept.

Sources: Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Use live captions in Microsoft Teams meetings; Zoom — Using Meeting Summary with AI Companion; Google — Calendar & Meet settings for "Take notes for me"; Google Meet — "Take notes for me" in Google Meet; Google Meet — Use translated captions; Slack — Meeting agenda template (canvas). Microsoft, Google and Slack meeting-notes and template pages checked October 2026; the Zoom meeting-summary page and the Teams and Meet captions pages checked August 2026. Vendors change plans, features and language lists over time; check their pages for the current state.