How to Write an SOP: Standard Operating Procedure Template and Best Practices

The purpose of an SOP is simple: allow any trained person to execute a process correctly without asking questions. The failure mode is equally simple: the document is so long, abstract, or bureaucratic that nobody reads it, and the tribal knowledge it was supposed to replace stays locked in one person's head.

Good SOPs are short, specific, and actually followed. Here's how to write one that qualifies.

When you need an SOP vs. when you don't

You need an SOP when:

• A process happens repeatedly (more than once a month)
• Multiple people perform the process and consistency matters
• A step performed incorrectly causes downstream problems
• The process is complex enough that people make different choices at decision points

You don't need an SOP when the process is truly one-time, when it requires continuous expert judgment, or when it changes so frequently that a document would be outdated before it's read.

The SOP structure that actually gets used

Header block

Every SOP needs: title, SOP number (for version control), owner (a specific person, not a team), effective date, and next review date. Without an owner, no one updates it. Without a review date, it quietly becomes wrong.

Purpose (2-3 sentences)

What does this procedure accomplish? Why does it exist? This isn't a background section — it's a single crisp statement: "This SOP defines the process for onboarding new hires to ensure they have system access, equipment, and introductory training before their first day."

Scope

Who does this apply to? When is it triggered? "Applies to all full-time hires. Triggered when an offer letter is signed."

Roles and responsibilities

List every role involved in the process and what they're responsible for. A table works well:

Role	Responsibility
HR Manager	Initiates process, sends welcome packet
IT	Provisions accounts and equipment
Hiring Manager	Assigns buddy, schedules week-1 meetings

Materials and prerequisites

What does the person need before starting? Systems access, tools, templates, information. If they have to go find something mid-process, the procedure breaks down.

Step-by-step procedure

This is the core. Rules for writing steps that work:

Use active verbs. "Click the Deploy button" not "The deployment button should be clicked."

One action per step. "Log into the system, navigate to Settings, and click Export" is three steps.

Be specific about decisions. "If the status is Pending, proceed to Step 7. If the status is Error, escalate to the on-call engineer."

Number everything. Don't use bullet points for procedural steps — they imply the order doesn't matter.

Expected outcome

What should the person see/have when they're done? "Account provisioned, welcome email sent, equipment shipped with tracking number recorded in HRIS." This is how the person knows they completed it correctly.

Exception handling

What are the known failure modes and what should they do? This is the "if something goes wrong" section. Keep it short — cover the 2-3 most common problems.

Revision history

A simple table: version, date, change description, changed by. This tells the reader how current the document is and what changed.

The secret to SOPs that get maintained

Single ownership. Assign one specific person — not a team — as the SOP owner. They're responsible for reviewing it before the review date and updating it when the process changes. Without single ownership, SOPs drift and become unreliable within a year.

Generate an SOP template →