How to Write an SOP in 8 Steps, With a Free Template

To write an SOP, pick one recurring task, watch the person who does it, and write each step as a single action with a result the reader can check. Add the decision points and when to escalate, test the draft with someone who has never done the task, then publish it with an owner, a version and a review date.

The eight steps below take you from a blank page to a published standard operating procedure. Each one says what to do and what to watch out for.

Quick answer: the 8 steps

Copy the free SOP template first and fill it in as you go. It has a section for each part below, plus a filled IT example.

1. Choose the process, who it’s for and who owns it.
2. Watch the person who does the task today.
3. List the roles and what someone needs before step one.
4. Write each step as one action with an expected result.
5. Add decision points and when to escalate.
6. Show the hard steps with screenshots or a recording.
7. Test the draft with someone who has never done the task.
8. Publish with a version, an approval and a review date.

Step 1: Choose the process, who it’s for and who owns it

Start with one task, not a department. “Process a refund request” is an SOP. “Support operations” is a handbook. Good first candidates are tasks that go wrong, get asked about often, or live in one person’s head.

Then decide who will read it. An SOP for a new hire explains more than one for a team that does the task daily. Write for the least experienced person who will follow it alone.

• Name the task with a verb: “Set up a new employee’s laptop.”
• Write where it starts and where it ends: the trigger and the finished state.
• Say what it doesn’t cover, so readers know when they need a different SOP.
• Name one owner by role, such as “IT support lead,” who keeps it current.

Step 2: Watch the person who does it

The person who does the task every day knows the shortcuts, the workarounds and the step everyone forgets. That knowledge rarely makes it into an SOP written from memory.

Sit with them, or have them share their screen, while they do the real task. Ask them to say what they’re doing and why. Note every system they open and every point where they stop to check something.

• Ask what usually goes wrong, and what they do when it does.
• Ask which steps they’d skip in a hurry, and why they shouldn’t.
• Record the session if they agree. A recording catches what notes miss, and you can replay a step instead of asking twice.

Step 3: List the roles and what someone needs first

Plenty of procedures fail before step one. The reader doesn’t have access, the form is somewhere else, or an approval hasn’t happened yet. Put all of that up front.

• Roles: each role that touches the task and what it’s responsible for. If two teams are involved, say who owns the handoff.
• Access: the systems, permissions and admin rights the reader needs.
• Inputs: the ticket, form, file or approval that has to exist before starting.
• Definitions: any term or acronym a new teammate wouldn’t know.

Step 4: Write each step as one action with an expected result

This is the core of the SOP. Number the steps, start each one with a verb, and keep it to one action. If a step has an “and” in it, it’s often two steps.

Beside each step, write what the reader should see when it worked. The expected result tells them they can move on, and it shows a reviewer exactly where a problem started.

• Use the exact labels the screen uses, so readers can match them.
• Say who does the step when more than one role is involved.
• Put anything you can’t undo, like deleting data or changing permissions, behind an explicit check or approval.

Step 5: Add decision points and when to escalate

Real tasks branch. The customer is on a different plan, the amount is over the limit, the install fails. An SOP that only covers the happy path leaves people guessing at the first exception.

Write each branch as “if this, then that,” next to the step it belongs to. If the branches get complicated, add a small flowchart and keep the written version beside it.

• If the refund is over the agent approval limit, then assign the ticket to a team lead.
• If encryption fails twice, then stop and escalate to the IT support lead.
• Name who to escalate to, by role, and how to reach them.
• Say when to stop: for example, before any step that would change something you can’t undo.

Step 6: Show the hard steps with screenshots or a recording

Some steps take a paragraph to describe and five seconds to show: a settings page, a menu three levels deep, a field that only appears after you change another one. Add a screenshot for those, with the button or field marked.

For a sequence of clicks, a short screen recording works better than a stack of screenshots. Link it next to the step it explains. Our guide to annotating screenshots for clear instructions covers how to mark them up.

Step 7: Test it with someone who has never done the task

Hand the draft to someone who hasn’t done the task and ask them to follow it exactly, without help. Watch, and don’t explain. Each time they pause, ask a question or take a different path, the SOP needs a clearer step.

Fix those spots, then test again with a second person if the task carries real risk. Ask the expert from step 2 to read it too, to catch anything that’s technically wrong.

Step 8: Publish with a version, an approval and a review date

• Get the owner and, if your team uses one, an approver to sign off.
• Give the SOP a version number and an effective date, and start a revision history.
• Put the next review date at the top. Six or twelve months is common.
• Publish it where people already look, and link to it from where the work starts: the ticket form, the onboarding checklist, the team wiki page.
• Tell the people who do the task that it exists, and how to flag a step that’s wrong.

Common SOP mistakes

How often should you review an SOP?

Set a review date when you publish, commonly every six or twelve months. Review sooner when the software, the team or a rule changes, or when someone reports a step that no longer matches the screen.

A useful review means someone does the task while following the SOP, rather than rereading it at a desk. Log what changed in the revision history, bump the version and set the next date.

In a regulated industry, your quality or compliance team sets the review and approval rules. Follow theirs. This article is general writing advice, not compliance guidance.

Record it once instead of writing from scratch

Steps 2, 4 and 6 usually take the longest: watching the expert, typing up every click and capturing screenshots. For software tasks, you can cover all three in one pass by recording the process.

Record the task once with Zight and it drafts a step-by-step guide with screenshots pulled from the recording. You still do the parts only a person can do: check each step against how the work is really done, add the scope, owner and exceptions, and test it. 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 (see plans).

When the person who knows the process isn’t you, send them a request link. They record their screen in the browser with no account and no install, and Zight can draft the guide from the recording they send back.

New to SOPs? Read what an SOP is, with formats and six examples, or copy the free SOP template.

Frequently asked questions