A standard operating procedure (SOP) is a written, repeatable description of how one task gets done in your business. A good SOP lets someone who has never done the task do it correctly, and lets someone who does it every day check that they have not drifted.
This page gives you the parts every SOP needs, four formats to choose from, and a complete worked example below. Copy the template at the top of the page, or download the format that fits your task from the side panel.
What an SOP template contains
Every SOP, whatever its format, answers the same questions. Keep these sections, in this order:
- Title and ID. A plain name for the task (“Process a customer refund”), plus an ID or version number if you keep many SOPs.
- Purpose. One or two sentences on why the procedure exists and what goes wrong without it.
- Scope. What the procedure covers and, just as important, what it does not.
- Roles and responsibilities. Who owns the procedure, who does each part, and who approves.
- Before you start. Tools, access, documents and information the person needs in hand.
- Procedure. The steps themselves, in the format you choose below.
- Exceptions and escalation. What to do when the normal path does not apply, and who to ask.
- Records to keep. What gets saved, where, and for how long.
- Review. Who reviews the SOP, how often, and when it was last changed.
Which format to use
| Format | Best for | Example |
|---|---|---|
| Step-by-step | Linear tasks done in a fixed order | Processing a refund, running payroll |
| Checklist | Routine tasks the person already knows how to do | Opening or closing a location, pre-event equipment check |
| Hierarchical | Long tasks where steps have their own sub-steps | Onboarding a new client, month-end close |
| Flowchart | Tasks where the path depends on decisions | Support escalation, approving a discount |
You can mix formats. A hierarchical SOP often ends with a checklist, and a flowchart usually needs a written version for anyone reading on a phone or using a screen reader.
How to write a good SOP
- Write it with the person who does the job. Watch them do it or record a walkthrough, then write down what they actually do, not what the process is supposed to be.
- Start every step with a verb. “Open the refund form”, not “The refund form should be opened”.
- Say who does each step when more than one person is involved.
- Put numbers in. Deadlines, amounts and thresholds are what people forget. Write “within 2 business days”, not “promptly”.
- Test it. Hand the draft to someone who has not done the task and watch where they get stuck.
- Give it an owner and a review date. An SOP nobody owns goes stale.
Worked example: step-by-step SOP
This example uses the step-by-step format. Replace the bracketed values with your own.
Process a customer refund
SOP ID: FIN-004
Version: 1.0
Owner: [Finance lead]
Last reviewed: [date]
Purpose
Make sure every refund is approved, paid back to the right place and recorded, so customers get their money on time and the books stay accurate.
Scope
Covers full and partial refunds for products and services paid by card or bank transfer. Does not cover chargebacks or disputes raised through a card issuer; those follow the chargeback SOP.
Roles and responsibilities
| Role | Responsibility |
|---|---|
| Support agent | Receives the request, checks eligibility, submits it for approval |
| [Finance lead] | Approves refunds and issues payment |
| [Operations manager] | Approves refunds above [$500] and all exceptions |
Before you start
- Access to [payment processor] and [accounting software]
- The customer’s order number and original payment method
- The current refund policy, found at [link]
Procedure
- Log the request. Support agent creates a ticket in [helpdesk] within 1 business day of the customer asking, and records the order number, amount and reason.
- Check eligibility. Support agent confirms the order is within the refund window in the policy and that it has not already been refunded.
- If it is outside the window, go to Exceptions below.
- Submit for approval. Support agent sets the ticket to “Refund pending” and assigns it to [Finance lead]. Refunds above [$500] also go to [Operations manager].
- Approve or decline. Approver reviews the ticket within 2 business days and marks it approved or declined with a reason.
- Issue the refund. [Finance lead] refunds to the original payment method in [payment processor]. Never refund to a different card or account without written approval from [Operations manager].
- Record it. [Finance lead] records the refund in [accounting software] against the original invoice and adds the transaction ID to the ticket.
- Tell the customer. Support agent emails the customer using the “Refund issued” template, including the amount and expected timing, and closes the ticket.
Checklist
- Request logged with order number and reason
- Eligibility checked against the policy
- Approval recorded on the ticket
- Refunded to the original payment method
- Recorded in accounting software
- Customer notified and ticket closed
Exceptions and escalation
Requests outside the refund window, requests to refund a different payment method, and any refund where the customer is upset or threatening a dispute go to [Operations manager] before anything is paid.
Records to keep
The ticket, the approval, and the processor transaction ID, kept in [helpdesk] and [accounting software] for [your required retention period].
Review
[Finance lead] reviews this SOP every [6 months], and whenever the refund policy or payment processor changes.
Download the other formats
The same structure works in every format. Use the download links to get a blank template for each:
- Step-by-step: numbered steps with sub-steps, like the example above.
- Checklist: a tick list grouped by stage, for tasks people already know.
- Hierarchical: numbered sections (1, 1.1, 1.1.1) for long procedures.
- Flowchart: a Mermaid diagram with a written version of the same flow, for procedures with decisions.