How to write an SOP people actually follow.
A practical method from 20 years of running delivery teams: what goes in, how to write steps that cannot be misread, and how to keep procedures alive after launch.
| Company | Northwind Studio | SOP ID | SOP-CS-RR-01 |
|---|---|---|---|
| Version | 1.0 | Department | Customer support and success |
| Owner | Support Agent | Approved by | Support Lead |
| Effective date | 2026-10-01 | Review | Every 12 months, or after a policy or pricing change |
1. Purpose
To process refunds and returns quickly and fairly while protecting [Company] from fraud and errors. It makes decisions consistent with the published refund policy.
2. Scope
Covers refunds for subscriptions and services and returns of physical goods requested by customers. It does not cover chargebacks already raised with a card issuer, which go to Finance, or supplier returns.
3. Definitions
| Term | Meaning |
|---|---|
| RMA | Return merchandise authorisation number issued before goods are sent back. |
| Goodwill refund | A refund outside policy approved as an exception. |
| Pro-rata refund | Refund for the unused part of a subscription period. |
4. Roles and responsibilities
| Role | Responsibilities |
|---|---|
| Support Agent | Receives requests, checks eligibility and processes refunds within their limit. |
| Support Lead | Approves refunds above the agent limit and goodwill exceptions. |
| Finance | Approves refunds above [finance limit], reconciles and handles chargebacks. |
| Warehouse Operative | Receives, inspects and restocks returned goods. |
5. Prerequisites, tools and materials
- Published refund and returns policy
- Access to [billing or payment system] with refund permissions by limit
- Return label or RMA process
- Refund log
6. Procedure
| # | Step and how | Owner |
|---|---|---|
| 6.1 | Log the request Record order or invoice number, reason code and requested amount in the ticket. | Support Agent |
| 6.2 | Check eligibility Check the request against policy: time window, usage, condition of goods and previous refunds on the account. | Support Agent |
| 6.3 | Try to resolve first Where the cause is a fixable issue, offer a fix or replacement, but never block a refund the customer is entitled to under policy or law. | Support Agent |
| 6.4 | Get approval by limit Agents approve up to [agent limit], Support Lead up to [lead limit], Finance above that. Goodwill exceptions always need Support Lead approval. | Support Lead |
| 6.5 | Issue RMA for physical goods Send the RMA number, return address and label with packing instructions within 1 business day. | Support Agent |
| 6.6 | Inspect returned goods Inspect within 2 business days of receipt, record condition and photos, and restock, refurbish or write off. | Warehouse Operative |
| 6.7 | Process the refund Refund to the original payment method within [5] business days of approval or receipt of goods. | Support Agent |
| 6.8 | Confirm to customer Send confirmation with amount, method and expected bank timing, and close the ticket with a reason code. | Support Agent |
| 6.9 | Reconcile monthly Match refunds in the payment system to the refund log and accounting records and investigate differences. | Finance |
| 6.10 | Review reasons Monthly, report refund volume and top reasons to product and operations for root-cause fixes. | Support Lead |
7. Quality checks and controls
- Every refund above agent limit has recorded approval
- Refunds go only to the original payment method
- Returned goods inspected before refund where policy requires
- Monthly reconciliation signed off
8. Measures of success (KPIs)
| Measure | Target |
|---|---|
| Refund processing time | 95% within 5 business days of approval |
| Refund rate | Below [x]% of revenue |
| Reconciliation errors | Zero unexplained differences |
| Chargeback rate | Below [0.5]% of transactions |
9. Risks and controls
| Risk | Control or mitigation |
|---|---|
| Refund fraud or abuse | Account history check and approval limits |
| Refund to wrong account | Original payment method only and no manual bank details by email |
| Non-compliance with consumer law | Policy aligned with local consumer rights; check local law |
10. Related documents
- Refund and Returns Policy
- Customer Complaint Handling
- Accounts Receivable and Credit Notes
- Chargeback Handling
11. Revision history
| Version | Date | Change | By |
|---|---|---|---|
| 1.0 | 2026-10-01 | First issue | Support Agent |
| Name | Signature | Date | |
|---|---|---|---|
| Prepared by | A. Pandey | ||
| Approved by | Support Lead |
What an SOP is
A standard operating procedure is the agreed, written way a recurring task is done in your business. It names who does each step, in what order, to what standard and how the result is checked. The goal is simple: anyone trained on it gets the same result, whether it is their first week or their fifth year.
Good SOPs are not paperwork for its own sake. They let you hand work over without losing quality, train new people faster, pass audits, and see where a process breaks when something goes wrong.
When you need one
Write an SOP when a task meets any of these tests:
- It happens more than once a month, or rarely but with high stakes (a data breach, a fire drill).
- More than one person does it, or it passes between teams.
- A mistake costs money, customers, safety or compliance.
- A new starter would have to ask someone how it is done.
- An auditor, investor, insurer or regulator may ask how you control it.
Start with the five processes that cause the most rework or questions. In most startups that is onboarding, invoicing, refunds, access management and product releases.
The 11 parts of a complete SOP
- 01Document controlID, version, owner, approver, effective and review dates.
- 02Purpose and scopeWhy it exists, who it covers and what it does not.
- 03DefinitionsThe terms a new starter might not know.
- 04Roles and responsibilitiesWho does what, so every step has an owner.
- 05PrerequisitesAccess, tools, forms and training needed first.
- 06ProcedureNumbered steps, each with an owner, timing and limits.
- 07Quality checksThe control points that catch mistakes.
- 08KPIsHow you know the process is working.
- 09Risks and controlsWhat can go wrong and what stops it.
- 10Related documentsForms, policies and linked SOPs.
- 11Revision history and sign-offEvery change, and who approved it.
Keep the order the same in every SOP. People learn where to look, and reviewers can compare documents quickly.
Writing steps that cannot be misread
- Start with a verb. "Check the bank details against the vendor master file", not "Bank details check".
- One action per step. If a step has "and then", it is probably two steps.
- Name an owner. A role, not a person, so the SOP survives staff changes.
- Give numbers. "Within 1 business day", "above 5,000", "three attempts". Vague words like "promptly" or "large" get read differently by everyone.
- Say what to do when it goes wrong. Add the exception or escalation path right where it happens.
- Write for the newest person. Spell out acronyms in the definitions, and link the forms and systems they will need.
Choosing a format
Match the format to the work. This tool uses a numbered step table with owners, plus an optional flow line, which suits most business processes.
- Step list: short, linear routines such as opening a store.
- Step table with owners: processes that move between roles, like hiring or invoicing.
- Hierarchical steps: long procedures where some steps have sub-steps.
- Flowchart: processes with decisions and branches, such as ticket triage.
- Checklist: a companion to any SOP, used on the job to confirm each step was done.
Rolling it out and keeping it alive
- Draft with the person who does the work.
- Test by having someone new follow it without help. Fix every place they stop.
- Approve and give it an ID, version and effective date.
- Train everyone affected and record who was trained.
- Measure the KPIs for a month or two.
- Review on the set cycle, or after any incident, and log each change in the revision history.
This is the Plan, Do, Check, Act cycle that ISO 9001 and Lean teams use. The SOP is the "standard" that each improvement builds on.
Common mistakes
- Writing how the process should work instead of how it does work, so nobody follows it.
- Huge documents that try to cover every case. Split them.
- No owner, so it is never updated.
- Steps without timing, limits or an escalation path.
- Copying a template without replacing the placeholders and local rules.
- Launching without training, then blaming people for not following it.
Questions
What is the difference between a policy, an SOP and a work instruction?
A policy says what the rule is and why. An SOP says how the process runs across people and teams, step by step. A work instruction goes deeper into one task at one workstation, often with screenshots or photos. Checklists are the shortest form, used to confirm the steps were done.
Who should write an SOP?
The person who does the task every day writes the first draft, because they know the real steps. The process owner edits it, and someone who has never done the task tests it before it is approved.
How often should SOPs be reviewed?
At least once a year, and straight away after an incident, an audit finding, a new tool or a change in the law. Put the review date in the document control block so it is not forgotten.
How many steps should an SOP have?
Most work well with 6 to 15 steps. If you need more than about 20, split the process into separate SOPs and link them.
What makes an SOP audit-ready?
A unique ID, a version number, a named owner and approver, an effective date, a review date, a revision history and evidence that people were trained on it. Auditors also check that what people actually do matches the document.