A structured SOP template for operations and admin teams — with purpose, scope, roles, step-by-step procedure, and revision history sections. Download as a Word document and generate a completed SOP for any repeatable process in WordFields.
[Procedure title — e.g. Supplier Invoice Processing]
| SOP number | [Department prefix and number — e.g. FIN-012] |
| Version | [Version — e.g. 1.0] |
| Effective date | [Date this version takes effect] |
| Next review | [Date by which this procedure must be reviewed] |
| Owner | [Name and job title of the person who owns this procedure] |
| Approved by | [Name and job title of the approving manager] |
| Department | [Owning department] |
Purpose
[Why this procedure exists and the outcome it is meant to secure, in one to three sentences]
Scope
This procedure applies to [Who must follow it and what it covers — e.g. all finance staff processing supplier invoices received by post or email]. [What it does not cover, as a full sentence — e.g. It does not apply to employee expense claims. Leave empty if nothing is excluded.]
Roles and responsibilities
| Role | Responsibility |
|---|---|
| Process owner | [e.g. Keeps this procedure current, approves exceptions and reviews it annually] |
| [Who carries out the procedure — e.g. Accounts payable clerk] | [e.g. Carries out steps 1 to 5 for every invoice received] |
| [Who checks or approves — e.g. Finance manager] | [e.g. Approves invoices above the authorisation limit and signs off the weekly payment run] |
Definitions
[Terms and abbreviations used, one per line — e.g. PO: purchase order raised in the ERP system. Leave empty if none.]
Procedure
[One step per line, numbered. Say who does what, in which system, and to what standard. Include approval and escalation points.]
Records
[What is recorded, where it is kept and for how long — e.g. Approved invoices are filed in the finance system for seven years]
Related documents
[Policies, forms and other procedures this one relies on, one per line. Leave empty if none.]
Revision history
| Version | Date | Author | Summary of changes |
|---|---|---|---|
| [[Version]] | [TEXT([Effective Date], "d")] | [VALUE("Author.FullName")] | [What changed in this version] |
| SOP number | Department prefix and number — e.g. FIN-012 |
| Version | Version — e.g. 1.0 |
| Effective date | Date this version takes effect |
| Next review | Date by which this procedure must be reviewed |
| Owner | Name and job title of the person who owns this procedure |
| Approved by | Name and job title of the approving manager |
| Department | Owning department |
Why this procedure exists and the outcome it is meant to secure, in one to three sentences
This procedure applies to Who must follow it and what it covers — e.g. all finance staff processing supplier invoices received by post or email. What it does not cover, as a full sentence — e.g. It does not apply to employee expense claims. Leave empty if nothing is excluded.
| Role | Responsibility |
|---|---|
| Process owner | e.g. Keeps this procedure current, approves exceptions and reviews it annually |
| Who carries out the procedure — e.g. Accounts payable clerk | e.g. Carries out steps 1 to 5 for every invoice received |
| Who checks or approves — e.g. Finance manager | e.g. Approves invoices above the authorisation limit and signs off the weekly payment run |
Terms and abbreviations used, one per line — e.g. PO: purchase order raised in the ERP system. Leave empty if none.
One step per line, numbered. Say who does what, in which system, and to what standard. Include approval and escalation points.
What is recorded, where it is kept and for how long — e.g. Approved invoices are filed in the finance system for seven years
Policies, forms and other procedures this one relies on, one per line. Leave empty if none.
| Version | Date | Author | Summary of changes |
|---|---|---|---|
| =[Version] | =TEXT([Effective Date], "d") | Author | What changed in this version |
Download as a Word document and generate a completed SOP using the WordFields form — title, version, date, author, approver, and all procedural content fill in from a single form without editing the source file.
What's included
Each SOP auto-populates the following fields when used in WordFields:
- Procedure title, SOP number, version, effective date and next review date
- Process owner, approver and owning department
- Purpose, scope and exclusions
- Roles and responsibilities table: process owner, the role that performs the procedure, and the role that checks or approves it
- Definitions, one per line
- Numbered procedure steps, records kept, and related documents
- Revision history row built from the version, effective date and author (pulled from the logged-in user automatically)
When to write a standard operating procedure
Use this SOP template to document any repeatable operational process that must be performed consistently by more than one person, or that must be performed consistently by one person across time. The practical threshold is simple: if variation in how this task is performed could cause an error, a compliance failure, or a quality defect, it needs an SOP. Operations managers documenting procurement workflows, admin teams standardising supplier communication processes, and quality managers building a document library for ISO 9001 compliance are the primary users. For teams working toward or maintaining ISO 9001:2015 certification, every process referenced under Clause 7.5 as documented information requires a controlled document of this type — this template satisfies that requirement directly.
The revision history table is not administrative padding — it is the mechanism that makes an SOP a controlled document rather than a shared file. An SOP without a revision history gives no indication of whether it reflects the current process or an outdated version from two years ago. Every time the procedure changes, updating the revision history creates a dated audit trail that demonstrates the organisation actively manages its documented information. For teams storing SOPs in WordFields, generating a new version of the document through the form — updating the version number, effective date, and revision summary — takes less than two minutes and produces a correctly formatted document ready for distribution and filing. Teams managing multiple SOPs across departments can create a separate WordFields template per process area, with standing fields pre-filled for the department, approver, and review cycle, so new SOPs follow the same structure without any formatting work.
Frequently asked questions
What should a standard operating procedure include?
A standard operating procedure should include a title block with the SOP title, document number, version, effective date, and author; a purpose section explaining why the procedure exists; a scope section defining who the procedure applies to and what it covers; a roles and responsibilities section naming who does what; a step-by-step procedure section with numbered instructions in the order they are performed; a references section listing related documents or policies; and a revision history table recording every version change. All sections must be present for the SOP to function as a controlled document.
What is the correct format for an SOP?
The most widely used SOP format for business and operations teams is the step-by-step format — numbered instructions presented in the order they must be performed, with each step covering one discrete action. For processes with decision points or conditional outcomes, a hierarchical format with sub-steps or a flowchart supplement is more appropriate. For routine tasks that experienced team members perform regularly, a checklist format can serve as a concise reference. Whichever format you choose, always begin with the title block, purpose, and scope before the procedure steps.
What is the difference between an SOP and a policy?
A policy states what must be done — it defines rules, principles, or requirements that govern behaviour within an organisation. An SOP explains how to do it — it provides step-by-step instructions for carrying out a specific task in accordance with those policies. Policies are typically broader and less detailed than SOPs. SOPs must always align with relevant policies, but they operate at the procedural level, not the governance level. When a policy changes, the SOPs that implement it must be reviewed and updated accordingly.
How long should a standard operating procedure be?
An SOP should be exactly as long as the procedure requires — no longer. Simple, routine procedures can often be documented in one to two pages. Complex multi-step processes with multiple roles and decision points may run to five or more pages. The most common mistake is writing SOPs that are too long because they include background information, rationale, or detail that belongs in a separate policy or training document. If someone cannot find the next step they need in under ten seconds of scanning, the SOP is too long or too poorly formatted.
Who should write an SOP?
The person with the most detailed knowledge of how the procedure is actually performed — typically the team lead, operations manager, or subject matter expert for that process area. The draft should then be reviewed by the people who will use it, who will often identify missing steps, ambiguous instructions, or practical constraints the author overlooked. For compliance-sensitive procedures, a senior manager or quality officer should sign off before the SOP is approved and distributed. The author and approver should always be different people.
How often should SOPs be reviewed and updated?
SOPs should be reviewed at least every twelve months as a matter of routine, and immediately whenever the underlying process changes, a regulatory requirement changes, or the SOP fails to prevent an error it was designed to prevent. Every review should be recorded in the revision history table with the date, a summary of what changed, and the name of the reviewer. SOPs that are not periodically reviewed become outdated without anyone noticing, which is one of the most common findings in operational audits and ISO compliance reviews.
What is an SOP number and why does it matter?
An SOP number is a unique identifier assigned to each SOP document within your organisation's document control system. It matters because it allows SOPs to be referenced precisely in other documents, training records, audit reports, and compliance submissions — without relying on the document title, which may change across versions. A common numbering convention is a prefix indicating the department or process area followed by a sequential number, for example OPS-001, OPS-002. Once assigned, an SOP number should never change, even if the document is substantially revised.
Do SOPs need to be approved before use?
Yes. An SOP should be reviewed and formally approved by a person with appropriate authority — typically a department head, quality manager, or operations director — before it is distributed or used. The approval should be recorded in the document itself, either with a signature block on the title page or an entry in the revision history table. Using an unapproved SOP creates a compliance risk because there is no documented evidence that the procedure was reviewed for accuracy, safety, or regulatory alignment before staff were instructed to follow it.
Related operations email templates
Explore more professional document and email templates you can copy, customize, and use immediately
