SOP template: format, example, review cycle — and the SOP every member reads in their own language (2026)

A standard operating procedure, or SOP, is the written way a recurring job is done in your organization: the steps in order, who takes each one, what each step produces, and what to do when the normal path is blocked. An SOP template is the fixed skeleton those words go into, so that the fortieth procedure looks like the first and a person who has read one can read them all. The template is the easy part; most of this guide is about what goes in it and what keeps it true after the day it is written.

This guide is the craft first — what an SOP is and isn't, the standard format, how to write one that people actually follow, a template you can copy, two filled-in examples — then the mechanics: how the review cycle works, where the SOP and its review live in the tools your team already uses, and what the person who reads it in another language gets. Because the SOP's real test is not the day it is approved. It is the Tuesday a new colleague opens it alone, at the counter, with a customer waiting.

What an SOP is — and what it isn't

Five kinds of document describe how work gets done, and the SOP is the one in the middle:

The distinctions matter because they decide the length. An SOP that explains the policy behind each step is a manual nobody opens at the counter; an SOP that goes down to which button to click is rewritten every time the software changes. The SOP says what is done, by whom, in what order, with what result; the policy above it says why, and the work instruction below it says exactly how on this screen.

An SOP is also not a description of how the job is usually done. It is the agreed way — which is why it has an owner, a version and a review date, and why a step that nobody follows is a step to delete or a conversation to have, not a sentence to leave in.

What to include: the standard format

A usable SOP carries a header and eight sections. Most templates online carry the header and the steps and stop, which is why most SOPs are out of date within a year and nobody knows it:

The header — the identity of the document, five fields on one line: an ID people can cite ("SOP-CS-04"), a version ("v2.1"), the owner — one named person, not a department — the effective date and the next review date. A document without a review date is reviewed when something goes wrong.

1. Purpose. One or two sentences: what this procedure achieves and what goes wrong without it. "Every complaint is logged, acknowledged and resolved the same way, so a customer gets the same answer whoever picks up the phone."
2. Scope. When this SOP applies and when it does not. "Complaints from customers about a product or a delivery. Not: warranty claims (SOP-CS-07), not: supplier complaints."
3. Roles and responsibilities. Each role that appears in the steps, with what it is accountable for. Roles, not names: names change; the SOP shouldn't have to.
4. Definitions and prerequisites. Terms a new person might not know, and what must be in place before step 1 — access to the register, the template, the escalation list.
5. The procedure. Numbered steps, one action per step, in the order they happen, each starting with the role and a verb: "Reception logs…", "The team lead reviews…". Where it helps, three columns — who, does what, result or record — so each step ends in something a second person could check.
6. Exceptions and escalation. The branches: what to do when the customer is not in the system, when the amount exceeds the limit, when the owner is away. Each exception names a person or a role, not "ask someone".
7. Records and outputs. What exists at the end that didn't at the start — the register entry, the sent email, the signed form — and where it is kept. This is the section an auditor reads, and the one that tells you whether the procedure was followed.
8. References and revision history. The policy it implements, the related SOPs and work instructions; then one line per version — date, what changed, who approved it. The history is the part that stops the same mistake being reintroduced under a new version number.

Four formats for the procedure section. Simple steps — a numbered list — for a job of under ten steps with no branches. Hierarchical — numbered steps with lettered sub-steps — when a step has its own sequence inside it. Flowchart when the branches matter more than the sequence: a decision diamond is easier to follow than "if… otherwise… unless". Checklist for a routine done daily by the same people, where the question is not "how" but "did we". Many SOPs use two: a hierarchical procedure, and a one-page checklist derived from it for the shift.

What stays out: justification (the policy's job), screenshots of every click (the work instruction's job), and anything a person could not act on. "Treat the customer with respect" is a value, not a step.

How to write one: observe, draft, test, publish

Observe the person who does the job, and write down what they actually do. Not what the manager thinks happens — what happens, including the workaround with the spreadsheet. The person who does the job every day is the co-author; the SOP that is written about them instead of with them is the one that lives in a folder while the real procedure lives in their head. Ask at each step: what do you do if this fails?

Draft in the template, steps first. Write the procedure section before the purpose: the steps show you where the scope ends and which roles exist. One action per step, role plus verb, present tense. If a step needs a paragraph, it is two steps or a work instruction. Keep the whole thing short enough to read in five minutes; the detail lives in the linked instructions.

Test it on someone who has never done the job. Give them the SOP and nothing else, and watch where they stop. Every stop is a missing step, a missing definition or a missing exception. One test with a new person is worth three reviews by experienced ones, who fill the gaps without noticing them.

Publish where the team reads, and set the date. An SOP in a folder with forty others is found by the people who already know the job. It belongs where the team that runs the procedure already talks, with the owner's name and the review date visible, so that the question "is this still current?" is answered by the header, not by asking around. Then put the review date in the calendar — the SOP that is written and never reviewed is the one that is confidently followed after it stopped being true.

The step-by-step version of this section — from choosing the job to the first review date, with a worked example — is in how to write an SOP.

An SOP template

[SOP ID] — [Procedure name]
Version: [n.n] · Owner: [role, name] · Effective: [date] · Next review: [date]

1. Purpose
[One or two sentences — what this procedure achieves, and what goes wrong without it.]

2. Scope
Applies to: [situations, products, sites] · Does not apply to: [what is covered elsewhere, with the SOP ID]

3. Roles
[Role] — [what it is accountable for in this procedure]
[Role] — [what it is accountable for]

4. Definitions and prerequisites
[Term] — [meaning]
Before step 1: [access, tools, templates, lists needed]

5. Procedure
5.1 [Role] [does what] → [result or record]
5.2 [Role] [does what] → [result or record]
5.3 [Role] [does what] → [result or record]
[a. sub-step] [b. sub-step]

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

7. Records
[What exists at the end — register entry, email, form — and where it is kept, for how long.]

8. References and revision history
Implements: [policy] · Related: [SOP IDs, work instructions]
v[n.n] — [date] — [what changed] — approved by [name]
v[n.n] — [date] — [what changed] — approved by [name]

The template pastes into a Word file, a Google Doc, a Notion page, a Slack canvas or a chat note without reformatting. The two fields most often left blank are the owner and the next review date; they are the two that decide whether the document is still true in a year.

Two filled-in examples

Handling a customer complaint — service team, hierarchical

SOP-CS-04 — Customer complaint handling
Version: 2.1 · Owner: Service lead, Marta R. · Effective: 1 Oct 2026 · Next review: 1 Apr 2027

1. Purpose — Every complaint is logged, acknowledged and resolved the same way, so a customer gets the same answer whoever takes the call, in the customer's language.
2. Scope — Complaints from customers about a product, a delivery or an invoice, by phone, email or chat. Not: warranty claims (SOP-CS-07); not: supplier complaints (SOP-PR-02).
3. Roles — Reception: logs and acknowledges. Service agent: investigates and answers. Service lead: approves anything above the credit limit, decides escalations.
4. Prerequisites — Access to the complaints register; the acknowledgement template in the customer's language; the current credit limit (see the register header).

5. Procedure
5.1 Reception logs the complaint in the register → entry with date, channel, customer, product, the customer's language, and a complaint ID
5.2 Reception sends the acknowledgement within one working day → acknowledgement email with the complaint ID, in the customer's language
5.3 The service agent investigates:
a. checks the order, delivery and invoice records;
b. calls or writes to the customer if a fact is missing;
c. records the finding and the proposed remedy in the register → finding and remedy, dated
5.4 If the remedy is a credit under the limit, the agent issues it; above the limit, the service lead approves within one working day → credit note or written approval
5.5 The agent answers the customer within five working days of 5.1 → answer in the customer's language, referencing the complaint ID
5.6 Reception closes the entry → status Closed, date, remedy

6. Exceptions — Customer not in the system: log with the contact details given, flag unverified, continue. Customer threatens legal action: stop at 5.3, hand to the service lead the same day. Owner away: the deputy named in the register header approves.
7. Records — The register entry (kept 5 years), the acknowledgement and the answer (in the customer's file), the credit note (finance).
8. References — Customer policy §4; SOP-CS-07; work instruction WI-CS-04a "The complaints register".
v2.1 — 1 Oct 2026 — step 5.2 deadline changed from two days to one; acknowledgement now in the customer's language — approved by Marta R.
v2.0 — 15 Mar 2026 — credit limit and approval step added — approved by Marta R.

Opening the clinic — reception, daily checklist

SOP-FD-01 — Opening the clinic
Version: 1.3 · Owner: Practice manager, Tomás A. · Effective: 1 Sep 2026 · Next review: 1 Mar 2027

1. Purpose — The clinic is ready for the first patient at 08:00, every day, whoever opens.
2. Scope — Weekday opening by the receptionist on the early shift. Not: weekend opening (SOP-FD-02).
3. Roles — Opening receptionist: everything below. Practice manager: called on any failed item.

5. Procedure — by 07:45, in this order
☐ Alarm off, doors unlocked, lights and heating on
☐ Reception computer on, appointment system open, today's list printed
☐ Phone line switched from the night message to live
☐ Waiting room checked: chairs, water, the day's notices in both languages
☐ Treatment rooms 1–3: consumables above the minimum line on the cabinet
☐ Card terminal on and test transaction cleared
☐ The day's first three patients called if any has a note confirm

6. Exceptions — Any item cannot be completed: call the practice manager before 07:50; do not open the doors to patients until the manager has answered. Appointment system down: use the printed list from the evening before (SOP-FD-05).
7. Records — The ticked checklist, initialled and dated, in the opening folder; kept three months.
v1.3 — 1 Sep 2026 — notices in both languages added to the waiting-room item — approved by Tomás A.

Notice what the two have in common: every step starts with a role and a verb and ends in something a second person could check; the exceptions name a person; the header says who owns it and when it is next looked at; and the last lines record what changed and why. That is the whole craft. Everything else in this guide is about keeping the document true after the day it was signed.

The review cycle: how a procedure stays true

An SOP is a claim about how work is done, and the work moves. The review cycle is what keeps the claim honest. It has four parts.

A date, and triggers that beat the date. Every SOP has a next review date in its header — six or twelve months is usual, shorter for anything regulated or safety-related. Four events bring the review forward: an incident the procedure did not prevent; a change in the tool, form or supplier the steps depend on; a change in the rule or regulation the SOP implements; and three deviations in a row — three people doing a step differently from the document is a vote, not a discipline problem.

A short review meeting with the people who do the job. Twenty minutes, the owner and two or three people who run the procedure, the current version on everyone's screen. The agenda is always the same:

SOP-[ID] review — [date]
1. Deviations since the last review: where did we do it differently, and why — 5 min
2. Incidents and complaints the procedure touched — 5 min
3. Steps to change, add or delete — one line each, with the reason — 7 min
4. Decision: reissue as v[n.n] on [date], or confirm unchanged with a new review date — 3 min
Actions: who edits, who approves, who tells whom, by when

A new version, with the old one kept. The edit goes into the revision history as one line — date, what changed, who approved — and the version number moves: a changed step is a minor version (2.0 → 2.1), a changed scope or a new role is a major one. The previous version is marked superseded and kept, not deleted: an auditor, or a colleague explaining what happened in March, needs the procedure as it was then. A decision taken in the review that changes a rule, not just a step, belongs in the decision log as well, with the SOP ID in the entry.

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 three lines that changed quoted — and the new review date goes in the calendar the same day.

Where the SOP and its review live in the tools you already use

The procedure itself is a document, and it lives wherever the team's documents live — a Word file in a shared library, a Google Doc, a page in a wiki, a canvas. The review is a meeting, and each platform has a place for what the review meeting leaves behind, and 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 the colleague who reads another language reads that one or a copy someone made; and what the review changed gets into the document only if a person types it in afterwards, in that same language.

How the procedure — and every review of it — comes back in each member's language

InterMIND is a communication space where a team's work lives in a channel, so the 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, editable later from its own menu — it is read by each member in their own language, with the original and a diff of what changed a toggle away, and pinned so the current version is the first thing a new colleague finds. Uploaded as a file instead — a PDF or a Word document — it opens for each reader translated into their language on paid plans, and on every plan its card carries an AI summary in the reader's language, each point linked to the paragraph it came from, so the five-minute read exists before anyone has written it. 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. 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 v2.1 is one click from the note that is v2.1, and a member's own assistant — Claude, ChatGPT, Copilot or Gemini, connected through the MCP connector — can search recaps, transcripts, chats and the text of shared files in one question, "what did we change in the complaints procedure in October?", and read the document itself; this runs for organizations with AI features on.

The people who run a procedure are not always employees. A distributor's 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 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.

SOPs as a craft survive every tool: somebody still has to watch the job being done, write the steps as actions, and ask the new person where they got stuck. 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

What is an SOP template?

An SOP template is the fixed skeleton a standard operating procedure is written into: a header with the ID, version, owner, effective date and next review date, followed by the standard sections — purpose, scope, roles, definitions and prerequisites, the numbered procedure, exceptions and escalation, records, and references with a revision history. The template makes every procedure in the organization look the same, so a person who has read one can find their way in all of them.

What are the 5 parts of an SOP?

The five parts most templates agree on are the title block or header, the purpose, the scope, the roles and responsibilities, and the procedure itself. A complete SOP adds three more — exceptions and escalation, records, and references with a revision history — and it is usually the missing ones that make a procedure fail: no one knows what to do when the normal path is blocked, and no one knows what changed since the last version.

How do you write an SOP?

Observe the person who does the job and write down what actually happens, including the branches. Draft the procedure section first — one action per step, role plus verb, present tense — then fill in scope, roles and exceptions from what the steps revealed. Test it on someone who has never done the job and fix every place they stop. Publish it where the team already reads, with the owner and the next review date in the header, and put that date in the calendar.

What is the format of an SOP?

A header line — ID, version, owner, effective date, next review date — and eight numbered sections: purpose, scope, roles, definitions and prerequisites, procedure, exceptions and escalation, records, references and revision history. The procedure section takes one of four shapes: simple numbered steps, hierarchical steps with sub-steps, a flowchart when the branches matter more than the order, or a checklist for a daily routine.

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

An SOP describes one job end to end at the level of roles and steps — who does what, in what order, with what result. A work instruction describes one of those steps on one screen, machine or form, down to the field and the button. The SOP says "Reception logs the complaint in the register"; the work instruction shows the register, the fields, and the drop-down values. Keeping them separate is what lets the SOP survive a software change.

What is the difference between an SOP and a policy?

A policy is the rule and the reason: what the organization does and does not do. An SOP is how a role carries the rule out, step by step. "Every complaint is answered within two working days" is a policy; the eight steps from logging to closure are the SOP that implements it. A policy changes rarely and by decision; an SOP changes whenever the work does, and its revision history says when.

Is there an SOP template in Word or Google Docs?

The template in this guide is plain text with bold labels, so it pastes into a Word document, a Google Doc, a Notion page, a Slack canvas or a chat note without reformatting. The format matters more than the file: whatever holds the SOP needs the header with the owner and the review date, numbered steps that begin with a role and a verb, a named person for each exception, and a revision history — and it needs to live where the people who do the job already read.

How often should SOPs be reviewed?

On a date written in the header — every six or twelve months is usual, and 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 deviations in a row. The review is a twenty-minute meeting with the people who do the job, and it ends in a new version with one line in the history or a confirmation with a new review date.

Sources: Microsoft — Take meeting notes in Microsoft Teams; 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; Slack — Meeting agenda template (canvas). Microsoft, Google and Slack pages checked October 2026; the Zoom meeting-summary page checked August 2026. Vendors change plans, features and language lists over time; check their pages for the current state.