How to Write an SOP (Standard Operating Procedure)

By Nikhil Gupta

How to Write an SOP (Standard Operating Procedure)

Short answer: To write an SOP:

1. Define its purpose and scope.

2. Interview the people who do the work.

3. Map the process visually.

4. Write numbered steps in plain, active language.

5. Add decision rules and exceptions.

6. Name an owner and a review date.

7. Test it with someone who's never done the task.

The most common mistake is writing the SOP from memory or policy instead of from how the work actually happens.

Part of the Process Documentation Guide.

What an SOP is (and isn't)

A standard operating procedure is a documented, repeatable way to carry out a process so that it's done consistently, safely, and correctly, whoever does it.

An SOP is not a policy (which says what must happen and why) and not a work instruction (which details one task at keystroke level). See SOP vs work instruction vs process map.

Step 1: Define purpose and scope

Write two sentences:

• Purpose: why this procedure exists. "Ensure vendor invoices are approved and paid accurately and on time."

• Scope: where it starts and ends, and what's excluded. "From invoice receipt to payment. Excludes employee expense claims."

If you can't state the start and end points, the SOP will sprawl.

Step 2: Talk to the people who do the work

Interview one or two people who actually run the process. Walk through a real, recent example ("show me the last invoice you processed"), not the ideal version. Ask:

• What triggers this?

• What do you do first, then next?

• Where do you wait on someone?

• What goes wrong, and what do you do then?

Recording the conversation helps. Vevos can turn a walkthrough transcript into a process map automatically.

Step 3: Map the process before writing it

A visual map catches gaps that text hides: missing decisions, unclear hand-offs, steps nobody owns. Use swimlanes for roles and diamonds (gateways) for decisions. A BPMN map is ideal because it's standard and can later be automated.

Shortcut: describe the process or upload existing notes and Vevos generates the BPMN map, then drafts the written procedure from it.

Step 4: Write clear, numbered steps

Rules for steps people will follow:

• Start each step with a verb: "Match the invoice to the purchase order."

• One action per step.

• Say who does it: "AP clerk: …"

• Use the names people actually use for systems and forms.

• Include the "how" only where needed. Link to work instructions for detailed system steps.

• Keep it short. If a step needs a paragraph, it's probably two steps.

Step 5: Add decisions and exceptions

Most SOPs describe only the happy path. Add:

• Decision rules: "If the amount is over $5,000, send it to the Finance Director for approval."

• Exceptions: "If the invoice doesn't match the PO, return it to the vendor with the reason."

• Escalations: "If it's not approved within 3 business days, escalate to…"

Step 6: Add the control information

Every SOP should include:

Step 7: Test it

Give the SOP to someone who's never done the task and watch them follow it. Every question they ask is a gap. Fix it, then publish.

Step 8: Publish where people work, and keep it current

An SOP in a forgotten folder doesn't get followed. Publish it where the team works, link it from the systems it covers, and set review triggers.

Example: a short SOP

FIN-007 Vendor Invoice Approval · Owner: AP Manager · v1.2

Purpose: Approve and pay vendor invoices accurately and on time. Scope: Invoice receipt to payment. Excludes employee expenses.

1. AP clerk: Log the invoice in the ERP within 1 business day of receipt.

2. AP clerk: Match the invoice to the PO and goods receipt.

   • If they don't match: return to the vendor with the reason; end.

3. AP clerk: Route for approval.

   • Over $5,000: Finance Director.

   • $5,000 or less: Department approver.

4. Approver: Approve or reject within 3 business days.

   • If not actioned in 3 days: AP escalates to the approver's manager.

5. Payments: Schedule payment in the next payment run.

Review: annually, or when the ERP or approval limits change.

Open this process as a BPMN template →

FAQ

How long should an SOP be?

As short as possible while still complete. Most good SOPs fit on one to three pages, with detailed system steps in linked work instructions.

Who should write the SOP?

The process owner is accountable, but it should be drafted with the people who do the work.

Can AI write SOPs?

AI can draft an SOP from a description, existing notes, or a recorded walkthrough. Vevos generates the process map and the written documentation together. A person who knows the process should still review it.

What's the best SOP format?

A short header (ID, owner, version), purpose and scope, a process map, numbered steps with decisions and exceptions, and related documents. Use the free SOP template.

Draft your SOP with AI: describe the process in Vevos and get the map and the documentation.