SOP Checklist: Every Section Your Standard Operating Procedure Needs [Free Template 2026]

I’ve audited a lot of SOPs over the past few years. Internal ones. Ones from acquired companies. Ones customers email over with a “hey, is this any good?”

The pattern is bleak and consistent. Most SOPs out there are missing at least three critical sections. Someone wrote down the steps, slapped on a title, and shipped it. Six months later, an operator hits an edge case the doc doesn’t cover, escalates to the wrong person, and the whole thing unravels.

I’m Yuval, CEO of Glitter AI. We build software that turns screen recordings into structured SOPs, so I spend a lot of time thinking about what actually belongs in a standard operating procedure, and what tends to get skipped.

This post is a reference. Bookmark it. Use it as an audit checklist when you’re reviewing existing SOPs, or as scaffolding when you’re writing new ones from scratch. Every section below answers three questions: why it matters, the most common mistake people make, and a real example you can copy.

Skip the blank page — generate SOP sections automatically

Teach your co-workers or customers how to get stuff done – in seconds.

Start for Free

Replay video

0:00 / 0:00

The 15 Sections Every SOP Needs

Before getting into details, here’s the full checklist. If your SOP is missing any of these, that’s a gap worth closing:

1. Document Header
2. Purpose & Scope
3. Roles & Responsibilities (RACI)
4. Prerequisites & Inputs
5. Materials, Tools & Software
6. Definitions & Acronyms
7. Step-by-Step Procedure
8. Decision Points & Branching Logic
9. Quality Checks & Acceptance Criteria
10. Outputs & Deliverables
11. Exceptions & Escalations
12. Compliance & Regulatory References
13. Related Documents
14. Change Log & Version History
15. Approval Signatures

Quick audit tip before getting into specifics: most SOPs out there fail because they skip sections 8, 11, and 14 - branching logic, exception handling, and version history. If you only patch three things in your existing documentation, patch those.

1. Document Header

Why it matters: The header is how anyone (auditor, new hire, regulator) figures out what this document is, who owns it, and whether it’s still current. Without it, you’ve got an orphaned file.

Common mistake: Slapping on just a title and date. That tells the reader nothing about ownership or whether the content is stale.

What to include:

• Title - descriptive and specific (not “Sales Process” but “New Customer Onboarding for Mid-Market Accounts”)
• SOP ID - a unique identifier like SOP-SALES-007
• Version number - semantic versioning works (v2.1)
• Document owner - a named person, not “the team”
• Effective date - when this version went live
• Next review date - when it needs to be re-validated (annually at minimum)
• Department / function

Real example:

Title: New Customer Onboarding - Mid-Market Accounts
SOP ID: SOP-CS-014
Version: 3.2
Owner: Maya Chen, Head of Customer Success
Effective: 2026-04-01
Next Review: 2027-04-01
Department: Customer Success

2. Purpose & Scope

Why it matters: This section tells readers whether they’re even in the right document. Skip it, and people end up using SOPs in situations they were never designed for.

Common mistake: Writing a vague purpose like “to ensure quality.” Useless. Be specific about what process is covered, and just as important, what’s not covered.

What to include: A 2-3 sentence purpose statement, then explicit scope boundaries.

Real example:

Purpose: Standardize the first 30 days of onboarding for mid-market accounts (ARR $50k - $250k) to ensure consistent time-to-value and reduce churn risk in the first quarter.

Scope: Applies to all accounts signed after 2026-01-01 in the mid-market segment. Does not apply to Enterprise accounts (see SOP-CS-018) or self-serve accounts.

3. Roles & Responsibilities (RACI)

Why it matters: When something breaks, the first question is always “who owns this?” If the SOP doesn’t answer clearly, you get finger-pointing.

Common mistake: Listing roles in prose (“the CSM is responsible for X, but the AE should also be informed…”). Use a RACI table. It’s faster to read and harder to misinterpret.

RACI stands for Responsible, Accountable, Consulted, Informed. Exactly one person is Accountable per task. Responsible is whoever does the actual work. Consulted gets input before. Informed gets a heads-up after.

Real example:

4. Prerequisites & Inputs

Why it matters: Steps that quietly assume “you already have X” are how SOPs break. Spell out everything the operator needs before they start.

Common mistake: Burying prerequisites inside Step 1. Pull them out so a reader can scan them up front and bail before wasting an hour.

Real example:

Before starting this SOP, confirm you have:

• Signed order form in CRM with deal stage = “Closed Won”
• Customer’s primary technical contact email
• Access to the CS workspace in Notion
• Salesforce permissions for “Account Owner” handoff

5. Materials, Tools & Software

Why it matters: Tells the operator what tabs to open before they start, and helps IT know which licenses to provision for someone running this SOP.

Common mistake: Naming a tool but not the version, the URL, or the access level required. “Use Salesforce” isn’t enough. Which Salesforce instance, with what role?

Real example:

• Salesforce (production, role: CSM or above) - https://company.lightning.force.com
• Notion CS workspace - must be Editor on “Customer Health” database
• Gainsight (read access minimum)
• Loom or Glitter AI for recording walkthroughs (Loom produces a video viewers must scrub through; Glitter produces both a video and a scannable written guide from the same recording)

6. Definitions & Acronyms

Why it matters: New hires have no clue what “MQL” or “PRR” or “the green path” means. Internal jargon quietly destroys SOP usability.

Common mistake: Skipping it because “everyone knows what these mean.” They don’t. Especially not on day three.

Real example:

• TTV - Time to Value, measured from contract signature to first successful production use
• Health Score - composite metric (0 - 100) calculated weekly in Gainsight
• Sponsor - the named executive champion at the customer, identified during sales

Glitter angle: When you record an SOP through Glitter, this section gets auto-extracted. We pull tool names, UI labels, and recurring terms straight from the recording, so you don’t have to sit there writing the glossary yourself.

Skip the blank page — generate SOP sections automatically

Teach your co-workers or customers how to get stuff done – in seconds.

Start for Free

Replay video

0:00 / 0:00

7. Step-by-Step Procedure

Why it matters: This is the meat of the SOP. It’s also the section people botch most often, either by being too vague or absurdly detailed.

Common mistake: Mashing what to do together with why to do it in the same sentence. Keep steps imperative and atomic. If you need to explain rationale, drop it in a callout.

What to include: Numbered steps written in plain imperative voice. One action per step. Add screenshots or screen recordings for any UI-driven step.

Real example:

1. Open the account in Salesforce (Accounts → search by company name).
2. Verify the deal stage is “Closed Won.” If not, stop and contact the AE.
3. Click New Case → select case type “Onboarding Kickoff.”
4. In the case description, paste the success plan template from Notion.
5. Assign the case to yourself and set priority to High.

For a deeper walkthrough of structuring this section, see my guide on how to write an SOP.

8. Decision Points & Branching Logic

Why it matters: Real processes have forks. “If the customer is on Enterprise, do A. If they’re on Pro, do B.” If your SOP doesn’t model these forks out loud, operators guess. And they guess inconsistently.

Common mistake: This is the number one missing section in audited SOPs. Authors write the happy path and ignore the branches. Then they wonder why the process produces inconsistent outputs.

What to include: Explicit decision blocks with criteria and the path to follow for each outcome. A simple format works fine:

DECISION: Is the customer on Enterprise?
 → YES: Schedule white-glove technical kickoff (see SOP-CS-018)
 → NO: Continue to Step 9 below

For more involved branching, link out to a Mermaid flowchart or a separate decision-tree document. Don’t try to nest three levels of “if/else” inside numbered steps. It becomes unreadable.

9. Quality Checks & Acceptance Criteria

Why it matters: “Done” is subjective unless you define it. Acceptance criteria let an operator self-verify, and let a reviewer audit objectively.

Common mistake: Writing acceptance criteria as feelings (“the customer should feel welcomed”). Make them observable and binary.

Real example:

The onboarding is complete when all of the following are true:

• Kickoff call held and recording uploaded to Gong
• Success plan signed by customer sponsor (PDF in account folder)
• At least 3 power users created and logged in once
• Health score ≥ 70 in Gainsight
• Case closed with disposition “Onboarding Complete”

Glitter angle: Acceptance criteria get auto-suggested from your recording. Click “Save” or “Submit,” or land on a confirmation screen, and Glitter flags that moment as a likely completion checkpoint and proposes it as an acceptance criterion.

10. Outputs & Deliverables

Why it matters: Tells downstream teams what they’ll get when this SOP wraps up, and where to find it.

Common mistake: Listing only the primary deliverable and forgetting the artifacts that other teams depend on (logs, signed forms, updated records).

Real example:

When this SOP is complete, the following artifacts exist:

• Signed Success Plan in the account’s Google Drive folder
• Closed kickoff case in Salesforce with full notes
• Updated Onboarding Stage = Complete field on Account record
• Calendar invite for the 60-day business review
• Slack notification posted to #cs-handoffs

11. Exceptions & Escalations

Why it matters: When the happy path breaks, who do you call? An SOP without escalation paths leaves operators stranded, and they end up inventing their own escalations, usually badly.

Common mistake: Same story as section 8. Most SOPs just omit this. The author assumes nothing will go wrong, which may be the most expensive assumption in operations.

What to include: A list of common exceptions, the trigger condition for each, and the named owner to escalate to.

Real example:

12. Compliance & Regulatory References

Why it matters: If your SOP touches anything regulated (PII, PHI, financial data, export controls), you need to cite the regulation. Auditors will ask. So will lawyers, the moment something goes wrong.

Common mistake: Assuming compliance “lives somewhere else.” It doesn’t. The SOP is the operational artifact auditors trace controls back to.

Real example:

• This procedure handles customer PII. All data access governed by SOC 2 CC6.1 (logical access controls).
• Customer health data shared with EU sponsors requires GDPR Article 28 processor terms in MSA. Verify before sharing.
• Data retention: account artifacts retained 7 years per internal Data Retention Policy DR-001.

13. Related Documents

Why it matters: SOPs don’t exist in isolation. Linking related documents (parent processes, child SOPs, policy documents) creates a navigable web instead of an island.

Common mistake: Linking every document in the company “just in case.” Be selective. Only link documents an operator actually needs while running this SOP.

Real example:

• Parent process: Customer Lifecycle Master SOP (SOP-CS-001)
• Predecessor: Sales-to-CS Handoff (SOP-SALES-009)
• Successor: 60-Day Business Review (SOP-CS-022)
• Policy: Customer Data Handling Policy (POL-INFOSEC-004)
• Template: Success Plan Template v4.1 (TPL-CS-003)

14. Change Log & Version History

Why it matters: Without a change log, nobody knows what changed between v1.4 and v2.0, when it changed, or why. That’s a compliance gap and a coordination disaster. Half the team is operating on the old version.

Common mistake: This is the third member of the missing-section trio (alongside 8 and 11). Authors update the SOP, bump the date, and don’t record what they changed. So when someone asks “did we used to do it differently?”, nobody can answer.

What to include: A simple table. Version, date, author, summary of change.

Real example:

15. Approval Signatures

Why it matters: Approvals close the loop. They show this document got reviewed by the right people, who took accountability for its accuracy.

Common mistake: Treating signatures as a formality. They’re not. For regulated industries (healthcare, finance, manufacturing), absent or incorrect approvals invalidate the SOP entirely from a compliance standpoint.

Real example:

For regulated environments, capture signatures in a system that produces an immutable audit trail. DocuSign, Adobe Sign, or whatever your QMS supports.

Skip the blank page — generate SOP sections automatically

Teach your co-workers or customers how to get stuff done – in seconds.

Start for Free

Replay video

0:00 / 0:00

How Glitter Auto-Generates Half the Checklist

I’ll be straight with you. Filling 15 sections from a blank page is the reason most SOPs never get written. So we built Glitter to take the heaviest lifting off your plate.

When you record an SOP with Glitter’s SOP generator, three sections get auto-generated from your recording:

• Section 6 (Definitions & Acronyms) - pulled from UI labels, tool names, and recurring terms
• Section 7 (Step-by-Step Procedure) - every click, type, and navigation, with annotated screenshots
• Section 9 (Quality Checks) - confirmation screens and submit actions get flagged as likely acceptance checkpoints

You still write the strategic sections yourself (purpose, scope, RACI, decision logic, escalations), because those require judgment, not transcription. But the mechanical parts? Those are done in 30 seconds.

If you want a deeper template walkthrough, my SOP template guide covers different formats for different process types. For formatting guidance like fonts, hierarchy, screenshots, callouts, see the SOP format best practices guide.

Free SOP Checklist (Copy & Paste)

Here’s the checklist as a markdown file you can drop into Notion, Confluence, or a markdown editor:

# SOP Audit Checklist

## 1. Document Header
- [ ] Title (specific and descriptive)
- [ ] SOP ID
- [ ] Version number
- [ ] Document owner (named person)
- [ ] Effective date
- [ ] Next review date
- [ ] Department / function

## 2. Purpose & Scope
- [ ] 2-3 sentence purpose statement
- [ ] Explicit "in scope" boundaries
- [ ] Explicit "out of scope" exclusions

## 3. Roles & Responsibilities
- [ ] RACI table present
- [ ] Each task has exactly one Accountable
- [ ] All named roles exist in current org chart

## 4. Prerequisites & Inputs
- [ ] All required upstream artifacts listed
- [ ] All required access / permissions listed
- [ ] All required information listed

## 5. Materials, Tools & Software
- [ ] Each tool named with version / URL
- [ ] Required access level specified per tool

## 6. Definitions & Acronyms
- [ ] All internal jargon defined
- [ ] All acronyms expanded on first use

## 7. Step-by-Step Procedure
- [ ] Steps numbered and atomic
- [ ] Imperative voice
- [ ] Screenshots for UI-driven steps

## 8. Decision Points & Branching Logic
- [ ] All branches modeled explicitly
- [ ] Criteria for each branch are observable

## 9. Quality Checks & Acceptance Criteria
- [ ] Acceptance criteria are binary / observable
- [ ] Self-verification possible by operator

## 10. Outputs & Deliverables
- [ ] Primary deliverable named with location
- [ ] Secondary artifacts (logs, records) listed

## 11. Exceptions & Escalations
- [ ] Common exceptions listed
- [ ] Each has a named escalation owner
- [ ] Each has an SLA

## 12. Compliance & Regulatory References
- [ ] Relevant regulations cited
- [ ] Internal policies linked

## 13. Related Documents
- [ ] Parent / child / sibling SOPs linked
- [ ] Templates and policies linked

## 14. Change Log & Version History
- [ ] Table present with version, date, author, summary
- [ ] Most recent change documented

## 15. Approval Signatures
- [ ] Document owner signed
- [ ] Process owner signed
- [ ] Compliance reviewer signed (if regulated)

Run this against any existing SOP and you’ll find gaps. That’s the point. Fix them before they cost you in an audit, an incident, or a botched onboarding.

Wrapping Up

A complete SOP isn’t a long document. It’s a document where every required section is filled in deliberately. Fifteen sections sounds like a lot, but most of them are short. The discipline isn’t writing more, it’s writing the right things.

If you’re auditing existing documentation, start with sections 8, 11, and 14. Those are the highest-leverage gaps in almost every SOP I’ve reviewed. If you’re writing new ones, use the checklist above as scaffolding so you don’t ship something incomplete.

And if filling 15 sections from a blank page sounds painful, that’s exactly the problem we built Glitter to solve. Record your process, get the mechanical sections written for you, and spend your time on the strategic ones that actually require your judgment.