Building SOPs That Actually Get Followed
Most SOPs are written, shared, and ignored. The problem is not the team's resistance to process it is that most SOPs are too long, too abstract, too difficult to access in the moment they are needed, and never updated when the process changes. Here is the SOP design methodology that produces documents people actually use.
Aditya Sharma
Author
Standard Operating Procedures are the operational infrastructure that allows a business to produce consistent outputs regardless of which team member executes the process. They are the mechanism by which the founder's operational knowledge becomes organisational knowledge accessible to every team member, executable without constant founder involvement, and preserved across team member turnover. In theory, SOPs solve the scaling problem. In practice, most SOPs are written once during an operational crisis, shared in a Google Drive folder that nobody can find, never updated when the process changes, and cited in performance conversations as the standard the team failed to meet despite the team having no practical reason to consult a document they have been told exists but that they have never actually read.
Why Most SOPs Fail
The first failure mode is length. An SOP that takes 20 minutes to read will not be read by a team member who has three minutes between tasks. The purpose of an SOP is to enable correct execution of a process not to document every possible scenario, exception, and background context. An SOP that serves this purpose is typically one to three pages for a standard operational process, with the most critical steps visible on the first page. An SOP that runs to 15 pages for a packaging and dispatch process is a document that somebody wrote, not a document that anybody will use.The second failure mode is abstraction. An SOP written at the level of 'ensure inventory accuracy is maintained' is not an SOP. It is a statement of intent. An SOP that produces consistent execution is written at the level of 'at the end of each dispatch session, the warehouse team member scans the quantity of each SKU shipped against the Shopify pick list, compares to the opening stock count from this morning, and enters the closing count in the WMS before leaving the warehouse.' This level of specificity is what allows a new team member to execute the process correctly on their first attempt.The third failure mode is inaccessibility. An SOP stored in a Google Drive folder that requires navigating three levels of folder structure to locate is not practically accessible in the moment when it is needed. SOPs that are used are the ones that are one click away from the task they govern linked from the tool where the task is performed, pinned in the relevant WhatsApp group, or printed and laminated at the physical workstation where the task is done.The fourth failure mode is stale content. A process that is documented in an SOP and subsequently changed because the team found a better way, because a tool was replaced, because a regulation changed produces an SOP that is wrong. A team member who follows the outdated SOP and gets a different outcome from what the SOP describes will stop trusting the SOP and revert to asking colleagues or experimenting independently.
The SOP Design Framework That Produces Documents People Use
An effective SOP has five components and nothing else. The process name and trigger (when does this process start what event or schedule initiates it). The owner (which role is responsible for executing this process not a person's name, but a role that persists across personnel changes). The step-by-step execution guide (numbered steps, each beginning with an action verb, each specific enough that there is only one correct way to interpret it). The common exceptions (the two or three most frequent situations that deviate from the standard steps, and what to do in each). The escalation trigger (what situation requires the team member to stop and escalate rather than proceeding and who they escalate to).Total SOP length under this framework: one to two pages for most operational processes. The test for completeness: give the SOP to a team member who has never performed the process before and observe whether they can execute it correctly without asking questions. If they need to ask more than one clarifying question, the SOP needs more specificity. If they do not need to ask any questions, the SOP is either complete or the process is so simple it does not need an SOP.
The SOP Maintenance System
- Review every SOP quarterly assign a named owner for each SOP whose responsibility includes keeping it current when the underlying process changes
- Build an SOP update trigger into the change management process any change to a tool, a supplier, a regulatory requirement, or a team authority framework that affects an existing SOP must produce an SOP update within five business days of the change going live
- Version-control SOPs with a date and version number when a team member asks 'which version should I follow,' the answer is always 'the current version, which has date X at the top'
- Conduct quarterly SOP audits where team members execute the documented process and report any step that is unclear, outdated, or missing the team member executing the process is the most reliable source for SOP improvement
- Measure SOP adherence not by whether the document was consulted but by whether the process output matches the documented standard the SOP that produces consistent output is being followed, regardless of whether the team member reads it each time
Why You Need Fewer Dashboards, Not More
Related articles
View all →
Contribution MarginUnderstanding Contribution Margin (Not Just Profit)
Profit is what remains after all costs. Contribution margin is what remains after variable costs and it is the metric that determines whether adding one more order, one more channel, or one more marketing rupee makes the business better or worse. Most founders optimise for profit. The best founders optimise for contribution margin first.
Seasonal InventoryInventory Planning for Seasonal Demand
Seasonal demand is predictable. Seasonal inventory problems are not inevitable they are the result of predictable demand being met with reactive planning. The brand that plans its Diwali inventory in October is already too late. The brand that planned it in August has the right stock, in the right channels, at the right cost.
Systems DesignBuilding Systems That Scale With You
Most founders build systems for the current problem. The right systems are built for three problems ahead designed to handle 5x the current volume with configuration changes rather than architectural rebuilds. The difference between a system that scales and one that requires replacement is in the design decisions made when the current volume is modest.