12 SOP Examples for Teams That Get Followed

Here's a test. Walk over to the newest person on your team and ask them to refund a customer, onboard a new hire, or push code to staging. Then watch what they do.

If they open a document and follow it, you have a working SOP. If they ping someone on Slack, dig through an old email, or just guess, you have a document that exists but doesn't work. That gap is where most teams live.

We've read a lot of standard operating procedures. The good ones share a few traits. The bad ones share one big one: nobody actually uses them. So instead of another lecture on why SOPs matter, we're going to show you 12 concrete SOP examples across real teams, hand you a template you can paste and edit today, and point out the mistakes that quietly turn a good procedure into shelf decoration.

What makes an SOP get followed

A standard operating procedure is just the agreed-on way to do a repeatable task. That's it. The fancy definitions don't help you. What helps is knowing why some get followed and some don't.

The SOP examples that stick tend to do four things:

• They're written for the moment of need. Not for an audit, not for a manager's peace of mind. For the person doing the task right now, often in a hurry.
• They're short and scannable. Numbered steps, one action per step, no walls of text. If someone has to read a paragraph to find the next click, they'll stop reading.
• They show, not just tell. A screenshot of the right button beats three sentences describing where the button is.
• They have an owner and a date. Someone's name is on it. There's a "last reviewed" line. Without that, every SOP rots.

Keep those four in mind as you read the examples. They're the difference between a procedure and a paperweight.

12 SOP examples by team

These are grouped by function so you can jump to what's relevant. Each one includes the trigger (when it runs), the core steps, and the format we'd actually use. Adapt freely.

Customer support and success

1. Issuing a refund. Trigger: a customer requests money back. Steps: verify the order, check it against the refund policy, choose full or partial, process in the billing tool, log the reason, send a confirmation email. The reason-logging step is the one people skip, and it's the one your finance team will beg for later.

2. Escalating a ticket. Trigger: an agent can't resolve something in two replies. This one is a decision tree more than a list. Is it a bug? Route to engineering. A billing dispute? Route to finance. Angry VIP? Loop in a manager. A flowchart here saves more time than prose ever will.

3. Onboarding a new customer. Trigger: a deal closes. Steps: send the welcome email, schedule the kickoff call, set up their account, share login details, book the 30-day check-in. The trap is treating this as a sales handoff instead of a checklist the CS rep owns end to end.

HR and people ops

4. Employee onboarding (first week). Trigger: a signed offer. This is the SOP everyone has and almost nobody keeps current. Steps: create accounts before day one, ship the laptop, assign a buddy, schedule the manager 1:1, walk through benefits, confirm payroll details. Split it into "before day one" and "week one" sections so nothing falls through.

5. Offboarding / departures. Trigger: a resignation or termination. This is the SOP that's a security risk when it's missing. Revoke access, recover hardware, run the exit interview, handle the final paycheck, transfer ownership of files and accounts. Treat the access-revocation step as time-sensitive, not a nice-to-have.

6. Handling a PTO request. Trigger: a time-off request lands. Short and sweet: check team coverage, approve or decline in the HR tool, update the shared calendar, confirm with the employee. The kind of thing that feels too simple to document until two people take the same week off.

Marketing and content

7. Publishing a blog post. Trigger: a draft is approved. Steps: run the SEO check, add alt text, set the meta description, schedule social posts, publish, then QA the live URL on mobile. That last step is the one most teams forget, and it's why broken links go live on a Friday afternoon.

8. Launching an email campaign. Trigger: a campaign is ready. Steps: build the segment, write subject lines, send a test to yourself, check links and unsubscribe, schedule, then monitor the first hour. A test-send step has saved more careers than any QA tool.

Sales and revenue

9. Qualifying an inbound lead. Trigger: a form fill or demo request. A scoring checklist works best here: budget, authority, need, timeline. If three of four are yes, book a call. If not, drop them into nurture. Clear rules beat gut feel, especially when the rep is new.

10. Logging a deal in the CRM. Trigger: any meaningful sales conversation. Steps: create or update the contact, set the stage, log next steps, set a follow-up date. Boring? Yes. But a CRM that's half-filled is worse than no CRM, and this SOP is the only thing standing between you and that mess.

IT, ops, and engineering

11. Deploying to production. Trigger: an approved release. Steps: confirm tests pass, get the second approval, run the deploy, watch the dashboards for ten minutes, post in the team channel, and document the rollback steps before you push. The rollback plan is the part people write only after they've needed it once.

12. Onboarding a new laptop / device. Trigger: a new hire or a replacement machine. Steps: image the device, install the standard app set, configure VPN and SSO, enable disk encryption, hand off with a quick walkthrough. Encryption is the step auditors check first, so don't bury it.

A copy-paste SOP template you can adapt

You don't need software to start. You need a structure. Here's one we'd actually use. Copy it, fill in the five fields up top, and you've got a real SOP in about ten minutes.

The "Done when" and "If something goes wrong" sections are what separate a real SOP from a to-do list. A to-do list ends when you run out of steps. An SOP tells you what success looks like and what to do when it doesn't go to plan.

Formats: checklist, flowchart, or screenshots

The same procedure can be brilliant or useless depending on the format. Match the format to the shape of the task.

Use a checklist when the steps are linear

Most SOPs are checklists. Onboarding, publishing, refunds, deploys. If you do step one, then step two, then step three in order, a numbered list is your friend. People can scan it, check items off, and not lose their place.

Use a flowchart when there are decisions

The moment your SOP has more than one "if this, then that," a wall of text falls apart. Ticket escalation, lead routing, and incident response all branch. Draw the branches. A simple flowchart answers "what do I do in my situation" faster than any paragraph.

Use screenshots and video for anything in software

This is where most written SOPs quietly fail. You write "click Settings, then Integrations, then the API tab," and three months later the UI changes and your instructions point to a button that no longer exists. A picture of the actual screen, with the right spot circled, is worth far more than the words.

The catch is that capturing, cropping, annotating, and blurring screenshots by hand is tedious, so people don't bother. This is the one spot where a tool earns its keep. With WriteHow, you record yourself doing the task once and it turns the recording into a step-by-step guide with the screenshots, annotations, and auto-blur for sensitive data already done. It also translates into 50+ languages and publishes straight to Zendesk, Notion, Confluence, or GitBook, which matters more than it sounds when your SOPs live in four different places.

Common mistakes that kill SOPs

We've seen the same handful of failures over and over. Avoid these and you're ahead of most teams.

• No owner. "The team" owns it, which means no one does. Put a single name on every SOP. When it's wrong, everyone knows who to tell.
• Never reviewed. An SOP written 18 months ago for software that's changed three times is worse than nothing, because it teaches people the wrong thing with confidence. Add a review date and actually hit it.
• Written for the writer. The author knows the system, so they skip the "obvious" steps. To a new hire, nothing is obvious. Write for someone on their first day.
• Too long. If your SOP is three pages of prose, people will skim it once and never open it again. Cut ruthlessly. One action per step.
• Hidden where no one looks. The best SOP in the world is useless if it's buried in a folder three clicks deep. Put it where the work happens, and link to it from the tool people are already in.

The honest truth is that most SOPs don't fail because they're badly written. They fail because they're abandoned. Someone writes a great one, ships it, and never touches it again. Six months later it's out of date, people stop trusting it, and you're back to the new hire pinging Slack.

So pick one task this week. Use the template above. Add an owner and a review date. Capture the screenshots properly. Then put it where people actually work. One good, maintained SOP beats a folder of forgotten ones every time.