How to Write an SOP from a Screen Recording (2026)

Most processes already exist as habits. Someone on the team knows how to run payroll, onboard a vendor or close the month, and everyone else asks them. A standard operating procedure (SOP) turns that habit into a document anyone can follow. The fastest way to write one for a software task is to record the person doing it, then turn the recording into written steps.

This guide covers what goes in an SOP, a plain-text template you can copy, how to turn a recording into steps by hand, how to take useful screenshots, how to keep private data out, and where to store and review SOPs. Most of it works with any tool. One section covers how Nook fits in.

#Short answer

To write an SOP from a screen recording, record someone doing the task once at a calm pace, watch it back and write one numbered step per action, take a screenshot for each step, and blur any private data. Then add the purpose, scope, owner, prerequisites, exceptions and a review date. Store it where the team works and review it on a schedule.

#What goes in an SOP

A good SOP answers who, what, when and how, and nothing more. These are the parts worth including.

• Title. Written as a task: "Issue a customer refund," not "Refunds."
• Purpose. One or two sentences on why the process exists. "Refunds over $500 need a second approval to prevent fraud."
• Scope. What the SOP covers and what it does not. "Covers card refunds in the billing tool. Bank transfers have their own SOP."
• Owner. The person responsible for keeping it accurate. Use a name or role, not "the team."
• Prerequisites. Access, permissions, tools and information needed before starting.
• Steps. Numbered, one action each, in the order they happen.
• Screenshots. One per step where the screen matters.
• Exceptions. What to do when something goes wrong or a case does not fit.
• Review date. When the SOP was last checked and when it is due again.

Optional parts that help in larger teams: a version history, related SOPs, a glossary of internal terms and a link to a short video of the task.

#A plain-text SOP template

Copy this into any document tool and fill it in.

SOP: [Task, written as "Do something"]

Purpose
[One or two sentences on why this process exists.]

Scope
Covers: [what is included]
Does not cover: [what is excluded, with links to other SOPs]

Owner
[Name or role]

Prerequisites
- Access to: [tool, with the role or permission needed]
- Information needed: [order number, customer email, etc.]
- Done first: [any earlier process]

Steps
1. [Action, using the exact words on screen.]
   Screenshot: [image]
2. [Action.]
   Screenshot: [image]
3. [Action.]
   Note: [why this step matters, if it is not obvious]

Expected result
[What the person should see when the task is done.]

Exceptions
- If [situation]: [what to do, or who to contact]
- If [error message]: [what to do]

Related
- [Link to related SOP or video]

Last reviewed: [date] by [name]
Next review: [date]

Keep the template the same across all your SOPs. A consistent layout makes them faster to read and easier to check.

#Record the process first

Writing an SOP from memory misses steps. People skip the clicks they do automatically. A screen recording shows every one.

• Record the person who actually does the task, not the person who manages it.
• Use a test account or test data if possible. If the task only exists in the live system, plan to blur.
• Close notifications, chat apps and extra tabs.
• Ask them to go slowly and pause before each click.
• Ask them to talk through it. "I check the order date first, because refunds after 90 days need approval." Those comments become your notes and exceptions.
• Record one clean run. If they hit an error, keep going. The error and the fix may belong in the exceptions section.

A recording of a few minutes is normal for a single task. If it runs much longer, the process may be several SOPs.

#Turning a recording into steps by hand

This is the core of the work. It takes some patience, but it is not hard.

1. Watch the whole recording once without writing anything. Get the shape of the task.
2. Watch again and pause at every action. A click, a typed value, a selection, a page change.
3. Write one step per action. Start with a verb: "Click," "Enter," "Select," "Open."
4. Use the exact labels on screen. If the button says "Issue refund," write "Click Issue refund." Bold the UI labels so they stand out.
5. Merge tiny steps that belong together. "Click the search box. Type the order number. Press Enter." can become "Search for the order number."
6. Split steps that hide a decision. "Choose the refund amount" may need "Choose Full refund, or Partial and enter the amount."
7. Add notes where the reason is not obvious. Pull these from what the person said while recording.
8. Write the expected result. "The order status changes to Refunded."
9. Test it. Give the draft to someone who has never done the task and watch them follow it. Every place they hesitate is a step that needs work.

The test in step 9 is the one most people skip, and it catches the most problems.

#Screenshot tips

Screenshots make an SOP faster to follow, because the reader can match what they see to what the document shows.

• Take the screenshot just before the action, so the button to click is visible and not yet clicked.
• Pause the recording and capture the frame, or take screenshots while doing the task a second time.
• Crop to the relevant area. A full screen at document width makes text too small to read. Keep enough context that the reader knows where they are.
• Mark the target. A simple box or arrow on the button to click. One mark per screenshot.
• Keep screenshot sizes consistent across the SOP.
• Add alt text describing the step, for screen reader users and for search inside your tool.
• Skip screenshots that add nothing, such as a step that only types into a field already shown.

#Blurring private data

Screen recordings of real work catch real data. Customer names, emails, phone numbers, card numbers, addresses, API keys and internal account details all show up in admin tools.

• Blur or replace them in every screenshot. Use a solid box or a strong blur. Light blur can sometimes be read.
• Check the edges of the screen. Browser tabs, bookmarks, notifications and the account name in the corner.
• Check the video too, if you attach the recording to the SOP.
• Prefer test data for any SOP that will be shared outside a small team.

Even if a tool blurs things automatically, look over every screenshot before you publish.

#Where to keep SOPs

Store SOPs where people already work. The best SOP is the one people find when they need it.

• Notion. Good for small and mid-sized teams. A database of SOPs with properties for owner, team and review date makes reviews easy to track. Notion imports Markdown.
• Confluence. Common in larger companies and engineering teams. Page trees work well for grouping SOPs by department, and page templates keep the layout consistent.
• Google Docs. Simple and familiar. Use a shared folder per team, a consistent naming pattern and the template above as a starting doc.
• Word. Common where SOPs need formal approval, printing or storage in a document management system. Use heading styles so the document has a navigable outline.

Whichever you choose, keep one index page that lists every SOP with its owner and review date. For more on the video side, see our guide to knowledge base videos.

#Review cadence

An SOP that was right last year may be wrong today. Software changes, policies change, people leave.

• Set a review date on every SOP. Many teams review every six or twelve months, and sooner for processes tied to compliance or money.
• Review after any change to the tool or the policy behind the process.
• Make the owner responsible for the review, and record the date and name when it is done.
• Retire SOPs that no longer apply. Archive them rather than deleting, if your team needs a record.
• Ask users to flag problems. A comment or a short form at the bottom of each SOP is enough.

#Making SOPs from recordings with Nook

The manual method works, but writing steps and capturing screenshots for every SOP takes time. This is one of the jobs we built Nook for.

1. Upload a screen recording you already have. Up to 15 minutes on paid plans. Nook does not record your screen.
2. Nook splits it into steps. If the person talked while recording, it uses their words. If the recording is silent, a vision model reads the frames, and Nook asks one question about what the recording is and who it is for.
3. You get a written guide with a heading, short text and a screenshot for each step. Edit any step's text.
4. Private data is blurred. Emails, phone numbers, card numbers, API keys, names and addresses are detected and blurred in the guide and the video. Check every screenshot anyway, since no automatic scan catches everything.
5. Export the guide as Markdown for Notion or Confluence, or as Word or PDF.
6. Optionally use the video too. The same recording becomes a narrated video with captions, which you can link from the SOP. See SOP videos.
7. Translate into Spanish, French, German, Portuguese, Italian, Dutch, Polish, Russian, Arabic, Hebrew, Hindi, Japanese, Korean or Chinese if your team works in several languages.

The honest limits: Nook writes the steps, but it does not know your policy. You still add the purpose, scope, owner, prerequisites, exceptions and review date, using the template above. It does not store or schedule SOP reviews, so that stays in your documentation tool. The free plan covers one recording up to 3 minutes, watermarked, without downloads or editing, so for real SOP work you would need a paid plan or a $4 single-video unlock. See pricing.

#Common mistakes

1. Writing from memory. Record the task and write from the recording.
2. Steps that hold several actions. One action per step.
3. Labels that do not match the screen.
4. No owner. An SOP with no owner goes stale.
5. No review date.
6. Private data in screenshots.
7. Missing exceptions. The normal path is easy. People open the SOP when something is odd.
8. No test with a new person.
9. Too much background. Keep the purpose short and link to the policy.
10. SOPs scattered across tools with no index.

#Checklist

#FAQ

#What is an SOP?

A standard operating procedure is a written set of steps for doing a task the same way every time. It usually includes the purpose, scope, owner, prerequisites, steps, exceptions and a review date.

#How do I write an SOP from a screen recording?

Record someone doing the task once at a calm pace. Watch it back, pausing at every action, and write one numbered step per action using the labels on screen. Add a screenshot for each step, blur private data, then fill in the purpose, scope, owner, prerequisites, exceptions and review date.

#What should a standard operating procedure template include?

At minimum a title, purpose, scope, owner, prerequisites, numbered steps with screenshots, expected result, exceptions and review dates. The plain-text template in this guide covers all of them.

#How long should an SOP be?

As long as the task needs and no longer. A single software task often fits on one or two pages with screenshots. If an SOP grows much longer, it may cover several tasks and work better as separate SOPs linked from an index.

#How often should SOPs be reviewed?

Many teams review every six or twelve months, and after any change to the tool or policy. Processes tied to money or compliance usually deserve a shorter cycle. Record who reviewed it and when.

#Should an SOP include a video?

It helps for tasks with many screens or tricky timing. Keep the written steps as the main reference, because people scan text while doing the work, and link a short video for those who prefer to watch. Our guide to making a software training video covers the video side.

#Can I put SOPs in Notion or Confluence?

Yes. Both work well. Write the SOP in Markdown or paste it in, keep one template, and use a database or page tree to track owners and review dates.

#Write your first SOP

Start with one task that people ask about often. Record it, write the steps, add screenshots, then test it on someone new. The template above is enough for most teams. If you would rather start from a draft, upload the recording to Nook and get a step-by-step guide with a screenshot per step, private data blurred and an export for Notion, Confluence, Word or PDF. See how it works for turning screen recordings into guides, or try it free.