How to write an SOP from a screen recording

Last updated: October 3, 2026

The reason to write an SOP from a screen recording, rather than from a blank page, is that a job is hard to describe accurately from memory. The steps you do without thinking are the easiest ones to leave out, and they are the ones a new person needs spelled out. Recording yourself doing the task once catches them, as long as you narrate while you work.

Below is the whole method, tool-agnostic. You can run it by hand with a screen recorder and any AI chat tool. I build a product that does steps four through seven in one pass, and I say where at the end rather than pretending the manual route does not work.

What do you need?

A screen recorder that also captures your microphone.
A transcription tool.
An AI tool that can rewrite text into steps.
One task in mind, and about as long as it takes you to do that task once.

The eight steps

Pick one task, not a whole process. Choose something with a clear start and a clear finish, the kind of thing someone asks you about. "Send the monthly invoice to a client" works. "Bookkeeping" does not: it is five tasks, and the recording will wander. If you cannot say out loud where the task ends, it is too big.
Record the screen and your voice at the same time. Don’t skip the audio; it is the part that matters. The clicks show where to go; your voice explains why. Any screen recorder that captures microphone audio works, including QuickTime on a Mac, the Snipping Tool on Windows 11, Loom or a browser tool.
Narrate the reasons, not the clicks. Do not read the interface out loud. The recording already shows you clicking Save. Say the things that are only in your head: why this client gets a different rate, what you check before you send, the one field that breaks everything if it is wrong, what you would do if the number looked off.
Get a transcript. Feed the recording to a transcription tool to get plain text with rough timestamps. That text, not the video, is what becomes the written steps. Keep the timestamps: they are how you match a sentence back to what was on screen.
Turn the transcript into numbered steps. Ask an AI tool to rewrite the transcript as numbered steps, each one an action somebody can follow, and to keep the reasons attached to the step they belong to rather than collecting them at the end. Give it the real names: the apps, the screens, the fields.
Add the real button names and a screenshot per step. A transcript cannot see the screen, so the draft will say "click the button" where the screen said "Record payment". Go through the recording and correct those, and grab one screenshot per step from the video. This is the slow part by hand, and it is what makes the difference between a guide someone follows and one they abandon.
Find what you skipped. Read the draft as though you had never done the task. Every place it says "then handle it as usual" or leaves a decision unexplained is a gap you narrated past. Write the answer in, or note the question for the person who knows.
Put it where the work happens. A document nobody opens is not written down. Put it wherever the person doing the task already looks, and link it from the tool they use. If you also want an AI tool to run the process, export it as a skill file the tool can read rather than pasting the whole thing into a chat each time.

On that last step, the “skill file” is a small folder with a SKILL.md inside it: a name, a description, and the instructions in plain Markdown. It is an open format, so a workflow written once can be read by any tool that supports it rather than pasted into a chat window every time. The spec is public if you want to write one by hand: the Agent Skills specification.

Try Edessa free

What can go wrong?

Three things, and all three come from the recording rather than the writing.

Silence. A recording with no narration produces a click list, which you could have written faster yourself. If you are not talking, you are not capturing anything the screen does not already show.
Performing instead of working. The moment you start presenting, you stop doing the job the way you do it. Let it be unpolished.
Recording the happy path only. The value is in the exceptions. If a task has a version that goes wrong, say what you would do, even if it does not happen in this recording.

When is a recording the wrong approach?

When the task is mostly decisions and barely any screen, a recording adds nothing: write it as a decision list instead. When it runs across days rather than minutes, record the individual sittings and stitch them, or you will end up with a video of you waiting. And when the task touches customer data on screen, either use a test record or redact the screenshots before you share the result.

Who wrote this. Thaddeus Demeke, Founder of Elevaite and the founder of Edessa. Five years at Genentech, most recently as a Senior Data Scientist, then building AI systems inside small businesses across agencies, home services, real estate and ecommerce. This is the method I use with clients, including the manual version.

Questions

How long should the recording be?

As long as the task takes you once, which as a rough guide is often three to fifteen minutes. If you are past twenty minutes you have probably recorded several tasks at once, and the write-up will read that way. Stop and split it.

Do I need to script it first?

No. A script turns into the sanitised version of the job, not the real one, and the exceptions are exactly what you need captured. Do the task the way you actually do it, mistakes included. A recording where you catch your own error and explain the fix is more useful than a clean one.

Can I do this without an AI tool?

Yes. Record, transcribe, and rewrite the transcript as steps by hand. As a rough guide, expect an hour or so per task, most of it on the screenshots and the button names. The method is the same either way; the tooling only changes how much of it you type.

What does Edessa do differently from this by hand?

It runs steps four through seven in one pass. You record the screen and voice, and what comes back is a numbered workflow with the real button names and field values that were on screen, a screenshot per step, an automation tag on each step, and a flag on anything the narration skipped. The write-up happens after you stop recording, so you can walk away while it runs. Every workflow also exports as a portable AI Skill.