The short answer

To create an SOP: pick one repeatable task, capture it from a real run (record it rather than writing from memory), write each step as a command with a screenshot, then wrap it with a title, purpose, scope, owner and last-updated date. Generating the draft from a recording keeps SOPs accurate and makes updates a one-minute re-record instead of a rewrite.

A standard operating procedure is the documented, repeatable way to do a task so it comes out the same every time, no matter who does it. SOPs are how knowledge survives turnover, how new hires get productive, and how quality stays consistent. Yet most SOP libraries are graveyards — written once, never updated, ignored. This masterclass fixes both halves: writing a good SOP, and keeping it true.

What is an SOP?

An SOP (standard operating procedure) is a step-by-step instruction set for a routine task. It differs from a casual how-to by its wrapper: an SOP also says who's responsible, when it applies, what you need first, and when it was last verified. That wrapper is what makes it auditable and trustworthy.

What every SOP should include

A copy-paste SOP template

SOP: [Task name]
Purpose: [Why this task exists, in one line]
Scope: [When this applies / starts / ends]
Owner: [Role responsible] · Maintainer: [Who keeps it current]
Prerequisites: [Access, tools, inputs needed]
Steps:
  1. [Verb + object] — [screenshot]
  2. [Verb + object] — [screenshot]
  3. [Verb + object] — [screenshot]
Expected outcome: [What success looks like]
Edge cases: [If X, then Y]
Last updated: [Date] · Version: [n]

How to create an SOP, step by step

1. Pick one task and define its scope

One SOP, one task. If you're tempted to cover three related things, write three SOPs and link them. Define exactly where the procedure starts and stops so it doesn't sprawl.

2. Capture it from a real run — don't write from memory

This is the step that decides accuracy. Writing an SOP from memory bakes in the version that lives in your head, which is always a little out of date and missing the edge cases. Instead, record the task once as you actually do it, so the steps and screenshots come from reality.

3. Write each step as a command

Start every step with a verb, one action per step, paired with a cropped screenshot of the control. "Click Approve" beats "the approval is then granted by clicking the relevant button."

4. Add the SOP wrapper

Drop the captured steps into the template above. The wrapper — purpose, scope, owner, prerequisites, date — is what turns a how-to into a governed procedure.

5. Review, publish, and schedule updates

Have the person who does the task verify it. Publish to a searchable home (knowledge base, wiki). Then set the expectation that it gets re-captured when the process changes — which is cheap if you generated it from a recording.

Common SOP mistakes to avoid

MistakeWhy it failsFix
Written from memoryMisses real steps and edge casesCapture from a live run
No screenshotsReaders can't find the controlOne cropped screenshot per step
No owner or dateNobody trusts or maintains itAdd owner + last-updated
Never updatedGoes wrong, then ignoredMake updates a re-record
BuriedCan't be found when neededSearchable title + knowledge base
An SOP isn't done when it's written. It's done when it's still correct the next time someone opens it.

How Spion keeps SOPs current

Spion records a task once and generates a screenshot-rich, editable draft you wrap into an SOP and export as a PDF for your knowledge base. When the process changes, you re-record in a minute instead of rewriting — which is the only realistic way SOP libraries stay accurate. (And if the task should run itself, Spion can export it as an automation instead.)