Most processes don't fail loudly. They stall quietly, in a group chat, while everyone waits for one person to say yes. A weekly inventory reorder is the classic case: the steps are obvious, the timing is predictable, and the whole thing still grinds to a halt because nobody knows who can approve an emergency order.
That is the gap a standard operating procedure template is supposed to close — and most templates don't. They give you a numbered list of steps and stop there. The steps were never the problem. The problem is that the decisions inside the process live in your head, so the process only runs when you're available.
Key takeaways
- A process that fails silently is usually missing decision rights, not instructions.
- Before writing steps, list every decision inside the process that currently waits for you.
- Capture each one as: decision | who may decide | limit | escalate when.
- Write the steps as a plain checklist a new hire could follow on their first Monday.
- Put the decision table and the checklist in the same document, or the checklist will stall again.
Why the weekly reorder stalls (and why you don't notice)
Run the reorder on a normal week and it looks fine. Someone counts stock, someone compares it to the forecast, someone places the order. Nothing about that sequence is hard.
Now run it on the week you're on a plane.
Inventory comes in low on a fast mover. The ops coordinator sees it, knows an order needs to go out today, and also knows that shipping it faster costs extra. That extra freight wasn't in the plan. So the coordinator does the reasonable thing: they message you. You're in the air. The order waits. By the time you land and reply, the fast mover is a stockout, and the customer emails arrive before the shipment does.
Nobody made a mistake. The coordinator followed the unwritten rule, which is ask first. The failure was built into the process before anyone touched it, because the process never said who was allowed to decide.
This is the quiet cost of undocumented decision rights. It doesn't show up as an error. It shows up as delay, and delay compounds.
The framework: decisions first, steps second
When you build a standard operating procedure template for any process, work in this order:
- Name the process and its trigger. For the reorder, that's "every Monday, and any time a fast mover drops below the reorder point."
- List every decision that currently waits for you. Not the steps — the decisions. The moments where someone has to pick between options and doesn't have permission.
- Fill in the four columns for each decision: decision | who may decide | limit | escalate when.
- Write the steps as a checklist. Short lines, plain verbs, no interpretation required.
- Add the escalation path. One name, one channel, one response window.
Steps two and three are the ones people skip. That's why their SOPs look complete and behave like they're not.
Step 1: List every decision that waits for you
Open a blank doc and write down every question your team has ever asked you during a reorder. Not the tasks. The questions.
For a weekly inventory reorder, the list usually looks like this:
- Approve rush shipping when stock is low and the order can't wait.
- Increase order quantity beyond the forecast.
- Switch suppliers for a single order when the primary is out.
- Place an order outside the normal weekly cycle.
- Write off damaged stock instead of returning it.
- Approve a partial shipment instead of waiting for the full order.
Each of these is a decision point. Each one, right now, means someone stops and waits for you. Write them all down before you write a single step.
Step 2: Fill in decision, who, limit, escalate when
This is the section most SOP templates leave out, and it's the part that frees you up. Take each decision from your list and give it four things: who may make it, how far they can go, and when they have to hand it up.
| Decision | Who may decide | Limit | Escalate when |
|---|---|---|---|
| Approve rush shipping | Any ops coordinator | Up to $150 extra freight per order | Above $150, or more than one rush order in the same week → ops manager |
| Increase order quantity beyond forecast | Ops coordinator | Up to 20% above the forecasted quantity | Anything above that, or a new SKU → ops manager |
| Switch suppliers for a single order | Ops coordinator | Single order only, no contract changes | Permanent supplier change, or price above the approved unit cost → founder |
| Place an order outside the weekly cycle | Ops coordinator | Any order below the standard approval threshold | Orders above the threshold → ops manager |
| Write off damaged stock | Ops coordinator | Small quantities, recorded in the log | Repeat damage from the same supplier → ops manager |
The exact limits are yours to set. The structure is the point: a named role, a clear ceiling, and a trigger that hands the decision upward. Notice that the escalation clause is what makes the delegation safe. You're not handing over unlimited authority — you're handing over authority inside a fence.
Notice also that "founder" only appears once in that table. That's the goal, not a side effect.
Step 3: Write the steps as a plain checklist
Now the steps are easy, because the decisions are already resolved. Keep them short enough to scan.
| Situation | What to do | Why |
|---|---|---|
| Monday reorder, stock normal | Compare stock to forecast, place the order, log it | Keeps the cycle predictable |
| Fast mover below reorder point | Check the decision table for order quantity, place the order same day | Removes the wait |
| Order can't arrive in time | Check the rush-shipping row; approve within your limit, or escalate | Turns a stall into a decision |
| Primary supplier out of stock | Use the supplier-switch row for a single order | Keeps fulfillment moving |
| Decision exceeds your limit | Send it to the named escalation contact with the numbers attached | Gives the approver what they need to say yes |
The left column is the situation a person actually faces. The middle column is what to do. The right column is why, which is what makes someone trust the document enough to follow it.
Step 4: Test it while you're still reachable
The week you publish the SOP is not the week to disappear. Run the reorder with the decision table in front of everyone and stay quiet. When someone asks you a question, do two things: answer it, then ask which row of the table should have covered it. If no row covered it, add one. If a row covered it and they still asked, the row is too vague.
A reorder that runs cleanly while you're at your desk is the only evidence that it will run while you're not.
Step 5: Review it when reality changes
Decision limits go stale. Freight costs move, forecasts change, new SKUs join the catalog. Once a quarter, read the table out loud and ask whether each limit still makes sense. Add decisions that came up since the last review and delete the ones that no longer apply. The document stays short and it stays true, which is the only reason anyone keeps using it.
What changes when decision rights are written down
The coordinator stops messaging you about freight and starts approving it. The reorder goes out on the day it's due, including the week you're traveling. You get fewer questions, and the questions you do get arrive with the numbers already attached, because the escalation row told people what to send.
None of this requires new software or a bigger team. It requires one document that contains both halves: the steps and the decisions.
Quick checklist
- Name the process and its trigger in one line.
- List every decision inside the process that currently waits for you.
- Fill in decision, who may decide, limit, and escalate when for each one.
- Write the steps as a short checklist with a situation, an action, and a reason.
- Name one escalation contact, one channel, and one response expectation.
- Run one cycle while you're reachable, then fix any row that people still had to ask about.
Start with the template
You can build this from a blank document, and plenty of people do. It's faster with a structure that already has the decision table in it. The free SOP template at https://tools.exiuss.com/sop-template walks you through writing your first standard operating procedure in about 15 minutes, including the decision-rights section that most templates leave out. Fill in the form and you get a clear, ready-to-use SOP. If you want to see what good looks like first, click "Fill with an example" and watch how a decision gets written as decision | who may decide | limit | escalate when.
Start with the reorder. It's weekly, it's boring, and it's the one where a two-day delay becomes a stockout. Once you've mapped the decisions in that process, you'll start seeing the same pattern everywhere else your team waits for you.