Team Systems template
Standard Operating Procedure (SOP) Template
Published 3 August 2026 · Last reviewed 22 August 2026 · By Kayley Hart
What this template is for
Use this SOP to make a recurring process teachable and checkable. It records the trigger, owner, steps, evidence and escalation route so the work does not depend on one person remembering how it is done.
Use this template your way
Copy it into your own workspace, print it, save it as a PDF from your browser, or download a DOCX file to edit offline.
How to use this template
- Draft the SOP while observing the work, then ask a second person to follow it without verbal coaching.
- Keep individual steps short and state the expected evidence, rather than hiding important decisions in a long paragraph.
- Assign an owner and review date; amend the shared SOP whenever the process or tool changes.
Reusable document
Working template
Replace the bracketed prompts with facts about your own team. Keep the completed version in the shared place where the relevant people can use it.
1. Process title, purpose and trigger
Use a precise title and state the event that starts the work. A trigger makes it clear when the SOP applies and when it does not.
Process title: [name] Purpose: [result] Trigger: [event that starts this process]
2. Owner, inputs and timing
Name the role responsible, the information or tools needed and the service level or deadline for completing the process.
Owner: [role] Inputs / tools: [items] Complete by: [timing]
3. Numbered steps
Write each action in the order it happens. Include the decision rule at the point the person needs it, not in a separate hidden note.
1. [first action] 2. [decision or action] 3. [next action] 4. [record or handover]
4. Definition of done and evidence
State the visible end point and where the evidence lives, so a reviewer does not need to infer whether the process was actually finished.
Done when: [observable result] Evidence: [record, link or message] Quality check: [what to verify]
5. Exception, escalation and review
Name the situations that should not be handled normally, the person who decides and the date the SOP will next be reviewed.
Escalate when: [conditions] Escalate to: [role / route] Next review: [date and owner]
Illustrative only
Filled example
This example shows the level of specificity to aim for. Replace it with your own names, limits, dates and evidence rather than copying the facts.
1. Process title, purpose and trigger
Process title: Weekly customer refund review. Purpose: Resolve valid refunds consistently and keep the refunds log accurate. Trigger: A refund request enters the support queue.
2. Owner, inputs and timing
Owner: Operations coordinator. Inputs / tools: Support queue, order record, returns policy and refunds log. Complete by: Two working days after the request is received.
3. Numbered steps
1. Check the order date and the customer’s reason against the returns policy. 2. If the request meets policy and is £75 or less, approve it. 3. Send the standard confirmation email. 4. Log the amount, reason and date in the refunds sheet.
4. Definition of done and evidence
Done when: The customer has a clear decision and the financial record is updated. Evidence: Refunds-sheet row and sent confirmation email. Quality check: Amount matches the order record and reason is categorised.
5. Exception, escalation and review
Escalate when: The request is outside policy, above £75 or involves a complaint. Escalate to: Operations manager in #ops-escalations. Next review: 1 December 2026, owned by the operations manager.
Before you share it
Ask a colleague who did not write the SOP to complete a low-risk test case from the document alone. Their questions are the next improvements to make.