Most guides on how to write an SOP start in the same place: list the steps, number them, save the document. That order is why so many SOPs go unread. A procedure only helps if the people following it are allowed to act, so start with the decisions instead. Write down every choice the process currently pushes back to you, give each one an owner, a limit, and an escalation trigger — then write the steps. Do it in that order and the procedure becomes something your team can run without you.
Key takeaways
- A useful SOP answers two questions: what happens next, and who is allowed to decide when it does not go to plan.
- Write the decision table before the steps, because decisions — not tasks — are where processes actually stall.
- Every decision row needs four fields: the decision itself, who may make it, the limit of that authority, and when it escalates.
- Once decisions have owners, the numbered steps become instructions a team can follow without checking in with you.
Why steps-first SOPs stay unread
You know the pattern. Someone writes the procedure, it is accurate, it is thorough, and it gets ignored the moment reality diverges from step four. The reason is structural. Most processes are full of branches where the next move depends on a judgment call, and if the document does not say who may make that call, the answer defaults to "ask the person who wrote it."
That person is usually you. So the SOP becomes a map with a locked door at the end of every corridor. The team follows the steps happily until they reach the door, then they wait. Nothing in the document is wrong. It is simply incomplete in the one place that matters.
How to Write an SOP: Decisions First, Steps Second
This is the whole method. Five moves, in this order.
Step 1: List the decisions that currently wait for you
Do not start with the tasks. Start with your interrupts. Think back over the last month of a single recurring process — onboarding a vendor, approving spend, publishing content — and write down every moment someone stopped and asked you for a yes or a no.
Keep them phrased as decisions, not activities. "Approve vendor" is a decision. "Collect the tax form" is a step. You want the list of things that need human judgment before the process can move forward.
Step 2: Fill in four fields for each decision
For every decision on your list, write one row:
decision | who may decide | limit | escalate when
The limit is the boundary of that person's authority, written as a condition rather than a vague feeling. The escalation trigger is the situation where the limit is exceeded and the decision travels upward. Leave either blank and the row defaults back to "ask you," which is exactly the problem you are trying to solve.
This is also where a template earns its keep. The free SOP template at https://tools.exiuss.com/sop-template is built around this four-field table, so you are filling in blanks instead of inventing a structure from scratch. There is a "Fill with an example" button if you want to see how a finished row reads before you write your own.
Step 3: Test each row against last month
Read every row and ask one question: would this have handled the last few times someone asked me? If a real case would still have landed on your desk, the limit is too tight or the escalation trigger is too vague. Loosen the limit. Tighten the trigger.
Step 4: Write the steps — and point them at the table
Now, and only now, write the numbered procedure. At every point where the process could branch, instead of describing what you would decide, write: "If this happens, see the decision table — [decision name]." The steps stay short because the judgment lives in the table.
Step 5: Review escalations, not the document
The measure of an SOP is not how complete it looks. It is how many decisions reach you that should not have. Watch what escalates, and refine the rows rather than the prose.
A worked example: vendor onboarding
Suppose a handful of vendors come through your team each quarter, and every one lands in your inbox four times: approve the vendor, sign the contract, release payment, and occasionally waive a missing document.
You could write the steps first. Instead, list the decisions, then fill in the four fields.
| Decision | Who may decide | Limit | Escalate when |
|---|---|---|---|
| Approve a new vendor | Team lead | A like-for-like swap of an existing vendor, or any vendor already on the approved list | The vendor handles customer data or opens a category of spend that is new to you |
| Sign the contract | Operations manager | Standard terms, inside the approved budget line, no auto-renewal | Terms are amended, or the contract commits spend beyond the current quarter |
| Release payment | Operations manager | The deliverable matches the signed scope | The deliverable is partial or disputed |
| Adjust the scope of work | Relationship owner | The change stays inside the signed budget and timeline | The change pushes total cost past the approved amount |
| Waive a required document | Founder only | No standing authority | Always |
Once that table exists, the steps are almost administrative: request intake, document collection, contract routing, payment scheduling. Each step ends by pointing at a row. The team can move a vendor from request to paid without a single check-in, except in the cases the table says to bring you.
Notice what the table surfaced. The waiver row has no sensible limit, so it stays with the founder by design — and now the SOP says so out loud, which stops people from guessing. The payment row exposes a quieter bottleneck too: most delays were not about money at all, they were about scope changes nobody had authority to approve. Writing steps first would have buried both of those in a footnote, if it mentioned them at all.
The common mistake: limits that are really just "check with me"
The failure mode is a limit so cautious it changes nothing. "Team lead may approve vendors up to a small amount" sounds like delegation and behaves like a bottleneck, because nobody knows where the line is. A real limit is a condition someone can evaluate in the moment: on the approved list, standard terms, inside the signed scope. If a person cannot tell whether they are inside their authority without asking, they are outside it.
Quick checklist
- List every decision in the process that currently lands on you.
- Rewrite each one as a decision, not an activity.
- Fill in who may decide, the limit, and the escalation trigger for every row.
- Test each row against the last few real cases and adjust.
- Write the numbered steps, pointing every branch at a named row.
- Review what escalates after a few weeks and tighten the rows again.
Start with the table today
You can run this whole method on a single process in one sitting. Pick the one that interrupts you most, list the decisions, fill in four fields each, then write the steps. Fifteen minutes is enough to get a first draft that your team can actually use.
If you would rather not build the structure yourself, the free SOP template at https://tools.exiuss.com/sop-template pre-structures the decision table and drafts the procedure from your own inputs — free, no account gymnastics, nothing invented on your behalf. Fill in the form, get a clear SOP, and see how much of your week stops waiting on you.