How do I start writing an SOP?

Pick one task with a clear trigger and a clear end point, then name three roles: the owner who keeps the SOP correct, the person who performs the steps, and the person who must approve the action, if anyone does. Write those into the header before you write a single step.

What are the 5 components of an SOP?

There is no standard five. The template on this page has four parts: a header, the steps, a check on the output, and a log of exceptions and revisions.

What are examples of SOPs?

Any task one role repeats and someone else must be able to repeat the same way: restoring a locked employee account, resetting a password, deciding whether a refund request is approved. This page fills in one real example from the public record, Delivery Hero's account-lockout recovery, and shows that the public case study documents part of a header and an outline of the steps, not the detailed steps or the exceptions.

Can I use ChatGPT to write my SOP?

For the format, yes. A tool cannot know the steps, the checks or the exceptions of a task it has not watched, so the person who does the task writes every step (step 4) and a colleague who has not done it tests the draft (step 8). TIN has not tested any tool's accuracy at writing SOPs, so this answer is reasoning, not a finding.

What is an SOP in business?

A standard operating procedure is a written set of steps that tells one role how to do one task the same way every time. It sits under a policy, which states the rule, and inside a process, which a process map shows end to end.

What does SOP stand for in business?

Standard operating procedure. Outside business, SOP also means statement of purpose, the essay in a university application; this page is not about that.

What is an SOP document?

It is the written procedure itself: a header that names the task, its trigger, end point, owner, approver and review date, followed by numbered steps, each with the check that shows it is done. The free template on this page is one you can copy.

What format should an SOP use?

Penn State Extension's guide decides by two questions: how many decisions the user makes and how many steps the procedure has. Few decisions and few steps take simple steps; more than ten steps with few decisions take hierarchical steps or a graphic format; many decisions take a flowchart.

How to write an SOP (standard operating procedure), with a free template, The Internet Ninja

The short answer

A standard operating procedure (SOP) is a written set of steps that tells one role how to do one task the same way every time. To write one, pick a single task with a clear trigger and end. Name who does it and who approves it. Write each step as an action starting with a verb, and give every check and every exception its own step. Say who reviews the output and how often. Test it with someone who has not done the task, then date it for review. The free template below is four tables you can copy. It is built from a real procedure that was followed exactly and was wrong.

What an SOP is, and what it is not

An SOP covers one task, done by one role, from the event that starts it to the result that ends it. The PLOS Computational Biology paper “Ten simple rules on how to write a standard operating procedure” calls SOPs “vital instruments for maintaining consistent quality” source.

Three documents sit next to it and get confused with it:

Document	What it says	How it relates to an SOP
Policy	The rule: what must or must not happen	The SOP is how one task obeys the rule
Process map	The whole flow across roles, with every handoff	The SOP is the instruction behind one step of the map
Checklist	A short list of items to tick	A format an SOP can take, for a task the reader already knows

One more confusion: “SOP” also means a statement of purpose, the essay in a university application. This page is about operating procedures only.

When you need one

The PLOS paper’s first rule is “Knowing when to write an SOP”, and its answer is that “SOPs are always needed when critical processes or workflows need to be repeated in a reproducible way or when defined procedures are obliged by compliance guidelines” source. In practice that means three situations:

More than one person does the task, and the result must not depend on who did it.
The task runs rarely enough that whoever does it next will have forgotten the details.
The task is about to be handed to someone new, or to a piece of automation.

The third is the one most guides skip. A written procedure is the closest thing a team has to a specification of the work. When the work is automated, a step that lived only in someone’s head (“check the claimant is eligible”) does not carry over, because a system runs only the steps it is given. That is TIN’s inference from the VA case below, not a measured finding.

How to write an SOP in eight steps

Each step below fills one or more fields in the template that follows. Do them in order; the first two decide whether the SOP is usable at all.

1. Pick one task with a trigger and an end point

Choose a single task, not a department’s work. Write down the event that starts it and the result that ends it. “Handle IT access” is not a task. “Restore a locked employee account” is: it starts when an employee is locked out and ends when they are back in. Fills: Title, Trigger, End point.

2. Name the owner, the performer and the approver

Three different roles, often confused. The owner keeps the SOP correct. The performer does the steps. The approver authorizes the action, where one is needed. The approver line can be the line that decides how the task performs. In Delivery Hero’s account-lockout recovery, “The fix moved approval to the person who actually knows the employee: their manager” source. Fills: Owner, Performed by, Approved by.

3. Write the purpose and the scope, including what is out of scope

One or two sentences on why the task exists and what a good result looks like. Then the scope: which cases, people and systems it covers, and which it does not. The out-of-scope line saves the most arguments later, because it tells the performer when this SOP is the wrong one. Fills: Purpose, Scope.

4. Walk the task with the person who does it

Sit with the performer and write what they actually do, not what the policy says they do. Write each step as a verb plus an object, one action per step: “Open the request”, “Confirm the employee’s identity”, “Reset the password”. Penn State Extension’s guide puts the reason plainly: “Human nature dictates that people support what they help create” source. Fills: Table 2, the Action and Role columns.

5. Write every check as its own step

For each step, write what “done” looks like, in terms someone else can check. If a step includes a check (“confirm eligibility”), give the check its own row. A person following a procedure may do an unwritten check out of habit. A system will not. The VA’s inspector general traced errors in automated survivors’ benefit decisions to “flaws in automation rules and processes” source. That case is the subject of “What happens when an SOP is followed exactly and is wrong” below. Fills: Table 2, Done when.

6. Write the exceptions

For every check, write what happens when it fails: “if this, then that”, and who to escalate to. An exception with no written path gets handled differently by each person who meets it, which is the inconsistency an SOP exists to remove. Fills: Table 2, If not, then.

7. Say who reviews the output, how often and how many cases

Name who looks at finished work, on what schedule, and how many cases. Make that review no weaker for work that is automated or delegated than for work done by your own staff. The VA’s inspector general found that “the quality review process for automated claims was less rigorous than for traditional claims” source. Fills: Table 3.

8. Test it, approve it, date it and set the next review

Give the draft to someone who has not done the task and watch them use it. The PLOS paper’s rule 7 says “the test person should be able to run the experiment without any support”, and tells the author: “Do not interfere while testing to receive authentic feedback” source. Fix what they stumble on. Then send it to the approver: rule 8 says to “Repeat the procedure until the SOP is agreed by all stakeholders” source. Finally, give it an effective date and a review date; rule 9 asks for a periodic review date source. Fills: Version, Effective date and next review date.

SOP format: simple steps, hierarchical steps, flowchart or checklist

Penn State Extension’s guide decides the format with two questions: “how many decisions will the user need to make during the procedure?” and “how many steps and substeps are in the procedure?” source. Its rule: short routine procedures with few decisions take simple steps; “Long procedures consisting of more than ten steps, with few decisions, should be written in a hierarchical step format or in a graphic format”; and “Procedures that require many decisions should be written in the form of a flowchart” source.

Format	Use it when	Example task
Simple steps	Few decisions, few steps	Reset a password
Hierarchical steps	Few decisions, more than ten steps; main steps for experienced users, substeps for beginners	Set up a new employee’s accounts
Flowchart	Many decisions, whatever the length	Decide whether a refund request is approved, escalated or refused
Checklist	A short task done by someone who already knows it, where the risk is skipping an item	Close the office at night

The checklist row is TIN’s addition; Penn State’s rule covers the first three. The template below is a table, which works for simple and hierarchical steps. For a flowchart, keep the table as the written record and draw the diagram from it.

Free SOP template

Free, no email, no account. Copy the four tables below into a document or a spreadsheet and fill them in.

Table 1: the SOP header

Field	What to write
Title	Verb plus object, for example “Restore a locked employee account”
SOP number and version	So a reader knows which copy is current
Purpose	One or two sentences: why this task exists and what a good result is
Scope	Who and what it covers, and what it does not cover
Trigger	The event that starts the task
End point	The result that ends it, and who receives it
Owner	One role, accountable for keeping this SOP correct
Performed by	The role that does the steps
Approved by	The role that must authorize the action, if any
Systems and tools	What the performer needs access to
Frequency and volume	How often it runs, and where that count came from
Time per run	How long it takes, measured, or “not measured”
Effective date and next review date	When it took effect, and when it must be checked again

Table 2: the steps

#	Action (verb first)	Role	System or record	Done when (the check)	If not, then	Record the step leaves
1
2
3

The “Done when” column exists because the VA’s automated pipeline paid benefits without checking for the evidence the work required (see the VA case below). The “If not, then” column exists because a check with no failure path only tells you something went wrong, not what to do about it.

Table 3: checking the output

Field	What to write
Who reviews completed work	A role, not “the team”
How often, and how many cases	For example a sample each week; write the number you will actually review
Same standard for automated or delegated runs	Yes or no. If no, say why
If the result looks wrong, escalate to	A named role, and how a person affected can dispute it

This table is TIN’s addition to the usual SOP. It comes from the VA case, where the review of automated claims was the weaker one. The escalation row is there because a record can be wrong: in the Post Office Horizon prosecutions, the Court of Appeal found that defendants were convicted “on the basis that the Horizon data must be correct, and cash must therefore be missing, when in fact there could be no confidence as to that foundation” source.

Table 4: exceptions and revisions

Date	What deviated from the SOP	Why	Outcome	Resolution, and SOP change if any	Approved by	New version

The columns follow the PLOS paper, which recommends an exception log recording “any deviation, the reason for the deviation, the outcome, any troubleshooting which has been applied, and resolutions and appropriate communication” source. The last two columns tie each deviation to the revision it caused, so the log feeds the next version instead of sitting in a drawer.

How to fill it in

If a sentence in Table 2 has “and” in it, it is probably two rows.
Write “not measured” or “not stated” rather than a guess. A guessed time per run gets copied into plans and budgets.
Name roles, not people, so the SOP survives a change of staff.

SOP example: what the public record holds for one real procedure

Good SOP examples are hard to find in public, because companies rarely publish their procedures. Here is one real procedure, Delivery Hero’s account-lockout recovery, filled into Table 1 from the only public source, n8n’s case study, as recorded in TIN’s case file source.

Field	Delivery Hero, account-lockout recovery
Title	Not stated (the task is account recovery for a locked-out employee)
SOP number and version	Not stated
Purpose	Not stated
Scope	Not stated
Trigger	An employee is locked out and requests account recovery
End point	The account is recovered
Owner	Not stated
Performed by	Automated API calls “to Okta, Jira and Google systems to trigger the actual account recovery as soon as the manager authorized it” source
Approved by	The employee’s manager
Systems and tools	Okta, Jira and Google
Frequency and volume	”around 800 such requests per month” source
Time per run	Before: “on average it took 35 minutes to complete the recovery process”; after: “the average time locked out dropped from 35 to 20 mins” source
Effective date and next review date	Not stated

Two things stand out. First, the line that changed was the approver. TIN’s case file describes the earlier setup in one sentence: “The bottleneck was IT sitting in the middle of every recovery” source. Moving the approval to the manager is a change to one field of the header, and the outcome the source reports followed it: “employees were locked out for a total of 200 hours per month less” source. Note also that the source words the two times differently, time to complete the recovery before and time locked out after, so the table quotes both as written.

Second, most of the header is blank. The public record holds a trigger, an approver, the systems, the figures quoted here and an outline of the steps source. The detailed steps and the exceptions are not published anywhere TIN could find. A case study is not an SOP, and when you read one, the blank rows are where to ask questions.

The scope of this example, as TIN’s case file records it: every figure comes from n8n’s own case study, which is vendor-published, with Delivery Hero’s IT director named and quoted, and no independent outlet reports these numbers source. The case file’s metrics table gives the before request volume and the before total hours as “not stated”. This page uses the case for its structure, not to recommend any tool.

What happens when an SOP is followed exactly and is wrong

Most advice on SOPs assumes the danger is people not following them. The VA case shows the other danger: a procedure followed to the letter, every time, with a step missing.

The Veterans Benefits Administration runs an automated pipeline for survivors’ death-benefit claims. FedWeek describes it as a system that “extracts data from scanned documents and applies predefined rules to generate decisions”, for a benefit the VA has processed this way since 2020 source. Some claims were, in the inspector general’s words, “completely processed from beginning to end by automation” source. In TIN’s reading, not the OIG’s, a set of predefined rules applied without variation is an SOP that a machine follows exactly.

The VA Office of Inspector General reviewed decisions issued over the 12 months from September 2023 through August 2024, in report 25-00153-47, published April 30, 2026 source. What it found, in its own words:

Finding	Source wording
Errors in decisions and letters	”At least 8,000 decisions or letters omitted favorable findings and had issues such as incomplete evidence summaries and incorrect formatting” source
Legal errors and money	”At least 2 percent of decisions had legal errors, resulting in an estimated $2.7 million in improper payments”, recorded as questioned costs of $2,727,764 source
The review of the output	”the quality review process for automated claims was less rigorous than for traditional claims” source
Whether it continued	”a review of additional cases through November 2025 confirmed similar errors” source
The cause	”Deficiencies stemmed from flaws in automation rules and processes that, if not addressed, will recur because the system applies predefined rules without human involvement” source

The missing step is the one from step 5 of this guide. WFAE reported one instance: “the system automatically paid out more than $22,000 to a family after attributing a veteran’s death to a service-connected condition without checking for any required” medical evidence source.

Read as an SOP, the case fails in two places this template has fields for. A check that the work required was not written as a step the system ran (Table 2, “Done when”). And the review of finished work was weaker for automated output than for work done by people (Table 3, “Same standard for automated or delegated runs”). TIN’s case file suggests two controls: “a quality-review process for automated output at least as rigorous as for human-handled claims, and an eligibility check the automation cannot skip” source.

Three limits on the case. The system is rule-based, “not specifically characterized as artificial intelligence” source. Press coverage reported a “98 percent” error rate and a round 8,100 reviewed against 8,000 in error; TIN’s case file notes those come from the press and from an attorney, so this page uses the OIG’s own “At least 8,000” wording source. And it is one public-sector process, not a sample.

A person in the loop helps and does not cure a bad procedure. In Michigan’s MiDAS unemployment-fraud system, “85 percent of these original fraud findings were reversed” for the cases resolved by computer program alone, against “44 percent of these fraud findings were reversed” for the cases referred to an investigator, according to the State of Michigan’s review source. TIN’s process and operations topic lists the case files on what gets automated and what happened next.

Keeping an SOP alive: review, deviations and versions

An SOP starts going out of date the day it is approved, because the work keeps changing and the document does not. Four habits keep it current.

One owner. The owner in Table 1 is the person who answers when the SOP is wrong. The PLOS paper’s rule 6 adds that “Changes to SOPs should preferably be made by the creator” and that each change needs review, approval and “an increase of the revision number” source.

A review date that is kept. Rule 9 says “Do not forget to review and update an SOP regularly”, and that changes go into a revision form with the “version number, change data, reason and description for change, reviewers’ data, and signatures” source. Put the next review date in the header and in the owner’s calendar.

The exception log feeds the next version. Every deviation in Table 4 is either a one-off or a sign the SOP is wrong. When the same deviation appears twice, change the SOP rather than logging it a third time.

Retire what no longer matches the work. Rule 8 says that an SOP made out of date by new technology or a change in the organization “should be terminated, labelled (out of date), and archived for traceability”, and that valid versions should sit “in a folder at a central location” source. Two live copies of one SOP is worse than none, because people follow whichever one they find first.

What this guide cannot tell you

The failure case is one process. The VA’s automated survivors’ benefit decisions are one public-sector, rule-based process, chosen because its failure is documented in public. It says nothing about how often SOPs fail in general.
The example rests on one vendor-published source. Every Delivery Hero figure comes from n8n’s case study, with no independent report of the numbers.
The evidence is four TIN case files read as procedures, not a study of SOPs. Whether SOPs reduce errors, how long they take to write and how often they are followed are outside what this page can show.
The extra template parts are TIN’s design. The check on the output and the “Done when” and “If not, then” columns are drawn from the VA case; they are not from a standard. The exception log follows the PLOS paper.

How this guide was made

Written by TIN on 2026-10-16. The method sources are the PLOS Computational Biology paper “Ten simple rules on how to write a standard operating procedure” and Penn State Extension’s “Standard Operating Procedures: A Writing Guide”, both read on that date. The examples come from TIN’s case files and the primary sources each one links: n8n’s Delivery Hero case study, VA OIG report 25-00153-47 with FedWeek’s and WFAE’s reporting on it, the State of Michigan’s review of MiDAS cases, and the Court of Appeal in Hamilton v Post Office. Every figure on the page is quoted as its source states it.

Sources

Hollmann S, Frohme M, Endrullat C, Kremer A, D’Elia D, Regierer B, Nechyporenko A, on behalf of COST Action CA15110, “Ten simple rules on how to write a standard operating procedure,” PLOS Computational Biology 16(9): e1008095, September 3, 2020. https://pmc.ncbi.nlm.nih.gov/articles/PMC7470745/
Penn State Extension, “Standard Operating Procedures: A Writing Guide.” https://extension.psu.edu/standard-operating-procedures-a-writing-guide
n8n, Delivery Hero case study (vendor-published). https://n8n.io/case-studies/delivery-hero/
TIN case file, Delivery Hero account-lockout recovery. https://theinternetninja.com/stories/delivery-hero-n8n-it-ops-automation/
VA Office of Inspector General, “Review of Automated Decisions for Veterans’ Service-Connected Death Claims,” report 25-00153-47, April 30, 2026. https://www.vaoig.gov/reports/review/review-automated-decisions-veterans-service-connected-death-claims
FedWeek, “Audit: Automated Benefits Decisions at VA Rife With Errors, Overpayments,” May 12, 2026. https://www.fedweek.com/federal-managers-daily-report/audit-automated-benefits-decisions-at-va-rife-with-errors-overpayments/
WFAE, reporting on the VA OIG audit, June 19, 2026. https://www.wfae.org/2026-06-19/audit-finds-va-automation-glitch-ruined-98-of-veteran-survivors-benefits-claims
TIN case file, VA automated survivors’ death-benefit decisions. https://theinternetninja.com/stories/va-oig-automated-survivors-death-benefit-decisions-8000-errors-2-7m-improper-payments-2026/
TIN case file, Michigan MiDAS, quoting the State of Michigan Unemployment Insurance Agency’s completed review. https://theinternetninja.com/stories/michigan-midas-unemployment-fraud-algorithm-40195-cases-93pct-error-20m-settlement-2024/
TIN case file, UK Post Office Horizon, quoting the Court of Appeal in Hamilton and Others v Post Office Limited [2021] EWCA Crim 577. https://theinternetninja.com/stories/uk-post-office-horizon-it-scandal-court-of-appeal-quashes-39-convictions-2021/
TIN, process and operations topic. https://theinternetninja.com/guides/process-and-operations/

How to write an SOP (standard operating procedure), with a free template