How to Write an SOP: Step by Step Guide

Apply the SOP threshold test: a process needs an SOP when it is performed at least weekly, involves more than one person, and either carries measurable risk (financial, compliance, or customer impact) or depends on knowledge concentrated in one or two people.

A practical filter: if the person who performs this task best were unavailable for two weeks, could someone else execute it at 90% quality using only what is currently written down? If the answer is no, that process is your priority. Start with the process that would cause the most disruption if the primary operator were suddenly unavailable.

Watch the process being performed by the person who does it most often. Do not write from memory, meeting notes, or assumptions. Sit next to the operator (or share their screen) and document every action they take, including the steps they consider obvious.

Pay attention to three things most people skip: the informal workarounds (“I always check this spreadsheet first even though it is not part of the official process”), the decision points that are not documented anywhere (“if the number looks off I ping Maria before continuing”), and the setup steps the operator does automatically (logging into systems, pulling up reference documents, checking prerequisites). These hidden steps are why SOPs written from interviews fail in practice.

Match the format to the process complexity. Use a step by step SOP for linear processes with no branching decisions (processing a refund, setting up a vendor account). Use a hierarchical SOP for complex procedures with subprocedures (regulatory compliance documentation, multidepartment workflows). Use a flowchart SOP for processes with frequent “if/then” decisions (escalation paths, quality inspection routing). Use a checklist SOP for verification tasks where confirming every item matters more than sequence (safety inspections, closing procedures).

When in doubt, start with step by step. You can always restructure later if decision points emerge during the drafting process.

Every SOP starts with identification and boundaries. Write the SOP ID using your organization’s numbering convention (e.g., SOP-FIN-003 for the third finance SOP). Set the revision to 1.0, today’s date as the effective date, and a review date 6 to 12 months out. Name the SOP owner: the person accountable for keeping it current.

The scope statement defines what the SOP covers and, equally important, what it does not cover. A bank reconciliation SOP might state: “Covers all operating bank accounts for US entities. Does not cover petty cash or credit card reconciliation (see SOP-FIN-007).” Scope exclusions with cross references prevent the SOP from becoming a catch all document that grows until nobody reads it.

Write each step as a single action performed by a single role. Avoid compound steps like “check the gauge and adjust the valve if necessary” because compound steps hide decision points. If a step contains the word “and” connecting two distinct actions, split it into two steps.

For each step, include four elements: the action (what to do), the owner (who does it), the timeline or trigger (when to do it), and the completion criteria (how to verify it is done correctly). Here is the difference between a weak step and a strong one:

Weak: “Review the report and send it to the manager.”

Strong: “Review the reconciliation worksheet for unmatched items. If all items are matched or classified, submit to the Finance Manager via the shared drive with a summary email noting the final variance amount. Completion: Finance Manager confirms receipt within one business day.”

The strong version names a specific action, a specific recipient, a specific method, and a specific completion signal. The weak version leaves all four ambiguous.

Quality controls answer two questions: how do you know the process was done correctly, and what do you do when something goes wrong? Without quality controls, an SOP is a task list, not a quality assurance tool.

Define escalation triggers with specific thresholds. Instead of “escalate if something seems off,” write “if the unexplained variance exceeds $500, escalate to the Controller before proceeding.” Instead of “monitor for issues,” write “if the error rate exceeds 1% within 15 minutes of deployment, execute the rollback procedure in Section 7.”

For exception handling, document the three to five most common exceptions and what to do about each one. You cannot anticipate every edge case, but you can document the ones that the experienced operator handles routinely. Add a catch all: “For exceptions not covered above, pause the procedure and contact [Role] before continuing.”

Send the draft to two reviewers: the process operator who does the work daily (accuracy check) and the process owner or manager (authority and completeness check). Ask reviewers to mark any step where they would do something different, anything they consider unclear, and any step they think is missing.

After incorporating feedback, get formal approval from the designated approver (typically a department head or compliance officer). Record the approval in the revision history table at the bottom of the SOP with the date, approver name, and version number.

Before the SOP goes live, walk through it with every person who will use it. Have them perform the process using only the SOP document, without verbal guidance from you. If they get stuck or confused at any step, that step needs rewriting. This walkthrough test catches the gaps that desk reviews miss: the steps that are clear to the writer but ambiguous to a new reader.