How to Write an SOP: Step by Step Guide

Start with processes that score highest on a simple matrix: frequency multiplied by risk. A task performed daily with financial or compliance consequences is a higher priority SOP than a task performed quarterly with low stakes. Build a shortlist of your top 5 to 10 processes and rank them.

Good first SOPs include: new employee onboarding, invoice processing, customer refund handling, equipment maintenance routines, and end of period close procedures. These are high frequency, involve multiple people, and create measurable problems when done inconsistently.

Watch the process being performed by the person who does it best. Take notes on every action, decision, and tool used. Then interview them: ask what goes wrong most often, what steps get skipped under time pressure, and what they wish they had known when they first learned the process.

Do not write the SOP from a conference room. The gap between how managers think a process works and how it actually works on the floor is where most SOP inaccuracies originate. Direct observation closes that gap.

Match the format to the process complexity. Use a step by step format for linear tasks with no branching decisions. Use a hierarchical format when individual steps need sub steps. Use a flowchart format when the process includes frequent decision points. Use a checklist format when completion verification matters more than strict sequence.

When in doubt, start with step by step. It is the most familiar format and the easiest to write, review, and update. You can always convert to a more complex format later if needed.

Every SOP begins with a title block containing the SOP title, a unique ID number, the version number, the effective date, and the document owner. Use a consistent numbering scheme across your organization, such as department abbreviation followed by year and sequential number (FIN 2025 001).

The scope section defines exactly what the SOP covers and, equally important, what it does not cover. A clear scope prevents the document from expanding into a catch all reference that tries to cover every edge case. Boundaries keep SOPs focused and maintainable.

Write each step as one discrete action starting with a verb: Verify, Open, Submit, Calculate, Confirm, Notify. Assign a responsible role (not a person's name) to each step. Include the tool or system used when it matters for execution.

Keep each step to one action. If a step contains "and" joining two different actions, split it into two steps. If a step requires explanation beyond two sentences, it is too complex for a single step and should be broken into sub steps or supported by a reference document.

After critical steps where errors would be expensive to reverse, insert a quality checkpoint. A checkpoint defines what "done correctly" looks like and what to do if the result does not meet the standard. Example: "Checkpoint: verify the three way match is within 2% tolerance before coding the invoice."

Every SOP needs an exception section that answers: what happens when the standard process cannot be followed? Without this section, employees improvise during edge cases, which is exactly what SOPs are designed to prevent.

For each common deviation, document the trigger condition, who to notify, what alternative steps to take, and what approvals are required. Keep exception handling concise. If a particular exception is complex enough to need its own procedure, create a separate SOP and reference it here.

Before publishing, have two people review the SOP. First, the subject matter expert who performs the task should verify accuracy. Second, someone unfamiliar with the process should attempt to follow it and identify unclear steps. This two reviewer approach catches both technical errors and usability gaps.

After both reviews, obtain formal approval from the process owner or department head. Log the approval in the revision history with the date, approver name, and version number. This creates the audit trail that regulatory frameworks require.