How to Write an SOP in 7 Steps (With Format and Template Guide)

Someone on your team knows exactly how to run payroll, handle a refund request, or onboard a new client. Then they take a vacation, and nobody else can do it.

A standard operating procedure fixes that. This guide covers how to write an SOP people will actually follow, including the parts most templates skip.

TLDR

• An SOP is a step-by-step document that shows exactly how to complete one specific task, so anyone can do it the same way every time.
• Pick your format before you write. Simple steps for short tasks, hierarchical for long ones, flowchart when there are decisions.
• Write in the imperative style. “Open the dashboard,” not “the dashboard should be opened.”
• Test it with someone who has never done the task. That is the only real proof it works.
• Most SOPs fail because nobody can find them or nobody updates them, not because they were written badly.

What Is a Standard Operating Procedure?

A standard operating procedure is a written document that gives step-by-step instructions for completing one specific task, so that anyone on your team can perform it consistently and correctly.

The word doing the work there is specific. An SOP covers one task, not a whole department.

People confuse four things constantly, so here is the difference in plain terms.

• A policy says what your company requires and why. “All refunds over $500 need manager approval.”
• A process document gives the high-level view of how work flows from start to finish. “Here are the six stages of publishing an article.”
• An SOP details one of those stages, step by step. “Here is exactly how to format, review, and publish a post.”
• A work instruction goes narrower still, down to a single action within a step.

If you are documenting a broader set of information for customers rather than staff, our guide on types of product documentation covers where each format fits.

When You Actually Need an SOP

Not every task deserves one. Writing SOPs for things nobody repeats is how teams end up with a library nobody reads.

Write an SOP when a task meets at least two of these conditions.

• It repeats. Daily, weekly, or monthly. One-time projects do not need one.
• Consistency matters. Doing it differently produces different results, or costs money.
• More than one person does it, or will need to.
• Only one person knows how. That is a single point of failure sitting in someone’s head.
• Getting it wrong is expensive, whether in money, compliance exposure, or customer trust.

A useful starting question is where you see the most drift. Which tasks get done differently depending on who picks them up? Which roles turn over most often? Those are where an SOP pays for itself fastest.

Pick the Right SOP Format Before You Write

Choosing your format first saves you from rewriting later. Two things decide it, how many steps the task has, and how many decisions the person has to make along the way.

Format	Use it when	Example
Simple steps	Under 10 steps, few or no decisions	Processing a return, closing the register
Hierarchical steps	More than 10 steps, with sub-steps	Onboarding a new employee, quarterly close
Flowchart	The path changes based on decisions	Handling a customer escalation, incident response
Checklist	Order matters less than completeness	Pre-launch checks, site inspections

Pick the simplest format the task allows. A flowchart for a five-step task makes it harder to follow, not easier.

What Every SOP Should Include

Most SOP templates share the same skeleton. You do not need every element, but you do need these.

• Title. Specific enough that someone can find it by searching. “How to Process a Customer Refund,” not “Refunds.”
• Purpose. One or two sentences on what this procedure accomplishes and why it exists.
• Scope. What the SOP covers, and what it does not. This prevents the document from sprawling.
• Roles and responsibilities. Who performs this, and who approves it.
• What you need first. Tools, system access, materials, or information required before starting.
• The procedure. The numbered steps themselves. This is the document.
• Document control. Version number, author, approval date, and last review date.

Regulated industries add more, including safety warnings, references to applicable regulations, and formal signatures. If you work in a regulated environment, check what your standard requires before designing your template.

How to Write an SOP in Seven Steps

Here is the full sequence. Each step is expanded below.

1. Define the purpose and scope
2. Identify who will actually read it
3. Talk to the people who do the work
4. Draft the steps in imperative style
5. Add visuals where words get clumsy
6. Test it with someone who has never done the task
7. Review, approve, and publish

Step 1. Define the Purpose and Scope

Write one sentence stating what this SOP accomplishes. If you cannot do that, the task is too broad and needs splitting into several SOPs.

Then set the boundaries. State where the procedure starts and where it ends. An SOP for processing refunds might start when a request arrives and end when the refund is confirmed, with the separate question of refund eligibility living in a policy instead.

Step 2. Identify Who Will Actually Read It

Detail level depends entirely on the reader. A new hire needs context and explanation. An experienced employee needs the steps and nothing else.

Write for the least experienced person who will realistically use it. Then ask whether they will understand every term you used. If your SOP contains internal jargon or acronyms, define them or remove them.

Step 3. Talk to the People Who Do the Work

This is the step most people skip, and it is why so many SOPs describe a process that does not match reality.

Sit with the person who performs the task and watch them do it. You will find steps they do automatically without mentioning, workarounds nobody documented, and points where things routinely go wrong. All of that belongs in the SOP.

Interviewing beats writing from memory. The person doing the work knows things the manager does not.

Step 4. Draft the Steps in Imperative Style

Good manufacturing practice guidance is direct about this. Procedures and work instructions should be written in an imperative, mandatory style. It is the single most useful writing rule for SOPs and almost nobody follows it.

In practice that means starting each step with a verb and telling the reader what to do.

• Write this. “Open the billing dashboard. Select the customer account. Click Issue Refund.”
• Not this. “The billing dashboard should be opened, at which point the relevant customer account can be selected.”

Keep one action per step. If a step contains the word “and,” it is probably two steps. And keep sentences short, because someone is reading this while trying to do the task, not studying it at a desk.

Our guide on writing clear and concise documentation goes deeper on the language side.

Step 5. Add Visuals Where Words Get Clumsy

Screenshots earn their place when a step involves finding something on screen. A short caption under each one tells the reader what they are looking at.

Use visuals where describing something takes more words than showing it. Do not decorate. Every screenshot you add is another thing to update when the interface changes.

Step 6. Test It With Someone Who Has Never Done the Task

Hand the draft to someone unfamiliar with the process and ask them to complete the task using only your document. Do not help them. Watch where they hesitate.

Every pause marks a gap. Maybe you assumed knowledge they do not have, skipped a step you do automatically, or used a term that means nothing to them. Fix those and test again.

This is the only real proof your SOP works. An SOP that makes sense to its author is not the same as an SOP that works.

Step 7. Review, Approve, and Publish

Send the tested draft to whoever owns the process for a factual check, and to anyone responsible for compliance if that applies.

Then record the version number, the author, the approval date, and the next review date before you publish. Skipping this step is how teams end up with three versions of the same SOP and no idea which one is current.

Decide Where Your SOPs Will Live

This decision matters more than the writing, and almost every guide ignores it.

An SOP saved to someone’s desktop, buried in a shared drive, or attached to an old email might as well not exist. When people cannot find the procedure in under a minute, they ask a colleague instead, and you are back to knowledge living in someone’s head.

Whatever you use should do four things.

• Search that works. People search by the words in their heads, not by your folder structure.
• Clear organization. Related procedures grouped together, with nesting for larger sets.
• Controlled access. Internal SOPs stay internal. Some should be visible only to specific roles.
• One current version. Not five copies with different edits.

If your team already runs on WordPress, weDocs handles this without adding another subscription. You get drag-and-drop organization, live search, nested sections for grouping related procedures, and role-based permissions so internal SOPs stay internal. Setting up multiple knowledge bases also lets you keep staff procedures separate from anything customer-facing.

The tool matters less than the principle. Put your SOPs somewhere searchable, and put all of them in the same place.

Keep Your SOPs From Going Stale

An out-of-date SOP is worse than no SOP, because people follow it and get the wrong result.

Three things keep documentation current.

• Name an owner for each SOP. Not a team, a person. Shared ownership means nobody updates it.
• Set a review date and put it in the document. Annual works for stable processes. Quarterly for anything tied to software that changes.
• Update on triggers, not just on schedule. When a tool changes, a regulation changes, or someone finds an error, that is the moment to fix it.

Running a periodic knowledge base audit catches the documents that quietly drifted out of date while nobody was looking.

Mistakes That Make SOPs Useless

These come up over and over, and all of them are avoidable.

• Writing for compliance instead of for the reader. Teams pad SOPs to look thorough, and end up with documents so long that staff skim or ignore them. A procedure nobody finishes reading protects nobody.
• Describing the ideal process instead of the real one. If the SOP does not match what actually happens, people trust their own habits instead.
• Assuming knowledge. The author does the task daily and forgets which parts are not obvious. Testing catches this.
• Vague titles. “Client Process v2” is unfindable. Title it the way someone would search for it.
• Publishing and walking away. No owner, no review date, no updates. Within a year it is fiction.

Our post on common documentation mistakes covers more of the traps growing teams fall into.

Frequently Asked Questions

How long should an SOP be?

As short as the task allows. Length is not a quality signal, and padding a document to look thorough makes it less likely anyone reads it to the end. If your SOP runs past a few pages, check whether you are documenting more than one task.

Who should write the SOP, the manager or the person doing the job?

Usually a collaboration. The person doing the job supplies the reality, and someone else writes it up, because people are often too close to a task to notice what they do automatically. If the person doing the work writes it alone, have someone else test it.

Do SOPs need formal approval or signatures?

In regulated industries, yes, and the requirements are set by your standard. For most teams a lighter review works fine, one factual check from whoever owns the process, plus a recorded approval date so people know the document is current.

Should I record a video instead of writing an SOP?

Video works well for showing an interface, and badly for everything else. You cannot search it, skim it, or update one step without re-recording. The strongest approach is a written SOP with a short video embedded where seeing the screen genuinely helps.

What if the process changes too often to document?

Document the parts that are stable and keep the volatile details in one clearly marked section you can update quickly. A process that changes constantly usually still has a fixed backbone. If it genuinely does not, a checklist may serve you better than a full procedure.

Does a small team really need SOPs?

Small teams benefit most, because the risk is concentrated. When four people run everything, one person leaving takes a large share of your operating knowledge with them. Start with the two or three tasks only one person knows how to do.

Start With One Procedure

Do not try to document everything at once. That project stalls, every time.

Pick the one task that only one person knows how to do, and write that SOP this week. Test it on someone else. Then pick the next one.

Within a few months you will have covered the procedures that actually matter, and the knowledge that used to live in people’s heads will live somewhere your whole team can reach.