Documenting a Process So Someone Else Could Run It
A Usable Standard Operating Procedure (SOP) Template
The real test of a documented process isn't whether it looks thorough — it's whether a reasonably capable person who's never done this task before could actually follow it and get the right result. That's the standard this template is built to meet.
If you haven't mapped the real process yet (workarounds and all), start with "Process Mapping 101" first — this template turns that honest map into a usable, written procedure.
The Template
Copy the structure below for each process you document.
---
Process Name: (Be specific — "Processing a Customer Refund Request," not "Customer Stuff.") Process Owner: (The person accountable for this procedure staying accurate — not necessarily the only person who can do it.) Last Updated: Purpose (1–2 sentences — why this process exists and what outcome it produces): Trigger (What specifically starts this process? A form submitted, an email received, a date on the calendar?): Inputs Needed (What information or materials have to be in hand before starting?):- -
Step-by-Step Instructions (numbered, one clear action per line, name who does each step):1. 2. 3.
Decision Points (If X, then Y — every branch in the process, written out):- If ___________, then ___________ - If ___________, then ___________
Tools / Systems Used:-
Common Exceptions and How to Handle Them (the things that don't go according to plan — and what to actually do when they happen):-
Output / "Done" Definition (How do you know this process is actually finished — not just that the main steps are complete?): Escalation / Backup Contact (Who to go to if something falls outside what this document covers?):---
A Filled-Out Example
(Illustrative only — written to show the template in use, not a real client's procedure.)> Process Name: Processing a Customer Refund Request > Process Owner: Customer Support Lead > Last Updated: date > Purpose: To issue a refund to an eligible customer accurately and within the stated turnaround time. > Trigger: A refund request is submitted through the support form or received by email. > Inputs Needed: Order number; reason for the request; confirmation the item meets the refund policy. > Step-by-Step Instructions: > 1. Support agent confirms the order number exists in the order system. > 2. Support agent checks the request against the refund policy's eligibility rules. > 3. If eligible, support agent processes the refund in the payment system. > 4. Support agent sends the customer a confirmation email with the refund amount and expected timing. > 5. Support agent logs the refund reason in the tracking sheet for monthly review. > Decision Points: If the order is outside the policy's return window, then escalate to the Support Lead for a manual exception review, rather than process automatically. > Tools / Systems Used: Order system, payment processor, refund tracking sheet. > Common Exceptions: If the payment method on file is expired or closed, the refund must be issued by the alternate method the finance team specifies — not guessed. > Output / "Done" Definition: Refund is confirmed processed in the payment system AND the customer has received the confirmation email. > Escalation / Backup Contact: Support Lead, for anything outside the stated eligibility rules.
Why This Format, Specifically
Two things separate a usable SOP from a document that just looks like one:
1. It names who does each step, not just what happens. "The request is reviewed" hides accountability. "The support agent reviews the request" doesn't. 2. It documents the exceptions, not just the happy path. A procedure that only describes the version where nothing goes wrong will fail the first time something does — and that's usually within the first week of real use.
A process documented this thoroughly is also the exact foundation an automation project needs — the "if X, then Y" logic above is the same logic a workflow tool or script would need to be given.
---
Want help turning a real process into a document like this? We can run the mapping and documentation session with your team. Book a free consultation →