Most founders write their first SOP wrong. They document the steps of a task — how to format an invoice, how to file a report — and skip the part that actually keeps the work off their desk: the decisions. A good SOP template forces you to write down who is allowed to decide what, and when they should stop and escalate.
There is a specific sequence to making this work. Most people skip step two — naming the decisions — and wonder why the document never gets used.
Key takeaways
- The most useful first SOP for a founder is inbox triage, because it is the process that quietly absorbs the most decision-making time.
- A decision-ready SOP records four things for each request type: the decision, who may decide, the limit, and when to escalate.
- The format is written as decision | who may decide | limit | escalate when, and it can be filled in for one request type in a few minutes.
- You can build your own inbox SOP in 15 minutes using the free SOP template at https://tools.exiuss.com/sop-template.
Why inbox triage is the right first SOP
Inbox triage is where delegation usually breaks down. Your team can already write the email, draft the reply, or prepare the quote. What they cannot do is decide. So the message sits, or it gets forwarded to you with "thoughts?" attached, and your day fills with small rulings that only you feel qualified to make.
That pattern is not a discipline problem. It is a missing document. Nobody has written down which decisions belong to whom, so the safe default is to ask the founder.
Triage also makes a good first SOP because it is small. You are not mapping an entire department. You are listing the handful of request types that arrive most often and deciding, once, how each should be handled.
The framework: decision | who may decide | limit | escalate when
This is the core of the walkthrough. Every row in your inbox SOP uses the same four-part sentence. Learn the pattern once and you can apply it to any process in the business.
Decision — what is actually being decided. Not the email subject, the underlying call. "Approve a discount" is a decision. "Reply to the pricing email" is a task.
Who may decide — the person or role who can make the call without asking. Use roles, not names, so the SOP survives a hire or a holiday.
Limit — the size, scope, or condition inside which that authority holds. A limit is what keeps delegation safe. Without one, you have handed over a blank cheque.
Escalate when — the conditions that send the decision upward. This column is the one most templates leave out, and it is the one that lets your team act without asking, because they know exactly where the boundary is.
Step-by-step: building the inbox SOP
Step 1: List the request types, not the emails
Open your sent folder from the last month and look for repeats. Most founder inboxes carry a short list: discount requests, vendor contracts, refunds, custom scope questions, hiring approvals, and introductions. Write down the request types. Aim for five to eight on the first pass.
Step 2: Name the decision inside each request
For each type, finish the sentence "the decision here is whether to…". If you cannot name a single decision, the request type is probably too broad — split it. This is the step people skip, and it is the reason their SOPs end up as procedure documents nobody consults.
Step 3: Assign the decision to a role
Ask who has enough context to make this call well. Often the answer is not you. An ops person can approve a small discount with a clear limit. A department head can own a vendor renewal inside an existing budget. Write the role, not the individual.
Step 4: Set the limit
A limit is a boundary, not a judgement call. It can be a percentage, an amount, a contract length, or a condition such as "only for customers in their first year". Keep it simple enough that someone can check it in ten seconds.
Step 5: Write the escalation trigger
Finish the row with the conditions that send it to you. Anything outside the limit. Anything involving a new vendor. Anything where the customer has already escalated. Be specific, because "when unsure" escalates everything.
Two filled-in example rows
Here is how the pattern looks in practice. These two rows alone usually remove a surprising amount of inbox traffic.
| Decision | Who may decide | Limit | Escalate when |
|---|---|---|---|
| Discount request | Ops lead | Up to the standard small-discount band on a first or renewal order | Above the band, or the customer has already been refused once, or it is a multi-year deal |
| Vendor contract | Department head who owns the budget | Renewal of an existing vendor at the same or lower cost | Any new vendor, any cost increase, any term longer than the current agreement, or any auto-renew clause change |
| Refund request | Support lead | Refund inside the published refund window | Outside the window, or a refund tied to a discount that was separately approved |
| Custom scope question | Delivery lead | Requests that fit inside the existing service description | Anything requiring a new deliverable, new timeline, or a change to price |
Read the discount row out loud. The ops lead now knows they can settle the ordinary discount email without you, and they know precisely when to stop. The vendor row does the same for renewals. Neither row required a policy manual — just four short clauses.
Notice that the escalate column does most of the work. It is the difference between "ask me if it feels big" and a boundary a competent person can apply on their own.
The common mistake
Most first attempts at an SOP template produce a procedure, not a decision. The document explains how to write the reply, where the pricing sheet lives, and which folder to file it in — and then says "check with the founder" at the end. Nothing has been delegated. The inbox stays the same size and the SOP gets abandoned within a month.
Fix it by checking every row against a simple test: could a capable new hire read this row and act without messaging you? If the answer is no, the row is missing a limit or an escalation trigger.
Advanced application: extending the pattern
Once the inbox SOP holds, the same four-part format travels. Onboarding exceptions use it. Purchase approvals use it. Client escalations use it. The rows get longer, but the shape stays identical, which means your team only has to learn the pattern once.
A useful second move is writing the SOP backwards from your own calendar. Look at where you actually spent decision time last week and write a row for each. The document then reflects real delegation rather than an idealised org chart.
Start today
The fastest way to start is to open the free SOP template at https://tools.exiuss.com/sop-template and fill in the inbox section. Click "Fill with an example" to see how decisions are written as decision | who may decide | limit | escalate when before you write your own. The form gives you a clear, ready-to-use standard operating procedure — most people finish their first one in about 15 minutes.
Quick checklist
- List five to eight request types from your sent folder
- Name the single decision inside each request type
- Assign each decision to a role, not a person
- Set a limit that can be checked in ten seconds
- Write the escalation trigger for every row
- Test each row: could a capable new hire act on it without messaging you?