An SOP is not a manual. It's not a philosophy. It's a single process written so clearly that a new person can execute it without asking questions.
Most people get this wrong. They write 50 pages on "how our company does things" and call it an SOP. Then they're frustrated when the new hire reads it and still asks the same question three times.
This guide shows you how to write an SOP that actually gets used—and what separates a usable SOP from a document that sits on a shelf.
What Is an SOP, Actually?
A Standard Operating Procedure is a written record of one specific process. Not a role. Not a system. One process.
Examples of processes: - How to respond to a new customer email - How to process a refund request - How to onboard a new contractor - How to run the weekly standup - How to deploy code to production - How to submit an expense report
Examples of what's NOT a process (don't write these as SOPs): - "How to be a customer service manager" (that's a role, not a process) - "Our customer service philosophy" (that's culture, not a process) - "All the things the sales team does" (that's 10-20 processes, not one)
One process = one SOP.
Why? Because one process can be executed by anyone. A process is mechanical—input goes in, output comes out. If you write a process clearly enough, the outcome is predictable regardless of who executes it.
The Six-Field SOP Structure
Every SOP should have six fields. This is the structure that works.
1. Name What is this process?
Examples: - "Respond to a new customer inquiry email" - "Process a refund request" - "Approve and book a contractor" - "Deploy a hotfix to production"
Make it a gerund phrase (ending in -ing). Specific, not vague.
Don't write: "Customer email." Write: "Respond to a new customer inquiry email."
2. Owner Who owns this process? Who do you ask if something goes wrong? Who decides if the process needs to change?
Usually a job title: "Head of Customer Service," "Finance Manager," "Engineering Lead."
Not always the person who executes it. A junior customer service rep might execute the process, but the Head of Customer Service owns it.
3. Trigger When does this process start?
Examples: - "When a customer submits a support request through the website form" - "When a customer requests a refund via email" - "When we receive a timesheet from a contractor" - "When a critical bug is reported in production Slack"
Be specific about the signal. Don't write "whenever." Write the exact condition.
4. Steps Here's the meat. Step-by-step instructions for executing the process.
This section has rules (see below). Follow them.
5. Output What does the world look like when this process is done?
Examples: - "Customer receives an email response and is added to the support queue" - "Refund is issued and customer receives confirmation email" - "Contractor is in the Guidepoint system and has signed the agreement" - "Hotfix is deployed to production and tagged with version number"
Describe the state, not the effort. "Output: the contract is signed and filed" not "Output: you've worked hard."
6. Exceptions What if something weird happens?
Examples: - "If the customer is asking about a billing issue, forward to Finance Manager." - "If the refund amount is over $500, get approval from the owner before processing." - "If the contractor already exists in the system, skip the creation step and go to step 6." - "If the hotfix fails tests, roll back immediately and notify the team in #incidents."
Don't try to cover every possible edge case—just the ones that happen regularly. If it's happened more than once, it gets an exception.
How to Write Steps That Actually Work
This is where most SOPs fail.
Rule 1: Use imperative verbs (command voice).
Don't write: "The customer service rep might want to check the ticket system." Write: "Open the ticket system and search for the customer name."
Imperative is clear. It doesn't leave room for interpretation.
Rule 2: One action per step.
Don't write: "Log into the system, find the order, and check the status." Write: 1. Log into the system. 2. Search for the order using the customer email. 3. Check the current status.
One action, one line, one line number. If someone gets stuck, they can say "I'm stuck at step 3" instead of "I'm stuck somewhere in that big sentence."
Rule 3: Include decision points.
Some steps have branches. Write them clearly.
``` 4. Check the status. - If status is "pending," proceed to step 5. - If status is "shipped," send the tracking link (step 7). - If status is "cancelled," check the refund status (step 8). ```
Rule 4: Link to templates and tools.
Don't write: "Send a helpful email response." Write: "Send the email using the [New Customer Template](link to Google Doc). Personalize the greeting with their first name."
One template = one source of truth. If you need to change the wording later, you change it once.
Rule 5: Be stupidly specific.
Don't write: "Add the contact to the CRM." Write: "Open HubSpot. Click 'Contacts.' Click 'Add Contact.' Fill in: First Name, Last Name, Email, Phone (if provided), Company. Set the source to 'Website Form.' Click 'Save.'"
I mean it. Stupid specific. Imagine the person has never seen the software before. Where do they click first?
Rule 6: Include time estimates.
``` Step 2: Review the customer's order history. (2 minutes) Step 4: Process the refund. (5 minutes) Step 6: Send confirmation email. (1 minute) ```
This helps people know if they're on track. If step 4 is taking 15 minutes and the estimate is 5, something is wrong.
Rule 7: No ambiguous words.
Avoid: "soon," "quickly," "efficiently," "properly," "as needed."
Write: "Respond within 2 hours," "complete in under 10 minutes," "using the template in the shared drive," "if the amount is over $500."
An SOP Example
Here's a real, usable SOP. Use this as your template.
---
Name: Respond to a new customer inquiry email
Owner: Head of Customer Service
Trigger: A new email arrives in the support inbox with the subject "New Customer Inquiry" and the sender is not in the CRM.
Steps:
1. Open the shared inbox. (30 seconds) 2. Search the CRM for the sender's email address. (1 minute) - If the email exists: skip to step 8. - If the email does not exist: proceed to step 3. 3. Create a new contact in the CRM. - Click "Add Contact" - Enter: First name, last name, company (if mentioned), email address. - Set source to "Inbound Email." - Click "Save." (2 minutes) 4. Open the [New Inquiry Response Template](link). (30 seconds) 5. Replace [Name] with their first name and [Question] with a one-sentence summary of their question. (1 minute) 6. Copy the response text. 7. Reply to their email and paste the response. (1 minute) 8. Add the email thread to the "Follow Up" label. 9. If no response within 48 hours, you will receive an automatic reminder to follow up.
Output: Customer has received an acknowledgment email, their contact is in the CRM, and the thread is tagged for follow-up.
Exceptions: - If the email is a billing question, forward to Finance Manager at finance@company.com instead of responding. - If the email is abusive or spam, add to "Spam" label and mark as resolved. - If the customer is a known account, forward to their account manager instead.
---
That's an SOP. It's specific, repeatable, and a new person could execute it on day one.
Common SOP Writing Mistakes
Mistake 1: Writing a how-to manual, not a process. You wrote 30 pages on "everything you need to know." You needed one SOP for one process.
Fix: Break it into separate SOPs. One for "Respond to billing questions." One for "Respond to technical questions." One for "Escalate to a manager."
Mistake 2: Assuming knowledge. "Then you'll want to check the system and handle it from there."
Nobody knows what "the system" is. Nobody knows what "handle it" means. You've written nothing.
Fix: Spell it out. "Log into Jira. Click the 'Unresolved' filter. Find the ticket matching the customer name. Click 'Assign to Me.' Fill in the response field and click 'Post.' Change the status to 'Waiting on Customer.'"
Mistake 3: Including opinions. "It's important to be professional" or "Remember to prioritize quality."
That's culture, not process. If it's important enough to be in the SOP, it's a step.
Fix: Remove it or make it a step. "Send a response within 2 hours" (speed + professionalism as a constraint). "Use the Quality Checklist before submitting" (makes quality concrete).
Mistake 4: The SOP is too long. If your SOP is longer than 2 pages, it's probably 3-5 different processes jammed together.
Fix: Split it. "How to respond to a billing question" is one SOP. "How to escalate a complaint" is another. "How to process a refund" is a third.
Mistake 5: Nobody uses it. You wrote a beautiful SOP and nobody reads it.
This usually means: - The SOP is wrong (doesn't match what you actually do). - The SOP is ignored (nobody knew it existed). - The SOP is inaccessible (filed in the wrong place, hard to search).
Fix: Post it where people look. A shared Google folder, a wiki, or a doc linked from Slack. Tag it with searchable keywords. After you write it, watch someone execute it once and ask: "Did this help? Was anything confusing?" Update based on feedback.
How to Get Your Team to Actually Use SOPs
Writing the SOP is 20% of the work. Getting people to use it is 80%.
1. Start with one. Don't write 20 SOPs and expect adoption. Write one. Get it right. Use it. Then add more.
2. Make it searchable. If someone needs to know "how to process a refund," they should find it in 5 seconds. Tag it: "refund, money, customer service." Include the keywords in the doc title.
3. Review it quarterly. Processes change. An SOP from two years ago might be wrong. Every quarter, ask the person who executes it: "Is this still accurate?" Update if needed.
4. Tie it to hiring. When you onboard someone, make SOPs their first resource. "Here's what you need to do. Here's the SOP. Try it, then ask me if you're stuck." This trains people to use SOPs instead of asking you directly.
5. Use it as a management tool. If someone isn't following the SOP, that's a coaching conversation. "I noticed you're doing step 4 differently. The SOP says X. What's the reason?" This either improves the process (maybe their way is better) or improves the execution (maybe they didn't know).
The Next Level: A Documentation System
If you're serious about scaling, you need more than scattered SOPs.
*The Documentation Standard* by Tanta Holdings covers: how to organize SOPs across your company, how to build a wiki that people actually use, how to decide what to document and what not to, and how to keep docs updated without it becoming a second job.
It includes templates, examples, and a documentation audit to find gaps in your current system.
Grab it on [Amazon](https://www.amazon.com/dp/B0FJ5D7L17).
Or if you want to build your documentation system from scratch with someone who's done it before, [let's talk](https://tantaholdings.com/consulting). We can audit what you have, design the structure, and write the first batch of SOPs with your team.
Bottom Line
An SOP is a process written clearly enough that someone new can execute it without asking questions. Use the six-field structure. Write imperative steps. Be stupidly specific. Test it with someone who's never done it before. Then update based on what they get stuck on.
One good SOP beats 50 half-written manuals. Start with one today.
---
Related reading: - [How to Write Standard Operating Procedures for Small Business](https://tantaholdings.com/blog/how-to-write-standard-operating-procedures-small-business) - [How to Get Employees to Document Their Work](https://tantaholdings.com/blog/how-to-get-employees-to-document-their-work) - [Delegation Skills for Managers](https://tantaholdings.com/blog/delegation-skills-for-managers) - [Virtual Assistant Tasks List for Business Owners](https://tantaholdings.com/blog/virtual-assistant-tasks-list-for-business-owners)