How to Write an SOP: The 7-Step Process Teams Actually Follow

To write an SOP, pick one repeating task, interview the person who does it best, list every step in order, write each step as one short action in plain language, add checklists or photos where words fall short, test the draft with someone new, then approve it and set a review date.

By Julian Vance

Before You Write: The Mindset

Most bad SOPs are not written badly. They are written with the wrong mindset. The author sits at a desk, imagines the task, and types up what seems logical. The result reads well and works poorly, because the real task has quirks the desk never sees.

The right mindset is humble and curious. You are not documenting your opinion of how the work should go. You are capturing how the best practitioner actually does it, then cleaning it up so others can repeat it. The people who do the work are your experts. Your job is to listen, organize, and write clearly.

Three principles guide everything below:

1. Write for the new hire, not the expert. The expert does not need the SOP. The person on day three does.
2. Short beats thorough. A SOP people read beats a perfect SOP nobody opens.
3. Done is a draft. Every SOP improves after real use. Ship version one, then refine.

If you are new to the topic, start with what is an SOP for the full definition, or what is a SOP for the practical view. This guide assumes you know what an SOP is and are ready to create one.

What a Finished SOP Looks Like

Before writing, know your destination. A complete SOP usually contains these sections:

• Title and document code. A clear name plus a tracking code like SOP-OPS-014.
• Purpose. One or two sentences on why this SOP exists.
• Scope. Who follows it, and which situations it covers.
• Roles and responsibilities. Who does what, often in a small table.
• Materials and tools. Everything needed before starting.
• The procedure. Numbered steps, one action each, in order.
• Safety notes. Warnings placed before the risky step.
• References. Related documents or forms.
• Revision history. What changed, when, and who approved it.

You do not need every section for every SOP. A one-page procedure for a simple task might carry just the title, steps, and a safety note. Match the structure to the risk: the costlier the mistake, the more complete the document.

The 7-Step Writing Process

Step 1: Choose the Right Process

Do not start with the hardest process or the most political one. Start where success is likely and the payoff is fast. Pick a task that passes three tests:

• It repeats. Daily or weekly tasks give the fastest return on writing time.
• It varies. If everyone already does it the same way, there is nothing to standardize. Look for tasks done three different ways by three different people.
• Mistakes cost something. Prioritize work where errors lose money, upset customers, or create safety risks.

Write the task as one sentence before you go further: "This SOP covers how we close the store at night." If you cannot state it in one sentence, the scope is too wide. Split it.

Common first SOPs: opening and closing checklists, customer refund handling, new-hire onboarding, equipment cleaning, order packing. For business-specific guidance on choosing, see SOP meaning in business.

Step 2: Talk to the People Who Do the Work

This step decides whether your SOP lives or dies. Find the person who does the task best, not the manager who oversees it, and watch them work. Then ask questions:

• Walk me through what you do, start to finish.
• What do you check before you begin?
• Where do people usually go wrong with this?
• What would you tell a new person on their first day?
• Has anything about this task changed recently?

Take notes in their words. You will notice things no manual mentions: the drawer that sticks, the customer type that needs extra patience, the gauge that reads slightly off. These details are the difference between a SOP that works on paper and one that works in reality.

If several people do the task, talk to two or three. Where they agree, you have the standard. Where they differ, you have a decision to make: pick the better method, or ask the team lead to choose. Write down why you chose it. That note prevents the argument from reopening every six months.

Step 3: Map Every Step in Order

Before writing sentences, map the flow. List every action in sequence, from the trigger that starts the task to the finished result. A simple numbered list on paper works. For tasks with decisions ("if the customer has no receipt, then..."), sketch a small flowchart with yes/no branches.

Check your map for three common gaps:

• Missing first steps. Authors often start at the interesting middle. Capture the setup: what to gather, what to check, what to put on.
• Missing checks. Where should the worker verify something before continuing? Mark those points. A missed check early becomes a failure late.
• Missing end. Define what "done" looks like. The task is not finished when the steps stop; it is finished when the result meets the standard. Write that standard down.

Show the map to your expert from Step 2. Ask: "Is anything missing? Anything out of order?" Fix it now, while changes are cheap. Rewriting a map takes minutes. Rewriting a finished document takes hours.

Step 4: Write in Plain, Short Language

Now turn the map into prose. The rules are strict and simple:

• One action per step. "Open the valve, wait for the green light, then record the reading" is three steps wearing a trench coat. Split them.
• Start steps with verbs. Open. Enter. Verify. Record. Call. Verbs tell the reader what to do without decoding.
• Keep sentences short. If a step needs more than two lines, it is probably two steps.
• Name exact things. Not "the form" but "the refund form (Form R-12)." Not "clean it" but "wipe with a damp cloth until no residue remains."
• Explain jargon on first use. If the task involves a technical term, define it briefly the first time it appears. Never assume the new hire knows it.
• Write warnings before the risky step. "Warning: the surface is hot" belongs directly above the step where someone touches it, not in a safety section at the end.

Read each step and ask: could a smart new hire do exactly this without asking a question? If not, rewrite. Vague words are the enemy: replace "ensure," "handle," "process," and "manage" with the actual physical action.

Tone matters too. Write like a calm instructor, not a lawyer. "Record the temperature in the log" beats "The operator shall ensure that temperature data is duly recorded in the designated logbook." Same meaning, half the words, twice the clarity.

Step 5: Add Checklists and Visuals

Words have limits. Some things are better shown than described. This step upgrades your draft from readable to usable.

Checklists belong at natural pause points: before starting (do I have everything?), at the handoff (did I complete my part?), and at the end (is the result correct?). A closing checklist for a retail store might read: register counted and logged, displays straightened, back door locked, alarm set, lights off. Five boxes, thirty seconds, zero forgotten tasks.

Photos and diagrams earn their place wherever words get clumsy. A photo of a correctly loaded dishwasher rack beats three paragraphs describing it. A diagram of where the fire extinguisher hangs beats "located near the exit." Use your phone camera freely. Label each image with what it shows and circle the important part if it is not obvious.

Tables help when a step varies by situation. A cleaning SOP might include a small table: surface type in one column, cleaner to use in the next, dwell time in the third. Tables let the reader find their row and act, instead of hunting through paragraphs.

Flowcharts suit tasks with branches. Keep them simple: boxes for actions, diamonds for decisions, arrows for flow. If the chart needs more than about ten boxes, the process probably needs two SOPs.

One caution: visuals support the steps; they do not replace them. Every photo needs a caption tying it to a step number. Every checklist item needs a matching step in the procedure. Orphan visuals confuse more than they help.

Step 6: Test With a Real User

This is the step most writers skip, and it is the step that matters most. Find someone who knows the general job but has not seen your draft. Ideally, a newer team member. Hand them the SOP and watch them follow it. Do not help. Do not explain. Just watch and take notes.

You are looking for three things:

1. Where they hesitate. Hesitation means the step is unclear. Rewrite it.
2. Where they ask questions. Each question is a gap in the document. Add the answer to the SOP.
3. Where they do something different from the SOP. Either they found a better way (update the SOP) or the SOP misled them (fix the SOP).

Run the test with two people if you can. One test catches the big problems; the second catches the ones the first person worked around silently. Thank your testers and credit them. People who help test an SOP become its first champions.

If testing reveals the process itself is broken, say so. A SOP cannot fix a bad process; it can only document it faithfully. Sometimes the right outcome of Step 6 is "we need to redesign this workflow first." That is a win, not a failure.

Step 7: Approve, Publish, and Schedule Reviews

A tested draft is not yet a standard. It needs authority behind it.

Approve. Have the responsible manager or team lead review and sign off. The approval says: this is now the official way. Keep the approval light: a signature and date, or an electronic approval in your document system. Heavy approval committees slow everything down and add little.

Publish. Put the SOP where the work happens, in the format people will actually use. Digital master copy in the shared system, plus printed copies at workstations for physical tasks. Announce it briefly to the affected team: what changed, why, and where to find it. Train the team following the pattern in our guide to what are SOPs: introduce, demonstrate, practice, confirm, reinforce.

Retire the old way. If an older version or an informal cheat sheet exists, remove it. Two versions of the truth will split the team within weeks.

Schedule the review. Every SOP gets a review date, usually twelve months out, sooner for high-risk procedures. Put it on a calendar with the owner's name attached. Also define change triggers: new equipment, new software, new regulations, or a repeated error should prompt an update before the scheduled review. For the full picture on keeping documents alive, see the review section of what are SOPs.

10 Mistakes That Ruin SOPs

Learn from the failures of others. Here are the ten killers, and the fix for each:

Mistake	Why It Kills the SOP	The Fix
Written without the workers	Misses real-world detail	Interview and observe the experts (Step 2)
Too long	Nobody reads it	One action per step; split big tasks
Vague language	Readers guess, and guess wrong	Verbs, exact names, short sentences
No owner	Nobody keeps it current	Name an owner and a review date
Hidden storage	Cannot be found in seconds	Publish where the work happens
Never tested	Looks fine, fails in practice	Test with a real user (Step 6)
No version control	Old copies circulate	Number versions; retire old ones
Warnings at the end	Read after the injury	Warnings before the risky step
Written once, never reviewed	Becomes fiction within a year	Annual review plus change triggers
Tries to cover everything	Bloated and unfocused	One task per SOP; link related ones

If your existing SOPs suffer from several of these, do not patch them one by one. Rewrite the worst offender using the seven steps above, and let the improvement sell the method to the team.

Templates That Save You Hours

A blank page is the slowest place to start. These templates give you the structure so you can focus on the content:

• Standard operating procedure template: the all-purpose starting point with every standard section.
• SOP template: a leaner format for straightforward tasks that do not need the full structure.
• Work instruction template: for the task-level detail that sits under an SOP. See SOP vs work instruction if you are unsure which level you need.
• Employee onboarding SOP template: the classic first SOP for growing teams, covering the full first-week sequence.
• Quality management SOP template: for procedures that support audits and quality systems.
• Restaurant opening checklist template: a checklist-format example from food service you can adapt to any opening routine.

Pick the closest match, replace the sample content with your own steps, and run it through Steps 6 and 7. A template handles the formatting. The seven steps handle the quality.

Keep Learning: The Full SOP Library

This guide is the hub. These companions go deeper on each piece:

• What is an SOP: the complete definition, history, and types.
• What is a SOP: the practical view, with industry examples and signs you need one.
• What are SOPs: how collections of SOPs work as a managed system.
• What does SOP stand for: the meaning behind each word in the term.
• SOP acronym meaning: a decoder for SOP and the abbreviations around it.
• SOP meaning in business: why companies run on procedures, from startups to enterprises.
• SOP vs work instruction: the comparison that settles which document you need.

Frequently Asked Questions

How long does it take to write an SOP?

A simple one-page SOP takes a few hours including testing. A complex multi-role procedure can take several days across interviews, drafting, and two rounds of testing. Templates cut the formatting time; the thinking time is the real cost.

Who should write an SOP?

The person closest to the work should supply the content, usually through interviews and observation. A supervisor or quality lead often does the actual writing and owns the final document. The worst author is someone who has never done the task.

How do I know if my SOP is good enough?

Hand it to someone new and watch them follow it without help. If they finish correctly with at most one or two questions, it is good enough to publish. Perfection comes from later revisions, not from longer drafting.

Should SOPs include pictures?

Yes, wherever words get clumsy. Photos of correct setups, diagrams of layouts, and screenshots of software steps all reduce misreading. Label every image and tie it to a step number.

How often should SOPs be reviewed?

At least once a year, and sooner when the process, tools, or rules change. Assign each SOP an owner and a review date so updates happen on schedule instead of by accident.

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

An SOP documents the whole process with roles and flow. A work instruction documents one task in exact detail. Write the SOP first, then add work instructions where steps need precision. Our SOP vs work instruction guide covers this fully.