How to Create an SOP: Step-by-Step Guide with Examples

The phrase "create an SOP" conjures images of elaborate document templates, approval workflows, and binders of printed procedures. In reality, creating an effective SOP is a focused 45-minute activity if you approach it right — and a months-long ordeal if you don't.

This step-by-step guide covers how to create an SOP that teams will actually follow, with examples at each stage.

Step 1: Choose the right procedure to start with

The most common mistake in SOP programs is trying to document everything at once. You end up with a sprawling SOP library that's 80% incomplete and 100% unused.

Start with one procedure: the one that generates the most questions on your team. The procedure that new hires ask about most in their first week. The one that, when it's done wrong, causes the most downstream problems.

This is your highest-value SOP. Build it first. Prove the format works. Then expand.

For a more complete view of what types of SOPs to prioritize by team, see our SOP examples guide which covers 10 common procedures across customer support, operations, HR, and IT.

Step 2: Define the scope precisely

Before writing a single step, write these three things:

• Trigger: "Use this procedure when [specific situation occurs]"
• Owner: "[Role name] runs this procedure"
• Outcome: "This procedure ends when [specific outcome is achieved]"

Example:

• Trigger: Customer submits a refund request for a subscription product
• Owner: Customer support agent (Tier 1)
• Outcome: Refund is processed and confirmation email is sent, OR case is escalated to billing team

If you can't write a single-sentence outcome, the SOP scope is too broad. Split it.

Step 3: Interview the person who does it best

Don't write the SOP from memory, from a job description, or from what the process is supposed to look like. Interview the team member who runs this procedure most reliably.

Ask them: "Walk me through exactly what you do, from the moment you receive this request to the moment it's closed."

Then stop talking and take notes verbatim. Pay special attention to:

• Every "and then I..." — that's a step
• Every "it depends on..." — that's a branching condition
• Every "usually I..." — that's an exception you need to handle
• Every "if something goes wrong..." — that's your escalation path

This 20-minute conversation will give you 80% of your SOP content.

Step 4: Draft the steps in order

Take your interview notes and convert them into numbered steps. The rules:

• One action per step
• Start every step with an action verb: Open, Check, Verify, Enter, Send, Click, Confirm
• Name the specific tool: "Open Salesforce" not "check the CRM"
• Keep steps to actions completable in under 5 minutes

Example draft for the refund procedure:

1. Open the customer's account in Salesforce
2. Navigate to the Subscription tab
3. Confirm subscription status is currently Active or Cancelled
4. Check the purchase date against the 30-day refund eligibility window
5. If purchase date is within 30 days: proceed to step 6
6. If purchase date is outside 30 days: go to step 12 (escalation path)
7. Ask customer for preferred refund method: original payment or store credit
8. Open the billing portal and navigate to Refunds
9. Enter order ID and refund amount
10. Select refund method and submit
11. Send refund confirmation email from template RF-001
12. Log refund in CRM with reason code and close ticket

Step 5: Map the branching conditions

Every "it depends" from your interview notes becomes a branching condition. Branching conditions are the most important — and most neglected — part of SOP design.

For each condition you identified, define:

• What question triggers the branch?
• What are the possible answers?
• What happens next for each answer?

In a flat document, you handle this with "go to step X" directives. This works but creates navigation overhead. A better approach is to build the procedure as an interactive flow using a visual flow builder: the user answers the question and sees only their relevant path.

A decision tree format is particularly effective for SOPs with complex branching — it makes the logic visual and auditable.

Step 6: Add the escalation path

Every SOP needs exactly one clear answer to: "What do I do if I can't resolve this?"

Format: "If you cannot resolve [X], escalate to [specific role] via [specific channel]."

Avoid vague escalation instructions like "contact your manager" or "escalate appropriately." Specific role, specific channel. The person following the SOP should never have to figure out who to contact.

Step 7: Test with a pilot user

Before publishing, give the draft SOP to a team member who wasn't involved in writing it — ideally someone newer who won't fill in gaps from memory.

Ask them to follow the procedure for a real task, out loud, with you watching. Don't intervene. Don't answer questions. Just observe.

Every moment they hesitate, ask a question, re-read a step, or take an action that isn't in the SOP is a signal that the SOP needs revision. This feedback loop is how you eliminate the gaps between how you wrote the procedure and how someone will actually use it.

Most SOPs need two rounds of pilot testing before they're ready for broad use.

Step 8: Publish it where work happens

Procedure lives in a shared drive = procedure doesn't exist for practical purposes.

Publish the SOP in the place where the work happens:

• Embed it as an iframe in your help center or internal dashboard
• Share a direct link in the relevant Slack channel
• Pin it in your ticketing system or CRM for the teams that use it daily
• Add a QR code to physical workstations for operations or retail contexts

The zero-friction principle: the SOP should be accessible with one click or less from the place where someone would need it.

See how operations teams and helpdesk teams implement this in practice.

Step 9: Measure and improve

After publishing, measure adoption. If you're using interactive SOP software, you'll have access to:

• Access counts: is anyone actually using it?
• Completion rates: how many users who start the procedure finish it?
• Drop-off nodes: where do users abandon the procedure?

A completion rate below 70% on a procedure that should be followed to completion indicates a problem. Identify where users drop off and investigate: is the step unclear? Does it require a tool access they don't have? Is the step itself wrong?

Step 10: Schedule the first review before you publish

Set the next review date before the SOP goes live. Put it in your calendar. Quarterly reviews are a minimum — more frequent reviews for fast-changing processes.

The review checklist: are tool names current? Are role names current? Do the steps match current practice? Has anyone flagged outdated steps? Do analytics show unexpected drop-off?

If you're using SOP software with live links, updates take effect immediately — no redistribution required. The review becomes a 30-minute edit session rather than a document management exercise.

A complete SOP example

Putting all the steps above together, here's what a complete, well-structured SOP looks like for a customer escalation procedure:

Title: How to handle a customer escalation request
Trigger: Customer asks to speak with a supervisor, or uses the phrase "I want to cancel"
Owner: Customer support agent (Tier 1)
Outcome: Escalation is logged and transferred to senior agent, OR issue is resolved at Tier 1

1. Acknowledge the request: "I understand you'd like to speak with someone else. Let me make sure I have everything I need to pass this along correctly."
2. Review the full ticket history in Zendesk
3. Identify the core unresolved issue (separate from the emotional context)
4. Determine: can this be resolved at Tier 1? (branch: Yes / No)
5. If Yes: offer resolution and confirm acceptance before closing
6. If No: document issue summary in the Escalation Notes field
7. Transfer ticket to senior support queue with priority flag
8. Inform customer of expected callback time (within 2 business hours)
9. Log outcome in CRM with escalation reason code

Escalation: If the senior support queue has no available agents, notify support manager via #escalations Slack channel with ticket number.

Frequently asked questions

How do you create a standard operating procedure?

Create an SOP by: (1) identifying the process and its trigger, (2) interviewing the person who does it best, (3) writing verb-first numbered steps, (4) mapping branching conditions explicitly, (5) testing with a pilot user, (6) publishing where the work happens, and (7) scheduling regular reviews.

What are the 5 parts of an SOP?

The five essential parts of an SOP are: (1) trigger condition, (2) responsible role, (3) numbered steps, (4) branching conditions for common exceptions, and (5) escalation path.

How long does it take to write an SOP?

A well-scoped SOP for a single process takes 30 minutes to 2 hours to write, depending on complexity. Building it as an interactive flow in PathPilot takes an additional 15–20 minutes.

What is the best format for an SOP?

For procedures with conditional logic, an interactive flow format is significantly more effective than a flat document. Interactive SOPs show users only the steps relevant to their situation, reducing cognitive load and increasing completion rates.