How to Write an SOP: A Simple Template and Steps

Key Takeaway

An SOP (standard operating procedure) is a written, repeatable set of steps for doing one task the same way every time. To write one, name the outcome the task produces, list the steps in order as short verb phrases, add the tools and access someone needs, note the common mistakes, and have a person who has never done the task test it. A good one is not long, it is followable: clear enough that a new hire gets the right result without asking you. Use the template in this guide and you can write your first one in about 30 minutes.

What an SOP Is, in Plain English

An SOP, short for standard operating procedure, is a written set of steps for doing one task the correct way every single time. That is the entire idea. It takes a job that currently lives in one person's head and puts it on paper, so anyone in the right role can pick it up and get the same result whether or not the usual person is available.

Here is why that matters more than it sounds. When we studied 16 small businesses across 68 roles and 461 process areas, only 22 percent of those areas were documented well enough for a new hire to actually use. The rest ran on memory and habit. That is the quiet risk in most small businesses: the work gets done, but it is trapped in people, and the day one of those people leaves, the knowledge leaves with them. An SOP is the unit of work that turns trapped knowledge into a shared asset.

One quick clarification before we write one, because the words get used loosely. A process, a procedure, and a policy are not the same thing. The process is the whole flow, the procedure is the step by step for one task inside it, and a policy is a rule that governs choices. This guide is about the middle one.

How to Write an SOP in 5 Steps

Writing one is not creative writing. It is a fill in the blanks exercise once you know the five moves. Here they are in order.

1. Name the Outcome

Start with the finished result, not the first step. Title the document with what it produces: "Book a new customer job," not "Booking process." When the reader knows what done looks like before they start, every step has a purpose. Write one line under the title describing exactly what a completed, correct result looks like so there is no ambiguity about when the task is finished.

2. List the Steps in Order

Write each step as a short line starting with a verb: "Open the CRM," "Confirm the deposit cleared," "Send the confirmation email." One action per line, in the real order they happen. Do not explain, do not editorialize, just lay out the sequence. If you captured the task on a recording first, this step is mostly transcription, which is why we always recommend documenting the process before you format the SOP.

3. Add the Tools and Access Needed

List what the person needs before they start: the logins, the templates, the physical materials, the approvals. Nothing kills momentum like getting to step four and discovering you need a password nobody gave you. Put the requirements up top so the reader gathers everything first, then works straight through.

4. Note the Common Mistakes

This is the step that separates a checklist from real training. Add a short "watch out for" section listing the two or three mistakes people always make: the field everyone forgets, the timing rule, the thing that looks optional but is not. This captured judgment is often the single most valuable part of the whole document, because it is the knowledge that usually only lives in an expert's head.

5. Have a Fresh Person Test It

The only real quality check. Hand the draft to someone who has never done the task and watch them follow it with no help from you. Every place they hesitate, ask a question, or do it wrong is a gap in the writing, not a failing of the person. Patch those gaps and the procedure is done. Until a fresh person has run it successfully, what you have is a draft.

A Copy and Paste SOP Template

You do not need special software to write a great SOP. You need a consistent structure. Here is the exact skeleton we use with clients. Copy it, fill in the fields, and delete the italic prompts as you go.

SOP: Name the task as its outcome, e.g. "Book a new customer job"

Owner: The role responsible, e.g. "Office Admin"

Trigger: The event that starts this task, e.g. "Customer approves the quote"

Done when: What a finished, correct result looks like

---

You will need: Logins, templates, materials, and approvals to gather first

---

Steps:

1. Verb plus object
2. Verb plus object
3. Verb plus object
4. Verb plus object

---

Watch out for: The 2 or 3 mistakes people always make

Last updated: Date and who updated it

That is the whole template. Notice what it does not have: a cover page, a version control table with nine columns, a mission statement. Those things make SOPs feel official and make them die in a drawer. The fields above are the ones that make a procedure followable and trustworthy, and nothing more.

The Three Voices of a Great SOP

The best SOPs quietly speak in three voices, and weak ones are missing at least one. Once you can hear the three, you will spot exactly what a lifeless procedure is lacking.

Purpose: the why. One line that tells the reader what this task produces and why it matters, so they can make sensible judgment calls when the steps do not cover a situation. Without purpose, people follow steps blindly and cannot adapt.

Context: the when and what you need. The trigger, the owner, and the tools and access to gather first. Context makes the document usable in the real moment someone reaches for it, not just readable in the abstract.

Method: the how. The numbered steps themselves, in order, verb first. This is the part most people think of as "the SOP," but on its own it produces someone who can follow directions and still get the outcome wrong.

Purpose tells them what good looks like. Context tells them what they need and when. Method tells them exactly what to do. Get all three on the page and you have written something a person can actually run with.

How Detailed Should an SOP Be? The Glance Test

The most common question, and the one people get wrong in both directions. Too little detail and the procedure is useless to a beginner. Too much and nobody reads it or keeps it current. The rule we use is the glance test: a reader should be able to glance at any single step and know what to do without stopping to read a paragraph.

If a step passes the glance test, leave it alone. If it does not, if it needs a wall of explanation, you have two better options than cramming: break it into a few sub steps, or link a short video of someone doing that one part. A screen recording is often the cleanest way to handle a fiddly step, and you can turn that recording straight into instructions using the approach in how to turn a screen recording into an SOP.

Aim the detail at a competent new hire. Not an expert who needs no instructions, and not a robot that needs every mouse click spelled out. Somewhere in the middle is a real person on their first week who is smart, motivated, and has never seen this task. Write for that person and the detail level takes care of itself.

What a Good SOP Looks Like Versus a Bad One

Two SOPs for the same task can look completely different. Here is the side by side, so you can check your own writing against it.

The single biggest tell is the last row. A weak procedure has never been tested, so it is really just the author's memory typed out, gaps and all. A strong one has survived contact with a real beginner. If you only add one habit to your writing, make it the test.

Writing It Is Only Half the Job

A perfect procedure that nobody can find, that is three versions out of date, or that lives in a folder no one opens is a perfect document that changes nothing. Writing a great procedure and getting your team to actually use it are two different jobs. This guide covers the writing. For the adoption side, keeping SOPs current, findable, and the default way work gets done, see guides on how to write SOPs your team will actually follow and why your SOPs collect dust.

Where SOPs Fit in the Bigger Picture

An SOP is one task, done right, on paper. It is powerful, but it is a piece of something larger. Before you write a stack of SOPs, it helps to know which ones you actually need, and that comes from documenting the process first. The process shows you the whole flow and every step in it. Each step that carries risk or gets done wrong is a candidate for a procedure. That is why we always map or document the process before writing procedures.

There is a business case underneath all of this. Most small businesses spend 60 to 70 percent of their overhead on salaries and around 1 percent on training the people those salaries pay for. SOPs are the cheapest, highest leverage way to close that gap. You are not buying a course. You are capturing the expertise you already pay for, once, so it stops evaporating every time someone is out sick or moves on.

The Bottom Line

Writing an SOP is a five step, fill in the blanks task, not a writing project. Name the outcome, list the steps in order, add the tools and access, note the common mistakes, and have a fresh person test it. Speak in the three voices, purpose, context, and method. Keep every step inside the glance test. Use the template in this guide and you can have your first real SOP written and proven before lunch.

Do not try to write your whole library this month. Write one SOP this week, for the task people interrupt you about most, and hand it to someone else. The first time that task gets done correctly without you, you will understand why this small, unglamorous document is the building block of a business that runs without you.

Frequently Asked Questions

How do I write a good SOP?

Name the outcome the task produces, list the steps in order as short verb-first lines, add the tools and access needed, note the common mistakes, and have someone who has never done the task test it. A good SOP passes the glance test: any single step should be clear without stopping to read a paragraph. Use a consistent template and you can write a usable SOP in about 30 minutes.

What should be included in an SOP?

A strong SOP has four parts: the outcome and when it is done, the context (trigger, owner, tools and access needed), the numbered steps in order, and a short list of common mistakes to watch for. Those four elements are what make a procedure something a new hire can actually run with, rather than a wall of text they read once and ignore.

How long should an SOP be?

As short as it can be while still passing the glance test: someone should be able to glance at a step and know what to do without stopping to read a paragraph. If a step needs a lot of explanation, break it into sub-steps or link a short video instead of cramming more text in. Most task-level SOPs run five to fifteen steps.

What is the difference between a process, a procedure, and a policy?

The process is the whole flow from trigger to finished result. The procedure, which is what an SOP documents, is the step-by-step for one task inside that flow. A policy is a rule that governs choices, like who is allowed to approve a refund. People use these words interchangeably, but they describe different altitudes of the same operation.

How do I know if my SOP is good enough?

Test it. Hand the draft to someone who has never done the task and watch them follow it without your help. Every place they hesitate or get it wrong is a gap in the document, not a failure of the person. An SOP that has never been tested by a fresh set of eyes is still a draft, no matter how polished it looks.

Do I need software to write SOPs?

No. A plain document and a consistent template are enough to start. Software becomes useful once you have more than a handful of people and need to assign, track, and keep procedures current, but the writing itself does not require any special tool. Start with what you already have open.