Northline Ops › Guides › How to Write an SOP

How to Write an SOP: A Step-by-Step Guide

By Northline Ops · Published May 2026 · Last updated August 2026

A standard operating procedure (SOP) turns a task that lives in someone's head into something anyone on your team can do the same way, every time. Here is a practical process for writing one your team will actually follow — plus the exact structure to use and a free AI prompt to draft your first one in minutes.

What an SOP actually is (and isn't)

An SOP is a documented, step-by-step set of instructions for completing a recurring task consistently. Done well, it answers four questions: who does the work, when they do it, the exact steps to follow, and what "done correctly" looks like.

An SOP is not a policy (which sets rules), a flowchart (which maps decisions), or a training course. It's the reliable recipe a competent person can follow without asking you to explain it again.

When it's worth writing one

You don't need an SOP for everything. Write one when a task is:

• Recurring — it happens weekly, monthly, or on a predictable trigger.
• Done by more than one person — or will be, once you delegate it.
• Costly to get wrong — mistakes mean rework, unhappy customers, or compliance risk.
• Currently undocumented — it only exists in one person's memory.

Not sure which to tackle first? Start with the 10 SOPs every small business should document first. If you run a specific kind of business, a tailored starting point helps: we have ready-made SOP templates for trucking and logistics, construction, medical and dental clinics, real estate teams, and law firms.

The structure every SOP should use

Keep one process per document and use the same skeleton each time so your team always knows where to look (our guide to SOP format and structure breaks each part down further):

1. Title & purpose — the process name and one sentence on why it matters.
2. Scope — when this applies (and when it doesn't).
3. Owner / role responsible — the role, not a person's name, so it survives staff changes.
4. Tools & access needed — software, logins, files, or equipment required before starting.
5. The steps — numbered, in order, each starting with an action verb.
6. Expected outcome / quality check — how to know it was done right.
7. Last reviewed — a date so you know when it's stale.

If you'd rather not lay those seven parts out by hand, our free SOP generator gives you a field for each one and formats the finished procedure for you as you type. It's free, needs no signup, and you can copy the result straight into Word, Docs or Notion.

Step-by-step: writing the SOP

1. Pick one narrow process

"Onboard a client" is too big. "Set up a new client in the billing system" is an SOP. If you can't describe the task in a single sentence, split it. (A big process like hiring becomes several small SOPs — see our employee onboarding SOP for a worked example.)

2. Do the task once and capture every step

The fastest way to write an accurate SOP is to perform the task and note each action as you go — every click, check, and hand-off. Don't tidy it yet; just capture reality.

3. Rewrite each step as a plain action

Start every step with a verb: "Open…", "Confirm…", "Send…". One action per step. Assume the reader is competent but new — no insider shorthand. If it helps to see finished versions, our SOP examples you can copy show the format in action.

4. Add the quality check

State what the finished result looks like. "The invoice shows the correct PO number and the status is "Sent"" beats "make sure it's right."

5. Have someone else follow it

The real test: hand it to a person who has never done the task and watch them follow it without asking questions. Every question they ask is a missing step.

You are an operations expert who writes clear, usable SOPs.
I'll describe a task my team does. Interview me one question
at a time to fill any gaps, then produce a standard operating
procedure with these sections: Title & Purpose, Scope, Role
Responsible, Tools/Access Needed, Numbered Steps (each starting
with an action verb, one action per step), Expected Outcome /
Quality Check, and Last Reviewed date. Keep it to one page.

The task is: [describe your task in a sentence or two]

A worked example: from messy notes to a finished SOP

The steps above are easier to trust once you see the output. Here is the same process at both ends — the raw capture from step 2, then the finished document. The process is sending a client invoice, chosen because almost every business does it and almost nobody has written it down.

Before — the raw capture

This is what step 2 actually produces. It is disorganised on purpose. Do not clean it up while you are capturing:

invoice stuff
- check the timesheet thing first, hours for the month
- open QB, new invoice, pick the client
- rates are in the client folder, watch for the ones on retainer
- PO number goes in the memo box if they gave us one
- add the hours, description like "Bookkeeping - August"
- email it from QB not gmail
- cc the office inbox
- mark it in the tracker sheet
- if over $5k Lori has to look at it first

After — the finished SOP

Same information, run through steps 3 to 5 and dropped into the seven-part structure:

Three things changed between the two versions, and they are the three that matter most:

• Order. The raw notes mention the $5,000 approval last. In the finished SOP it sits before the send step, which is where it actually happens.
• Roles, not names. "Lori has to look at it" became "the account manager", so the SOP survives a staffing change.
• A checkable ending. "Mark it in the tracker" became a specific state you can look at and confirm.

That is the whole job. If you want the same treatment applied to a stack of processes rather than one, our library of copy-ready SOP examples and the SOP format guide cover the patterns that repeat across most businesses.

Common mistakes to avoid

• Writing for an expert. SOPs are for the person who doesn't already know the task.
• Bundling multiple processes. One document, one process — or no one can find anything.
• Naming a person instead of a role. People leave; roles don't.
• Never reviewing. An SOP that's wrong is worse than none, because people trust it.
• Letting perfect block done. A rough SOP in use beats a perfect one that never gets written.

Frequently asked questions

What should an SOP include?

A title and purpose, scope, the role responsible, tools or access needed, numbered action steps, an expected-outcome quality check, and a last-reviewed date — one process per document.

How long should an SOP be?

As short as possible while staying unambiguous — usually one to two pages. If it runs longer, you're probably documenting two processes that should be separate SOPs.

Can I use AI to write an SOP?

Yes. Describe the process in plain language and a model like ChatGPT, Claude, or Gemini will structure it into clear steps; you review for accuracy. The free prompt above gives you a usable first draft in a few minutes.