How to Write an SOP (Standard Operating Procedure)

What is an SOP and when does your business actually need one?

A standard operating procedure (SOP) is a written document that shows how to complete a specific process the same way every time, typically with a title, purpose, scope, responsibilities, and numbered steps. University EHS programs use this structure so results don't depend on who's on shift (University of Washington SOP guidance). Same logic applies to your client onboarding or invoice workflow.

The three-question test for SOP-worthy processes

Most processes don't need documenting. Write an SOP when a process answers yes to all three: it happens weekly or more, more than one person does it, and a mistake costs money or a client. If only you do it and rarely, a checklist in your notes is enough.

Why undocumented processes keep you founder-dependent

Undocumented processes are why every exception routes back to you: staff can't follow what was never written down, so quality depends on your memory and availability. That's the founder-dependent work pattern that blocks hiring, vacations, and later automation. Our guide on processes worth automating starts from the same threshold: document what's repeated and costly first, because an SOP you can hand to a new hire is also the draft software needs later.

How do you scope an SOP so it stays usable instead of bloated?

Most SOPs bloat because they cover too many priorities at once. Scope each document around three things: one trigger (what starts the process), one owner (who is accountable when it runs), and one defined start and end point. If you cannot state the end point in a sentence, the scope is too wide.

One process, one document: the scope rule

Write the trigger as an event, not a mood. "Client signs the onboarding agreement" works; "when we get a new client, eventually" does not. Then write the end point the same way: "invoice sent and filed in QuickBooks." Everything between those two sentences belongs in the document. Everything after the end point belongs in a different one. This matches how you should sequence work in a 90-day roadmap: one documented process per cycle, not ten half-finished ones (how to build a 90-day operational improvement roadmap).

When to split an SOP into two

Split when the process crosses a role or a system. If your coordinator hands off to a technician, or the work moves from email into your job software, that boundary is a natural break. Two short SOPs that staff follow beat one long one they skim. A quick test: if a step exists mainly to explain what the other team does, cut it and link to that team's SOP instead.

What sections must every SOP include, in what order?

Every SOP you write should use the same eight sections, in the same order: title, purpose, trigger, owner, roles, steps, exceptions, and revision log. The fixed order matters because it forces tradeoffs before you reach the steps. Purpose and trigger kill scope creep: if a step does not serve the stated purpose or fire on the stated trigger, it belongs in a different SOP. Owner and roles settle the "who does this when the founder is off the clock" question, which is the whole point of documenting. Steps come seventh, not first, so they inherit the constraints instead of becoming a dump of everything you know. Exceptions protect staff judgement, and the revision log keeps the document honest over time.

That order also mirrors how checklists reduce errors in high-stakes work: the reason a short, structured procedure outperforms a long one is that people actually complete it. In a peer-reviewed study of surgical checklists, implementation cut deaths and complications substantially (Haynes et al., NEJM). A bloated SOP fails the same way a bloated checklist does: it gets skipped. The same structure works for care and property operators juggling multi-site routines (operations support for care, property and multi-site operators).

What you can safely leave out

Leave out background history, theory, tool screenshots that go stale, and any step that belongs in a different SOP. Leave out "may also" alternatives; pick one path and note exceptions separately. If a section would not help a new hire follow the process untrained, it is bloat.

How do you write steps so any employee can follow them without training?

Start every step with a command verb: "Open," "Enter," "Send," "Confirm." If a step contains "and," split it. "Log the payment and email the client" becomes two numbered steps, because an employee mid-task will do one and skip the other. Keep each step short enough to read at a glance while working.

Name the system, the field and the value

"Update the record" is not a step; it is a wish. Write "In QuickBooks, open the invoice, set the Status field to Paid, and enter the payment date in the Payment Date field." The test: could a new hire on day one find the exact screen and field without asking anyone? If your process names are undocumented, fix that first (OG Project Partners Inc. — AI-Native Operational Intelligence).

Write the failure path, not just the happy path

Every step that can fail needs a line for what to do when it does: "If the invoice shows Partially Paid, stop and flag the owner in Slack. Do not mark it Paid." Most bloated SOPs cover only the happy path, which is why staff improvise the moment something goes wrong. State the escalation point and the person, not "contact management."

Worked example: a unit-turnover inspection SOP from blank page to finished document

A property-management firm with 12 staff needed to document its unit-turnover inspection: the check a supervisor runs between one tenant leaving and the next arriving. Undocumented processes like this one are a common source of rework for small firms, because the knowledge lives in one person's head (SBA, Business Guide).

Stage 1: scoping notes

The owner wrote three lines before drafting anything: trigger (tenant notice accepted), owner (ops supervisor), and stop point (unit marked rent-ready). Anything outside that, like repairs or lease paperwork, got a one-line "hand off to" note instead of steps. This is the same scoping discipline we recommend in our guide to SOPs before automation.

Stage 2: the first draft and what is wrong with it

The first draft ran to four pages. It mixed three processes (inspection, repair dispatch, deposit accounting), used vague verbs ("verify the unit is up to standard"), and buried the actual checklist in paragraph three. A new hire could not have followed it untrained, which is the test that matters.

Stage 3: the finished SOP

Pruning decisions: repair dispatch and deposit accounting moved to their own SOPs, "up to standard" was replaced with a 14-item pass/fail checklist, and the whole document was cut to one page.

The final version is testable by a real employee and structured well enough to hand to software later.

• Pages — 4 — 1
• Processes covered — 3 — 1
• Checklist items — Vague prose — 14 pass/fail
• Sign-off — None — Supervisor initials + date

How do you test and revise an SOP so people actually use it?

Hand the draft to an employee who has never done the task, then watch without helping. Every hesitation, wrong turn, or question is a drafting defect, not a training gap. If they stop at step 4 because it says "verify the unit is ready," the step was vague; rewrite it to say what to check and what "ready" means. One silent watch usually surfaces more fixes than a month of reading the document yourself.

Logging revisions so the SOP stays authoritative

Keep a short revision table at the bottom: date, what changed, why, who approved. This stops two versions circulating and makes it obvious which document is current. Fix defects the same week you spot them, or staff will revert to asking you directly, which is exactly the founder-dependence the SOP exists to remove.

How do you keep SOPs current as your processes change?

An outdated SOP is worse than no SOP: staff follow steps that no longer match reality, then stop trusting the document entirely. Maintenance needs to be lightweight enough that you actually do it.

The same-day update rule

Any process change updates the SOP the same day, before the person making the change moves on. Add a one-line revision log at the bottom: date, what changed, who changed it. This mirrors the document control discipline in ISO 9001's requirements for controlling documented information, scaled down for a team of five.

A quarterly review that takes 15 minutes

Every quarter, skim your ten most-used SOPs and check three things: do the steps match what people actually do, are the KPIs still the right ones, and is anything flagged for automation. If a review surfaces drift, fix it that day. Skip the review only when a process has not changed, and say so in the log so you know you checked.

When is an SOP ready to be automated or handed to software?

An SOP is ready for software when all five are true: the steps have stayed unchanged through two revision cycles; every input is digital (forms, not paper checklists); the outcome is measurable with a weak KPI now defined; exceptions happen in under roughly 10% of runs; and the process runs often enough that saved minutes compound, say weekly or more per person. Miss any one and automation just digitizes your undocumented processes and founder-dependent work.

Judging AI SOP tools by the same criteria, including ours

Hold AI drafting tools to the same standard. ChatGPT will produce a starting draft fast, but it will not know your team capacity or real distribution, so a human pass is non-negotiable. Strategy-execution tools sit at the planning layer, and business-planning tools target forecasts and pitches; none of them replace a plain document for step-by-step procedures. Our own OGPP Strategy Advisor forces constraints (one ICP, one channel, one core offer) and adds expert review at $149, but it falls short for SOP libraries: it shapes plans, not step-by-step procedure documents, so pair it with a plain document tool for the writing itself.

FAQ: How long should an SOP be for a small business?

One page is a good target. The worked example in this guide cut a four-page draft to a single page with a 14-item pass/fail checklist, and shorter structured procedures get completed where long ones get skipped. If your SOP runs past a page, you are probably covering two processes; split it at the role or system boundary.

Can I use ChatGPT to write my SOPs, and what are the risks?

Yes, as a starting draft, but never as the finished document. ChatGPT does not know your team, your systems, or your field names, so it will produce vague steps like "update the record" that fail the day-one test. A human pass is non-negotiable: name the exact system, field, and value, and write the failure paths yourself.

Who should write an SOP: the owner, the manager, or the person doing the work?

The person doing the work drafts it, because they know the real screens, fields, and exceptions. The owner or manager sets scope: one trigger, one owner, one start and end point. Then a silent watch test with someone who has never done the task catches drafting defects before the document goes live.

What is the difference between an SOP and a checklist or a work instruction?

An SOP documents a full process the same way every time, with purpose, trigger, owner, roles, numbered steps, and exceptions. A checklist is a compressed pass/fail list inside that structure, like the 14-item inspection list in the worked example. A work instruction zooms into one step. If only you do a task rarely, a checklist in your notes is enough.

How many SOPs does a 10-person company actually need?

Only the processes that pass the three-question test: they happen weekly or more, more than one person does them, and a mistake costs money or a client. For most 10-person teams that is a handful of documents, not a library. Document one process per cycle rather than ten half-finished ones, and split any SOP that crosses a role or system.