Use this SOP template to turn recurring work into an observable, testable, and maintainable operating procedure.
An SOP does not need to document every action in the business. Prioritize recurring, delegated, error-prone, regulated, security-sensitive, or continuity-critical work. Read the SOP guide for solopreneurs for the complete documentation method.
What Belongs in an SOP?
Document the conditions that start the process, the expected result, the role allowed to perform it, required access, ordered steps, decision rules, quality checks, evidence, exceptions, escalation, and review ownership.
Separate policy from procedure. A policy explains the rule or principle; an SOP explains how the work is performed under current systems.
Choose the Right Level of Detail
Write for a named level of knowledge. Include screenshots or field-level directions where errors are costly, but do not bury important decisions inside obvious mouse movements. Link to authoritative source material instead of copying information that changes frequently.
Test Before Marking It Active
Have the intended user run the procedure in a safe environment. Record ambiguity, missing access, exceptions, and completion evidence. An untested document is a draft, not an operating control.
Copy the SOP Template
Create one SOP per defined process. Store it near the work, assign an owner, and date every approved version.
Document control
SOP title: [Verb and object describing the process]
SOP ID: [Stable identifier]
Owner: [Role accountable for accuracy]
Status: [Draft, active, paused, or retired]
Version: [Version number]
Effective date: [Date]
Next review: [Date or trigger]
Authoritative location: [System and path]
1. Purpose and scope
Purpose: [Result or risk the procedure controls]
Included: [Work covered]
Excluded: [Adjacent work not covered]
Intended user: [Role and required competence]
Policies or obligations: [Rules the procedure must follow]
2. Trigger and completion
Trigger: [Observable event, schedule, or condition that starts the process]
Entry criteria: [Conditions required before starting]
Expected output: [Deliverable, state change, or record produced]
Completion criteria: [Evidence that proves the process is complete]
Service level: [Applicable response or completion time]
3. Inputs, tools, and access
Inputs: [Data, files, forms, approvals, or materials]
Systems and tools: [Approved tools and authoritative records]
Access level: [Minimum permissions required]
Security controls: [Credential, privacy, backup, or approval requirements]
Dependencies: [People, vendors, or preceding processes]
4. Procedure
Step 1: [Action, location, expected result, and evidence]
Step 2: [Action, location, expected result, and evidence]
Step 3: [Action, location, expected result, and evidence]
Decision rule: [If condition X, do Y; otherwise do Z]
Final step: [Close, notify, store, or hand off the result]
5. Quality controls
Critical checks: [Checks that prevent material error]
Reviewer: [Who performs independent review, if needed]
Acceptance standard: [Observable quality conditions]
Sample or reference: [Approved example or specification]
Failure evidence: [Signal that the process did not work]
6. Exceptions and escalation
Known exception: [Condition and permitted response]
Stop condition: [When the user must not continue]
Escalation route: [Person, provider, or professional adviser]
Incident record: [Where deviations and failures are documented]
Recovery or rollback: [How to restore a safe prior state]
7. Records and data handling
Records created: [Logs, approvals, files, invoices, or tickets]
Storage: [Authoritative location]
Retention and deletion: [Applicable period and method]
Confidentiality: [Who may access the record]
Backup or export: [How the record can be recovered or moved]
8. Test and review
Test user and date: [Who followed the SOP and when]
Test result: [Passed, failed, or passed with changes]
Observed ambiguity: [Missing instruction, access, or decision]
Approved by: [Name and date]
Next review trigger: [Date, system change, incident, law, vendor, or process change]
Completed SOP Example
This condensed example documents Northstar’s customer-interview recording and evidence process.
Show the completed example
Document control
SOP title: Publish an Approved Lifecycle Email Sequence.
SOP ID: NS-SOP-EMAIL-004.
Owner: Research lead
Status: Active and approved for the stated period
Version: SOP v1.3, reviewed 30 September 2026
Effective date: 30 September 2026
Next review: Review with Alex Morgan on 30 September 2026 and revise when new sales, delivery, cost, or risk evidence contradicts the record.
Authoritative location: Northstar operations vault → SOPs → Client delivery → NS-SOP-EMAIL-004.
1. Purpose and scope
Purpose: Accurate publication with tested links, events, consent rules, and rollback evidence.
Included: Funnel review, five customer interviews, message map, seven emails, one revision, implementation, QA, and measurement handoff.
Excluded: Strategy changes, unapproved copy edits, new automation branches, historical-data repair, and changes outside the approved client workspace.
Intended user: Northstar owner or an approved lifecycle specialist with client-platform training.
Policies or obligations: Signed scope, client brand rules, consent and unsubscribe requirements, least-privilege access, data-processing terms, and rollback policy.
2. Trigger and completion
Trigger: Client approves a participant and scheduled time
Entry criteria: Proceed only when the customer, evidence, authority, access, budget, timing, and ethical requirements are all confirmed.
Expected output: The approved sequence is live, scheduled correctly, tested, documented, and recoverable.
Completion criteria: Accurate publication with tested links, events, consent rules, and rollback evidence; verified by zero unresolved qa failures before activation.
Service level: Complete publication and QA within two business days after final approval and all required access.
3. Inputs, tools, and access
Inputs: Approved research question, participant details, consent wording, calendar link, and evidence-log access
Systems and tools: Client email platform, product analytics, secure password manager, project portal, and the approved QA worksheet.
Access level: Provide analytics and platform access, five interview participants, brand constraints, and approvals within two business days.
Security controls: Use the approved checklist, preserve evidence, resolve critical failures, and obtain written acceptance before closing the stage.
Dependencies: Results depend on accurate analytics, representative interviews, timely approvals, product quality, traffic quality, and lawful implementation.
4. Procedure
Step 1: Confirm prerequisites → complete research → approve the working draft → implement → run QA → hand over evidence and next actions.
Step 2: Confirm prerequisites → complete research → approve the working draft → implement → run QA → hand over evidence and next actions.
Step 3: Confirm prerequisites → complete research → approve the working draft → implement → run QA → hand over evidence and next actions.
Decision rule: If consent is absent or withdrawn, do not record; document permitted notes only
Final step: Confirm prerequisites → complete research → approve the working draft → implement → run QA → hand over evidence and next actions.
5. Quality controls
Critical checks: Correct audience and exclusions, approved sender, consent basis, working unsubscribe, links, personalization fallbacks, timing, events, and rollback snapshot.
Reviewer: Review with Alex Morgan on 30 September 2026 and revise when new sales, delivery, cost, or risk evidence contradicts the record.
Acceptance standard: Use the approved checklist, preserve evidence, resolve critical failures, and obtain written acceptance before closing the stage.
Sample or reference: OrbitFlow approved sequence v3 and QA record NS-OF-QA-07.
Failure evidence: Two related projects, one paid pilot, six interviews, proposal records, delivery-time data, and a dated source log.
6. Exceptions and escalation
Known exception: Late access, inaccurate data, scope expansion, security exposure, or missed approval; pause work and escalate to Alex Morgan.
Stop condition: Participant discloses data outside agreed research scope or requests legal, medical, financial, or other advice
Escalation route: Late access, inaccurate data, scope expansion, security exposure, or missed approval; pause work and escalate to Alex Morgan.
Incident record: Store the dated source record in the restricted client folder, retain only the agreed evidence, and delete temporary exports after acceptance.
Recovery or rollback: Pause the automation, restore the pre-change snapshot, notify the owner and client contact, preserve logs, and open an incident record.
7. Records and data handling
Records created: Store the dated source record in the restricted client folder, retain only the agreed evidence, and delete temporary exports after acceptance.
Storage: Final QA record and export are stored in the restricted client delivery folder.
Retention and deletion: Delete temporary user-level exports within 24 hours of acceptance and retain only the contracted QA evidence for 90 days.
Confidentiality: Follow the signed agreement, least-privilege access, confidentiality rules, and the client’s approved privacy and marketing-compliance process.
Backup or export: Export the current automation, message content, timing, and audience rules before any production change.
8. Test and review
Test user and date: 30 September 2026
Test result: The bounded test met its decision threshold, while delivery capacity and repeatability remain the next uncertainties to test.
Observed ambiguity: The phrase “active trial user” required a precise event and time-window definition.
Approved by: Alex Morgan on 30 September 2026 after a successful sandbox and rollback test.
Next review trigger: Trial volume increased while activation remained flat, making the cost of delay visible in the latest monthly review.
Quality Check
- The title describes one defined process.
- Trigger, entry criteria, output, and completion evidence are observable.
- The intended user and required competence are explicit.
- Access follows least privilege.
- Steps contain actions and expected results, not vague goals.
- Decision rules cover material branches.
- Quality checks focus on consequential errors.
- Stop, exception, escalation, and recovery conditions are visible.
- Records have storage, access, retention, and backup rules.
- The SOP was tested by an intended user and has a review owner.
Common SOP Mistakes
Documenting an unstable process too early
First observe and simplify the work. Otherwise the SOP preserves avoidable complexity.
Writing for an undefined user
The correct detail depends on the user’s role, access, and competence.
Listing steps without evidence
Completion must be verifiable through a record, output, status, or review.
Ignoring exceptions
A procedure that works only in the ideal path fails when judgment is most important.
Allowing several authoritative copies
Use one controlled version and clearly retire obsolete instructions.
Related Guides and Templates
- Learn the full method in Standard Operating Procedures for Solopreneurs.
- Map the work first with the business workflows guide.
- Store and retrieve procedures through knowledge management.
- Test continuity-critical procedures inside the Business Continuity Plan.