Standard Operating Procedure (SOP) Template

Most SOPs should fit on 1-2 pages (500-1,000 words). If it exceeds 2 pages, consider breaking it into multiple SOPs or adding an appendix for reference tables. The goal is clarity, not thoroughness. A 5-page SOP that nobody reads is worse than a 1-page SOP that everyone follows.

Three things matter: the SOP must be easy to find (stored in the team wiki, not a random Google Doc), easy to follow (numbered steps, decision points, checklists), and enforced through process (the SOP is referenced in onboarding, reviews, and incident post-mortems). If an SOP is consistently ignored, it either solves a problem the team does not have, or it is too burdensome. Fix or retire it.

Update an SOP whenever the process it documents changes: new tools, new roles, new steps, or new exceptions discovered. Also review every SOP on its scheduled review date even if nothing has changed, to confirm it is still accurate. Mark the version and date of every update in the revision history.

The person who performs the process most frequently, not their manager. Managers rarely know the step-by-step details. The owner is responsible for keeping the SOP current, training new team members on it, and flagging when the process changes. The approver (usually a manager or lead) signs off on the content.

An SOP documents one procedure (how to do X). A playbook documents an entire domain (how the team operates across multiple processes). The [Product Ops Playbook Template](/templates/product-ops-playbook-template) is a playbook that could contain links to a dozen individual SOPs. Start with SOPs for your highest-risk processes, then compile them into a playbook as the collection grows. ---