How to Create an SOP with Screenshots

A standard operating procedure tells people how a recurring task is done, every time, by anyone in the role. Screenshots make the software parts of an SOP easier to follow, especially for tasks done once a month or less.

This post covers what belongs in an SOP, how it differs from work instructions, and how to capture the steps on a Mac with Temposhot.

What is an SOP?

An SOP is a controlled document that defines a repeatable process: its purpose, scope, the roles involved, the steps and the checks. Teams use SOPs for tasks where consistency matters, such as month-end closing, customer refunds, user offboarding or release checks.

A visual SOP adds a screenshot to each software step. The text stays the authority, and the screenshot shows where the step happens.

SOP vs work instructions

The two terms are often mixed. The difference is level of detail.

	SOP	Work instruction
Covers	A whole process, possibly across roles	One task within the process
Answers	What happens, who does it, when	Exactly how to do one task
Typical length	A few pages plus linked instructions	One task, step by step
Screenshots	Optional overview	One per step

In practice, a visual SOP often contains short work instructions as sections. A long screenshot sequence is better as a linked work instruction.

Define the process boundary

Write the first and last event of the process in one line each. "Starts when a refund request is approved. Ends when the customer receives the refund confirmation." Anything outside those lines belongs in another SOP.

A clear boundary keeps the document short and tells readers whether they are in the right place.

List inputs, roles, and prerequisites

Before the steps, list what must be true for the process to start:

• Inputs: documents, IDs, approvals the person needs in hand.
• Roles: who performs each part, who approves, who is informed.
• Access: systems and permission levels required.
• Timing: deadlines or frequency, such as "by the third working day of the month".

A reader who lacks an input should find out on page one, not at step nine.

Run the current process and capture the steps

Record the process as it is done today, by someone who does it regularly. Use a test or sandbox account when the real process would move money or change customer records.

1. Configure the run

   On the Action Capture page (Command+3), open Configure. Turn on Parse clicked elements with the title template Click "[[element-name]]", and turn on Mark clicked area.

2. Start Action Capture

   Select Start Action Capture and choose Active Window for processes that move between apps, or Capture Area for a fixed region.

3. Perform the process

   Each accepted click saves the screen just before the click. Use Capture now or Shift+Command+2 for screens that need no click, such as a status that changes after processing.

4. Pause for side tasks

   Select Pause capture when you leave the process to check email or chat, then Resume capture.

5. Finish capture

   Select Finish capture. The Document opens in the editor with one page per step.

In the editor, rewrite each title to start with a verb and name the control, and put conditions in the Page description. The Action Capture guide explains the capture targets.

Split a long workflow into smaller guides

If a recording passes about 15 to 20 steps, look for natural breaks: a handoff between roles, a waiting period, a different system. Make each part its own guide and link them from the SOP in order.

Short guides are easier to update. When one system changes, you replace one guide, not a long document.

Add controls, exceptions, and stop conditions

A process document is incomplete without what to do when things go wrong.

• Controls: checks that confirm a step worked, such as "The status shows Refunded."
• Exceptions: known variations and how to handle them. "If the order is older than 90 days, follow the manual refund SOP."
• Stop conditions: when to stop and escalate. "If the amount differs from the request, stop and contact Finance."

Add a warning on pages before irreversible actions. A short Text label (T) or a Rectangle (R) around the confirm button draws attention without clutter.

Use this visual SOP structure

1. Title, SOP ID, version, effective date, owner.
2. Purpose and scope (process boundary).
3. Roles and responsibilities.
4. Inputs, access and prerequisites.
5. Procedure: linked work instructions with screenshots.
6. Controls, exceptions and stop conditions.
7. Related documents.
8. Revision history.

Export each work instruction with Export PDF. With Pro, the PDF dialog adds a cover page, step numbers and page numbers, and places descriptions before or after each screenshot. Put the SOP ID and version on the cover. The export guide lists the other formats.

Test the SOP and assign maintenance

Ask someone who has not done the process to follow the SOP on a test account while the author watches without helping. Every question marks a gap.

Then name one owner, set a review date, and list review triggers: a system update, a policy change, an incident. Documents live locally on the Mac that recorded them, so the owner should keep the source Document there and re-export after each change.

Frequently Asked Questions

Should every SOP step have a screenshot?

Software steps benefit from one screenshot each. Steps outside software, such as "Call the customer", need none.

How often should an SOP be reviewed?

On every trigger (system change, policy change, incident) and at a fixed interval your organization sets, commonly once or twice a year.

What is the difference between an SOP and a checklist?

A checklist lists items to confirm. An SOP explains the process, roles and steps. Many SOPs end with a checklist. See the screenshot tutorial checklist.

Turn your clicks into a clear step-by-step guide

Action Capture records the procedure once and gives you ordered, editable steps for the SOP. Download Temposhot and capture the process as it is done today.