I wrote an operations manual for Vulpine Creations. Thirty-two pages. Detailed procedures for order processing, customer support, inventory management, shipping, and returns. Every edge case documented. Every exception noted.
Nobody read it. Including me.
When a new task needed to be delegated, I found myself explaining the process verbally rather than pointing to the manual. The manual was too long, too dense, and too separate from where the work actually happened. It was a document that existed to make me feel organized. It did not make the business run better.
The problem was not the content. The problem was the format. Most operations manuals fail because they are written like textbooks when they should be written like recipes.
Why Traditional SOPs Fail
Standard Operating Procedures as traditionally conceived — multi-page documents stored in a shared drive — fail for three predictable reasons.
They are too far from the work. The SOP lives in a Google Drive folder. The work happens in Shopify, Stripe, Gmail, and Notion. When someone needs guidance, they do not navigate to a folder, find the right document, search for the right section, and follow the steps. They ask someone. Or they guess.
They are too detailed. A twenty-step procedure for processing a return includes steps like “Log into the dashboard” and “Click the Orders tab.” These steps add bulk without adding value. The person doing the work knows how to log in. What they need to know is the decision points: when to approve a refund, when to offer a replacement, when to escalate.
They are never updated. The process changes. The tool changes. The policy changes. The SOP does not change because updating a 32-page document is a task nobody wants to do. Within three months, the manual is outdated. Within six months, it is actively misleading.
The Format That Works
The format that gets used has three characteristics: it is short, it lives where the work happens, and it focuses on decisions rather than mechanics.
Short. Each process is documented on a single page or screen. Not “as short as possible” — literally one page. If the documentation requires scrolling, it is too long.
Embedded. The documentation lives inside the tool where the work is done. A Notion page linked from the relevant Notion database. A pinned message in the relevant Slack channel. A comment in the Trello card. Not in a separate folder that requires navigation.
Decision-focused. Instead of documenting every mechanical step, document only the decision points. The moments where the person doing the work needs to choose between options.
The Decision-Map Format
I replaced the 32-page manual with what I call Decision Maps. Each map covers one process and fits on one screen. The format:
Process name: [What this covers]
Trigger: [When to use this]
Decision 1: [The first choice point]
- If [condition A] → [do this]
- If [condition B] → [do this]
- If unsure → [escalate to whom]
Decision 2: [The next choice point]
- If [condition A] → [do this]
- If [condition B] → [do this]
Done when: [How you know the process is complete]
Here is a real example — the return process for Vulpine Creations:
Process: Customer Return Request
Trigger: Customer emails requesting a return or refund.
Decision 1: Is the product within the 14-day return window?
- Yes → proceed to Decision 2
- No → reply with template “outside-return-window” (offer 10% discount on next order)
Decision 2: Is the product damaged or defective?
- Damaged/defective → full refund + free replacement, reply with template “defective-return”
- Customer changed mind → refund upon return of product, reply with template “change-of-mind-return”
- Unsure → forward to Felix with subject “Return Review”
Done when: Refund processed in Stripe and customer confirmation sent.
That is the entire return process. One screen. Three decision points. Anyone can follow it without training.
Building Your Decision Maps
Step 1: List your processes. Everything you do repeatedly. Order processing. Customer support. Invoicing. Content publishing. Inventory ordering. Social media posting.
Step 2: For each process, identify the decision points. Not every step — only the moments where someone needs to choose. These are the steps where mistakes happen, where training is needed, and where documentation adds value.
Step 3: Write the decision map. Use the format above. Keep each map to one screen. If it needs more, split it into sub-processes.
Step 4: Embed the maps where the work happens. If the process starts with an email, put the decision map in your email tool (as a template or quick reference). If the process lives in a project management tool, pin the map to the relevant board.
Maintaining the Maps
Decision maps stay current because they are small enough to update in two minutes.
Update trigger: Any time you make a decision that is not covered by the current map, or any time the map’s guidance leads to a wrong outcome. Update the map immediately. Not “later.” Now.
Quarterly review: Once per quarter, read through all decision maps. Delete any that reference tools or processes that no longer exist. Update any that have drifted from current practice. This review takes thirty minutes for a small business.
The VA Test
The real test of your documentation is this: could a virtual assistant follow it without asking you questions?
Send your decision map to your VA or a new freelancer. Ask them to process three real tasks using only the map. Count the questions they ask.
Zero questions: the map is excellent. One to two questions: update the map to address those questions. Three or more: the map needs a rewrite.
This test also reveals whether the process is ready to delegate. If a competent person cannot follow your documentation, the process is still in your head — not in a system.
Building a business that does not need you requires documentation that works without you. Decision maps are the minimum viable format for that documentation.
The Anti-Manual
The goal is not a manual. The goal is a collection of decision maps — short, embedded, decision-focused — that allow anyone to do the right thing without asking you.
This is systematization at its most practical. Not a binder on a shelf. Not a 32-page PDF in a shared drive. A set of living documents, each one page, each embedded where the work happens, each updated when reality changes.
The operations manual nobody reads is a failure of format, not of intent. Switch the format. Keep the intent. Watch the documentation finally do what it was always supposed to do: make the business run without you in the room.
