Writing Standard Operating Procedures: A 16-Step Guide (With Examples)

Choose how SOPs will be presented and where they will live

Decide, for the whole programme, the medium your procedures will exist in. There are three realistic options: a document library (Word or Google Docs in a controlled folder), a wiki (Confluence, Notion, SharePoint pages), or a process platform where each SOP is a runnable checklist template. Each can work. What does not work is all three at once, which is what most companies have by accident.

The choice depends on how the procedures will be used. Reference material read occasionally suits a wiki with good search. Work that happens weekly and involves several people needs to run as a checklist with assignments and a completion record, because a static page tells you what should happen but never whether it did. Many programmes settle on a hybrid: narrative and screenshots in a document, executable steps as a checklist template that links back to it. Our comparison of the best SOP software sets out the trade-offs between document-first and execution-first tools.

Whatever you choose, write it down as a programme rule with one canonical location per SOP. Two copies of a procedure will diverge within a quarter.

Set up collaboration between writers, practitioners and approvers

SOPs written by managers from memory describe how the process is supposed to work. SOPs written with the people who do the work describe how it actually works, including the workaround for the CRM field that does not save and the step everyone does out of order because the official order is wrong. The second kind gets used.

Set the collaboration model up front. For each SOP, name a writer (often the SOP owner), one or two practitioners who perform the task, and an approver who signs it off. Agree how they will work: a 45-minute observation session, a draft within a week, comments back within another. Put those sessions in diaries now for the first batch; a programme that relies on people "finding time" produces its first draft in month four.

Give everyone the same shared template and a single comment channel. Five reviewers emailing tracked changes to a Word file is how "FINAL v3 (2)" happens.

Define the objective of each SOP

The programme has an objective; so does each procedure. Before anyone writes a step, state in one or two sentences what the SOP is for and what "done correctly" means. "This procedure provisions a new starter's accounts and equipment so that they can work productively from 9am on their first day, with access limited to what their role requires" gives the writer a test for every step. Does this step help the person work from 9am? Does it keep access to what the role requires? If not, it does not belong.

Where the SOP is an improvement to an existing process, the objective should name the pain point: "reduce month-end close from nine working days to five" or "stop leavers retaining access to client systems after their last day". Measure the current state before you write. The definition of a process is a useful test: if you cannot name the trigger, the inputs, the outputs and the owner, the objective is not yet clear enough to write against.

Pick a format for each SOP

Formats are chosen per procedure, from a small menu the programme has agreed in advance. The four that cover almost every case are simple sequential steps, hierarchical sections with sub-steps, flowcharts for branching logic, and checklists for routine work by experienced staff. The comparison table further down sets out when each fits.

The programme's job is to stop the menu growing. Without a rule, IT writes in a runbook style, HR writes in prose, and finance produces a spreadsheet with a column of instructions, and every reader learns a new layout for every document. Agree the four formats and a template for each; if someone needs a fifth, they make the case to the programme owner.

A useful default: hierarchical for anything with more than fifteen steps or more than one role, checklist for anything that runs weekly or more often, a flowchart embedded in either where there is a real decision point, and simple sequential steps for the rest.

Define the scope and limits of every procedure

Every SOP needs a boundary: the trigger that starts it, the state that ends it, and what it deliberately excludes. "Starts when HR submits the new-starter form; ends when the hiring manager confirms the starter has logged in and completed security training; does not cover contractors (see SOP-IT-009) or transfers between offices (see SOP-HR-012)." Boundaries stop two procedures overlapping and stop one procedure trying to be the whole employee lifecycle.

The rule of thumb is one process, one performer group, one SOP. If work crosses teams, write a procedure per team and define the hand-off precisely: what is handed over, in what form, and how the receiving team knows it has arrived. Client onboarding, for example, is usually best expressed as a short parent procedure that names the hand-offs and links to three or four child procedures, one per team. Record the scope, trigger, end state and exclusions in the SOP header block so a reader can tell in ten seconds whether this is the procedure they need.

Agree a house style and apply it everywhere

Style is not a matter of taste when forty documents share it. A reader who has followed three of your SOPs should open the fourth and know, without thinking, where the purpose statement is, what a step looks like, how warnings are marked and how a decision is written. Agree the rules once, write them on one page at the front of the template. The rules that earn their place are short and mechanical, the kind that survive being applied by a busy team lead at 5pm on a Friday.

• Every step starts with a verb: "Create", "Verify", "Send", "Record". Never "The account should be created".
• One action per step. "Click Save, then open the Review tab" is two steps.
• Name the system, screen and field: "In Entra ID, open Users, then Add user", not "set up the account".
• Write for the newest qualified person on the team, not the most experienced.
• Put the reason next to any step where skipping it causes damage: "Export as PDF — the portal rejects .docx silently".
• Mark decisions explicitly: "If the starter is a contractor, stop here and use SOP-IT-009."
• State what correct looks like at every checkpoint: "The user appears in the Finance group within 15 minutes."

These are the same rules that make a checklist usable, which is not a coincidence. Our guide to creating checklists that get used covers the same discipline from the execution side.

Use consistent company notation

Notation is the set of labels, identifiers and symbols the programme uses so that documents can refer to each other and to the systems they describe without ambiguity. At minimum, agree a document ID scheme (SOP-IT-004, SOP-FIN-011), a version scheme (v1.0, v1.1 for corrections, v2.0 for a rewrite), the canonical names of your systems (is it "the CRM", "HubSpot" or "Hub"?), and the canonical names of roles (is the person who approves invoices "Finance Manager", "FM" or "Sarah"?). Roles beat names: people leave, roles stay.

If you already use a formal modelling notation such as BPMN for process diagrams, use it in SOP flowcharts too. If you do not, do not adopt one for the sake of it. A handful of flowchart symbols — start and end, process box, decision diamond, arrow — is enough for the vast majority of procedures, and everybody already reads them. Our explainer on process flowcharts covers the symbols and when to reach for them. The test of good notation is that a step written by IT can be read by HR without a glossary.

List the process steps with the people who do the work

This is the step that produces the actual procedure, and it should be done the same way for every SOP in the programme: watch the practitioner do the task, write the skeleton of steps, then flesh each one out with the system, the inputs, the checkpoint and the hand-off. Run at least two observation sessions for anything complex; the difference between two runs shows you what is discretionary and what is always required.

Two programme-level rules. The practitioner, not the manager, is the source. And the skeleton comes before the detail: get the ten to twenty top-level steps agreed and in order before anyone writes a sub-step. Where a step is itself a small procedure (configure MFA, reconcile a bank account), write it as a linked sub-procedure rather than inflating the parent; a 60-step flat list is unreadable, a 12-step parent with four sub-procedures is not. The full drafting method is in the single-SOP guide.

Brainstorm failure scenarios before the first test

Once the steps are drafted and before anyone runs them, sit down with the practitioners for thirty minutes and ask, step by step: what happens if this fails, is skipped, or produces the wrong result? What if the bank feed has not updated when the reconciliation step runs? What if the P1 incident occurs at 2am and the named escalation contact does not answer?

You are looking for three kinds of gap. Missing decision points, where the procedure assumes the happy path and offers no branch. Missing prerequisites, where step 6 needs access or data that nothing earlier provides. And missing escalation, where a failure at step 9 leaves the performer with no instruction except "ask someone". Each becomes either a new branch in the procedure, a prerequisite added to the header, or a named escalation with a time limit.

This is where a procedure with real branching stops being a linear list. If more than two or three branches emerge, the flowchart format or a checklist with conditional logic that shows the right steps for each path will serve the reader far better than nested "if" clauses in prose.

Define how each SOP will be measured

A procedure with no measure cannot be improved, only argued about. For every SOP, define before release two or three numbers you will collect: usually one for adherence (how many runs were completed, with every step done, versus how many should have happened), one for speed (cycle time from trigger to end state), and one for quality (errors, rework, exceptions or incidents traceable to this process).

Then define how the numbers will be collected, which is the part most programmes skip. "We will track onboarding cycle time" means nothing unless something records when the new-starter form arrived and when the manager confirmed the login. If the procedure runs as a checklist, the run itself produces the timestamps. If it lives in a document, someone has to keep a log, and within three months nobody will. Write the measures and the baseline in the header block; they are what Step 13 and the review cadence will use to decide whether the procedure is working.

Run practical tests

Two tests, in this order. First, the cold read: give the draft to someone qualified but unfamiliar with the task and ask them to perform it, without coaching, while the writer watches and says nothing. Every hesitation, question or step performed differently from what was written is a defect in the document, not in the reader. Fix them and repeat with a second person if the first run found more than a handful.

Second, the pilot: run the procedure for real, with the people who will normally perform it, for a defined number of runs. Three onboarding runs, one month-end close, two weeks of the daily backup check. Measure the numbers from Step 10 during the pilot so you have a like-for-like comparison with the baseline.

Where the SOP runs as a checklist, each pilot run shows who did each step and when, which steps were skipped or took longest, and where the performers left comments. Where it is a document, the writer should sit in on at least one run in person; nothing else reliably surfaces the step everyone quietly ignores.

Collect feedback and get sign-off

Feedback comes from two directions. Practitioner feedback is about accuracy and usability: is anything wrong, missing or in the wrong order, and is anything so laborious it will be skipped? Collect it during the pilot and again a week after, because the second week surfaces the problems the first week's novelty hid.

Approver feedback is about fitness: does the procedure meet its objective, satisfy any regulatory or contractual requirement, and fit with the procedures around it? The approver is the SOP owner's manager, the compliance lead, or for high-risk procedures both. Record the sign-off — name, date and version in the revision history — because it is exactly what an ISO 9001 or SOC 2 auditor asks to see when checking that procedures are controlled.

Do not release a procedure that has practitioner objections outstanding. Either fix the step or write down why it stays as it is. An unaddressed "this step is pointless" comment is a promise that the step will not be done.

Make the optimisation path clear

Every SOP will be wrong eventually, because tools, teams and regulations change. The programme needs a defined way for the person who notices to get the document changed, or they will simply start ignoring it. Write the path into the template: how to propose a change (a comment on the checklist run, a message to the owner), who decides (the owner for corrections, the approver for anything that changes the outcome or the controls), how quickly, and how the change is versioned and communicated.

Then make the data from Step 10 part of the path. If cycle time has crept up or a step is skipped in most runs, that is a change request the numbers raised. This is how an SOP programme becomes a continuous improvement loop rather than a documentation project: the procedure is run, the run produces data, the data changes the procedure. Tell the team the path exists and show them the first change that came through it. A procedure people can change is one they will keep using.

Run a risk assessment on the final procedure

Before release, walk the final version step by step and ask what could go wrong for the performer, the company or a third party if the step is done as written, done wrongly, or not done. Check five categories: safety, security (does any step grant access, handle credentials or move data?), data protection (does any step touch personal data?), financial (does any step move money or commit spend?), and compliance (does the procedure implement a control that a standard or contract requires?).

For each risk found, add a control to the procedure: a second-person check before the payment step, a required field that records the ticket number before access is granted, a hard stop where the performer must confirm the leaver's last day before revoking anything. The output is a short risk register attached to the SOP. This step is mandatory in regulated work and worth ten minutes in all the rest; the offboarding procedure nobody risk-assessed is the one that revokes email before the manager has retrieved the client files from the leaver's mailbox.

Draw a flow diagram for the visual readers

A proportion of every team reads a diagram faster than a list. For any procedure with more than one role or more than one decision, add a one-page flowchart or swimlane diagram that shows the whole shape: who does what, in what order, where the hand-offs are, and where the path splits. Keep it to a single page; if it does not fit, the procedure's scope is probably too wide.

The diagram is a companion to the written procedure, not a replacement. It answers "where am I in this and what happens next?"; the text answers "exactly how do I do this step?". Put it at the top of the document or as the first screen of the checklist, with each box carrying the same step number as the text. Drawing it late, after testing, is deliberate: a diagram drawn before the steps are agreed becomes an argument about boxes rather than about the work.

Implement, train and withdraw the old way

Publish the procedure in its single canonical location as version 1.0. Then do the three things publishing on its own does not. Train the performers: a 20-minute walkthrough of the diagram and the checkpoints is enough for most procedures, a supervised first run for high-risk ones. Withdraw the old way: archive the previous document, mark it superseded, delete the stale copy from the shared drive, and retire the spreadsheet or email template the process used to run from. And start the measures from Step 10 on day one, so the first review has data.

Where the SOP will run as a checklist, build the template properly rather than pasting the steps in: assign each step to a role, set due dates relative to the trigger, add required fields at the control points, and set the schedule if the procedure recurs. A template designer that does this without code turns the roll-out from a communications exercise into a change in how the work is done. From this point the document describes the process and the checklist is the process, the distinction our guide to recurring checklists explains in full. Finally, tell the wider team what changed and put the first review date in the owner's diary before you close the batch.