How to Write an SOP: Steps, Format, and Example

To write an SOP, pick one repeatable task, define its goal and scope, then talk to the people who actually do the work. Write each action as a numbered step in plain, direct language, add the roles responsible, and test the draft by running through it yourself. Finish by publishing the SOP somewhere your team can find it and setting a date to review it. That is the whole loop, and the rest of this guide walks each step in order.

A standard operating procedure is just a written set of instructions for getting a recurring task done the same way every time. The hard part is not the formatting, it is capturing what really happens instead of what you assume happens. If you want a fill-in structure to start from, grab our SOP template and follow the steps below to fill it with real content.

Companies that document their core processes onboard faster and lose less knowledge when people leave. The global SOP management solutions market is projected to reach $5.5 billion in 2026, growing at a 7.8% CAGR through 2033 (Persistence Market Research, 2026). That growth tracks a simple shift: teams are treating written procedures as infrastructure, not paperwork.

Key Takeaways

• An SOP captures one repeatable task so anyone can complete it the same way.
• The eight steps below run from defining scope to maintaining the document over time.
• The people who do the task are your best source, so interview them before you draft.
• Test every SOP by following it yourself, then have a new person try it.
• Publish SOPs somewhere searchable, or nobody finds them when they need them.

What is an SOP and why write one?

An SOP, or standard operating procedure, is a document that spells out exactly how to perform a specific task. Think employee onboarding, monthly invoice runs, or deploying a release. The point is consistency. When the steps live in one document, results stop depending on who happens to be in the room.

Without SOPs, knowledge stays trapped in a few heads. New hires repeat the same questions for weeks, mistakes recur, and a single person leaving can stall a whole workflow. A written procedure turns that tribal knowledge into something the team owns. For a broader view of what good operational docs look like across an organization, see our roundup of process documentation examples.

Step 1: Define the goal and scope

Start by naming the task and what a finished result looks like. Be narrow. "Onboard a new sales rep" is a workable scope; "handle all HR tasks" is not. One SOP should cover one process with a clear start and end point.

Then write down the boundaries. State what the procedure covers and, just as important, what it does not. A customer-refund SOP might handle approving and issuing refunds while explicitly excluding billing disputes. Clear limits keep the document focused and stop it from sprawling into territory another SOP should own.

Step 2: Choose a format that fits the task

The format should match how complex the task is and who reads it. Picking the wrong one buries simple steps in clutter or oversimplifies something that needs detail. Here are the four common options.

• Step-by-step list. Best for linear, routine tasks. Write each action in order using direct, imperative phrasing like "Open the dashboard" or "Click Submit."
• Hierarchical steps. For complex tasks with subtasks. Main steps break into substeps, so "Run user research" splits into prepare survey, interview users, analyze results.
• Flowchart. For processes with decision points or branching paths. A diagram shows the "if this, then that" logic better than paragraphs ever will.
• Checklist. For repetitive or compliance-heavy work where skipping a step causes real problems.

When unsure, default to the step-by-step list. Most internal SOPs are linear, and a numbered list is the easiest format for a new hire to follow without coaching.

Step 3: Identify who the SOP is for

Write for the actual reader, not for yourself. An SOP aimed at a brand-new hire needs more context, defined terms, and screenshots. One written for an experienced specialist can assume background knowledge and move faster.

Naming the audience also sets the right level of detail. If you assume too much, beginners get stuck. If you over-explain, experts skim and miss the parts that matter. Decide who reads this before you write a single step, and the level of detail mostly answers itself.

Step 4: Gather information from the people who do the task

This is the step most SOPs skip, and it is why so many of them are wrong. Sit with the person who performs the task and watch them do it, or have them narrate each action. What they actually do almost always differs from the official version in someone's head.

Interviewing the doers does two things. It surfaces the small, undocumented steps that keep the process working, and it gives those people a stake in the result. People follow procedures they helped write. Capture their exact clicks, the edge cases they handle on instinct, and the points where they pause to make a judgment call.

Step 5: Write the steps clearly

Now draft the procedure. Number each step, keep one main action per step, and write in active, imperative voice. "Export the report as CSV" beats "The report should be exported." Short sentences win because someone is reading this mid-task, not at leisure.

A clean step structure looks like this:

1. Open the billing dashboard and select the current month.
2. Click Generate Invoices and wait for the batch to complete.
3. Review the error log for any failed entries.
4. Export the approved batch as a CSV file.
5. Upload the CSV to the shared finance folder.

Add screenshots, short clips, or a diagram wherever words get clumsy. A visual of where a button lives saves more time than a paragraph describing it. If your task is granular and hands-on rather than process-level, a focused work instruction template may fit the detail better than a full SOP.

Step 6: Add roles and responsibilities

State who does what. For each step or section, name the role responsible, not the person. Use "inventory manager" rather than "Sarah," so the SOP survives staff changes without rewrites.

For procedures involving several people, a simple RACI note helps: who is Responsible for doing the work, who is Accountable for the outcome, who needs to be Consulted, and who is kept Informed. Many people can be responsible for parts of a task, but exactly one role should own the result. Clear ownership is what prevents the "I thought you had it" failures.

Step 7: Review and test it

A draft is a hypothesis. Test it by following your own SOP literally, doing only what the document says. The moment you stumble, hesitate, or fill a gap from memory, you have found a missing step. Fix it and run through again.

Then hand it to someone who has never done the task, ideally a recent hire. If they can complete the process from your document alone, the SOP works. If they get stuck, the document, not the person, needs the fix. This single test catches more problems than any amount of internal review. For procedures tied to a wider operational flow, map how the SOP connects to other steps using our guide to building a documentation workflow.

Step 8: Publish and maintain it

A finished SOP that nobody can find is no better than no SOP. Store it where the team already works and can search it, with a clear title, an owner, and a version date. Buried files in a random drive folder get ignored within a week.

This is where most procedures quietly die. SOPs scattered across docs, chat threads, and email become impossible to trust because nobody knows which version is current. Tools like Docsio turn scattered SOPs into a single branded, searchable site your team can actually find, so the latest version is always one search away. For practical patterns on keeping procedures discoverable across a company, see our guide to internal documentation.

Treat every SOP as a living document. Add a revision history, and update it whenever the tool, the team, or the policy changes. A quarterly review keeps procedures honest. An out-of-date SOP that tells people the wrong steps does more harm than no SOP at all.

A short SOP example

Here is a compact SOP that shows the structure in practice. Use it as a model for the level of detail to aim for.

SOP-014: Publish a Monthly Customer Newsletter
Version: 1.2  |  Owner: Marketing Lead  |  Last reviewed: 2026-06-01

Purpose: Send the monthly newsletter consistently and on schedule.
Scope: Covers drafting through send. Excludes campaign strategy and list growth.

Roles:
- Content Writer: drafts copy
- Marketing Lead: approves and schedules the send

Steps:
1. Draft the newsletter in the shared doc by the 25th.
2. Marketing Lead reviews and approves by the 27th.
3. Build the email in the platform from the approved doc.
4. Send a test to the internal list and check all links.
5. Schedule the send for the 1st at 9:00 AM local time.
6. Log the send date and open rate in the campaign tracker.

Exceptions: If a link test fails, fix and re-test before scheduling.

Can AI write an SOP for you?

AI can speed up the draft, especially the boring parts. Paste in a recorded walkthrough or rough notes and a model will structure them into numbered steps and a clean format. It handles the scaffolding, the consistent phrasing, and the first pass at a title and purpose.

What AI cannot do is know your actual process. It does not see the undocumented workaround your senior analyst uses or the edge case that breaks billing every December. Use AI to draft and format, then verify every step against reality with the people who do the task. Docsio's AI documentation generator can turn source material into a structured first draft fast, but the human review in step 7 is still what makes the SOP correct.

SOP writing checklist

Run a new SOP against this before you publish:

• The task is specific and has a clear start and end.
• Scope states what is covered and what is excluded.
• The intended reader is named, and detail matches their level.
• Steps came from the people who actually do the task.
• Each step is one action, numbered, in active voice.
• Roles are assigned by title, not by person.
• You followed the SOP yourself and fixed every gap.
• A new person completed the task from the document alone.
• It has a title, owner, and version date.
• It lives somewhere searchable with a review date set.

Frequently asked questions

What are the 5 steps of writing an SOP?

The core five are: define the goal and scope, gather information from the people who do the task, write the steps in clear order, assign roles and responsibilities, and review and test the draft. Many guides expand this to seven or eight steps by adding format choice and ongoing maintenance, but those five are the backbone of any usable SOP.

What is the format of an SOP?

A standard SOP format includes a title and ID, a purpose, the scope, roles and responsibilities, the numbered steps, and a revision history. The steps themselves can be a simple list, hierarchical steps with subtasks, a flowchart for branching paths, or a checklist. Match the format to how complex the task is and who reads it.

What does an SOP look like?

An SOP looks like a titled document with a short purpose statement, a defined scope, a list of roles, and numbered step-by-step instructions written in plain, direct language. Good ones include screenshots or diagrams for tricky steps and a version date at the top. The whole thing reads like a recipe a new hire could follow without asking questions.

How do I start writing my SOP?

Start by choosing one specific, repeatable task and writing down its goal in a single sentence. Then watch or interview the person who performs it today and capture every action they take, including the small undocumented ones. Those notes become your first draft, which you turn into numbered steps and then test.

Can ChatGPT write an SOP?

ChatGPT and similar tools can draft and format an SOP from notes or a recorded walkthrough, which saves real time. But AI does not know your actual process, its edge cases, or the workarounds your team relies on. Use it for the first draft, then verify every step with the people who do the work before you publish.

Putting it together

Writing an SOP comes down to a repeatable loop: scope one task, learn how it really gets done, write clear numbered steps, assign owners, test it on a real person, and keep it current. The steps are simple. The discipline is in capturing reality instead of assumptions and in publishing somewhere your team will actually look.

Start with one process that breaks most often when the wrong person handles it. Document that, test it, and ship it. Then do the next one. A library of trustworthy, searchable SOPs is built one tested procedure at a time, and it pays off every time someone new joins or someone experienced leaves.