What is a Standard Operating Procedure?

An SOP is a documented set of step-by-step instructions for performing a routine task the same way every time. Good SOPs reduce errors, speed up training, and make a process auditable and repeatable across a team.

What sections should an SOP include?

A complete SOP has a title and document ID, purpose, scope, roles and responsibilities, required materials or systems, the numbered procedure, a review schedule, and version history. The builder produces all of these.

Why does an SOP need a document ID and version?

IDs and versions make the document traceable and auditable. When a process changes you bump the version and log it in the history table, so anyone can see which procedure was in force at a given time.

How often should an SOP be reviewed?

At least annually, and sooner whenever the process, tools, or regulations change. The builder records your chosen review cycle so the obligation is written into the document itself.

Can I reorder the steps?

Yes. Each procedure step has up and down arrows so you can sequence them precisely, plus a delete control. The output renumbers automatically, so the final SOP always reads cleanly.

What is the Standard Operating Procedure (SOP) Builder?

Builds a Standard Operating Procedure with purpose, scope, responsible roles, materials required, a numbered step-by-step procedure, review schedule, and a version history table. It runs free in your browser on Gera Tools, with nothing uploaded.

Standard Operating Procedure (SOP) Builder

Name: Standard Operating Procedure (SOP) Builder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Write a clean, auditable SOP

Standard Operating Procedures turn tribal knowledge into something a new hire can follow on day one. This builder gives you a properly structured SOP — header metadata, purpose, scope, roles, materials, a numbered procedure, a review schedule, and a version history table — without wrestling with document templates.

How it works

The tool assembles the conventional SOP sections in order. Roles and required materials are entered as comma-separated lists and rendered as clean bullet points, while the procedure is a reorderable list of steps that the output numbers automatically. Because the numbering is generated at render time, inserting, deleting, or moving a step never leaves a gap or a duplicate.

The header carries the document ID, version, effective date, and process owner so the SOP is traceable. The version-history table seeds an initial release row, giving you a place to log every future change alongside the date and author — the backbone of auditable process control.

What each section is for

Purpose is a single paragraph that answers why this SOP exists. It grounds the reader before any procedure starts and helps reviewers determine whether the document is still relevant over time. A good purpose statement names the risk the SOP mitigates or the consistency goal it achieves.

Scope defines what is in and out of the procedure. This is especially important for SOPs that sit near related procedures — specifying exactly where this process starts and ends prevents confusion with adjacent documents and limits the scope of change when processes update.

Roles and responsibilities should name roles, not people. “The Accounts Payable Officer” is correct; “Jane Smith” causes the SOP to become inaccurate every time someone changes jobs. Some organisations use a RACI table here (Responsible, Accountable, Consulted, Informed); the builder uses a simpler list that works for most team sizes.

Materials and systems is where you list access requirements, tools, software, and any physical materials the person following the SOP will need before starting. Including this prevents the first step from being “log in to the system” when the person reading the SOP doesn’t have an account yet.

Procedure is the numbered, sequenced list of steps. Each step should be:

Expressed as an action starting with a verb (“Verify the invoice total matches the purchase order”, not “The invoice total”)
Specific enough that two different people following the same step would do the same thing
Testable — if you cannot tell whether the step was completed correctly, split it or add acceptance criteria

Review schedule and version history make the SOP a living document. Many quality management frameworks (ISO 9001, healthcare accreditation bodies) require SOPs to be formally reviewed at defined intervals and for changes to be logged with dates and authors. The version history table the builder generates satisfies this requirement.

Worked example of a single SOP step sequence

For a customer refund process, three steps written well:

Verify the refund request matches an existing order number in the system and the request was received within the return window stated in the refund policy.
Issue the refund in the payment processor at the exact order value. Do not adjust the amount without manager approval.
Send the customer the refund confirmation email template from [template library location], inserting the order number and refund amount.

Each step names exactly what to check, what to do, and where to find resources — nothing is left to interpretation.

Tips and notes

Write each step as a single, testable action that starts with a verb. If a step contains a conditional (“if X, do Y; if not, do Z”), split it into two steps with a decision point.
Name roles, not people, in the responsibilities section so the SOP survives staff changes.
Bump the version number and add a history row every time the process changes, even for small edits — the history log is what makes the document auditable.
Keep the scope tight — one SOP per task. Multi-process documents are the ones nobody reads and nobody updates.