How to write an SOP from a screen recording

A standard operating procedure written from memory is usually wrong in small ways. The person writing it forgets the step they do without thinking, the field that only appears after a checkbox, the confirmation dialog they have dismissed a thousand times. A screen recording removes that problem: the steps are whatever you actually did.

What the recording cannot do is turn itself into a procedure. That takes a short review afterwards. This is the method we use and recommend, with a recorder like Recordable or any other tool that captures steps and screenshots.

1. Choose one task with a clear end state

One task, one outcome. "Create a customer invoice" is a task. "Handle billing" is a department. Before you record, write down how you would verify the task was done: an order number exists, a status reads Approved, an email went out. That sentence becomes the last section of the SOP.

If the task branches, pick the most common path and note the branches. They become separate short guides later, linked from the decision points.

2. Record the whole task once, at working speed

Start at the point the reader will start, not three screens earlier. Use the browser extension for web applications and the desktop app for native software. Do not slow down or narrate for the recording's sake; the recorder captures the clicks, the typed text and the page changes on its own.

If you make a mistake, keep going. It is faster to delete a wrong step during review than to restart the recording.

3. Review it before anything leaves your machine

Look at every screenshot. Customer names, email addresses, amounts, internal URLs, browser tabs you forgot to close. Blur what should not be shared. Delete the steps that show a detour or a wrong click. Exclude what the reader does not need.

In Recordable this review happens locally, before the recording is uploaded. Whatever tool you use, treat redaction as your job: no tool can prove that every screenshot was inspected, and an approval click is not evidence that it was.

4. Give every step a title and a description

A generated step is a draft, not the finished text. Each step needs two things:

• A title. The short label of what the reader does: "Open the Sales menu", "Enter the quantity".
• A description. The detail they need to do it: which field, what value, what to check before moving on.

Then cut. Scroll steps, steps that only show a page loading, two clicks that a reader would obviously do as one: merge or delete them. A twelve-step guide that is right beats a thirty-step guide that is complete.

5. Write the parts the recording cannot see

The recording shows what happened. The reader also needs to know what to do when their situation differs. Add, in plain sentences:

• Preconditions. Access they need, where the input data comes from, what should already exist.
• Decisions. "If the customer is new, create them first" with a link to that guide.
• Verification. The end state you wrote down in step one. How the reader knows they are done.

These three sections are what separate an SOP from a click log.

6. Share it where the work happens

Share the guide by link. Readers do not need a paid seat to read it. Put the link where the task starts: the ticket template, the onboarding checklist, the pinned message in the team channel.

For browser tasks, Recordable can also show the guide beside the live application with Follow Along: the instructions stay in view and the next target is highlighted while the reader does the work themselves. It is optional, and it requires the extension and an account.

7. Keep it current with feedback, not a review calendar

A quarterly review of every SOP never happens. What does happen is that a reader hits a step that no longer matches the screen. Make that moment useful: readers should be able to flag the step, and the author should see it somewhere they already look. In Recordable that is a review inbox; the author re-records or edits that one step, resolves the item, and everyone with the link has the current version.

Guides do not update themselves. The loop works because a human closes it.

8. Export when a system of record needs a file

Some processes require a PDF in a quality system or a Word document in a shared drive. Export for those, on the plans that include it, and treat the export as a snapshot. The link is the living version; the file is dated the day you made it.

A checklist to paste into your SOP template

• Purpose and end state. One sentence each.
• Who does this. Role, not name.
• Preconditions. Access, inputs, what must already exist.
• Steps. Title plus description, one screenshot each.
• Decisions. Where the path branches and where each branch is documented.
• Verification. How the reader knows they are done.
• Owner and last reviewed. A person and a date, so the next reader knows how much to trust it.