Most SOP examples show you how to list steps. Almost none show you how to capture the workaround only one person in the company knows. That gap is where the real time leaks out.
Here is a working sop example built around a single, painfully familiar process: what happens when a customer's payment fails. In most small companies, this process lives entirely in the founder's head. The billing rep retries the card, it fails again, and then everyone waits — for you. Do we discount? Do we write it off? How many retries before we give up? Every one of those questions routes back to the same person.
This article walks through a filled-in SOP that fixes that, including the decision block that makes it work.
Key takeaways
- A useful SOP documents not just the steps, but the decisions people are allowed to make without asking you.
- The three workarounds founders usually keep in their heads — retrying a card, offering a retention discount, and writing off a small balance — can be written as four-column decision rights.
- Every decision right needs a limit and an escalation trigger, or it just moves the waiting somewhere else.
- Once the decisions are written down, the SOP becomes something a new hire can run on their first day.
Why your SOPs keep failing (it's not the steps)
When people search for a sop example, they usually want to see the format. Steps, owners, tools, timings. That part is easy and it is also the part that rarely fails.
The failure is almost always at the decision points. The step says "handle the failed payment." It does not say who decides whether to retry, discount, or write it off. So the person doing the work does the only sensible thing: they escalate. And you, the founder, spend your afternoon approving small calls that a team lead could have made.
This is the quiet cost of undocumented decision rights. Not dramatic, just constant. A message here, a quick question there, a customer waiting two hours for an answer that should have taken two minutes. It does not feel like a crisis. It feels like your job.
It isn't. It's a missing line in a document.
The sop example: failed payment retry
Start with the plain steps. This part you probably already know how to write.
| Step | What happens | Owner |
|---|---|---|
| 1 | Billing system flags a failed payment and notifies the customer | Automated |
| 2 | Billing rep reviews the account and checks for a known card issue | Billing rep |
| 3 | Card is retried according to the retry rule | Billing rep |
| 4 | If it still fails, apply a retention or recovery decision | See decision rights |
| 5 | Log the outcome and set the next follow-up | Billing rep |
Step 4 is where every real company's SOP goes blank. Let's not leave it blank.
The decision rights block (the part most templates leave out)
Instead of describing what to do in prose, write the workarounds as a table with four columns: the decision, who may decide, the limit, and when to escalate.
| Decision | Who may decide | Limit | Escalate when |
|---|---|---|---|
| Retry the card | Any billing rep | Up to 3 retry attempts | Card issuer flags fraud, or account is already past due on a payment plan |
| Offer a retention discount | Team lead | Up to 10% off | Customer asks for more than 10%, or the account has had a discount applied in the current term |
| Write off the outstanding balance | Ops manager | Balances under $100 | Balance is $100 or more, or the customer disputes the charge |
Read that table as a set of permissions, not instructions. It says: if the card fails, a billing rep does not need to ask anyone before retrying it three times. If the customer is on the edge of leaving, a team lead can offer up to ten percent without a meeting. If the amount is small and the fight isn't worth it, an ops manager can close it out.
Each row answers three questions the team would otherwise ask out loud: Can I do this? How far can I go? When do I stop and get someone else?
Notice what the escalate column does. It protects you from being surprised by the big cases while keeping you out of the small ones. You are not removing oversight. You are aiming it at the decisions that actually deserve your attention.
Why writing it down changes behavior
A workaround you carry in your head is a bottleneck by design. Nobody can use it without you, so everyone waits, and the process effectively stops at your inbox.
The same workaround written as a decision right behaves differently. A billing rep facing a failed payment has three clear options and a boundary for each. They act. The customer gets an answer while they are still on the page. You find out about it later, in a log, which is exactly when you want to find out about it.
There is a second effect that matters more over time. Once decisions are documented, they become reviewable. You can look at the log and see whether the limits were right. Maybe ten percent is too generous, maybe three retries is too few. You cannot tune a habit. You can tune a rule.
That is the difference between tribal knowledge and an actual process. Tribal knowledge lives in one person and dies with their attention span. A written decision right outlives the conversation that created it.
How to build yours in 15 minutes
You do not need a formal documentation project. Pick one process where your team currently waits on you — failed payments, refunds, discount approvals, expedited shipping, whatever generates the most messages — and do this:
- Write the five or six steps in plain language with an owner for each. Do not polish it.
- Find the step where people pause. That is your decision point.
- List the three workarounds you personally use when you handle it yourself.
- Turn each one into a row: decision, who may decide, limit, escalate when.
- Hand it to the person who does the work and ask them to run it for a week.
- Adjust the limits based on what actually happened, not what you imagined.
The first draft will be imperfect. Ship it anyway. An imperfect documented decision is still faster than a perfect one that only exists in your head.
If you want the structure already laid out, the free SOP template at https://tools.exiuss.com/sop-template walks you through it. Fill in the form and you get a clear, ready-to-use standard operating procedure. Click "Fill with an example" and you will see exactly how decisions are written as decision, who may decide, limit, escalate when — using the same failed-payment scenario above.
Quick checklist
- Pick one process where your team waits on you to decide
- Write the steps with a named owner for each
- Mark the step where people pause and ask
- List the three workarounds you use when you handle it yourself
- Convert each workaround into decision, who may decide, limit, escalate when
- Give it to the person doing the work and review the limits after one week
Documenting one decision block takes less time than answering the same question five times. Start with the failed payment. Then do the next one.