How to write a standard operating procedure (SOP): guide with examples

Every team has processes that need to happen the same way every time -- deploying code, handling customer escalations, onboarding new hires, responding to incidents. When those processes live in someone's head instead of a documented procedure, you get inconsistency, mistakes, and single points of failure.

Standard operating procedures solve this by turning tribal knowledge into repeatable, written instructions. This guide covers how to write SOPs that your team will actually follow, with practical examples for both technical and business teams.

What is a standard operating procedure (SOP)?

A standard operating procedure is a documented set of step-by-step instructions that describes how to perform a specific process or task. SOPs ensure that work is done consistently, regardless of who performs it or when.

The defining characteristic of an SOP is specificity. Unlike high-level policies or general guidelines, an SOP tells you exactly what to do, in what order, with what tools, and what the expected outcome should be at each step. It removes ambiguity so that a qualified team member can follow the procedure and achieve the same result every time.

SOPs are used across industries -- healthcare, manufacturing, finance, software development -- wherever consistency, safety, or compliance matters.

Why SOPs matter for modern teams

SOPs are not just for regulated industries or enterprise operations. Any team that wants to scale reliably needs documented procedures.

Consistency at scale. When your team goes from 5 to 50, you cannot rely on hallway conversations to transfer knowledge. SOPs ensure that the process works the same way whether it is your most experienced engineer or a new hire executing it.

Faster onboarding. New team members can get up to speed on critical processes without shadowing someone for weeks. A well-written SOP lets them execute independently, faster.

Reduced errors. Checklists and step-by-step procedures catch mistakes that memory alone misses. This is especially critical for high-stakes processes like production deployments, security incident response, and data handling.

Accountability and auditability. When processes are documented, you can track adherence, identify deviations, and improve over time. For teams in regulated industries, SOPs are often a compliance requirement.

Business continuity. If the one person who knows how to run your billing reconciliation process goes on vacation, your team should not grind to a halt. SOPs distribute knowledge across the organization.

Types of SOPs

Not every process needs the same format. Choose based on complexity and audience:

Step-by-step SOPs

The most common format. A sequential list of actions that must be performed in order. Works best for linear processes where each step depends on completing the previous one.

Best for: deployment procedures, account setup processes, data migration workflows.

Hierarchical SOPs

Step-by-step procedures with sub-steps nested under major steps. Useful when some steps contain multiple smaller actions that need their own detail.

Best for: incident response procedures, complex configuration workflows, compliance processes.

Flowchart SOPs

Visual decision trees that guide the reader through branching paths based on conditions. Useful when the process is not strictly linear and depends on decisions or outcomes at certain points.

Best for: troubleshooting guides, escalation procedures, approval workflows.

Checklist SOPs

A list of items to verify or complete, where order may not matter. Useful for processes where thoroughness is more important than sequence.

Best for: release readiness checks, security review checklists, environment setup verification.

How to write an SOP in 6 steps

Step 1: Identify the process and its scope

Start by defining exactly what process the SOP covers and where its boundaries are. A good SOP has a clear starting trigger (what initiates the process) and a clear end state (what "done" looks like).

Be specific about scope. "Handle customer support tickets" is too broad. "Escalate a P1 support ticket to the engineering on-call team" is the right level of specificity.

Ask yourself: Who performs this process? When is it triggered? What tools are involved? What does the successful completion look like?

Step 2: Gather information from the people who do the work

The worst SOPs are written by managers who have not actually performed the process in months or years. The best SOPs are written by -- or at minimum, closely reviewed by -- the people who execute the procedure regularly.

Interview the team members who run the process today. Watch them do it. Ask about edge cases, common mistakes, and undocumented workarounds. The goal is to capture the real process, not the idealized version.

If multiple people perform the same process differently, this is the moment to align on a single approach.

Step 3: Choose the right format

Based on the complexity and nature of the process, select from the formats described above. Most SOPs work well as step-by-step procedures. Use flowcharts when decision points make linear instructions confusing. Use checklists when completeness matters more than sequence.

Step 4: Write the SOP

A complete SOP includes these sections:

Title. Clear, descriptive, and specific. "Production Deployment Procedure for Core API Service" is better than "Deployment SOP."

Purpose. One to two sentences explaining why this SOP exists and what it ensures.

Scope. What the SOP covers and what it does not. Define the boundaries clearly.

Roles and responsibilities. Who is responsible for each part of the process. Use role names, not individual names, so the SOP survives team changes.

Prerequisites. What must be in place before starting the procedure. This includes access permissions, tools, prior completed steps, and any required approvals.

Procedure. The step-by-step instructions. This is the core of the SOP. Each step should be a single, clear action. Use numbered steps for sequential processes.

Expected outcomes. What the result should look like when the procedure is completed correctly.

Troubleshooting. Common issues that can arise during the procedure and how to resolve them.

Revision history. Track changes over time so readers know the SOP is current and can see what has changed.

Step 5: Review and validate

Before publishing, have the SOP reviewed by two groups:

The practitioners -- people who actually perform the process. They catch missing steps, incorrect details, and assumptions that do not hold in practice.

A fresh reader -- someone unfamiliar with the process who can follow the SOP and identify where instructions are unclear or ambiguous.

Run through the procedure using only the SOP as a guide. If the reviewer needs to ask questions or make assumptions, the SOP needs more detail.

Step 6: Publish and maintain

Publish the SOP where your team can find it easily. This is where many SOPs fail -- they get written and then buried in a shared drive or wiki page that no one visits.

Make SOPs searchable. Teams should be able to search for a process and find the relevant SOP instantly. Documentation platforms with strong search capabilities make this straightforward. Mintlify, for example, provides built-in search and AI-powered assistance that helps team members find the right procedure and get answers about it in context.

Assign ownership. Every SOP should have a designated owner responsible for keeping it accurate. Without clear ownership, SOPs decay.

Schedule reviews. Set a review cadence -- quarterly for frequently used procedures, annually for stable ones. Update the SOP whenever the underlying process changes, and mark the revision history.

Track usage. If your documentation platform provides analytics, use them. SOPs that are never accessed are either unnecessary, hard to find, or covering processes that have changed.

SOP examples

Example 1: Engineering deployment SOP

Title: Production Deployment Procedure -- Payment Service

Purpose: Ensure every production deployment of the payment service follows a consistent, safe process that minimizes the risk of customer-facing issues.

Scope: Covers deployments to the production environment for the payment-service repository. Does not cover staging deployments or database migrations (see separate SOP).

Roles: Deploying Engineer (performs the deployment), On-Call Engineer (available for rollback support), Engineering Manager (approves production deploys for the payment service).

Prerequisites: All CI checks passing on the main branch. Deployment approved by Engineering Manager in the deploy channel. On-Call Engineer confirmed available. No active incidents affecting the payment service.

Procedure:

1. Confirm all prerequisites are met. Post in the deploy channel: "Starting production deploy of payment-service, commit [hash]."
2. Run the deployment script: ./deploy.sh production payment-service.
3. Monitor the deployment dashboard for the rollout progress. Wait until 100% of instances are running the new version.
4. Check the error rate dashboard. Verify that the error rate has not increased by more than 0.1% compared to the pre-deploy baseline.
5. Run the post-deploy smoke test suite: ./test.sh smoke production.
6. If all checks pass, post in the deploy channel: "Deploy complete. All checks passing." If any check fails, initiate rollback (see Troubleshooting).

Troubleshooting: If the error rate spikes above the threshold, run ./rollback.sh production payment-service immediately and notify the On-Call Engineer. Post in the deploy channel with details of the failure.

Example 2: Customer escalation SOP

Title: P1 Customer Escalation Procedure

Purpose: Ensure critical customer issues are escalated to the appropriate team within defined time frames to minimize customer impact.

Scope: Covers escalation of P1 (service-disrupting) issues reported by customers. Does not cover P2-P4 issues or internal bug reports.

Roles: Support Agent (receives and categorizes the issue), Support Lead (approves P1 classification), Engineering On-Call (investigates and resolves).

Procedure:

1. Verify the issue meets P1 criteria: the customer's service is fully disrupted, or a core workflow is blocked for multiple users.
2. Get P1 classification approved by the Support Lead.
3. Create a ticket in the incident tracker with the P1 label, customer name, affected service, and reproduction steps.
4. Page the Engineering On-Call using the on-call tool.
5. Post in the incidents channel with a summary: customer name, impact, ticket link.
6. Update the customer within 30 minutes with an acknowledgment and expected next update time.
7. Continue updating the customer every 60 minutes until resolution.

Example 3: New hire onboarding SOP (checklist format)

Title: Engineering Team Onboarding Checklist

Before day one: Laptop ordered and configured. Accounts created for email, Slack, GitHub, and documentation platform. Onboarding buddy assigned. First-week schedule sent.

Day one: Welcome meeting with manager. Complete HR and compliance training. Set up local development environment using the setup guide. Introductions in team Slack channel.

Week one: Complete the "Your First Pull Request" tutorial. Shadow two code reviews. Read the architecture overview document. Attend team standup and sprint planning.

Week two: Pick up a starter task from the onboarding backlog. Complete the task with support from onboarding buddy. Participate in first code review as reviewer. One-on-one with manager to discuss first impressions and questions.

Best practices for writing SOPs

Write at the level of a competent new team member. Do not write for experts who already know the process, and do not write for someone with zero context. Aim for a reader who is qualified for the role but new to your specific process.

One procedure per SOP. Do not combine multiple processes into a single document. If you find yourself writing "for X, do this; for Y, do that," split it into separate SOPs.

Use specific language. "Check the dashboard" is vague. "Open the Datadog dashboard at [URL] and verify that the error rate is below 0.5%" is actionable.

Include screenshots and visuals where helpful. For UI-based processes, screenshots remove ambiguity about where to click and what to look for. For decision-based processes, flowcharts are clearer than prose.

Version your SOPs. Track changes with dates and descriptions. When someone refers to an SOP, they need to know it reflects the current process.

Keep SOPs close to where work happens. If your team works in a documentation platform, that is where SOPs should live. If engineers work from a Git repository, SOPs can live alongside code. The key is minimizing the distance between the procedure and the person who needs it. Platforms like Mintlify support Git-based workflows, making it possible to keep operational docs versioned and in sync with the codebase they describe.

How to keep SOPs current

The biggest risk with SOPs is staleness. A procedure that was accurate six months ago may be dangerously wrong today if the underlying tools, systems, or policies have changed.

Assign clear ownership. Every SOP should have a named owner (by role, not person) who is responsible for accuracy.

Trigger reviews on change. Whenever a tool, system, or policy covered by an SOP changes, the SOP owner should review and update the procedure.

Use automation. Some documentation platforms can detect when related code or configurations change and flag SOPs for review. This turns maintenance from a memory-dependent task into a system-driven one.

Collect feedback from users. Add a feedback mechanism to your SOPs so that people following the procedure can report inaccuracies or confusing steps.

Archive obsolete SOPs. Do not leave outdated procedures sitting alongside current ones. Archive or clearly mark deprecated SOPs to prevent confusion.

Key takeaways

Writing effective SOPs is about capturing real processes in clear, specific, actionable language -- then keeping them accurate over time. Start with your highest-impact processes, involve the people who actually do the work, choose the right format, and publish somewhere your team can find and search easily. The investment in documentation pays off every time a new team member onboards smoothly, an incident is handled consistently, or a process runs correctly without the one person who "just knows how."

Looking for a platform to host and maintain your team's SOPs alongside your technical documentation? Explore Mintlify to see how teams keep operational docs searchable, versioned, and up to date.