Every team has processes that people do differently. One person skips a step, another adds their own twist, a third wasn't around when the process was last explained. The result: inconsistent output, repeated mistakes, and new hires who take weeks to get up to speed.
A standard operating procedure fixes this by putting the process on paper in a clear, repeatable format. But most SOPs sit unread in a shared drive because they were written badly: too vague, too long, or too disconnected from how the work actually gets done.
This guide walks you through how to write a standard operating procedure that your team will follow. Seven steps, no theory, just a practical framework you can use today. If you are new to SOPs entirely, start with our getting started with SOPs overview.
What Is a Standard Operating Procedure
A standard operating procedure (SOP) is a document that describes how to perform a specific process, step by step. It exists so that anyone with the right training can execute the process consistently, regardless of who originally designed it.
SOPs differ from other documentation types. A work instruction zooms into a single task within a process (see SOP vs work instructions for a detailed comparison). A checklist confirms that steps were completed. A process map shows the flow visually. An SOP combines all of these elements into one actionable document.
When You Need an SOP
Not every process needs formal documentation. Write an SOP when:
- People keep asking the same questions. If you explain the same process to different people every month, that process needs an SOP.
- Mistakes happen during handoffs. When a process involves multiple people or departments, the transitions between steps are where errors creep in.
- You're onboarding frequently. New hires should be able to learn critical processes independently, without shadowing someone for days.
- Compliance requires it. Regulations in healthcare, manufacturing, food service, and finance often mandate documented procedures.
- You're scaling. Opening a second location, adding a shift, or growing the team means the process needs to work without you in the room.
If none of these apply, informal documentation or a quick checklist might be enough.
How to Write a Standard Operating Procedure in 7 Steps
1. Define the Scope and Purpose
Before writing a single step, answer two questions:
What does this SOP cover? Be specific. "Customer returns" is too broad. "Processing an in-store return for defective products" is a clear scope.
Why does this SOP exist? State the purpose in one sentence. This helps readers quickly decide if they're looking at the right document.
Write the scope statement at the top of the SOP. It should include:
- The process name
- When this process is used
- Who is responsible for performing it
- Any prerequisites (access, tools, materials)
A clear scope prevents the two most common SOP problems: covering too much and covering too little.
2. Identify the Right People
The best SOP writer is the person who does the work every day. Not the manager who designed the process two years ago. Not the consultant who has never touched the actual system. The frontline worker.
Here's why: experts know the real process. They know which step the training manual skips, which workaround everyone uses, and where new people always get stuck. That knowledge is what makes an SOP useful.
If you're writing the SOP yourself, pull in at least one other person who performs the same process. You'll catch blind spots. If you're a manager documenting a team's process, sit with the person who does it and write together.
Identify three roles:
- Author: Does the work, writes the first draft
- Reviewer: Another person who performs the process, catches gaps
- Approver: Manager or quality lead who signs off
3. Map Out the Process
Before you start writing steps, map the process from beginning to end. You don't need fancy software. A numbered list on paper works fine.
Walk through the process in real time. If it's a digital process, open the application and click through each step while noting what you do. If it's a physical process, do it while recording yourself (or use Credia's Voice to SOP).
Capture:
- Every action, including the ones that feel obvious
- Decision points where the process branches
- Tools and systems used at each step
- Inputs (what you start with) and outputs (what the result should look like)
Don't worry about perfect wording yet. The goal is a complete list of everything that happens.
4. Write Each Step
Now turn your process map into clear, actionable steps. This is where most SOPs fail, so follow these rules:
Start every step with a verb. "Open the order management dashboard." "Enter the customer's order number." "Verify the shipping address." Verbs make steps actionable.
One action per step. Don't combine "Open the dashboard and enter the order number." Those are two steps. Splitting them makes the SOP easier to follow and harder to misinterpret.
Be specific. Replace vague language with exact details:
| Vague | Specific |
|---|---|
| Go to the settings | Navigate to Settings > Account > Billing |
| Fill in the required fields | Enter the customer's full name, email address, and phone number |
| Wait for approval | Wait for the status to change from "Pending" to "Approved" (typically 1-2 business days) |
Use consistent language. If you call it "the dashboard" in step 3, don't call it "the main screen" in step 7. Pick one term and stick with it throughout the document.
5. Add Supporting Details
Steps alone aren't always enough. Add these elements where they help:
- Warnings and cautions. Flag steps where a mistake could cause data loss, safety issues, or irreversible changes. Place the warning before the step, not after.
- Screenshots and images. A screenshot of the correct screen eliminates ambiguity. Annotate with arrows or highlights pointing to the relevant button or field.
- Expected results. After a step, describe what the user should see if they did it correctly. "A green confirmation banner appears at the top of the page."
- Notes and tips. Short pieces of context that help the reader understand why a step exists, or how to handle a common variation.
- Links to related documents. If a step references another process, link to its SOP instead of repeating the instructions.
Keep supporting details concise. They should clarify the steps, not overshadow them.
6. Test with Someone Unfamiliar
This is the step most teams skip, and it's the most important one.
Hand your finished SOP to someone who has never performed the process. Watch them follow it. Don't help. Don't explain. Just observe.
You'll immediately see:
- Steps they get confused by
- Assumptions you didn't realize you made
- Missing steps they can't figure out on their own
- Technical terms they don't understand
Every point of confusion is a flaw in the SOP, not a flaw in the tester. Fix it. Then test again if the changes were significant.
This step is what separates SOPs that people follow from SOPs that collect dust.
7. Publish and Assign Ownership
A finished SOP needs three things before it goes live:
- An owner. One person responsible for keeping the SOP current. When the process changes, this person updates the document.
- A review date. Set a quarterly review reminder. Even if nothing changed, the owner confirms the SOP is still accurate.
- A home. Store the SOP where people will actually find it. Link it from onboarding materials, pin it in relevant channels, and make sure it's searchable.
Publish once, then share actively. An SOP that nobody reads serves no purpose.
SOP Format Options
Not every process fits the same format. Choose based on complexity:
Step-by-step procedure is the most common format and works for the majority of processes. Linear, numbered steps with supporting details. Use this when the process must be followed in a specific order.
Checklist works for processes that people already know but need to verify completion. Think pre-flight checks, shift handovers, or quality inspections. More on this in our checklist glossary entry.
Flowchart works for processes with many decision points and branches. If your SOP has more than two or three "If X, then Y" conditions, a visual process map paired with a written procedure is often clearer than text alone.
Most teams use step-by-step procedures for 80% of their SOPs and checklists for the rest.
Common Mistakes to Avoid
Writing from memory. Always write the SOP while performing the process or immediately after. Memory skips steps and oversimplifies details.
Making it too long. If your SOP is over 25 steps, break it into smaller procedures that reference each other. Readers lose focus on long documents.
Using passive voice. "The form should be submitted" is weaker than "Submit the form." Passive voice creates ambiguity about who does the action.
Skipping the test. Every untested SOP has blind spots. Testing with a newcomer is the fastest way to find them.
Setting and forgetting. Processes change. If the SOP doesn't change with them, people will stop trusting it and go back to doing things their own way.
How Credia Makes It Faster
Writing SOPs from scratch is time-consuming. Credia gives you three faster paths:
Voice to SOP. Explain the process out loud while Credia records. The AI transcribes your explanation and structures it into formatted steps. Most people create a complete SOP in 5 to 10 minutes this way. See our voice-to-SOP best practices for tips on getting the cleanest output.
Screen to SOP. Record your screen while performing a digital process. Credia's AI analyzes the recording and generates a procedure with screenshots included automatically.
Manual Editor. Build the SOP step by step in a clean editor when you want full control from the start.
Whichever method you choose, the result is a searchable SOP inside your team's knowledge base, ready to share and easy to update. Browse our SOP templates for industry-specific starting points, or compare the best SOP software to find the right tool for your team.