A sop template is a fill-in-the-blank document that turns a process you carry in your head into something your team can run without you. Most refund SOPs fail for one reason: they describe the happy path and leave the exceptions to you. This walkthrough shows how to fix that with a single block — decision, who may decide, limit, escalate when — and three filled-in examples for refunds under $50, refunds between $50 and $200, and anything over $200 or involving a chargeback.
Key takeaways
- A refund SOP that only covers the standard case creates a queue, because every unusual request still routes to the founder.
- The decision block — decision | who may decide | limit | escalate when — moves the common exceptions out of your inbox and into a written rule.
- Each row needs a real limit and a real escalation trigger, or the team will guess and you will end up re-deciding anyway.
- You can build the whole thing yourself in about 15 minutes using the free SOP template at https://tools.exiuss.com/sop-template.
Why refund SOPs break at the exception, not the rule
The refund itself is rarely the hard part. Someone asks for their money back, you check the order, you approve it, done. That part survives without documentation because it is obvious.
The break happens one step to the side. The customer wants a refund on a subscription they forgot to cancel. The order was placed eleven months ago. The payment is disputed with the card issuer. The customer is angry and threatening a public review. Each of those is a small variation, and each one lands on your desk because nobody wrote down what to do when the situation drifts off the standard path.
That is the pattern worth naming: the work that reaches you is not the work only you can do. It is the work nobody else was authorized to finish. The exception is where the queue forms, and the queue is where your week leaks out.
The block most sop templates leave out
A typical sop template gives you numbered steps, an owner, and a revision date. Useful, but incomplete. It tells someone what to do when everything is normal and says nothing about what to do when it isn't.
Add one table to the bottom of your refund SOP. Four columns:
| Decision | Who may decide | Limit | Escalate when |
|---|---|---|---|
| Approve a refund | Support rep | Up to $50 | Amount is $50 or more, or the order is older than the standard window |
| Approve a refund | Team lead | $50 to $200 | Amount exceeds $200, or the customer disputes the charge with their bank |
| Approve a refund | Founder | Above $200 | Chargeback is filed, or legal or press risk appears |
The value is not the table itself. It is that the table forces you to answer two questions you have been answering ad hoc: how much money can someone else commit without me, and what signal means stop and get me.
Filling in the three common exception rows
Here is the same block written out the way you would actually fill it in.
Row 1 — Refunds under $50
Decision: Approve a full refund and close the ticket. Who may decide: Any support rep. Limit: Up to $50 per refund, one per customer per order. Escalate when: The same customer requests a second refund on the same order, the order is outside the stated refund window, or the customer asks for credit instead of a refund.
This is the row that removes the most noise. Small refunds are a judgment call you do not need to make, and pricing them as a rep-level decision is what makes the queue disappear. Set the limit deliberately, not by accident.
Row 2 — Refunds between $50 and $200
Decision: Approve, partially approve, or decline a refund. Who may decide: Team lead. Limit: $50 to $200, including partial refunds that fall in that range. Escalate when: The amount exceeds $200, the customer has already received one refund in the last billing period, or the customer mentions a chargeback, a lawyer, or a public post about the company.
The middle band is where teams freeze. Too big to decide alone, too small to bother you. Naming a team lead as the decider — and giving them the authority to decline, not just approve — is what keeps the middle band from drifting upward.
Row 3 — Over $200 or a chargeback
Decision: Full refund, partial refund, or dispute response. Who may decide: Founder. Limit: No cap, but every decision gets logged with a one-line reason. Escalate when: Always. This row exists so the team knows the boundary is absolute, and so the founder sees every large or contested case instead of hearing about it after the fact.
Notice that "escalate when: always" is a complete instruction. Vague escalation rules like "use judgment" or "check with a manager" are what send people back to asking you.
Writing the rest of the SOP around the decision block
The decision table is the part that frees you up, but it needs a short process around it. Keep it to five or six steps.
- Confirm the order: customer name, order or subscription ID, date, amount, payment method.
- Check the request against the decision block and identify which row applies.
- If it falls inside your limit, decide and act. Log the decision, the amount, and the reason in one line.
- If it triggers an escalation, reply to the customer that the request is being reviewed, then escalate with the order details and the specific reason it escalated.
- Record the outcome in the same log, including declined requests.
- Review the log at a fixed interval and adjust the limits when the same exception keeps appearing.
That last step matters more than it looks. A recurring exception is a signal that the rule is wrong, not that the team is failing. When you see the same escalation three times, either the limit is set too low or the process is missing a case.
What this buys you
The measurable change is not really the dollars. It is the number of times per week someone has to wait for you before they can close a customer's request. That waiting is invisible on a calendar and expensive in practice: the customer waits, the rep stalls, and you get interrupted mid-task to answer something that could have been written down once.
When the decision block exists, three things shift. Reps stop guessing and start citing a rule. Team leads stop forwarding and start deciding. You stop being the exception handler and start being the person who sets the limits — which is the actual job.
This is what executive architecture looks like in practice: not a strategy document, just a written boundary that lets someone else finish the work.
Start with the free SOP template
You do not need to build the format yourself. The free SOP template at https://tools.exiuss.com/sop-template walks you through the sections in order, including the decision block, and you can write a usable SOP in about 15 minutes. Click "Fill with an example" to see how decisions are written as decision, who may decide, limit, escalate when — the refund rows above follow exactly that shape.
Quick checklist
- Write the standard refund steps in plain language, one action per line.
- Add the decision block with four columns: decision, who may decide, limit, escalate when.
- Fill a row for under $50 and name support rep as the decider.
- Fill a row for $50 to $200 and name the team lead, including the authority to decline.
- Fill a row for over $200 and any chargeback with a hard escalate-always rule.
- Share the finished SOP with everyone who touches refunds and log the first week of decisions.