Most founders don't need a 40-page process manual. They need one page that tells the person handling their inbox which emails they can answer, which they can hand off, and which still have to come to them. That is what a standard operating procedure template is for: capturing a repeatable decision so someone else can make it without asking.
This walkthrough takes the most common first SOP — inbox triage — and shows how to write it with a decision section, so the document actually removes work from your plate instead of just describing it.
Key takeaways
- A standard operating procedure template is only useful when it specifies decisions, not just tasks — who may decide, what limit applies, and when to escalate.
- Inbox triage is the right first SOP because it is the highest-volume, lowest-risk place to test whether your team can act without you.
- The format "decision | who may decide | limit | escalate when" turns a vague instruction like "use your judgment" into something a person can actually follow.
- You can draft a working inbox SOP in about 15 minutes using the free template at https://tools.exiuss.com/sop-template.
Why inbox triage is the right first SOP
Almost every founder writes the same first SOP badly. It says something like: "Monitor the inbox. Flag anything urgent. Handle routine requests." Then it gets saved somewhere, and within a week the founder is still the one answering everything, because the document never said what "routine" meant.
The problem is not the format. The problem is that the SOP describes activity instead of decisions. Tasks are easy to delegate and hard to enforce. Decisions are the opposite: once you write down who may make one and under what conditions, the work genuinely leaves your desk.
Inbox triage is the ideal starting point for three reasons. It is high volume, so the relief is immediate. It is low risk, because most incoming mail has a correct answer that is not controversial. And it is a clean test — if your assistant can run your inbox for a week without escalating everything, your written decisions are working.
The four-part structure of a decision-ready SOP
Every SOP you write should carry four sections. They are short, and skipping any one of them is what turns a procedure into a suggestion.
| Section | What it contains | Why it matters |
|---|---|---|
| Purpose | One or two sentences on what this SOP covers and what it does not | Prevents scope creep and stops edge cases from becoming arguments |
| Steps | The sequence of actions, in plain language, in order | Gives a new person something to follow on day one |
| Decisions | Rows in the format decision | who may decide | limit | escalate when | Turns judgment into a rule the team can apply without asking you |
| Review | Who updates this SOP and when | Keeps the document from quietly going stale |
Most templates you will find online stop after Steps. That is the gap the free EXIUSS template is built to close — it includes a dedicated decisions section, because that is where the founder's actual time is hiding.
Step 1: Write the purpose in two sentences
Name what the SOP covers and what it explicitly does not. For inbox triage, something like: "This SOP covers how incoming email to the main address is sorted and answered. It does not cover outbound campaigns, invoicing, or anything requiring a contract signature."
That second sentence does a lot of work. It gives the person a legitimate reason to stop and escalate rather than guess.
Step 2: Write the steps as a sequence, not a list of virtues
Steps should be actions a person takes in order. A workable inbox triage sequence looks like this:
- Open the inbox at the start of the working day and clear the previous day's queue first.
- Sort each message into one of four buckets: answer now, forward to a department, needs a decision, or archive.
- Answer anything covered by the decisions table below without waiting for approval.
- Forward anything that belongs to a department with a one-line note about what is being asked.
- Hold anything not covered, and batch it for a single daily review rather than forwarding each message as it arrives.
The batching in step five matters more than it looks. A founder interrupted by a steady drip of forwarded email never gets a clear block of work; a founder reviewing one digest a day does.
Step 3: Write the decisions — this is the part that frees you up
Now the section that does the real work. Each row answers four questions: what is the decision, who is allowed to make it, what limit applies, and when must it come to you anyway.
The format is: decision | who may decide | limit | escalate when
Here is a filled-in example from a real-shaped inbox SOP, covering two of the most common request types.
| Decision | Who may decide | Limit | Escalate when |
|---|---|---|---|
| Discount requests from existing customers | Operations lead | Up to the published discount tier, single order only | Request exceeds the tier, applies to a contract, or the customer is already on a custom rate |
| Vendor contracts and renewals | Department head | Renewal at existing terms with no price increase | Any new vendor, any price increase, any term longer than the current one, or anything needing a signature |
| Meeting requests from inbound leads | Assistant | Book within the standard calendar windows | The request comes from an existing customer with an open issue, or asks for time in the next 24 hours |
| Refund requests under the stated policy | Operations lead | Within the published refund window | Outside the window, or the customer disputes the policy |
| Press and partnership inquiries | Founder | None — no delegation | Always escalate |
Read the discount row again. Notice that it does not say "use judgment on discounts." It names the role, gives a specific ceiling, and lists three precise conditions that send the request upward. A person who has never met you can apply it correctly.
The vendor contracts row shows the other shape a decision can take: no autonomy over new spend, full autonomy over renewals at existing terms. That single row probably removes more interruptions than any other line in the document.
And the press row is worth keeping. Not every decision should be delegated. Writing "always escalate" is a decision too, and it stops people from guessing at the one thing you actually want to handle yourself.
If you want to see this pattern rendered in a working form, open https://tools.exiuss.com/sop-template and click "Fill with an example" — it loads the decision format so you can see how a row reads before writing your own.
Step 4: Test it on last month's email
The fastest way to find gaps is to go back through a few weeks of your own sent mail and ask, for each reply, which row would have covered this. Anything with no matching row is a decision you have been making silently.
Add those rows. Then run the SOP for a week with someone else handling the inbox and count how many messages still reach you. The number will not be zero, and it should not be — but the messages that do arrive should all be ones you genuinely wanted to see.
The common mistake: confusing a task list with a decision rule
A task list tells someone what to do. A decision rule tells them when they are allowed to act. "Sort the inbox" is a task. "You may approve a discount up to the published tier, and escalate anything above it" is a rule.
When people say an SOP didn't work, they usually mean the document described the work competently and left every actual judgment to the person reading it. That person, unsure, does the safest thing: they ask. Which means the SOP changed nothing about your day.
Advanced application: let the SOP improve itself
Once the inbox SOP is running, add one habit. Every time something escalates that you think should not have, add a row. Every time something gets answered wrong, tighten the limit or add an escalate condition.
The document becomes a record of the decisions you have already made and no longer need to make again. That is the real shift — you are not documenting work, you are transferring judgment in small, reviewable pieces.
Quick checklist
- Write the purpose in two sentences, including what the SOP does not cover
- List the steps as an ordered sequence of actions
- Fill in the decisions table using decision | who may decide | limit | escalate when
- Add an "always escalate" row for anything you must personally handle
- Test the SOP against a month of your own sent mail and add the missing rows
- Run it for a week and review what still reached you
You can build the first version of your inbox SOP in about 15 minutes. Start at https://tools.exiuss.com/sop-template, fill in the form, and you will have a clear, ready-to-use standard operating procedure — including the decisions section that most templates leave out.