SOPs and process docs get used interchangeably, but they solve different problems. Here's how to tell them apart and when you need each.
A process document explains how something works — the shape of a workflow, who's involved, and why. It's meant to be read once to understand the system.
An SOP (standard operating procedure) is meant to be followed, not just read. It's step-by-step, specific, and written so that two different people executing it produce the same result.
A process document for customer support might describe how tickets flow from intake to resolution, including which team handles which category and how escalations work.
An SOP for handling a refund request would spell out the exact steps: which fields to check, what qualifies for an automatic refund versus manager approval, the exact wording of the response, and how to log it.
You can't build a meaningful QA scorecard against a process document — it's too high-level to check against. QA checks need an SOP to measure execution against, step by step. Teams that only have process documentation tend to have QA that's more about “does it feel right” than measurable consistency.
Start with a lightweight process document for the workflow as a whole, then write SOPs for the two or three highest-frequency or highest-risk steps inside it. You don't need an SOP for everything on day one — you need one for whatever a new hire would otherwise get wrong.
Book a short call and we'll talk through what this would look like for your team.