SOP vs Work Instructions vs Process Documentation

Last updated: January 2026

TL;DR

Process documentation describes what happens across a whole workflow, end to end. A standard operating procedure (SOP) describes how one team performs a single procedure within it. A work instruction describes exactly how one person completes one task inside that procedure. They are the same subject at three zoom levels: process, procedure, task.

These three terms get used interchangeably, and the confusion is understandable. They all describe how work gets done. But they are not synonyms; they are three levels of zoom on the same subject. Getting the distinction right stops you from writing a fifty-page “SOP” that is really a process map, or a “process document” nobody can act on because it is actually a pile of click-by-click steps.

Below, each term gets a plain definition, then the scope, audience, and detail that separate it from its neighbours, followed by a side-by-side table, a worked example that flows through all three, and a short decision guide. If you are ready to write one, our guide to writing an SOP goes step by step, the SOP template gives you a starting format, and the SOP software page covers the tools that create and maintain these documents. The full field is on the comparison hub.

What is process documentation?

Process documentation is a record of an entire workflow from start to finish: every stage, decision, hand-off, and role involved in getting from trigger to outcome.

Its job is to show the whole picture: what happens, in what order, who owns each step, and where work passes from one team or system to the next. Because it operates at the workflow level, process documentation is usually the most abstract of the three: think flowcharts, swimlane diagrams, and stage-by-stage narratives rather than button-level detail.

Scope: an end-to-end process, often spanning multiple teams. Audience: managers, process owners, auditors, and new joiners getting oriented. Granularity: high-level stages and hand-offs, not individual clicks. Example: the complete employee onboarding process, from signed offer to a fully productive first week.

What is a standard operating procedure (SOP)?

A standard operating procedure is a set of ordered steps that defines how one team carries out a single, repeatable procedure the same way every time.

An SOP sits one level below process documentation. Where a process map shows that “IT provisions the new hire” as one box, the SOP is the contents of that box: the actual steps, the person responsible for each, the standard the output must meet, and how to handle common exceptions. It is detailed enough to act on but stops short of narrating every keystroke. That is a work instruction's job.

Scope: one repeatable procedure owned by a single team. Audience: the team accountable for the procedure. Granularity: ordered steps, responsibilities, standards, and exceptions. Example: the IT team's SOP for provisioning a new hire's accounts and hardware.

What is a work instruction?

A work instruction is a granular, step-by-step description of exactly how one person performs one specific task, down to the individual clicks, fields, and settings.

A work instruction is the deepest zoom. It takes a single step of an SOP that is too intricate to describe in a line (often a software task) and spells it out completely, so that someone who has never done it can complete it correctly on the first try. This is the level where screenshots earn their place: one action per step, the exact field values, and a clear success state at the end.

Scope: one specific task at one screen or workstation. Audience: the individual doing the task, often new or occasional. Granularity: literal click-by-click steps, usually with screenshots. Example: how to create a user in the admin console, field by field.

Side by side

The clearest way to hold the three apart is to line up the dimensions where they differ: scope, audience, level of detail, owner, update cadence, and a concrete example.

DimensionProcess documentationSOPWork instruction
ScopeAn entire end-to-end process, often across teams and systemsOne repeatable procedure owned by a single teamOne specific task performed at one workstation or screen
Question it answersWhat happens, in what order, and who owns each hand-off?How does our team consistently carry out this procedure?Exactly which buttons, fields, and clicks complete this task?
AudienceManagers, process owners, auditors, new joiners orientingThe team responsible for the procedureThe individual doing the task, often a new or occasional operator
Level of detailHigh-level: stages, decisions, hand-offs, rolesMedium: ordered steps, responsibilities, standards, exceptionsGranular: literal click-by-click steps with screenshots
Typical ownerOperations lead or process ownerTeam lead or subject-matter expertThe practitioner who performs the task
Update frequencyRarely, only when the workflow itself is redesignedOccasionally, when the procedure or standard changesOften, whenever the underlying tool or screen changes
ExampleThe full employee onboarding processThe IT team's SOP for provisioning a new hire's accountsHow to create a user in the admin console, step by step

The hierarchy: one example through all three

The three levels nest: a process contains several SOPs, and an SOP contains several work instructions.

Employee onboarding makes the nesting concrete. Follow one thread from the widest zoom to the narrowest.

Level 1: Process documentation

The employee onboarding process

A workflow spanning HR, IT, and the hiring manager: offer accepted → paperwork and payroll set up (HR) → accounts and hardware provisioned (IT) → first-week plan and introductions (manager) → new hire productive. It shows the stages and hand-offs; it does not say how any one team does its part.

Level 2: SOP (zoom into the IT box)

SOP: Provisioning a new hire's accounts and hardware

The IT team's procedure: create the user in the identity provider, assign the correct group and licenses, order and image a laptop to the standard build, grant access to the team's core apps, and confirm first-day login works. Each step names a responsible person and the standard to meet, but it does not narrate every click of creating the user.

Level 3: Work instruction (zoom into one SOP step)

Work instruction: Create a user in the admin console

The click-by-click for that one step: open the admin console, go to Directory → Users, click Add user, fill in the naming-convention email and department fields, assign the “All Staff” group, set “require password change on first login,” and click Create. A screenshot per screen, one action per step, ending at the confirmation that the user exists.

Which one do you need?

Work backwards from what is actually going wrong. A quick decision tree:

Do things break at the hand-offs between teams?

→ You need process documentation. The problem is the seams, not the steps. Map the whole workflow and make ownership of each hand-off explicit.

Does one team do the same procedure inconsistently, or does it live only in one person's head?

→ You need an SOP. Capture the ordered steps, responsibilities, and standard so anyone on the team can follow it the same way.

Do people get stuck on one intricate, click-heavy task, usually in software?

→ You need a work instruction. Document that single task step by step with screenshots so a first-timer can complete it unaided.

Most teams end up with all three over time, linked together. If you are starting from nothing, begin with the SOP for your most error-prone procedure (it is the most useful single document), and add the level above or below only when the SOP alone stops being enough.

Where a capture tool fits

Work instructions are the level most painful to write by hand, because they demand a current screenshot for nearly every step. This is where automatic-capture tools help: Dubble watches you perform a task once and turns it into a step-by-step guide with screenshots and video, so a work instruction is produced as a byproduct of doing the work rather than as a separate documentation chore. Because those captured guides paste cleanly into Notion, Confluence, or Google Docs, you can compose several of them into an SOP and reference that SOP from a higher-level process map, building the hierarchy from the bottom up. It does not replace the judgement of writing a good SOP or mapping a process; it removes the manual screenshot work at the task level where most documentation efforts stall.

Frequently asked questions

No. An SOP and a work instruction sit at different levels of detail. An SOP describes how a team carries out a whole procedure (the ordered steps, who is responsible, and the standard to meet) while a work instruction zooms into one task within that procedure and spells out the exact clicks, fields, and settings for one person to complete it. A single SOP usually references several work instructions; the SOP is the recipe, the work instruction is how to operate one appliance in the kitchen.

Standard operating procedures define how a team performs one repeatable procedure consistently, at a medium level of detail: ordered steps, responsibilities, standards, and exceptions. Work instructions define exactly how one person completes one task inside that procedure, at the highest level of detail: literal click-by-click steps, usually with screenshots. The SOP answers 'how do we do this procedure the same way every time?'; the work instruction answers 'which specific buttons do I press to do this one task?'

Enough that someone who has never done the task can complete it correctly on the first attempt without asking a colleague. In practice that means one action per step, a screenshot for any screen where the correct control is not obvious, exact field values or naming conventions, and a clear success state so the reader knows the task is done. If a step assumes prior knowledge of the tool, it belongs in an SOP or a prerequisite, not a work instruction.

ISO 9001:2015 does not mandate the terms 'SOP' or 'work instruction' at all. It replaced the older ISO 9001:2008 vocabulary of 'documented procedures' and 'work instructions' with the single umbrella term 'documented information.' The standard requires you to maintain and control the documented information needed for your processes, but leaves the naming and structure to you. Most quality teams still keep a hierarchy of process maps, SOPs, and work instructions in practice because it maps cleanly onto documented information at different levels; ISO simply no longer prescribes the labels.

Small teams often start with SOPs alone and are fine. You add process documentation when a workflow spans multiple teams and the hand-offs, not the steps, are where things break. You add separate work instructions when an SOP step is too intricate to describe in a line (a click-heavy software task, say), and cramming the detail inline would make the SOP unreadable. Split them when combining them hurts clarity, not before.

Start in the middle, with the SOP. It is the most useful single artifact because it captures a whole procedure at a level people can act on. Map the broader process only once you have a few SOPs and can see the hand-offs between them, and break out standalone work instructions only for the individual steps that turn out to need click-by-click detail. Building top-down from an abstract process map tends to produce diagrams nobody uses.

They overlap but are not identical. A work instruction is the complete, authoritative description of how to perform a task correctly. A job aid is a condensed reference (a checklist, a one-page cheat sheet, a laminated card at the desk) designed for someone who has already learned the task and needs a quick reminder. A good job aid is usually distilled from a work instruction; the work instruction teaches, the job aid reminds.

Wherever your team already works, ideally in one searchable knowledge base rather than scattered across drives. What matters more than the tool is that each level links to the next: the process map links to its SOPs, and each SOP links to the work instructions for its detailed steps. That cross-linking is what turns three separate documents into a system someone can navigate from 'what happens' down to 'which button do I press.'

Turn a task you just did into a work instruction

Dubble captures your screen while you work and produces a step-by-step guide with screenshots and video, free to start, and it pastes straight into your SOPs and knowledge base.