Record someone doing the job while explaining it, then write the SOP from the recording. Pull out the ordered steps, the decisions, the systems touched and the checks. Then add the steps the person skipped over because they felt obvious. That produces a procedure someone can follow, which a blank template rarely does.
Most SOPs are written the other way round, and you can tell.
Why are SOP templates the wrong starting point?
A template asks a person to describe work. Describing work and doing work are different skills.
Open any standard operating procedure template. Purpose, scope, responsibilities, procedure, references. The first four sections are easy to fill in and mostly useless. The fifth is where the value is, and it is a blank box titled "Procedure."
So the expert sits down, a little resentful, and writes what they would tell a visitor. Seven tidy steps. "Review the invoice. Match to the PO. Approve in the system." It reads as a procedure and fails as one. A new hire follows it and gets stuck on step two, because "match to the PO" quietly contains four sub-steps and a judgment call about tolerance.
The template also rewards length over accuracy. Nobody reads a thirty-page SOP, and nobody checks whether it is true. It exists to pass an audit and then sit on SharePoint.
A recording starts from what actually happened. It is a worse document and a far better source.
What do you pull from a recording?
Run it as an ordinary working session. One person does the task on a shared screen, talks through it, and somebody else asks questions. A video call recorded in Teams or Zoom is enough. Meeting notes work too, but a recording of someone doing the work beats a recording of people discussing the work.
From it, extract six things.
The sequence. What happened, in order, with timestamps so each step can be checked later.
The systems. Every application, shared drive, spreadsheet or email inbox touched. If they opened a Smartsheet, a SharePoint folder and an Excel file, those are three entries.
The decisions. Anywhere they paused and chose. "If the variance is under two percent I let it through." That sentence is the most valuable one in the hour, and it is almost never in a written SOP.
The inputs and outputs. What had to exist before they started, and what exists after.
The checks. What they looked at to confirm it worked. This is the control, and it is what your SOC 2 or ISO 27001 auditor is really asking about.
The vocabulary. The words they use. "The Friday file." "Run the sweep." Use their terms, with a plain definition the first time each appears.
A recording gives you things a written description never will. It shows the order the work really happens in, which may not be the order the expert would give if you asked. It shows the waiting: the file that has to land before anything can start, the approval that sits in someone's inbox. It shows every switch between systems, which is where handoffs and copy-paste errors live. And it shows the decision made without a word, the glance at a number that sends the work down one path instead of another. None of that survives a summary, so none of it makes it into a template.
Write the first draft straight from that. Short numbered steps, each starting with a verb, each tied to a point in the recording.
How do you handle the steps nobody says out loud?
This is the entire problem, so go slowly.
Experts skip steps because they are obvious. They are obvious because the expert has done them four thousand times. They are not obvious to the person who will follow the SOP.
An operations lead might narrate six steps while the video shows nine: logging in through a particular VPN profile, checking the vendor against a sanctions list in a second window, and renaming the attachment before saving it. Those actions go unmentioned because they no longer feel like part of the task. They are just how the work starts.
There are three ways to catch these.
Compare the narration to the screen. Anything done but not said is a candidate. This is slow by hand and a good job for a machine, which does not get bored of the mouse.
Ask what happens before and after. Where does the task begin? What has to be true when it ends? Gaps between the answer and the recording are missing steps.
Make a novice run it. Hand the draft to someone new and watch where they hesitate. Every hesitation is an unwritten step. The first pass turns up the most, and each later pass turns up fewer.
Also listen for the verbal tells. "Just." "Obviously." "You know." "Then you do the usual." Each one marks a step being waved through.
How long should an SOP be?
As long as the task is, and no longer.
A reasonable rule: if a procedure takes a trained person under an hour, the SOP should fit on one or two pages. If it runs longer, it is probably two procedures. Split it.
Put the steps first and the context after. Someone reaching for an SOP is mid-task and wants step six, not the history of the department. Keep the purpose to a sentence.
Name one owner and a review date. Add a short "when this goes wrong" section. Three or four known failure cases do more for a new hire than a page of policy.
If you find yourself writing a decision tree with eleven branches, the process has a design problem, and the SOP is just the place it became visible. Note it and keep going.
Can this be automated?
Mostly, yes. Transcribing a recording, ordering the steps and flagging the decisions are all work a model does well. Comparing what was said against what was shown, which is where the missing steps hide, is the more interesting part.
The honest limit is that a person must confirm the output. A machine can draft a procedure from a recording, a Confluence page and three email threads. It cannot know that the Singapore team does it differently on Fridays unless somebody says so. That is a review step, not a failure.
Zipper Blueprint for Operations is being built around this workflow: read the recordings, notes, wikis, email and spreadsheets a company already has, then draft an SOP for a subject-matter expert to review. It is in early access and not generally available.
Frequently asked
Do I need a video, or is a transcript enough? A transcript gets you the narration, which is the version of events the expert would write down anyway. The video gets you what they actually did. If you can only have one, take the video. Screens show the unspoken steps.
Who should be in the recording? The person who does the job today, plus one person who does not. The second person asks the obvious questions the expert has stopped hearing. Keep it to two or three people.
Is an SOP written this way acceptable to an auditor? Generally better than one written from memory, because every step traces to a dated recording. Keep the recording and the review sign-off with the document. Check the specifics with your own auditor.
Related: Automated documentation: what it actually means · Process documentation when your process lives in Excel