How to Write a Standard Operating Procedure from Scratch

Writing a good SOP takes more than putting steps in a numbered list. The goal is to produce a document that someone unfamiliar with the process can follow accurately on their first attempt, without needing to ask clarifying questions. This guide walks you through every stage of the drafting process, from selecting the right template to submitting your finished SOP for review.

The SOP Drafting Process

Choose the Right Template

Before you write a single word of content, select the template that matches the structure of your process. Using the wrong template creates confusion for readers and makes reviews harder.

Three templates are available in the SOP library:

Process SOP — Use this for linear, sequential procedures where steps must be completed in a specific order. This is the most common template and suits the majority of operational processes (e.g., onboarding a new vendor, processing an invoice).
Decision Tree SOP — Use this when the procedure branches based on conditions or inputs. If your process includes steps like "if X, do Y; otherwise, do Z," this template makes those branches explicit and easy to follow.
Checklist SOP — Use this for procedures where order is flexible but completeness is critical. This works well for audits, pre-launch checks, or recurring maintenance tasks where the goal is verifying that all items have been addressed.

If you're unsure which template to use, start with the Process SOP. You can always restructure it during the review phase.

Fill In the Header Fields

Every SOP begins with a structured header. Open your chosen template and complete each of the following fields before writing any procedure content.

Title — Write a clear, action-oriented title that names the process specifically. Start with a verb or a subject noun (e.g., "Submit a Vendor Payment Request" or "Quarterly Access Review Procedure").
Owner — Assign the person or role accountable for maintaining this SOP. The owner is responsible for keeping it accurate and initiating scheduled reviews.
Department — Identify the primary team this SOP belongs to. If the process spans multiple teams, list the team that owns the majority of the steps.
Effective Date — Leave this blank until the SOP is approved. The platform fills it in automatically upon publication.
Scope — Describe what the SOP covers and, critically, what it does not. Be explicit about edge cases that fall outside this procedure.

The Scope field is one of the most commonly skipped fields and one of the most important. A well-written scope prevents the SOP from being misapplied to situations it wasn't designed for. For example: "This SOP applies to refund requests submitted through the support portal. It does not apply to refunds initiated directly by account managers or chargebacks processed through the payment gateway."

Define the Procedure Steps

The procedure section is the core of your SOP. Write each step as a discrete, executable action. Follow these conventions to ensure your steps are clear and consistent:

Start every step with an imperative verb. Tell the reader exactly what to do: "Navigate to the Billing dashboard," "Select the affected invoice," "Click Approve."
One action per step. If a step requires two actions, split it into two steps. Readers lose their place when steps bundle multiple things together.
Include expected outcomes. After describing the action, note what the reader should see or confirm before moving on. For example: "Click Submit. The system displays a confirmation banner and sends a notification email to the requester."
Number every step sequentially. Never use bullet points for procedure steps — numbered lists signal order and make it easy to reference a specific step by number.
Specify roles for multi-actor processes. If different steps are performed by different people, label each step with the role responsible (e.g., [Finance Analyst] or [Manager]).

If your procedure has distinct phases (e.g., preparation, execution, verification), group steps under clearly labeled subsections to improve readability.

Add Supporting Materials

After your procedure steps are drafted, strengthen the SOP by attaching or linking supporting materials. These help readers handle edge cases, understand context, and navigate related processes.

Screenshots and diagrams — Embed screenshots for any step that involves navigating a UI, especially when field names or button locations may not be obvious. Label each screenshot with a caption that describes what the reader is looking at.
Templates and forms — If the procedure requires filling out a form or using a template, link directly to the current version. Do not embed copies — link to the source so readers always access the most up-to-date file.
Reference documents — Link to any policy documents, compliance requirements, or technical specifications that govern this process.
Related SOPs and how-to guides — Use the Related Documents field to connect this SOP to adjacent procedures. If a reader finishes this SOP and commonly needs to perform another process next, surface that link here.

Link related SOPs and how-to guides inline within the procedure steps, not just in the Related Documents footer. If step 4 of your SOP frequently requires readers to consult a separate guide, embed that link in step 4 directly. Readers are more likely to find it when they need it.

Submit for Review

Once your draft is complete, submit it for review to begin the approval workflow.

Open the SOP in the editor and click Request Review in the top action bar.
Select one or more reviewers from the dropdown. Reviewers must have at minimum Contributor access to the SOP's department workspace.
Add a Review Note describing what you'd like reviewers to focus on — for example, whether the scope is correctly defined or whether the steps reflect the current process accurately.
Set a Due Date for the review. The platform sends reviewers a reminder 48 hours before the due date if no review action has been taken.
Click Submit. The SOP status changes from Draft to In Review, and all assigned reviewers receive a notification.

You can continue editing the SOP after submission, but any changes reset the review and require reviewers to re-examine the updated content. Avoid making substantive edits once a review is underway unless a reviewer has flagged a specific issue.

Writing Effective Procedure Steps

The quality of your procedure steps determines whether your SOP is actually usable. A technically complete SOP that's written unclearly creates more confusion than no SOP at all. Apply these principles when drafting and revising each step.

Use imperative verbs. Every step should begin with an action verb in the imperative mood: "Open," "Enter," "Confirm," "Notify," "Upload." Avoid passive constructions like "The form should be submitted by…" — they obscure who is responsible and what the action is.

Describe one action at a time. If you find yourself writing "and then" within a single step, split it. Each step should represent a single, verifiable action. This makes it easier for readers to track their progress and easier for reviewers to identify gaps.

State the expected outcome. Don't just describe what to do — tell the reader what a successful action looks like. "Click Save. A green confirmation banner appears at the top of the page and the record status updates to Submitted." This lets readers self-verify without guessing.

Anticipate common errors. If a particular step is frequently misunderstood or has a common failure mode, add a brief inline note directly below that step. For example: "Note: If the Save button is grayed out, one or more required fields are incomplete. Scroll up to check for fields outlined in red."

Keep language consistent. Use the same terminology throughout the SOP that readers will see in the UI, system, or form they're working with. If the system calls it a "Work Order," don't call it a "job ticket" in your steps.

Example: A Well-Structured Procedure Step

The following example illustrates the level of specificity and structure that a good SOP step should have.

## Step 3 — Submit the Access Request Form

[Requester]

1. Navigate to the IT Portal at `https://portal.example.com/access-requests` and sign in with your company SSO credentials.
2. Click **New Request** in the top-right corner of the dashboard.
3. In the **Request Type** dropdown, select **System Access — New Grant**.
4. Enter the full name and employee ID of the person who requires access in the **Recipient** field.
5. Select the target system from the **Application** dropdown. If the system is not listed, select **Other** and enter the system name in the text field that appears.
6. In the **Justification** field, describe why access is needed, referencing the relevant project or business requirement. Minimum 50 characters are required.
7. Attach a copy of manager approval (email screenshot or signed form) using the **Attach Supporting Document** button.
8. Click **Submit Request**. The portal displays a confirmation screen showing your request ID (format: `AR-YYYYMMDD-XXXX`). Copy this ID — you'll need it to track the request status.

**Expected outcome:** The requester receives an automated email confirmation within 5 minutes. The assigned IT provisioner receives a task notification and has 2 business days to action the request.