Standard operating procedure
The workhorse format: one task, start to finish, recorded so that someone who has never done it can follow it without you in the room.
Record it in this order
Start from the real starting point
Open the tool from a cold start, the way the reader will. Starting mid-task from a screen you already had open is the single most common reason an SOP does not work for anyone else.
Do the task once, at normal speed
Do not narrate every click. Knovvy writes the steps from what you actually do, so your job is just to do it correctly and completely.
Include the checks, not just the actions
The moment where you verify it worked belongs in the SOP. That step is usually the difference between a process someone can follow and one they can only imitate.
Finish at a definite end state
Stop on the screen that proves the task is done. The reader needs to know when to stop as clearly as how to start.
Scope: one task, not one job
The most common SOP mistake is scope. "Month-end close" is not an SOP, it is nine of them.
- One SOP should answer one question and take one sitting to follow.
- If your recording runs past about five minutes, it is probably two guides.
- Small guides can be replaced individually when a tool changes. A large one only gets replaced by writing another large one, which is how documentation goes stale.
What to annotate afterwards
- Delete the stray clicks. A wrong turn you corrected mid-recording just confuses the reader.
- Add a tip callout for the shortcut you know and they do not.
- Add a warning callout on anything irreversible, before the step rather than after it.
- Blur customer data, internal IDs, and anything in a sidebar you did not think about.
Keeping it accurate
Re-record rather than repair. A fresh capture costs about two minutes and is correct by construction, where patching four screenshots in an old doc costs forty and is correct by hope.
Related: SOPs and process docs, and why SOPs go stale.