SOP stands for standard operating procedure: a written set of steps for a task a team does again and again, so whoever does it gets the same result. A good SOP says who does the task, when it starts, what to do in order, and what “done” looks like.
SOP also stands for “statement of purpose,” the essay graduate programs ask applicants to write. This article is about the workplace kind.
Below are the common SOP formats, the parts every SOP has, and six short examples by team that you can adapt.
What an SOP is, and what it isn’t
An SOP describes one procedure from start to finish. It says who does each step, in what order, and how they know the step worked. It’s written for the person doing the work, who is often doing it for the first time.
Three other documents get mixed up with SOPs. They work together, but each one answers a different question.
| Document | What it answers | Example |
|---|---|---|
| Policy | What we must or must not do, and why | Refunds are allowed within 30 days of purchase |
| Process | What happens across teams, at a high level | Customer asks for a refund, support approves it, finance pays it |
| SOP | How one team carries out a procedure, step by step | How a support agent checks, approves and logs a refund request |
| Work instruction | How to do one task inside a step, in detail | How to issue a partial refund in the billing system |
Why teams write SOPs
An SOP usually gets written after a task goes wrong more than once. A step gets skipped, two people do it two different ways, or the one person who knows how is out sick.
- Consistency. The task comes out the same whoever does it. That matters most when a customer, an auditor or a payroll run depends on it.
- Faster onboarding. A new hire can follow the SOP instead of shadowing a colleague until they’ve seen every case.
- Fewer interruptions. The expert explains the task once, in writing, instead of every time someone asks.
- Safer handoffs. When someone leaves or changes roles, the procedure stays with the team.
- A baseline to improve. It’s hard to fix a process when nobody agrees on what it is today.
Common SOP formats and when to use each
No single SOP format is required. Pick the one that matches how the task really runs. Plenty of SOPs combine two, such as numbered steps with a short checklist at the end.
Step-by-step list
Numbered steps, one action each, with the expected result beside every step. It suits tasks that run in a straight line with few choices, like publishing a blog post or resetting a password. Most SOPs start here.
Hierarchical steps
Main steps with numbered sub-steps beneath them (3, 3.1, 3.2). Use it when a step carries detail that experienced people can skip and new people need. Month-end close and equipment setup often look like this.
Flowchart or decision tree
Boxes and arrows, or a series of yes-or-no questions. Use it when the next step depends on a condition: is the customer on a paid plan, is the amount over the approval limit. Keep a written version beside the diagram so people can search it and screen readers can read it.
Checklist
Items to tick off, with little or no explanation. Use it for tasks people already know how to do but can’t afford to skip a step of, like an end-of-day close. A checklist works best as a companion to a full SOP, because it assumes the reader already knows each step.
The parts of an SOP
Most SOPs share the same skeleton. These are the sections in our free SOP template, which you can copy and fill in. A short SOP can drop a section it doesn’t need, such as definitions.
- Header: title, SOP ID, version, effective date, next review date, and the owner and approver, named by role.
- Purpose: why the procedure exists, in a sentence or two.
- Scope: what it covers, what it doesn’t, when it starts and when it ends.
- Roles and responsibilities: each role that touches the procedure and what it’s responsible for.
- Definitions: any term or acronym a new teammate wouldn’t know.
- Before you start: the access, tools and inputs needed before step one.
- Procedure: numbered steps, each with who does it and the expected result.
- Decision points and exceptions: the “if this, then that” branches, and when to stop and escalate.
- Records: what to record, where it’s kept and for how long.
- Related documents and recordings: work instructions, forms, screenshots or short videos that explain a step.
- Revision history: each version, its date, what changed and who approved it.
Six SOP examples by team
These are short, fictional examples for a generic company. Each one gives the owner, the trigger, the result that means the procedure is done, and the steps in between. A real SOP adds the header, scope and exceptions; the template has room for those.
IT: set up a new employee’s laptop
Owner: IT technician. Starts when HR confirms a start date. Expected result: the new hire signs in on day one and email, chat and VPN all work.
- Enroll the laptop in device management and check that it shows as enrolled.
- Apply the standard image for the operating system.
- Install the apps listed in the onboarding ticket and open each one once.
- Turn on disk encryption and check that the status reads “On.”
- Create the user account and send the setup link.
- On day one, sign in with the new hire and test email, chat and VPN.
Support: handle a refund request
Owner: support agent. Starts when a customer asks for a refund. Expected result: the customer has a reply, and the refund is issued or declined with the reason logged.
- Find the order and check its date against the refund window in the policy.
- If it’s inside the window and under the agent approval limit, approve it. If not, assign the ticket to a team lead.
- Issue the refund in the billing system and paste the transaction ID into the ticket.
- Reply to the customer with the amount and when to expect it.
- Tag the ticket with the refund reason so the monthly report counts it.
HR: run a new hire’s first week
Owner: people operations coordinator. Starts the Friday before the start date. Expected result: by Friday of week one, the new hire has met their manager and buddy, finished required training and has a 30-day plan.
- Send the welcome email with the start time, the address or video link, and who to ask for.
- Confirm with IT that the laptop and accounts are ready.
- On day one, walk through the handbook, benefits enrollment and payroll forms.
- Book meetings with the manager and an onboarding buddy in the first two days.
- Assign the required training and check completion on day five.
- Hold a short end-of-week check-in and log any questions that need follow-up.
Finance: approve an expense report
Owner: finance analyst. Starts when an employee submits a report. Expected result: the report is approved and queued for payment, or returned with a reason.
- Check that every line has a receipt and a category.
- Compare each amount with the limits in the expense policy.
- If a line is over the limit, return the report and name the line and the reason.
- Confirm the employee’s manager has approved it in the expense tool.
- Approve the report and add it to the next payment run.
Marketing: publish a blog post
Owner: content editor. Starts when a draft is marked ready for review. Expected result: the post is live, linked from at least one related page, and scheduled on the planned channels.
- Edit the draft against the style guide and check that every link opens.
- Add the title tag, meta description, featured image and alt text.
- Preview the post on a desktop and on a phone.
- Publish, then open the live URL in a private window to confirm it loads.
- Link to the post from a related page and schedule the social posts.
Operations: end-of-day close
Owner: shift lead. Starts 15 minutes before closing time. Expected result: the site is locked, the alarm is set and the closing log is filled in.
- Check that every workstation is logged out and shared equipment is off.
- Count the cash drawer, or confirm the day’s card totals match the sales report.
- Walk the space and lock the windows and side doors.
- Set the alarm and lock the main door.
- Fill in the closing log with the time, the totals and anything the morning shift needs to know.
How to keep SOPs current
An SOP that describes last year’s tool can be worse than none, because people follow it and get stuck. A few habits keep them accurate.
- Put the next review date at the top, where readers see it. Six or twelve months is common.
- Review early when the tool, the team or a rule changes. Don’t wait for the date.
- Give each SOP one owner, by role, who approves changes.
- Keep a revision history with the date, what changed and who approved it.
- Ask the people who do the task to flag any step that no longer matches the screen. They notice first.
- Keep SOPs in one place people already search, and link to them from where the work starts, like the ticket form or the onboarding checklist.
Record it instead of writing it
Some steps take a paragraph to describe and ten seconds to show: a settings screen, a menu three levels deep, a field that only appears after you change another one. For software tasks, a recording is often the fastest first draft of an SOP.
Record the process once with Zight and it drafts a step-by-step guide with screenshots from the recording. You review it, add the owner, scope and exceptions, and share it as a link. Turn a screen recording into an SOP draft. AI drafting is plan-based: Create includes 5 AI smart actions a month, and Collaborate and up are unlimited (compare plans).
If someone else knows the process best, send them a request link. They record their screen in the browser, with no Zight account and nothing to install, and Zight can draft the guide from the recording they send back.
Write your first SOP
Pick one task that goes wrong or gets asked about often, and start there. Our guide to writing an SOP in 8 steps walks through it, from watching the person who does the task to testing the draft with someone new.
For a ready structure, copy the free SOP template. If the procedure is a support handoff, the customer service SOP template is a closer fit.
Frequently asked questions
What does SOP stand for?
At work, SOP stands for standard operating procedure: written, step-by-step instructions for a recurring task. In university admissions, SOP means statement of purpose, a personal essay, which is a different document.
What is an example of an SOP?
A support team’s refund procedure is a typical SOP: check the order against the refund window, approve it or escalate it based on the amount, issue the refund, reply to the customer and log the reason. Each step has one owner and a result you can check.
What format should an SOP use?
Use numbered steps for a task that runs in a straight line, hierarchical steps when steps need sub-steps, a flowchart when the next step depends on a condition, and a checklist when people know the task and mustn’t skip anything. Many SOPs pair numbered steps with a short checklist.
What’s the difference between an SOP and a work instruction?
An SOP covers a whole procedure: who does what, in what order, and when to escalate. A work instruction covers one task inside a step in more detail, such as how to issue a partial refund in a specific tool. SOPs often link to work instructions from the step they belong to.
How long should an SOP be?
As long as the procedure needs, and no longer. Many fit on a page or two. If an SOP grows past a dozen or so steps, check whether it’s really two procedures with different triggers, and split it.
Who writes SOPs?
Usually the person who does the task, or someone who watches them do it, with the team lead or process owner approving the result. The owner named on the SOP keeps it current after it’s published.