How to Create an SOP with Screenshots

This guide shows how to create visual documentation for a standard operating procedure. You will define the process boundary, record roles and prerequisites, capture the approved steps, add controls and exceptions, test the document, and assign an owner and review date.

TL;DR: A useful SOP explains when a process starts, who owns each part, how to complete it, how to verify the result, and what to do when the normal path does not apply.

What is an SOP?

A standard operating procedure defines a repeatable process and the controls around it. It gives the process a purpose, scope, owner, inputs, ordered steps, expected result, exceptions, and review responsibility.

An SOP is broader than a list of clicks. The screenshots may show how to complete the software actions, but the document also needs to explain who should perform them and under which conditions.

SOP vs work instructions

An SOP describes the overall process, while work instructions explain one task inside that process. For example, an employee-offboarding SOP may cover approvals, account ownership, data retention, and completion records. A linked work instruction may show how to remove the user from one specific application.

Use one combined document when the process is short, one role performs it, and the software actions are the process. Split the SOP from its work instructions when several roles, systems, or independent tasks would make one document difficult to maintain.

Define the process boundary

The boundary states where the SOP begins and ends. Write the trigger, final result, intended role, and exclusions before documenting the steps.

Use specific endpoints:

Trigger: A manager submits an approved offboarding request.
Finish: Access is removed, company data is retained, and completion is recorded.
Owner: IT operations.
Audience: IT administrators with account-management access.
Outside scope: Payroll, equipment return, and legal retention decisions.

This boundary keeps a long business process from expanding into one guide that no single reader can complete.

List inputs, roles, and prerequisites

Prerequisites prevent the operator from discovering missing access halfway through the process. List the required permissions, approved request, source data, files, systems, and backup or rollback steps.

Assign responsibility when more than one role participates. A simple table is enough:

Responsibility	Role
Approve the request	Manager
Perform account changes	IT administrator
Verify data retention	System owner
Confirm completion	Operations lead

Avoid using a person's name as the only owner. Roles survive staff changes and make the maintenance responsibility clear.

Run the current process and capture the steps

The first capture pass should follow the approved process with safe data. Use a test account, close notifications, and record any part of the written procedure that does not match the current interface.

Capture screenshots where the operator must locate a control, choose a value, confirm a warning, or verify a visible result. Do not add a screenshot to every sentence if the image does not help the next decision.

Action Capture can collect the software path while you complete it. Each accepted click saves the target state immediately before the action and records the click location. Review the sequence afterward, remove incidental steps, and split separate subprocesses into their own guides.

Split a long workflow into smaller guides

A long workflow should be split when one part has its own trigger, owner, system, or reusable outcome. The overview SOP can keep the process order and link to focused work instructions for the detailed software tasks.

Split when any of these conditions apply:

• different roles perform different sections
• a section is reused by several processes
• one section changes more often than the others
• a reader can complete one section independently
• a branch serves a different outcome
• the guide becomes difficult to test from beginning to end

Do not split only to reach an arbitrary page count. A 15-step procedure completed by one person in one app may be clearer than five short files that force the reader to switch documents.

Add controls, exceptions, and stop conditions

Controls explain how to verify that the process is safe and complete. Add a checkpoint after any action that changes access, sends data, publishes content, charges money, or is difficult to reverse.

Exceptions explain the route when the normal step does not apply. Keep each exception tied to an observable condition:

If the account owns shared files, transfer ownership before removing access. If ownership cannot be transferred, stop and contact the system owner.

Avoid hiding important warnings in a long note at the end. Put the stop condition immediately before the risky action.

Use this visual SOP structure

The following structure covers the process information that screenshots alone cannot provide:

Title:
Purpose:
Scope:
Owner:
Intended role:

Trigger:
Finished result:
Prerequisites:
Inputs:

Procedure:
1. Action
   Expected checkpoint
2. Action
   Expected checkpoint

Exceptions and stop conditions:
Escalation route:
Completion record:

Verified product/process version:
Last reviewed:
Next review:
Approver:

This is a copyable writing structure, not an importable Shotomatic template. Store it in the document system where your team manages approvals and revisions.

Test the SOP and assign maintenance

The test should use someone with the intended role and expected experience level. Ask them to complete the process using only the SOP, then record missing prerequisites, ambiguous steps, and results that were difficult to verify.

The owner should update the verified product version and review date after corrections. Review the SOP when the interface changes, the process owner changes, a linked work instruction changes, or an exception becomes common enough to join the main path. Use the change-audit process in How to Keep Screenshot Documentation Up to Date when only part of the visual procedure needs replacement.

Action Capture helps collect and edit the visual steps, but the process boundary, roles, controls, and maintenance plan make the result an SOP. For the click-by-click capture workflow, see How to Create a Step-by-Step Guide from Clicks on Mac.