How to write an SOP: a step-by-step guide with a worked example

To write an SOP (standard operating procedure), pick one routine task and name who does it, the event that starts it and the result that ends it. Watch the person who does it best, and write down every action in order as a numbered step that starts with a verb and ends with a check. Add the frame around the steps: purpose, scope, roles, the trigger, what the doer needs and what to do when something goes wrong. Then test the draft on someone who has never done the task, fix every place they stumble, get it approved and set a review date.

The nine steps below follow one SOP from the first interview to sign-off, a month-end bank reconciliation at a small design studio, so you can see the notes, the rough list and the finished procedure. For seven finished procedures in different formats, see the SOP examples. For a blank document with every section ready, use the SOP template.

When a task needs an SOP

The US Environmental Protection Agency's Guidance for Preparing Standard Operating Procedures (EPA QA/G-6, 2007) opens with a plain definition: “A Standard Operating Procedure (SOP) is a set of written instructions that document a routine or repetitive activity followed by an organization.” The key words are routine and repetitive. A task that repeats weekly, monthly or every time a certain event happens is worth writing down when any of these is also true:

If a regulation requires a written procedure, that settles it on its own. A task that happens once needs a plan, not an SOP. Work that depends on judgment, such as editing a feature or pricing a quote, needs guidelines and examples. And when the job is to describe how work flows across several teams rather than how one task is done, write a process document and link the SOPs from it.

How to write an SOP in nine steps

The running example: Calder Street Studio, a 40-person design firm, wants its bookkeeper's monthly bank reconciliation written down before a new hire takes it over.

1. Name the task, the doer, the trigger and the result

   Write the task as a verb and an object (“Reconcile the operating bank account”), then fix three things: who does it, the trigger that starts it and the result that ends it. Here the doer is the bookkeeper, the trigger is the first working day of the month, and the end is a reconciliation report signed by the finance director by the fifth working day. Write the result so someone could check it afterward. That sentence becomes the purpose, and it is the success condition every later step works toward.

2. Watch the person who does it best

   Don't write from memory, yours or theirs. Sit beside the expert while they do the real task, and write down every action, every screen and everything they look at. Ask two questions throughout: “How do you know that worked?” and “What goes wrong here?”

   Interview notes

   Maya Lindqvist, bookkeeper. Watched her reconcile September, 2 October, 9:10 to 10:25.

   • Bank portal: downloads the statement as PDF and CSV. “The PDF is for the auditors, the CSV is what I import.”
   • Banking, operating account, Reconcile. Types the closing balance from the PDF.
   • First check: opening balance = August's closing. “If not, someone changed a reconciled month. I stop.”
   • Imports the CSV; most lines match automatically. Unpicks two wrong matches (right amount, wrong payee).
   • Card processor pays out net of fees: matches each payout to the batch report, books the fee separately. Never written down.
   • Uncashed checks: leaves them unmatched.
   • Difference not zero? “Look for a duplicate, then for swapped digits: the difference divides by 9.”
   • Saves report and statement in Finance / Bank. Emails Grace (finance director), who signs. Due by the 5th working day.

3. List every action in order, including the invisible ones

   Turn the notes into a rough list, one line per action, in the order they happened. Keep the checks the expert makes without thinking. In Maya's case three of the most valuable lines were never written anywhere before: the opening-balance check, the rule for card payouts and the divisible-by-nine test for transposed digits. Swapping two digits always changes a number by a multiple of 9, so a difference that divides by 9 makes a swap the first thing to look for.

   Here is where each line of the notes ended up in the finished SOP, FIN-07, which appears in full after the nine steps. Each rough note became a step with an action someone else can repeat and, where it matters, a check they can see.

   In the notes	In FIN-07
   In the notesTypes the closing balance from the PDF.	In FIN-07Step 2: enter the statement's closing date and closing balance, under the menu name the screen shows
   In the notesOpening balance = August's closing. “If not … I stop.”	In FIN-07Step 3, with a check (the two are equal) and a stop that sends the doer to Exceptions
   In the notesUnpicks two wrong matches (right amount, wrong payee).	In FIN-07Step 5: undo any match that pairs the right amount with the wrong payee
   In the notesMatches each payout to the batch report, books the fee separately.	In FIN-07Steps 6 and 7. Check: the payout equals the batch total minus fees
   In the notesUncashed checks: leaves them unmatched.	In FIN-07Step 8. Check: each one appears on the Outstanding items list
   In the notes“Look for a duplicate, then for swapped digits.”	In FIN-07Exceptions: the same order, plus a 30-minute limit before the report goes to the finance director
   In the notesEmails Grace, who signs. Due by the 5th working day.	In FIN-07Step 11: send by the fourth working day. Check: the signed report comes back by the fifth

4. Choose the format

   Match the format to the task. A fixed sequence done by one person takes numbered steps; a long job takes steps and sub-steps; trained staff doing routine work need a checklist; a path that branches needs decision steps. The reconciliation is a sequence for one person, with a few known problems, so it gets numbered steps and an exceptions section. The SOP examples show each format in full.

5. Write each step as a command with a check

   Start with a verb, give one action per step, use the names on the screen, and end with what the doer should see. Put conditions and warnings before the action, not after it. The EPA guidance adds a useful rule of grammar: “The active voice and present verb tense should be used. The term ‘you’ should not be used, but implied.” The imperative does exactly that. Here is one vague step from a first draft, rewritten:

   Draft 2

   • 6. Match each card-processor payout to its batch in the batch report, not to individual sales. Check: the payout equals the batch total minus fees.
   • 7. Record each payout's processing fee, and any bank fees or interest on the statement, as bank charges or interest income.
   • 8. Leave checks not yet cashed and deposits not yet credited unmatched. Check: each one appears on the Outstanding items list.

   Draft 1

   • Reconcile the account and investigate any differences.
6. Build the frame around the steps

   Add a header (ID, title, owner, version, effective date, review date), then purpose, scope, roles, the trigger and what the doer needs before step 1. Scope should say what the SOP doesn't cover and where that lives. Write the exceptions from the expert's answers to “What goes wrong?”, and finish with a revision line. The SOP template has every one of these sections ready.

7. Test it on someone who has never done the task

   Hand the draft to a newcomer and watch them follow it on real work, without helping. Mark every pause, question and wrong turn; each one is an edit. Calder's new hire, Tom Okafor, followed draft 0.3 on the October statement. He stopped three times: his screen said “Reconcile account”, not “Reconcile”; he didn't know where the card batch report was kept; and when the difference came out at 27.00, nothing told him what to do. Each stop became a fix, and the next test ran clean.

8. Review, approve and publish one copy

   Ask the expert to check accuracy and the owner to approve. In the EPA's words, “Signature approval indicates that an SOP has been both reviewed and approved by management.” Then publish it in one place, withdraw every older copy (printouts, email attachments, the wiki page from 2023), and walk the people who do the task through what changed.

   If you draft in Strokes, attach the policy the SOP has to follow and ask the Strokes Assistant to review the draft against it before the expert does. It flags inconsistencies such as a 90-day limit where the policy says 60.

9. Set a review date and update it after every change

   Put a review date in the header. The EPA guidance suggests that SOPs “be also systematically reviewed on a periodic basis, e.g. every 1-2 years”, and says that whenever procedures change, the SOP should be updated and re-approved. Review sooner when a tool, a team or a rule changes, or when a mistake shows a step was wrong, and give every change a line in the revision history that says why.

The finished SOP

This is the version Calder issued. Compare it with the interview notes: nothing in it is invented, but everything is now in order, named and checkable.

Why it works. The role, the trigger and the success condition are stated before step 1: the bookkeeper does it, the first working day starts it, and the purpose is a result Grace can check on the fifth working day, not a description of an activity. Every piece of Maya's private knowledge has a home, as the table in step 3 shows, and the divide-by-nine trick sits in Exceptions, where the person who needs it will look. Tom's three stops are fixed in the text itself: the menu name in step 2, the batch report's location under You need, and the 27.00 difference under Exceptions.

SOPs in regulated work

In some industries a written procedure is a legal requirement, and the regulation sets the minimum it must contain. The two US federal examples below show the pattern; they are summaries, not compliance advice. What applies to you depends on the rule that covers your site and on your organization's own quality or safety procedures, so read the current text of both.

• Drug manufacturing. Under 21 CFR 211.100, there must be written procedures for production and process control, drafted, reviewed and approved by the appropriate organizational units and by the quality control unit. They must be followed and documented at the time of performance, and “Any deviation from the written procedures shall be recorded and justified.”
• Lockout/tagout. OSHA's standard for controlling hazardous energy, 29 CFR 1910.147, says procedures “shall be developed, documented and utilized”, with a narrow exception for some machines with a single energy source that is easy to isolate. It requires them to “clearly and specifically outline the scope, purpose, authorization, rules, and techniques” for controlling the energy, and calls for a periodic inspection of each procedure at least annually.

Common SOP writing mistakes

• Writing it at a desk from memory. The expert's automatic checks, often the ones worth most, tend not to make it onto the page.
• Writing the official process instead of the real one. If people skip a step, find out why before you write it in. Either the step is unnecessary or the SOP has to explain why it matters.
• Mixing policy and procedure. “Uncashed checks older than 90 days are reviewed” is a rule. The SOP says who lists them and when, and links to the policy for the why.
• Hiding judgment inside a step. “Check the totals are correct” leaves the doer to decide what correct means. Say what to compare with what, and what counts as a match.
• Vague time and quantity words. “Promptly”, “as needed” and “large amounts” each mean something different to every reader. Use the fourth working day, a number and a limit.
• Copies everywhere. A binder, a shared drive and an email attachment soon disagree, and nobody knows which one is current. Keep one controlled copy and link to it.
• Inconsistent terms. Payout, settlement and transfer for the same thing read as three things. A short style guide keeps a whole SOP library on the same words, and plain words improve its readability.

For the general rules behind clear procedures, which apply to manuals and how-to guides as much as to SOPs, see what technical writing is. When the task is running and fixing a software system rather than a business task, the better document is a runbook.