Skip to main content

SOP: SOP Standards & Governance

Document ID: WMS-000 Version: 1.0 Effective date: 04/30/2026 Owner: Warehouse Operations Manager Next review: [six months from effective date] Applies to: Anyone authoring or revising a WMS SOP

1. Purpose​

This document defines how WMS Standard Operating Procedures are authored, reviewed, distributed, and retired. It exists so that the SOP library stays accurate, consistent, and actually used by staff. SOPs that are inconsistent, outdated, or undiscoverable become wallpaper — worse than having no SOP at all, because they give a false sense of documentation.

2. Scope​

In scope:

  • All SOPs in the WMS-* series
  • The template, naming convention, and storage location
  • The review and retirement process

Out of scope:

  • Non-warehouse SOPs (finance, HR, sales ops)
  • One-off runbooks and incident postmortems (stored separately in /docs/runbooks/)

3. Roles & permissions​

RoleAuthor a draftApprove a new SOPRevise an existing SOPRetire an SOP
STAFF✓✓ (with owner review)
MANAGER✓✓✓
ADMIN✓✓✓✓

SOP ownership is by role, not by person. If the named owner leaves the role, the SOP transfers automatically to their successor. Never list a personal name as the owner.

4. Procedures​

4.1 Document ID & naming convention​

Use when: Creating any new SOP.

Document IDs follow the pattern WMS-[SERIES]-[###]:

  • 000 — Foundations
  • REC — Receiving & Putaway (series 100)
  • INV — Inventory (series 200)
  • PICK, PACK, SHIP — Outbound (series 300)
  • RET — Returns (series 400)
  • TASK — Work tasks (series 500)
  • AUD — Audits & incidents (series 900)

Numbers are assigned in creation order within the series. Never reuse an ID — retired SOPs keep their ID and their history.

Filenames match the document ID: WMS-INV-001-inventory-activity.md.

4.2 Authoring a new SOP​

Use when: A new feature ships, a new procedure is adopted, or a recurring incident reveals an undocumented gap.

  1. Check SOP-INVENTORY.md (the library index) for an existing SOP that covers this. If one exists, revise it instead (§4.3).
  2. Copy _TEMPLATE.md to the correct path: /docs/sops/WMS-[SERIES]-[###]-short-name.md.
  3. Draft by shadowing, not by inventing. Watch the best operator perform the procedure. Transcribe what they do. Show them the draft. Iterate with them, not around them.
  4. Fill every section of the template. If a section doesn't apply, write "N/A" with a one-sentence explanation — do not delete the section.
  5. Add the new SOP to SOP-INVENTORY.md with its ID, title, owner, and status.
  6. Open a pull request with the docs/sop label. Request review from the owner role and one SME on the floor.
  7. On merge, announce in #warehouse-ops with a link.

⚠ Do not backfill SOPs retroactively by writing them from memory after the fact. An SOP that doesn't match the real procedure is worse than none.

4.3 Revising an existing SOP​

Use when: A procedure changes, a new reason code is added, a feature changes the UI, or a review date has passed.

  1. Bump the version number. Patch changes (typo, clarification) go 1.0 → 1.1. Material changes (new step, removed step, permission change) go 1.0 → 2.0.
  2. Add a row to §9 Revision history describing what changed and why.
  3. Update the effective date and next review date.
  4. Open a PR with the docs/sop label and the ID in the title.
  5. If the change is material (major version bump), require re-training acknowledgment from affected roles before merging.

4.4 Six-month review​

Use when: An SOP's "Next review" date has passed.

  1. The SOP owner is pinged automatically (via calendar reminder or weekly digest).
  2. Owner either:
    • Re-affirms the SOP is current → bump patch version, push next review date six months out.
    • Revises the SOP → follow §4.3.
    • Flags the SOP as stale or wrong → mark STATUS: UNDER_REVIEW in the inventory and block usage until revised.
  3. If an owner doesn't respond within 14 days, the WMS admin reassigns ownership or retires the SOP.

4.5 Retiring an SOP​

Use when: A procedure is no longer performed (feature removed, workflow replaced, or consolidated into another SOP).

  1. Mark the SOP as RETIRED in §9 Revision history with the date and reason.
  2. Move the file to /docs/sops/retired/.
  3. Update SOP-INVENTORY.md status to RETIRED.
  4. If another SOP replaces it, add a "Superseded by" link at the top of the retired doc.
  5. Never delete a retired SOP. Auditors may need it.

4.6 Linking to code, features, or tickets​

SOPs reference the system they document. Use:

  • #entity-type/id for database entities (e.g., #inventory-unit/cuid123)
  • Relative links to other SOPs by ID (see WMS-INV-001 §4.2)
  • Commit/PR links for major procedure changes driven by code
  • Never reference personal tools (Notion pages, private docs) that won't outlive the team

5. Reference​

5.1 Document format rules​

  • Markdown, not Word. Source of truth is the git repo.
  • Line length: unlimited (don't hard-wrap). Rendering handles wrapping.
  • Screenshots: PNG, stored under /docs/sops/img/, named WMS-[ID]-step-[#].png.
  • No external image hosts. Everything lives in the repo.
  • Tables for structured data. Numbered lists for procedures. Prose only for context.

5.2 Where SOPs live​

  • Source of truth: /docs/sops/ in the wms-crm monorepo
  • Rendered for floor staff: docs.hq.team (Docusaurus site, auto-deployed from main)
  • Floor cards (laminated): PDF exports generated from the floor-card tagged sections, taped at every station
  • Distributed formats: docs site for reading, PDF for printing. No Word, no Notion, no Google Docs — those drift.

5.3 Required sections per SOP​

Every SOP must have sections 1–9 from the template. If a section genuinely doesn't apply, it reads "N/A — [reason]" rather than being omitted. This is enforced in PR review.

  • _TEMPLATE.md — starting point for new SOPs
  • SOP-INVENTORY.md — live list of all SOPs with status

6. Audit & compliance​

Every SOP change is a git commit, signed by the author. The full revision history of every procedure is reconstructable from git log. Quarterly, the Warehouse Operations Manager reviews:

  • Count of overdue reviews (SOPs past their "Next review" date)
  • Count of UNDER_REVIEW SOPs (flagged but not yet revised)
  • Count of SOPs without recent acknowledgment from affected staff

All three should trend toward zero. Rising numbers indicate the governance process is failing and needs attention.

7. Troubleshooting​

SymptomCauseResolution
Floor staff doing something different from the SOPSOP is out of date, or staff weren't trained on the revisionRevise SOP to match reality OR retrain — do not punish mismatch
Two SOPs contradict each otherOne wasn't updated when the other wasRevise both in the same PR; note the conflict in both revision histories
Nobody knows who owns an SOPOwner role changed and wasn't updatedWMS admin reassigns ownership based on current org chart
SOP written but no one reads itWrong format for audience (prose for floor staff)Extract a floor card; consider a 30-second Loom

8. Escalation​

  • Procedure question during an operation: Don't pause for the SOP — ask a lead. Update the SOP afterward if the answer wasn't there.
  • Suspected SOP is wrong: Flag it in #warehouse-ops, tag the owner. Do not silently ignore.
  • Governance questions: Warehouse Operations Manager.

9. Revision history​

VersionDateAuthorChanges
1.0[DATE][NAME]Initial release — defines template, naming, review cadence, retirement process