- Step 1: Pick the right process
- Step 2: Check what you already have
- Step 3: Record one clean take
- Step 4: Turn the recording into a first draft
- Step 5: Add what the recording can't show
- Step 6: Test it on someone who doesn't know the process
- Step 7: Put it where people will look, and keep it current
- When a screen recording is the wrong starting point
- Where to start this week
Most small businesses don't have an SOP problem. They have a writing problem.
The process exists. Someone on the team does it every week and could show you in ten minutes. What never happens is the part where that person sits down, opens a blank document, and writes it all out with screenshots. So the process stays in one person's head until they go on holiday, or leave.
A screen recording gets you past that. Showing a process is easy and most people already do it, on Zoom calls and in quick Loom videos to a colleague. The recording is the raw material, and turning it into a proper SOP is a much smaller job than starting from nothing.
Here is how to do it, whether you do the conversion by hand or use a tool. A disclosure up front: I build Vidocu, one of the tools that does this, so I'm not neutral. The method below works either way.
Step 1: Pick the right process
Start with a process that meets three tests:
- It happens on a screen. Software workflows, account setup, invoicing, publishing a blog post, onboarding a client in your CRM. A recording can't document work that happens away from the screen.
- It repeats. If it runs weekly or monthly, the SOP pays for itself quickly. A once-a-year task can wait.
- It follows a mostly fixed path. If the honest answer to "how do you do this?" is "it depends", a recording shows only one path. You'll need to write the decision rules yourself.
Keep the scope tight. One SOP covers one process. "Client onboarding" is too broad to record in one go. "Create a new client workspace" is about right. A big process can be split into a few short SOPs that link to each other, and those are far easier to update later.
Step 2: Check what you already have
Before you record anything new, look through your old recordings. Handover calls, training sessions and "here's how I do it" videos often contain exactly the walkthrough you need.
They are worth using if the screen is readable and the process hasn't changed since. If the walkthrough is buried in a long call, trim it down to the relevant section first. Everything else in the file will only add noise.
Step 3: Record one clean take
If you do need a new recording, use whatever you already have. Zoom, Loom, Teams, Google Meet, OBS and the recorders built into macOS and Windows are all fine. The tool matters far less than the take.
A few habits make a big difference to the SOP you end up with:
- Have everything open first. Tabs, logins and sample data should be ready, so nobody watches you hunting for a password.
- Close the noise. Turn off notifications, and close any tabs you wouldn't want a new hire to see.
- Zoom your browser in a little. Small interface text makes for screenshots nobody can read.
- Say what you're doing and why. "I'm choosing the annual plan here because this client pays upfront" tells the reader something the screen never will. That reasoning is usually the most valuable part of the document.
- Pause briefly between actions. A second or two of stillness makes each step easy to separate later.
- Retake instead of recovering. Dead ends and backtracking end up in the draft. If you take a wrong turn, it's usually quicker to start again than to clean it up afterwards.
Aim for one process from start to finish, at a steady pace. If the recording passes the ten-minute mark, ask whether you're really documenting two processes.
Step 4: Turn the recording into a first draft
This is where the time goes, and you have two options.
By hand
- Get a transcript of the recording. Most meeting and recording tools can export one.
- Watch the video and mark every action: each click, each field filled in, each new page.
- Rewrite each action as a single instruction that starts with a verb.
- Pause at each step, take a screenshot, crop it and paste it in.
Step 3 is the real work, so here is what it looks like in practice:
What was said: "So then I just go up here to the settings thing, and we want the billing one, and you'll see the plan."
The SOP step: Click Settings in the top menu, then select Billing. Check that the current plan is shown.
Done by hand, a ten-minute process typically takes one to two hours to document, mostly because of all the pausing and scrubbing. That's fine for one SOP. It's why you never get to the twentieth.
With a tool
AI SOP tools cut out most of that scrubbing, but they don't all start from the same place, so check how a tool captures the process before you commit. Lilach's roundup of the best AI SOP generators is a good place to compare the options.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
Click-capture tools record your steps while you work, which suits a process you're about to perform. If your starting point is a recording you already have, you need a tool that accepts a video file. That is the case we built Vidocu's video to SOP workflow for: you upload a recording, and you get a draft with a title, numbered steps and a screenshot taken at the moment of each step. Processing a typical walkthrough takes around five minutes.
Whichever route you take, treat the result as a first draft. Which brings us to the step that actually makes it an SOP.
Step 5: Add what the recording can't show
A recording shows what happened on one good run. A useful SOP also covers everything around that run, and no tool can fully work that out for you. Go through the draft and add:
- Purpose. One line on what this process achieves and why it matters.
- Owner. Who is responsible for the process and who keeps the document current.
- Prerequisites. The logins, permissions and information someone needs before they begin.
- Decision points. What to do if the client is on a different plan, or the payment fails, or the button isn't there.
- The finish line. How someone knows the process worked: a confirmation email, a status change, a record in the right place.
While you're there, cut the noise. Remove steps that were really just you moving around, merge any that belong together, and check that terminology matches what your team actually says. Also look closely at every screenshot for client names, email addresses and other details that shouldn't be in a shared document.
Step 6: Test it on someone who doesn't know the process
This is the step most teams skip, and it's the one that tells you whether the SOP works.
Give the document to someone who has never done the task, and ask them to follow it with no help. Sit next to them, or get them to share their screen, and stay quiet. Every time they stop and ask a question, you've found a gap. Fix it in the document, not in conversation.
Ten minutes of this will catch more than an hour of proofreading, because the person who wrote the SOP can't see what it leaves out.
Step 7: Put it where people will look, and keep it current
An SOP nobody can find doesn't exist. Keep it wherever your team already goes for answers, whether that's a shared drive, Notion or a help centre. Most tools can export to common formats such as PDF or Word if you need to move it there, and a consistent naming pattern, such as "Billing: Issue a refund", makes everything easier to search.
Then keep it alive:
- Give every SOP an owner and a review date. Quarterly is plenty for most processes.
- Update on change, not on schedule. When the software changes or someone finds a better way, that's the moment to update.
- Re-record rather than patch. If a process changes substantially, record it again and make a fresh draft. For small changes, edit just the affected steps and screenshots.
This is the other big advantage of working from recordings. Updating an SOP stops being a rewrite. It's another ten-minute recording.
When a screen recording is the wrong starting point
Recordings aren't right for every procedure. Think twice in these cases:
- Physical work. Warehouse, lab or on-site procedures need a different capture method.
- Judgment-heavy work. If the process is mostly about deciding, write the decision rules first and use recordings only for the mechanical parts.
- Regulated procedures. If you need a signed audit trail, you need a proper compliance system. The SOP is only the document.
- Sensitive data. Don't record on live customer, health or financial records. Use test data, and check the policy of any tool before you upload.
Where to start this week
You don't need a documentation project, just one recording.
Pick the process that would hurt most if the person who runs it were away next week. Ask them to record it once, talking through what they're doing. Turn that into a draft, add the context, and watch someone new follow it.
Once you have seen one SOP go from recording to finished document, the second takes less time. Do one a week, and within a quarter the processes that matter most will live somewhere other than in someone's head.
Daniel Sternlicht is the CEO of Vidocu, an AI platform that turns videos into SOPs, help articles, subtitles and voiceovers.
