SOP (Standard Operating Procedure): what it is, a ready-to-use template and how to write one
What a Standard Operating Procedure (SOP) is, a copy-ready SOP template, a filled-in example, how to write an SOP in 7 steps and when the process should stop existing.
TL;DR: An SOP (Standard Operating Procedure) is the document that describes how an activity must be carried out so it always produces the same result. This guide gives you the definition, an SOP template to copy, a filled-in accounts payable example, how to write an SOP in 7 steps, the mistakes that get an SOP ignored, and the question that should come before everything else: should this process exist at all?
The document was written once, by someone who described the process as they remembered it, and it sat in a shared folder while the operation changed next to it.
A good SOP does the opposite. It describes what actually happens, it is short enough to consult during the task, and it says what to do when something falls outside the normal path. That is what this guide teaches you to write.
What is an SOP (standard operating procedure)
An SOP is a document that describes, step by step, how to carry out an activity so it always produces the same result, whoever performs it. For each step it answers five questions: what to do, who does it, where (system, spreadsheet, machine), what result to expect and what to do if it goes wrong.
SOP is the English acronym. In Brazil the same document is called POP (Procedimento Operacional Padrão), and you will see that term in documents from companies with operations there. The content and the function are identical.
SOP, flowchart, work instruction and manual
The four documents get mixed up because they live side by side. The difference is the level of detail:
| Document | What it shows | Level |
|---|---|---|
| Process manual | The set of processes of an area and how they connect | Whole area |
| Flowchart | The sequence and the decisions, as a drawing | One process |
| SOP | The full procedure: steps, roles, exceptions, records | One process or activity |
| Work instruction | How to carry out a single task, almost always screen by screen | One task |
In practice, the flowchart lives inside the SOP (as an attachment or figure) and the work instruction is referenced in the step where it applies.
What an SOP is for
- Consistency: the same activity comes out the same on Monday and on Friday, with the experienced person and with the new hire.
- Onboarding: the newcomer learns from the document, not only by shadowing someone for weeks.
- Audit and compliance: the SOP says what should have happened; the records prove it did.
- Continuity: when the person who "knows how to do it" goes on vacation or leaves the company, the knowledge stays.
- A base for improvement: you cannot optimize or automate a process that nobody can describe.
SOP template to copy
Use the structure below as a starting point. The fields are the same for any area; what changes is the content.
SOP-[AREA]-[NUMBER] | [Activity name]
Version: [1.0] Date: [dd/mm/yyyy] Next review: [dd/mm/yyyy]
Prepared by: [name] Approved by: [process owner]
1. PURPOSE
Why this activity exists, in one sentence.
2. SCOPE
Where it starts, where it ends and which cases it covers (and which it does not).
3. ROLES
Who performs it, who approves it, who is called in case of an exception.
4. DEFINITIONS
Acronyms and terms a newcomer does not know.
5. SYSTEMS AND MATERIALS
Systems, spreadsheets, access rights and documents required.
6. PREREQUISITES
What must be ready before the first step.
7. STEP BY STEP
| No. | What to do (imperative verb) | Who | Where | Expected result |
8. EXCEPTIONS
| Situation | What to do | Who to call |
9. RECORDS
What proves the activity was done, and where it is stored.
10. INDICATORS
How to know the activity is working (lead time, errors, rework).
11. REVISION HISTORY
| Version | Date | What changed | Approved by |
Three writing rules apply to the whole template: one step per line, an imperative verb at the start ("Check", "Post", "Send") and no step that depends on "good judgment" without saying what the criterion is.
Filled-in SOP example: supplier invoice posting
An illustrative, condensed example from an accounts payable area with three systems:
SOP-FIN-004 | Supplier invoice posting
- Purpose: post the supplier invoice in the ERP with the correct purchase order, amount and cost center, so payment goes out on time.
- Scope: starts when the invoice is received; ends with the invoice approved and released for payment. Does not apply to expense reimbursement (SOP-FIN-007).
- Roles: the accounts payable analyst performs it; the manager of the requesting area approves; the finance coordinator is called in exceptions.
| No. | What to do | Who | Where | Expected result |
|---|---|---|---|---|
| 1 | Download the invoice received in the invoice mailbox | Analyst | Invoice email | PDF and XML saved in the month folder |
| 2 | Check whether a purchase order exists with the same supplier and amount | Analyst | ERP | Order found, same amount |
| 3 | Post the invoice linked to the order | Analyst | ERP | Invoice posted with the order's cost center |
| 4 | Send it for approval to the requesting manager | Analyst | ERP | Pending approval recorded |
| 5 | Release it to the payment batch of the due date | Analyst | ERP | Invoice in the right batch |
| Exception | What to do | Who to call |
|---|---|---|
| Invoice arrived through another channel (WhatsApp, by hand) | Ask the supplier to resend it to the invoice mailbox | Responsible buyer |
| No purchase order exists | Do not post; return it to the requester to open the order | Requesting manager |
| Amount differs from the order | Do not post; record the divergence and consult the buyer | Responsible buyer |
| Manager absent for more than 1 business day | Forward to the registered substitute | Finance coordinator |
Notice that half of the document's value is in the exceptions table. That is where the newcomer makes mistakes and where a generic SOP copied from the internet does not help.
Writing an SOP like this for one process is feasible. For dozens of them, observing who does the work and surfacing every exception by hand becomes the bottleneck. Fhinck's Operational Mapping starts from the digital activity recorded in your systems, uses an AI interview with the people who do the work to capture the exceptions, and generates the manual (SOP) from the real operation.
How to write an SOP in 7 steps
- Pick an activity with a clear start and end. "Accounts payable" is too big; "supplier invoice posting, from receipt to release for payment" fits in one SOP. Start with the activity that generates the most errors, rework or newcomer questions.
- Observe the people who do the work, not the people who manage it. Follow the real execution of two or three different people, noting every screen, spreadsheet and check. The manager describes the designed process; the person doing the work shows you the process that exists.
- Write the steps in their real order. One step per line, imperative verb, with who does it, where and the expected result. If two people do it differently, record both versions and decide which becomes the standard.
- Record the exceptions. Ask: when do you leave the normal path? What do you check before moving on? When do you call someone? Each answer becomes a row in the exceptions table.
- Validate with the people who do the work. Ask someone who did not write the SOP to carry out the activity following only the document. Wherever they get stuck, the SOP is incomplete.
- Get approval from the process owner. The owner signs because they answer for the result. Without approval, the SOP is a suggestion.
- Set when to review it. Put the next review date in the header and a trigger: whenever a system, a rule or a person responsible changes, the SOP is reviewed.
Common mistakes that get an SOP ignored
- Writing from memory. The SOP describes what the author remembers, not what happens. The result is a document the people doing the work do not recognize.
- Being generic. A template downloaded from the internet, with steps like "check the document", does not say which check to make. Without a criterion, everyone does it their own way.
- Forgetting the exceptions. Almost everyone knows the happy path. The SOP exists for the case that leaves it.
- Being too long to consult. If the document cannot be read during the task, nobody consults it. Screen-level detail belongs in the work instruction.
- Never reviewing it. An SOP with no review date ages in silence.
- Documenting what should not exist. This is the most expensive mistake, and it deserves its own section.
Before the SOP: should this process exist?
Documenting a bad process well only makes the bad process last longer. Before writing, classify the activity into one of five decisions:
| Decision | When it makes sense | What happens to the SOP |
|---|---|---|
| Eliminate | The activity exists out of habit or to fix an error that starts upstream | It is not written; you fix the source |
| Standardize | Everyone does it their own way and the result varies | The SOP is the main tool |
| Optimize | The process is necessary, but has waiting, rework or too many steps | The SOP is rewritten after the redesign |
| Automate | The steps are repetitive, with a clear rule and structured data | The SOP becomes the specification for the automation |
| Agentify | There is repeatable judgment, with described exceptions and available data | The SOP becomes the instruction and the limit of the AI agent |
In the accounts payable example, the classification changes the document: the retroactive purchase order should be eliminated (requiring the order before the purchase), invoice intake standardized into a single channel, reading the invoice fields automated and approval optimized with a defined substitute.
How to write an SOP from the real operation
The most expensive step of the method above is the second one: observing real execution. Done by hand, it covers one or two activities. For dozens of processes across several areas, observation becomes the bottleneck and the SOP goes back to being written from memory.
This is the point Operational Mapping from Fhinck, an Operational Intelligence Platform, addresses. It starts from the digital activity recorded in your systems, with a defined purpose, rebuilds the real sequence with its variations, uses an AI interview with the people who do the work to capture the exceptions and generates the manual (SOP). Then the AI recommends, process by process, whether it should be eliminated, standardized, optimized, automated or agentified. The decision and the execution stay with your company.
The full step-by-step of that method, with the accounts payable example mapped, is in Process mapping with AI: the operations manual written from the real operation. To compare the ways of mapping before you choose, see Process mapping tools: the 6 categories and how to choose.
Frequently asked questions
What is an SOP?
SOP stands for Standard Operating Procedure: a document that describes, step by step, how an activity must be carried out so it always produces the same result, no matter who performs it. It says what to do, who does it, in which system, what result to expect and what to do when something falls outside the normal path.
What is the difference between SOP and POP?
None in content. SOP is the English acronym (Standard Operating Procedure) and POP (Procedimento Operacional Padrão) is the Portuguese equivalent used in Brazil. You will see POP in documents from companies with operations in Brazil. The document has the same function.
What should an SOP template include?
Identification (title, code, version, date), purpose, scope, roles, definitions, systems and materials, prerequisites, the step-by-step with who does it and the expected result of each step, exceptions and what to do in each one, records that prove execution, indicators and a revision history with approval.
How do you write an SOP step by step?
Pick an activity with a clear start and end, observe who really performs it (ideally more than one person), write the steps in their real order using imperative verbs, record the exceptions, validate with the people who do the work, get approval from the process owner and set when the document will be reviewed.
What is the difference between an SOP, a flowchart and a work instruction?
A flowchart shows the sequence and the decisions as a drawing. An SOP describes the full procedure, with roles, exceptions and records. A work instruction details a single task inside the SOP, almost always at the level of a screen or a machine.
When should a process not become an SOP?
When it should not exist at all. Before documenting, ask whether the activity can be eliminated, standardized with another, optimized, automated or handed to an AI agent. Carefully documenting a bad process only makes the bad process last longer.