Most organisations have at least one process that everyone knows and nobody has written down. As long as the experienced colleague is around, nobody notices. When she is on holiday, it shows on day one.
A standard operating procedure closes that gap. It records how a process runs, who owns it and what applies in the special cases. This article covers the structure, how an SOP differs from a work instruction, and how to capture the knowledge that otherwise only lives in people’s heads.
What is a standard operating procedure?
An SOP describes a process that involves several roles. Typical examples are handling a complaint, approving a purchase order or onboarding new hires. It answers four questions: what happens, in which order, who is accountable, and with which documents or systems.
That makes it a management tool rather than a manual. Someone new to the process should know after reading it what is expected of them and whom to turn to.
SOP or work instruction?
The two terms are often used interchangeably. The difference is the level of detail.
- Standard operating procedure: governs a process across roles. Example: from receiving a complaint to issuing a credit note.
- Work instruction: governs a single task at one workstation. Example: how a returned part is inspected.
In practice the SOP references work instructions at the relevant steps. That keeps the SOP short, and the detail sits where it is needed.
Structure: the required fields
A good SOP always follows the same grid. That makes SOPs comparable and easy to review.
Purpose and scope
One or two sentences: what the process is for, which sites, departments or products it covers, and what it explicitly does not cover.
Responsibilities
Who owns the process overall and who owns each step? Use roles rather than names so the SOP survives a change of staff.
Procedure steps
Numbered steps, each with what happens, who does it and what the output is. A simple table or a small flowchart works better than prose.
Exceptions and escalation
What applies when the normal case does not? When is a case escalated, to whom, with what information? This section is the most valuable and the one most often missing.
Related documents
Work instructions, forms, systems. Referenced, not copied, so there is only ever one current version.
Validity and change history
Version, date, the role responsible for maintenance, the next review date and a short change log.
Example: what an expert interview adds
Take the SOP “Handle a customer complaint”. The normal flow is quick to write: log the complaint, inspect the goods, decide, inform the customer, arrange a credit note or replacement.
Ask the clerk who has done this for years about her last difficult case and something else comes out. For one key account, sales is informed before any decision. Parts from a particular batch get a shortened inspection because the defect is known. And above a certain value, the team lead decides, not her.
These are exactly the sentences that belong in the exceptions and escalation section. They are in no form, because the experienced person sees them as routine, not as rules.
The way to surface this knowledge is to ask about concrete incidents rather than the process. How that works in a structured interview is covered in the piece on AI expert interviews for knowledge capture. Which method suits which kind of knowledge is set out in Capture tacit knowledge.
Template: the fields to copy
You can copy this structure straight into your own document:
| Field | Content |
|---|---|
| Title and number | Name of the process, unique ID |
| Purpose | What is the process for? (1 to 2 sentences) |
| Scope | Who and where it applies to, and what it excludes |
| Responsibilities | Role for the overall process, roles per step |
| Procedure | Numbered steps: what, who, output |
| Exceptions and escalation | Special cases, thresholds, contacts |
| Related documents | Work instructions, forms, systems |
| Definitions | Abbreviations and technical terms |
| Validity | Version, date, next review |
| Maintenance | Responsible role, change history |
Keeping SOPs current
An SOP nobody maintains becomes a risk within a year: it looks binding and describes a process that no longer exists. Three things prevent that.
- One owner per SOP. Not the quality department for everything, but the function that runs the process.
- A review date. Visible in the document, with a reminder.
- Fixed triggers. After every process change, after complaints or errors in the process, and when an experienced person leaves the role.
The last trigger is the one most often forgotten. When someone who carried the process for years leaves, that is the moment to ask about the exceptions once more. Afterwards it is too late.
