The SOP graveyard is full of documents that were written by managers, reviewed once, and never opened again. Every Filipino team I've worked with has a Notion or Google Drive folder with 30–50 "SOPs" that nobody refers to because nobody designed them to be referred to. Writing an SOP that gets used requires understanding why SOPs fail — and designing for the person doing the work, not the person writing the documentation.
By Diosh Lequiron, PhD, MBA, CSM — President & CEO, HavenWizards 88 Ventures OPC Last updated: May 9, 2026
Why Most SOPs Are Useless
The standard SOP format — Purpose, Scope, Definitions, Procedure, References — was designed for regulated industries where documentation compliance matters more than execution speed. Manufacturing. Aviation. Healthcare. In those contexts, the SOP exists to satisfy an auditor. It works for that purpose.
For a venture operations team, the auditor is irrelevant. The person who matters is the team member who is in the middle of an order exception at 9 PM and needs to know exactly what to do in the next 3 minutes, in plain language, with no ambiguity.
The failure modes we've observed across our portfolio:
- SOPs written in English by a manager whose first language is English, for team members whose operational vocabulary is Tagalog-dominant — creating a comprehension gap that nobody admits to
- SOPs that describe what to do in the happy path but have no guidance for exceptions — which are the situations where an SOP is actually needed
- SOPs that require accessing 3 different systems to execute one step — so team members develop informal workarounds that bypass the SOP entirely
- SOPs that aren't updated when the underlying system changes — so the documented process no longer matches reality
The result is a team that ignores the SOPs and relies on institutional knowledge, WhatsApp messages to the founding team, and guesswork. This is a governance failure — not a team failure.
The HW88 SOP Design Framework
We rebuilt our SOP system across all 8 ventures after the first year of operations proved that long-form procedural documents weren't working. The new framework has four design principles.
Principle 1 — One SOP per Trigger Event, Not per Department
Most SOP systems are organized by function (Operations SOPs, Customer Service SOPs, Finance SOPs). Ours are organized by trigger event — what happened that requires this SOP to be followed.
Instead of "Order Management SOP," we have:
- "Order Received — Standard Flow"
- "Order Received — Out of Stock"
- "Order Received — Payment Declined"
- "Order Delivered — Customer Complaint"
- "Order Delivered — Return Requested"
The team member at the moment of the trigger doesn't think "I need the Order Management SOP." They think "a payment was declined, what do I do?" The SOP is organized around that moment.
Principle 2 — Maximum 7 Steps, Each Under 20 Words
If an SOP step requires more than 20 words to describe, the step is either two steps being combined or it contains explanation that belongs in a training document, not an SOP.
An SOP step is not an explanation. It is an instruction. "Check if the inventory count in Supabase matches the fulfillment center report" is an instruction. "Review the inventory data to ensure consistency across systems because discrepancies can cause fulfillment errors" is an explanation — it belongs in onboarding, not in the SOP the person uses at 9 PM.
Seven steps is the cognitive limit for working memory under operational pressure. If the procedure requires more than 7 steps, it should be split into sub-SOPs, each with a clear handoff point.
Principle 3 — Exception Handling Is Part of the SOP, Not an Afterthought
Every SOP we write includes an "Exception Path" section that answers: what do you do when step 3 doesn't go as expected? For every decision point in the happy path, there is a corresponding exception path.
This is the most important section and the one that's almost always missing from standard SOPs. The happy path is intuitive enough that many team members could figure it out without documentation. The exception paths are where people get stuck, call their manager, or make the wrong call.
Exception paths end with one of three outcomes:
- Team member resolves it independently using the documented exception steps
- Team member escalates to Pod Lead with specific information collected (defined in the SOP)
- Team member pauses and documents the undocumented exception for SOP update
Principle 4 — SOPs Include Role and System Access Requirements
Every SOP opens with:
- Who uses this: [Role name] — not the team member's name, the role
- Systems needed: [System 1, System 2] — with specific permission level required
- When to use this: The exact trigger condition, described in operational language
If the person doing the work doesn't have access to the systems listed, the SOP cannot be followed. This sounds obvious. It is routinely ignored. We learned this after deploying a fulfillment SOP across Bayanihan Harvest only to discover that 2 of the 5 team members using it didn't have the Supabase query access required for step 3.
The SOP Template We Use
SOP: [Trigger Event Name]
Version: [X.X] | Last updated: [Date] | Owner: [Pod Lead name]
WHO USES THIS: [Role]
SYSTEMS NEEDED: [System 1 (permission level)], [System 2]
WHEN TO USE: [Exact trigger — "When a customer submits a return request via the website form"]
STEPS:
1. [Action — verb-first, under 20 words]
2. [Action]
3. [Action]
→ IF [exception condition]: go to Exception Path A
4. [Action]
5. [Action]
→ IF [exception condition]: go to Exception Path B
6. [Action]
7. [Action — final state, record, notification]
EXCEPTION PATH A: [Condition]
A1. [Action]
A2. [Action]
A3. Escalate to Pod Lead with: [specific information to collect before escalating]
EXCEPTION PATH B: [Condition]
B1. [Action]
B2. [Action]
RECORD: [Where and how to record this execution — Notion, Supabase, Slack]
UPDATE: If you encountered a situation not covered here, document it in [channel/doc] for SOP update.
This template is intentionally spare. The goal is not to document everything — it is to document enough that the right person can execute correctly, independently, the first time they encounter this trigger.
What Happened When We Deployed This System
We rebuilt 23 core SOPs across Bayanihan Harvest and AHA eCommerce using this format over a 6-week period. The rebuild itself was a team project — pod leads wrote first drafts, team members reviewed them against actual execution experience, and we iterated until the SOP matched what the team actually does (not what we thought they did).
Month 1 result: The number of "quick questions" escalated to the founding team dropped by approximately 60%. Most of those questions were exception-path questions — situations where the team didn't know what to do and defaulted to asking. When the exception paths were documented, they stopped needing to ask.
Month 3 result: Three SOPs had been self-updated by pod leads based on undocumented exceptions that team members flagged. The governance system was self-maintaining — the team was fixing the SOPs rather than working around them.
What didn't work: SOPs written entirely by management without team member input were ignored more often than SOPs co-created with the people who use them. The knowledge of what actually happens at each step lives in the people doing the work. The SOP author's job is to extract and structure that knowledge, not to describe the process from the outside.
Common Mistakes in SOP Design for Philippine Operations
Writing in formal business English for a team whose operational language is Filipino. This creates comprehension distance. Either write in Filipino (or Taglish), or use the simplest possible English with no idioms, no passive voice, and no compound sentences.
Centralizing SOP ownership. When one person owns all SOPs, updates become a bottleneck. Assign each SOP to the pod lead whose team uses it. They own it, maintain it, and are accountable for its accuracy.
Not versioning SOPs. An SOP without a version number and update date is untrustworthy. If team members don't know when it was last updated, they don't know if it's current.
Confusing training material with SOPs. An SOP is not where you explain why something is done. That's onboarding documentation. An SOP is where you document what to do and when. Keep them separate.
Frequently Asked Questions
How long should an SOP be? One page maximum for most operational SOPs. If it doesn't fit on one page using the template above, split it into sub-SOPs.
How often should SOPs be updated? Any time the underlying system or process changes. Additionally, a quarterly SOP review (pod leads review their SOPs, flag outdated steps) prevents drift.
Should SOPs be bilingual (English/Filipino)? For teams that operate primarily in Filipino, yes. For mixed teams, English with simplified language and a Tagalog glossary for key terms is a workable middle ground.
What tool should we use to manage SOPs? Notion is our choice — searchable, linkable, permission-controlled. Confluence works for larger teams. Google Docs works for teams starting out. The tool matters less than the structure — a perfectly formatted SOP in Google Docs beats a messy SOP in Notion.
What's the difference between an SOP and a workflow? An SOP describes what a person does in a specific trigger situation. A workflow describes how a process moves between people or systems. SOPs often reference workflows (the n8n or Make.com automation that runs in the background). They are complementary documents.
SOP Development Checklist
- Identify the 10 most common trigger events your team handles
- For each, interview the team member who handles it — not the manager who designed it
- Draft SOP using the template: trigger, who, systems, steps (max 7), exceptions
- Have the team member who will use it read it and execute it against a test case
- Revise until execution matches the documented steps
- Assign ownership to the pod lead whose team uses it
- Version and date the SOP
- Store in a searchable, linked location (Notion/Confluence)
- Review all SOPs quarterly; update immediately when the underlying system changes