A sop example is only useful if it shows the decisions, not just the steps. Most templates hand you a numbered list — receive the complaint, log it, respond, close — and then leave the hardest part blank: who is actually allowed to say yes. The example below fills that part in. It is a complete complaint-handling procedure with a decision-rights block covering refunds, discounts, and escalations, written in a format you can copy straight into your own document.
Key takeaways
- A copyable SOP example has two halves: the steps anyone can follow, and a decision block that states who may decide what, within which limit, and when to escalate.
- Decision rights are written one row at a time as decision | who may decide | limit | escalate when, which turns "use your judgement" into something a team member can act on without asking.
- Refunds, discounts, and escalations are the rows complaint-handling SOPs most often miss — and they are exactly the rows that keep your queue waiting on you.
- You can build the same structure for your own process in about 15 minutes with the free SOP template at https://tools.exiuss.com/sop-template.
What a good SOP example actually shows
There are two parts to any working procedure. The first is the procedure itself — the sequence of steps that anyone who has done the task could write down. The second is the decision block, and this is where the value sits.
A procedure tells someone what to do. A decision block tells them what they are allowed to decide while doing it. Without the second part, every step that involves a judgement call funnels back to the person who wrote the document. That is the pattern most teams live with: the SOP exists, it is even followed, and the queue still stops at the owner's desk every time a customer asks for money back.
The decision block most SOP examples leave out
Write each decision as a single row with four fields:
- Decision — the call being made, described as an action, not a topic.
- Who may decide — a role, never a name, because roles survive people leaving.
- Limit — the boundary, expressed as a number or a clear scope.
- Escalate when — the specific trigger that moves the call up a level.
Four fields, one row per decision. That is the whole format. It stays small because it has to be readable at the moment someone is on a call with an unhappy customer.
A filled-in SOP example for handling a customer complaint
The procedure comes first and is deliberately short:
- Log the complaint in one place, with the customer's name, order reference, and what they are asking for.
- Restate the problem back to the customer in writing so there is a shared record of what is being fixed.
- Check the decision block below. If the fix sits inside a row your role owns, act now — do not ask.
- If the fix falls outside your limit or matches an escalation trigger, pass it up with a recommendation attached, not just the raw complaint.
- Close the loop with the customer once the action is done, and note which decision row was used.
The numbers and limits below are placeholders. Set your own — the shape of the block is what you are copying.
| Decision | Who may decide | Limit | Escalate when |
|---|---|---|---|
| Issue a refund | Support lead | Up to the full order value, once per order | The customer disputes the charge with their bank, or the order has already been refunded once |
| Offer a discount on the next order | Support lead | Up to 20% off | The customer asks for more than 20%, or the complaint involves a safety issue |
| Ship a replacement | Support lead | One replacement per order | A second replacement is requested on the same order |
| Waive a shipping fee | Any team member | Standard shipping only | The customer paid for expedited shipping |
| Close a complaint with no action | Support lead | Only when the customer agrees in writing | The customer replies after closure, or mentions leaving a public review |
| Change a published policy for one customer | Founder or manager | Any change | Never at team level — always a manager call |
How to read those rows
Start with the refund row. It does three things at once. It tells the support lead they can say yes to a refund without checking in. It caps the exposure at the order value, so a larger claim has to travel upward. And it names the escalation trigger — a bank dispute, or a repeat refund on the same order — so the lead knows precisely when to stop.
The discount row works the same way, but notice the second half of the escalate condition. A safety issue overrides the percentage limit, because the cost of getting it wrong is not measured in margin. Limits handle the ordinary case; escalate-when clauses handle the case that should never be handled quietly.
The last row is the one that quietly frees up the most time. Changing a published policy for one customer is almost always a founder decision, and writing that down means the team stops opening a thread every time. They escalate, they know why they are escalating, and they know it is not a failure on their part.
The common mistake
The mistake is writing limits as adjectives. "Reasonable discount." "Small refund." "Use your judgement." Each of those sentences sounds like delegation and behaves like a bottleneck, because the team member still has to check what reasonable means this week. A limit has to be a number, a scope, or a named condition — something two people would read the same way.
The second version of the same mistake is naming a person instead of a role. The moment that person is on holiday, the rule stops working.
Building your own in 15 minutes
Take the procedure above and replace the complaint steps with whatever your team actually does — onboarding a client, fulfilling an order, handling an invoice query. Then write the decision block honestly: list the calls your team currently brings to you, and turn each one into a row.
The free SOP template at https://tools.exiuss.com/sop-template walks you through both halves in a single form and gives you a clear, ready-to-use document at the end. If you want to see the decision rows written out before you start, click "Fill with an example" and it will show you how a row reads as decision | who may decide | limit | escalate when. Fifteen minutes of writing buys back the interruptions that currently fill your week.
Quick checklist
- Write the procedure as five or fewer numbered steps.
- List every decision your team currently brings to you, one per line.
- Add a row for each decision with all four fields filled: decision, who may decide, limit, escalate when.
- Replace every adjective limit with a number, a scope, or a named condition.
- Check that every role named is a role, not a person.
- Send the finished SOP to the team and tell them which rows they now own outright.