How to write an SOP: a step-by-step guide

To write an effective standard operating procedure, define the outcome and scope, observe the real process, assign responsibilities, document each action in clear language, test the instructions with a user and establish approval and review controls. The best SOP is not the longest. It is the one an employee can follow correctly under real working conditions.

This guide explains the complete writing process, a practical SOP format, common mistakes and the controls required to keep procedures current. For organisations managing many procedures, our SOP management approach connects documented standards with the wider context employees need to perform the work.

What is an SOP?

An SOP is a controlled document that explains how to perform a recurring task or process consistently. It translates a policy or business requirement into specific actions, decisions, responsibilities and evidence.

A policy might state that supplier payments require appropriate approval. The SOP explains who checks the invoice, which system they use, what evidence is required, which approval threshold applies and what to do when information is missing.

SOPs support quality, training, safety, compliance and continuity. They are especially useful when variation creates risk or when several employees must perform the same process.

When should you write an SOP?

Create an SOP when a process is repeatable, teachable and important enough to standardise. Strong candidates include:

• A task performed frequently by several employees.
• A process where errors affect customers, finance, safety or compliance.
• Work that depends heavily on one experienced person.
• A hand-off between teams where responsibilities are unclear.
• A process required by policy, regulation, contract or quality control.
• A workflow that may later support business process automation.

Do not use an SOP to force certainty onto work that requires expert judgement in every case. Document principles, decision criteria and escalation paths instead of pretending that every situation follows one script.

SOP, policy, process and work instruction

These documents should connect. The SOP should name the governing policy and link to detailed work instructions rather than repeating content that changes frequently.

The basic SOP format

Most organisations can start with the following structure.

Document control

Include a unique title or ID, owner, approver, version, effective date, review date and status. This information tells employees whether they are using an authorised document.

Purpose

State the outcome in one or two sentences. Explain why the procedure exists without repeating the whole process.

Scope

Define where, when and to whom the SOP applies. Include meaningful exclusions. Scope prevents employees from using a valid procedure in the wrong situation.

Roles and responsibilities

Name roles rather than individuals. Explain who performs, reviews, approves and handles exceptions.

Prerequisites and inputs

List required access, training, forms, systems and information. A user cannot follow a procedure if an essential dependency appears halfway through.

Procedure steps

Write numbered actions in execution order. Include decision points, quality checks and expected outputs.

Exceptions and escalation

Explain what to do when the normal path cannot be followed. Identify stop conditions and the responsible escalation role.

Records and controls

State what evidence must be retained, where it is stored and which control confirms completion.

References and definitions

Link to related policies, forms, systems and work instructions. Define specialised terms and abbreviations.

Revision history

Record material changes, dates and approvals. A useful history explains what changed, not merely that a new version exists.

How to write an SOP in ten steps

Step 1. Define the outcome

Start with the result the procedure must produce. “Process an invoice” is vague. “Validate, approve and record an eligible supplier invoice for payment” gives the writer a clearer endpoint.

Define how you will know the process is complete. The outcome might be a system status, approved record, delivered service or retained piece of evidence.

Step 2. Set the scope and boundaries

Identify the trigger, end point, users, locations, products and exceptions. Ask where this SOP stops and another process begins. Clear boundaries prevent duplication and conflicting instructions.

Step 3. Identify the process owner and subject-matter experts

The process owner is accountable for the procedure. Subject-matter experts explain how the work is performed. Front-line employees often know exceptions and workarounds that managers do not see.

Assigning an owner before writing prevents the document from becoming orphaned after publication. A scalable SOP management software should make ownership, status and revision visible.

Step 4. Observe the real process

Do not write only from memory. Watch the task, inspect systems and collect existing forms, policies, screenshots and checklists. Compare how different employees perform the work.

If actual practice differs from policy, resolve the gap before publishing. The SOP should not quietly legitimise a workaround or describe an ideal process nobody can perform.

Step 5. Choose the right format

Use a simple step list for linear work. Use hierarchical steps when each main action contains several sub-actions. Add a decision table when outcomes depend on clear criteria. Use a flowchart only when branching is difficult to understand in prose.

The format should reduce cognitive effort. Avoid making users interpret a dense diagram for a short linear task.

Step 6. Draft actions in the order performed

Begin each step with a verb: verify, open, compare, record, submit or escalate. Name the system or record and define the expected result.

• Weak: “Invoice details should be checked.”
• Better: “Compare the supplier name, purchase order and amount in the invoice against the approved purchase order.”

Use the active voice when responsibility matters. Keep one primary action per numbered step, then place conditions or explanation beneath it.

Step 7. Add decisions, controls and exceptions

Real processes are rarely perfectly linear. Explain what the employee should do if information is missing, a threshold is exceeded or a system is unavailable.

Write decision criteria that can be applied consistently. Replace “seek approval if necessary” with the actual threshold and approver role. Add safety warnings before the risky action, not after it.

Step 8. Include roles and evidence

For each control point, state who is responsible and what record proves completion. Evidence may include a system status, approval log, signed form or saved output.

This makes the SOP operational and auditable. It also exposes unclear hand-offs before they become production problems.

Step 9. Test the SOP with a real user

Ask an employee who did not write the document to complete the process using only the draft. Observe where they hesitate, ask a question or make an incorrect assumption.

Testing is more valuable than another silent review. It reveals missing prerequisites, ambiguous language and steps that rely on tribal knowledge.

Step 10. Approve, publish and schedule review

Obtain approval from the process owner and any required compliance, safety or quality role. Publish the SOP in the location employees use and remove obsolete copies.

Set a review date and event-based triggers. A system change, policy update, incident or process failure may require review before the calendar date.

SOP writing rules that improve usability

Write for the person performing the task

Use the language employees use at work. Define unavoidable technical terms. Do not write to impress an auditor at the expense of the operator.

Make steps specific and observable

A good instruction tells the user what action to take and what correct completion looks like. Avoid words such as “properly”, “regularly” or “as needed” unless you define them.

Put information where it is needed

Place warnings before hazards, decision criteria at the decision and examples beside the relevant step. Do not make the user search an appendix for essential instructions.

Keep related content connected

Link policies, templates and work instructions instead of copying them. Duplication makes updates harder and creates competing versions. A single source of truth clarifies which document is authoritative.

Use visuals deliberately

Screenshots help when interface location matters, but they become stale after software changes. Crop to the relevant area, add alt text and pair the image with a written instruction. Use flowcharts for meaningful branches, not decoration.

Design for scanning

Employees often consult an SOP during work rather than read it from beginning to end. Use descriptive headings, short paragraphs, numbered steps and visible decision criteria.

A practical SOP example

Consider an SOP for approving a supplier invoice.

Purpose: Ensure eligible invoices are validated, approved and recorded before payment.

Scope: Applies to invoices from approved suppliers with a valid purchase order. Excludes employee expenses and emergency payments.

Roles: Accounts payable validates documents; the budget owner approves within their threshold; finance handles exceptions.

Procedure:

1. Confirm the supplier is active in the approved vendor record.
2. Match the invoice to the purchase order and evidence of receipt.
3. Check the amount, tax treatment, payment terms and bank details.
4. If the amount or bank details differ, stop processing and follow the exception path.
5. Submit the matched invoice to the authorised budget owner.
6. Record approval and update the invoice status in the finance system.
7. Retain the invoice, match evidence and approval record according to policy.

This compact example shows the essential pattern: scope, role, action, decision, evidence and escalation. A production SOP would contain the organisation's exact thresholds and system instructions.

How to ensure SOP compliance

Compliance is not achieved by asking employees to acknowledge a document once. The procedure must be accessible, workable and reinforced by the operating environment.

Use these controls:

• Assign an accountable owner and authorised approver.
• Keep one current published version and retire superseded copies.
• Provide role-based training where the risk warrants it.
• Embed required approvals and evidence into the workflow.
• Monitor exceptions, errors and control failures.
• Review the SOP after incidents and material process changes.
• Make the relevant instruction easy to retrieve at the point of work.

Our Company Brain helps connect procedures with related policies and live company context. A knowledge support agent can make the approved guidance easier to reach while maintaining the link to its source.

Can ChatGPT or AI write SOPs?

AI can help create an outline, simplify language, identify missing sections and convert interview notes into a structured first draft. It should not be treated as the authority on how your process works.

An effective SOP requires company-specific facts: systems, permissions, thresholds, responsibilities, hazards and exception rules. Those inputs must come from verified internal sources and subject-matter experts. A model may produce plausible but incorrect detail when context is missing.

Use AI as a drafting assistant, then require owner validation, user testing and approval. An AI knowledge management system improves this process by grounding assistance in authorised company knowledge rather than relying only on general model training.

Common SOP mistakes

Documenting the ideal instead of the real process

If systems or resources do not support the written steps, employees will create workarounds. Validate the process before standardising it.

Hiding responsibility

Passive language often conceals who must act. Name the responsible role, especially for approval and escalation.

Omitting exception paths

The normal route is usually easy. The value of an SOP appears when something is missing, late or outside limits.

Writing too much

Long background sections obscure the action. Put rationale in policy or supporting guidance unless the user needs it to make a decision.

Publishing without maintenance

An out-of-date SOP may be more dangerous than no SOP because it appears authoritative. Use version control, ownership and review triggers.

Measuring publication instead of performance

The number of completed SOPs is not the outcome. Measure process accuracy, cycle time, exceptions, employee questions and incidents.

An SOP quality checklist

Before publication, confirm that:

• The title identifies one specific process.
• Purpose, scope, trigger and end state are clear.
• Roles and approval responsibilities are named.
• Prerequisites and required access are complete.
• Steps follow the actual execution order.
• Decision criteria and exception paths are explicit.
• Safety, quality and compliance controls appear at the right point.
• Required evidence and retention are defined.
• A new user has tested the instructions.
• The owner, version, approval and review trigger are visible.
• Related policies and templates link to authoritative sources.
• Superseded copies will be removed or marked obsolete.

Write procedures that remain useful after publication

A high-quality SOP turns organisational expectations into work an employee can perform consistently. Its value depends on accuracy, usability and governance, not word count.

Start by observing one real process. Define the outcome and boundaries, write actions in execution order, test the procedure with a user and assign an owner before publishing. Then make the SOP retrievable within the wider knowledge management environment so employees can use the current instruction when it matters.

If you want to connect approved procedures with the systems and context your teams already use, book a demo.