How to Write an SOP: Record the Job First, Then Write It

Most guides on how to write an SOP start with a blank page. Title, purpose, scope, steps. Then you sit there and try to remember what you do.

That is the step that breaks it. When you write a procedure from memory, you leave out the things you do without thinking, and those are the things a new person gets stuck on.

So this is a different order. You record the job first, then write. Below are the steps, a rewrite of a vague step into a clear one, and how to find out whether anyone is actually using the SOP once it exists. It is written for SaaS teams, where most procedures are a path through screens: setting up a customer account, triaging a bug, handing a deal to onboarding.

How to write an SOP: start by recording the job

Here is what the guides I read agree on. systemHUB, which sells SOP software, says the biggest mistake is starting by writing, and that the best SOPs are "captured from reality, not composed from memory." Herzing University says many people find it easier to draft while they do the task, and suggests asking a coworker to take notes or recording yourself to watch back later. QuickSOP, which sells a workflow capture tool, says memory is unreliable and tells you to perform the process in real time and capture every click and decision before polishing anything.

Three sources, one idea. They each have a product to sell, so I would not take their word on how much time it saves. But the idea holds without any numbers: the person doing the job is the best source, and a recording does not forget the steps they stopped noticing.

Step 1: Pick one process and put a fence around it

Not all of them. One. systemHUB suggests the one that breaks when a key person is away, or the one that brings the same questions again and again. It also gives a good test of where the edges are: "Sales" is not a process, but "from a new enquiry arriving to a discovery call being booked" is.

For a SaaS team, good first picks are the handoff from sales to onboarding, setting up a new customer's workspace, routing a bug report, and the support question that arrives every week.

Step 2: Decide who it is for

Herzing's first step is to work out who will use the SOP. A teammate taking over your job needs less than someone in their first week. systemHUB says to write for the newest person on the team, and gives a test: could a competent new hire follow it without asking questions and get the same result?

Write that person's name at the top of your notes. You will use them again in step 6.

Step 3: Record someone doing it for real

Ask the person who does the job best to do it, with their real screen, while the recording runs. Not a clean demo. The real thing, including the part where they open the wrong tab because that is what everyone does.

With DemoSix, that person records with DemoSix Recorder on Mac or Windows, or uploads a video they already have. The SOP software page says captions are added automatically. Keep it to one procedure per video, so each video answers one question and you can record it again when that one thing changes. If a procedure will not fit in a short video, it is probably two procedures.

Step 4: Write the start, the finish, then the steps

Now you write, but you are copying from the recording, not inventing.

Write two lines first. systemHUB calls them the trigger and the endpoint: what tells someone to begin, and how they know they are done. Everything in between hangs on those two lines.

Then list the steps in the order the recording shows them, and follow these rules:

• One action per step, starting with a verb. systemHUB says to keep each step to one action and start with a verb. If you are past twenty steps, it says you have probably fenced off two processes.
• Tell the reader what they should see. QuickSOP says to write commands, not descriptions, and to say after key steps what should happen. Its example is a confirmation banner with a reference number. That line is what lets someone know they are on track, or that something has gone wrong.
• Use roles, not names. Atlassian, which owns Loom, says to assign tasks to roles, like "inventory manager," so the SOP stays right when people change jobs.
• Say "must" when you mean it. The FDA Group, a consulting firm for regulated industries, says "must" is always mandatory and "should" is conditional by nature. So a step that says "should" can be read as optional.

A vague step, rewritten

This is an illustration I made up, not a real company's process.

Before:

Configure the integration settings as needed.

After:

1. Open Settings, then Integrations. Result: you see the list of connected apps.
2. Click Connect next to the CRM. Result: a sign-in window opens.
3. Sign in with the shared team login, not your own. Why: your own login would break the connection when you leave.
4. Confirm the status reads Connected. If it reads Error, stop and tell the onboarding lead.

The first version was written by someone who knows the answer. The second one was written by someone who watched a recording of themselves doing it. The recording is why the third step is there. Nobody remembers to write that one down.

Step 5: Say what to do when it goes wrong

Herzing lists this as one of the marks of a good SOP: it says what happens when the procedure cannot be followed and who needs to be told. For a SaaS process, that is usually one line: who to message, and what to do first. Put it at the bottom of the steps, not in a separate document nobody opens.

Step 6: Test it with someone who did not write it

This is the step people skip, and the one that matters most.

Hand the SOP, and the video, to the newest person you named in step 2. Ask them to follow it, and then stay quiet. Herzing says not to interfere with the test, so that you get honest feedback. QuickSOP calls it the teach-back test and lists what to watch for: where they hesitate, which steps they get wrong, what questions they ask, and where they get a different result than expected.

systemHUB puts it plainly: every place they pause or improvise is a gap in the document, not a gap in the person. Fix the document.

Step 7: Give it a home, an owner and a review date

An SOP on someone's desktop does not exist. Put it where your team already looks, give it one owner, and set a review date. systemHUB suggests every 6 to 12 months or whenever the process changes. Herzing says SOPs are living documents and there is no fixed schedule, so keep an eye on what changes in your product. If you ship every week, review more often.

Where the video goes is where DemoSix fits. Procedures live in a private library, sorted into Channels by team or process, and only the people you invite can watch. You can keep your written checklist where it is today and link each step to its video. Teammates watch in a browser.

Step 8: Check that people used it

Most guides stop at step 7. But an SOP nobody opens has not done its job, however well it is written.

On Standard and Teams, Who watched shows, for each demo in a private library, who watched it, who stopped part way, and who has not started. So when you ask a new hire to learn the handoff procedure, you can see whether they did, and how far they got. If several people stop in the same video, look at that video first: a step may be too long or unclear. Fix it, and record that one video again.

If you want the one-page version of this, I wrote an SOP template for SaaS teams with a slot for the video. The use case behind all of it is on the process documentation page.

What this post does not cover

If your SOPs have to meet a regulator, approvals, versioning and signatures are part of the job. The FDA Group's guide covers what that looks like in its industry. This post is for everyday SaaS operations, and I am not giving compliance advice. Ask whoever owns compliance at your company.

Also, a video does not replace the written steps. The video shows how the job looks. The short list is for running it again quickly. Keep both.

The takeaway

Don't start with a blank page. Pick one process, record the person who does it best, write the steps from the recording, and hand it to your newest teammate to test. Then check who actually watched it.

Start with the question your team gets asked most this week.