Work

SOP Template (Standard Operating Procedure)

An SOP is only useful if a person who has never done the task can follow it and get the same result. This template puts the trigger, the checks and the escalation path next to the steps, and gives every procedure an owner and a review date so it does not quietly go stale.

Updated 2026-10-27

Copy and adapt

The template

Standard operating procedureTemplate

SOP: [Procedure name]

SOP ID: [DEPT-000] Version: [1.0] Effective: {{date}} Owner: [name, role] Approved by: [name, role] Next review: [YYYY-MM-DD] Related: [[Team, site or system name]]

Purpose

[One or two sentences: what this procedure produces and the failure it prevents.]

Scope

Applies to: [who, which site, which system]
Does not cover: [neighboring tasks that have their own SOP]
Trigger: [when this procedure starts: a time, an event, a request]

Roles

Performs: [role]
Checks: [role, if a second person verifies]
Escalate to: [role, and how to reach them out of hours]

Before you start

[Access, tools, forms, materials]
[Safety gear or preconditions that must be true]

Procedure

[Action verb first. One action per step.]
[Step]. Check: [what correct looks like]
[Step]. If [condition], then [what to do instead]

Done when

[An end state someone else could verify without asking you]

Exceptions and escalation

[Situation the steps do not cover]: [who decides, and how fast]

Records

[What gets logged, where, and how long it is kept]

References

[Policy, form, or related SOP]

Revision history

Version	Date	Author	Change
1.0	{{date}}	[name]	First issue

5 examples

Examples for different situations

The same structure, filled in for the situations people actually bring to it. Copy the one closest to yours.

1.Restaurant closing procedure

When it fits: Use this when several people close on different nights, the last one out is often the newest, and a missed step costs food, cash or a break-in.

Restaurant closing procedureExample 1

SOP: Closing, front and back of house

SOP ID: HSK-OPS-04 Version: 2.3 Effective: 2026-10-20 Owner: Gemma Ruiz, general manager Approved by: Paul Okafor, owner Next review: 2027-01-20 Related: [[Harbor Street Kitchen]]

Purpose

Leave the restaurant food-safe, cash-reconciled and locked so the opening shift starts without surprises.

Scope

Applies to: the closing manager and the last line cook, every service night.
Does not cover: deep cleaning (HSK-OPS-07) and delivery receiving (HSK-OPS-02).
Trigger: last table seated, or 22:30, whichever is later.

Roles

Performs: closing manager (front), last line cook (kitchen)
Checks: closing manager signs the kitchen sheet before leaving
Escalate to: Gemma, by phone, for cash variance or equipment failure

Before you start

Closing sheet on the clipboard by the pass, probe thermometer, cash bag and safe key.

Procedure

Kitchen: label and date every open container, move to the walk-in. Check: nothing left on the line.
Kitchen: record walk-in and reach-in temperatures. If either reads above 41°F, then move high-risk items to the other unit and call Gemma before leaving.
Kitchen: filter fryer oil, turn off gas at the wall valve, empty and clean the grease trap tray.
Front: run the end-of-day report on the POS, count the drawer against it. If the variance is over $5, then recount with a second person and note both names.
Front: drop cash into the safe, keep a $200 float in the drawer.
Both: walk the back door together. Check: door closed, bar down, alarm panel shows "back door secure".
Set the alarm at the front panel, lock the front door, text "closed" with the variance figure to the managers' group.

Done when

Closing sheet is signed by both people and the "closed" text has been sent.

Exceptions and escalation

Walk-in alarm or gas smell: do not leave. Call Gemma, then the gas utility line on the sheet.

Records

Closing sheets go in the binder in the office, kept 12 months for inspections.

Revision history

Version	Date	Author	Change
2.3	2026-10-20	Gemma Ruiz	Added step 6 after the back door was found propped open on 10-12
2.2	2026-06-02	Gemma Ruiz	Variance threshold lowered from $20 to $5

2.Biweekly payroll run

When it fits: Use this when a finance process runs on a fixed calendar, depends on other people hitting a cutoff, and one late correction can mean someone is paid wrong.

Biweekly payroll runExample 2

SOP: Biweekly payroll run

SOP ID: FIN-PAY-01 Version: 4.0 Effective: 2026-11-02 Owner: Hollis Grant, payroll lead Approved by: Ifeoma Bello, controller Next review: 2027-05-01 Related: [[Payroll calendar 2026]]

Purpose

Pay 142 employees correctly and on time every second Friday, with an approved record of every change.

Scope

Applies to: salaried and hourly staff on the US payroll.
Does not cover: contractor invoices (FIN-AP-03) and year-end W-2s (FIN-PAY-06).
Trigger: Monday of pay week.

Roles

Performs: payroll lead
Checks: controller approves the register before submission
Escalate to: controller, then CFO if the controller is out

Before you start

Admin access to the payroll system, the HR change log, timesheet export from the scheduling tool.

Procedure

Monday 09:00: post the cutoff reminder. Timesheets and HR changes close Tuesday 12:00.
Tuesday 12:00: export approved timesheets. If a department has unapproved hours, then message its head; unapproved hours roll to the next run, they are not estimated.
Apply HR changes from the log: new hires, terminations, rate changes, bonuses. Each change needs a signed form attached.
Run the preview register. Check: gross pay within 3% of the previous run. If not, then list every employee whose pay moved more than 10% and explain each one in the approval note.
Send register and approval note to the controller by Wednesday 15:00.
After approval, submit by Thursday 15:00 so direct deposits land Friday.

Done when

Payroll submitted, confirmation number saved, approval email filed.

Exceptions and escalation

Missed pay or wrong amount reported after submission: off-cycle correction within two business days, approved by the controller. Never adjust the next regular run silently.

Records

Revision history

Version	Date	Author	Change
4.0	2026-11-02	Hollis Grant	Cutoff moved from Wednesday to Tuesday after two late submissions in September

3.Laboratory sample intake

When it fits: Use this when the procedure is audited, chain of custody matters as much as the work itself, and the person at the receiving bench must know when to say no.

Laboratory sample intakeExample 3

SOP: Water sample receipt and login

SOP ID: LAB-QA-112 Version: 6.1 Effective: 2026-11-09 Owner: Rosalind Achebe, QA manager Approved by: Dr. Neil Ferreira, lab director Next review: 2027-11-09 Related: [[Sample receiving bench]]

Purpose

Accept only samples whose results will be defensible, and record each one so it can be traced from cooler to report.

Scope

Applies to: drinking water and wastewater samples delivered by courier or client.
Does not cover: soil and air samples (LAB-QA-114).
Trigger: a cooler arrives at receiving.

Roles

Performs: sample custodian on shift
Checks: second custodian initials any rejected or flagged sample
Escalate to: QA manager for any client dispute

Before you start

Calibrated IR thermometer (check the sticker date), chain-of-custody (COC) forms, LIMS login, label printer.

Procedure

Read the cooler temperature blank. If it is above 6°C and the sample was collected more than 4 hours ago, then flag it as "received out of temperature".
Compare every bottle label with the COC: client sample ID, collection date and time, analysis requested. Check: counts match.
Check preservation: pH strip on one bottle per preserved set. Record the result.
Check hold time. If a sample cannot be analyzed within its hold time (48 hours for nitrate, for example), then reject it and call the client the same day.
Sign and time the COC as received. Log each sample in LIMS; it assigns IDs in the format 2611-0418-01.
Print and apply LIMS labels below the client label, never over it.
Move samples to the 4°C receiving fridge, shelf by analysis.

Done when

Every bottle has a LIMS label, the COC is signed and scanned, and flags are visible in LIMS.

Exceptions and escalation

Broken bottle or leaking cooler: photograph before touching anything, quarantine the cooler, tell QA.

Records

Scanned COC attached to the LIMS work order. Paper COC filed by month, kept 5 years.

Revision history

Version	Date	Author	Change
6.1	2026-11-09	Rosalind Achebe	Added photo requirement for damaged coolers after an October client dispute

4.Production software deploy

When it fits: Use this when engineers take turns shipping a service, most deploys are routine, and the one that is not needs a clear rollback trigger instead of a debate.

Production software deployExample 4

SOP: Deploying billing-api to production

SOP ID: ENG-REL-03 Version: 3.2 Effective: 2026-10-26 Owner: Arjun Mehta, platform lead Approved by: Carla Jensen, engineering manager Next review: 2027-01-26 Related: [[billing-api]]

Purpose

Ship a tested build of billing-api with a rollback path that anyone on the rota can run without asking.

Scope

Applies to: any change to billing-api, including config.
Does not cover: database schema migrations (ENG-REL-04 runs them first, separately).
Trigger: a release tag pushed from main.

Roles

Performs: engineer who tagged the release
Checks: on-call engineer watches the canary dashboard with them
Escalate to: platform lead, then the on-call manager

Before you start

CI is green on the tag. No deploys after 15:00 Friday or during the Nov 26 to 30 freeze.
Post the tag and changelog link in the deploys channel.

Procedure

Run the deploy job with the tag. It deploys to the canary pool (10 percent of traffic).
Watch the canary for 15 minutes. Check: error rate under 1 percent and p95 latency under 800 ms.
If either threshold is crossed, then run the rollback job immediately. Do not investigate first.
Promote to 100 percent. Watch for another 15 minutes.
Confirm the version endpoint returns the new tag on all regions.
Post "deployed" with the tag in the deploys channel.

Done when

All regions report the new tag and the canary dashboard has been green for 15 minutes at full traffic.

Exceptions and escalation

Rollback fails: page the platform lead. Do not deploy a fix forward without a second engineer.

Records

Deploy job log and channel post. Rollbacks also get a line in the incident log.

Revision history

Version	Date	Author	Change
3.2	2026-10-26	Arjun Mehta	Rollback before investigating, after a 40-minute debate during the Oct 14 canary

5.Customer refund requests

When it fits: Use this when frontline staff need to decide quickly, the money limits differ by role, and inconsistent answers are already showing up in reviews.

Customer refund requestsExample 5

SOP: Handling refund requests

SOP ID: CS-BILL-02 Version: 1.4 Effective: 2026-11-16 Owner: Teodora Vasquez, support operations Approved by: Malik Henderson, head of finance Next review: 2027-02-16 Related: [[Support playbook]]

Purpose

Give every customer the same answer for the same situation, and keep refunds inside approved limits.

Scope

Applies to: refund requests by email, chat or phone for orders and subscriptions.
Does not cover: chargebacks and disputes (CS-BILL-05). Never refund an order that has an open chargeback.
Trigger: a ticket tagged "refund".

Roles

Performs: support agent
Checks: team lead approves $100 to $500; finance approves over $500
Escalate to: team lead on shift

Before you start

Billing system access with refund rights, the customer's order history.

Procedure

Confirm the order or subscription and the date of purchase.
Check eligibility. Inside 30 days: eligible. Days 31 to 60: store credit only, unless the product failed. Over 60 days: escalate.
Check the amount. Up to $100: refund yourself. $100 to $500: request team lead approval in the ticket. Over $500: send to finance with the order history.
Issue the refund to the original payment method. Check: the billing system shows "refunded", not "pending".
Reply with the macro "Refund issued", including the amount and 5 to 10 business days for it to appear.
Tag the ticket with the reason: damaged, not as described, changed mind, duplicate charge.

Done when

Refund shows as completed, the customer has the confirmation, and the ticket has a reason tag.

Exceptions and escalation

Third refund request from the same customer in 90 days: team lead decides; note the history in the ticket.

Records

Ticket and billing record. Finance reviews reason tags monthly.

Revision history

Version	Date	Author	Change
1.4	2026-11-16	Teodora Vasquez	Agent limit raised from $50 to $100; lead approvals were averaging 6 hours

What belongs in an SOP

Most SOP templates share the same skeleton: title and ID, purpose, scope, roles, materials, numbered steps, references and a revision history. That skeleton is right. What separates an SOP people follow from one that sits in a shared drive is four additions most templates leave out.

A trigger. The moment the procedure starts. Without it, a task that belongs to "whoever closes" belongs to nobody.
Checks on the steps. What correct looks like, written where the person is looking, not in a quality section at the end.
If/then branches. The step that goes wrong is the reason the SOP exists. Say what to do when it does.
An owner and a next review date. In the header, where nobody can miss them. An SOP with no owner is out of date from the day the process changes.

Pick the format that fits the work

Step-by-step for linear tasks: the payroll run, the refund. This is the template above.
Hierarchical when each major step has sub-steps that a newcomer needs and an expert skips. Use numbered sub-lists under each step.
Flowchart when decisions outnumber actions, such as triaging a support ticket. Draw the flow, then keep a written version for search and for screen readers.
Checklist for people who already know the reasons. Put it at the top of the full SOP rather than in a separate document that drifts.

How to write the procedure

Watch the task being done, or do it yourself, and write while it happens. Procedures written from memory miss the steps that have become automatic, which are exactly the steps a new person does not know.

Start every step with a verb. Keep one action per step. Put numbers where an adjective would go: a temperature, a dollar limit, a number of minutes. When a step depends on a judgment call, say who makes it and how fast. "Call Gemma before leaving" is followable; "use your judgment" is not.

Test it on someone who has never done it

Before you publish, hand the draft to a person outside the process and watch them follow it without help. Do not answer questions; write them down. Every question is a missing step, an undefined term or a check that is not there. Two rounds of this catch more than any review meeting.

Keep it current after it is published

The question most SOP guides leave open is what happens after version 1.0. Most SOPs do not fail because they were written badly. They fail because the process changed and the document did not.

One owner, by name. Not a department. The owner approves changes and is the person asked when the SOP and reality disagree.
Review on a date, and after incidents. Put the next review date in the header and a task with a due date in your task list. Any incident the SOP should have prevented triggers a review that week.
Every change goes in the revision history with its reason. "Added step 6 after the back door was found propped open" tells the next reader why the step exists, which stops it being deleted as unnecessary.
Retire the old copy. One current version, in one place. Printed copies get a version number in the footer so a stale binder is easy to spot.

Common mistakes

Writing the ideal process, not the real one. If the floor does it differently, either the SOP or the floor is wrong. Find out which before publishing.
Steps that need context the reader does not have. Define acronyms and link the forms.
No exception path. People improvise when the SOP is silent, and improvisations do not get recorded.
One giant document. A 60-step SOP is not read. Split it and link the parts.

When to use a different template

An SOP describes routine work. For responding when a system breaks, the steps are diagnostic rather than routine: use a runbook template and see how to write a runbook. For teaching a new hire which SOPs exist and in what order, the onboarding checklist template is the right container. And when one person hands their responsibilities to another, the handoff document template covers the context an SOP leaves out.

Customization tips

Start with the trigger
Most SOPs describe the steps but not the moment they start. "Last table seated, or 22:30" or "a release tag is pushed" tells the reader when the procedure is theirs. Without a trigger, everyone assumes someone else started it.
Put the check next to the step
A separate quality section at the end gets skipped. Write Check: on the step itself, with what correct looks like, so the person catches the error while they can still fix it.
Make a checklist version for experienced staff
Once people know the reasons, they only need the sequence. Keep the full SOP as the reference and add a short checkbox list at the top for the people who run it every week.
Split anything over 15 steps
A long procedure usually hides two procedures. The deploy example moves schema migrations into their own SOP for that reason. Link the two with a reference line instead of nesting them.
Write numbers, not adjectives
"Cold enough", "a small variance" and "a large refund" produce three different answers from three people. 41°F, $5 and $500 produce one.
Photograph physical steps
For valve positions, alarm panels and label placement, a photo replaces a paragraph. Keep the photo next to the step it explains, not in an appendix.

In the app

How to do this in Scribelet

Open Desk Settings, then Templates, tap Add Template, paste the template above, choose the General category and set #sop as a default tag. Keep {{date}} so the effective date fills itself in.
Or describe the procedure in plain language ("closing checklist for a 40-seat restaurant with a walk-in") and use Generate with AI to draft a template, then edit it against how the work is really done.
Add the review as a task inside the SOP: - [ ] Review HSK-OPS-04 @due(2027-01-20). It shows up in the Tasks view until someone ticks it, so the review date is more than a field nobody reads.
Attach photos of panels, labels and forms to the note. Scribelet extracts the text from them, so a search for "alarm code panel" finds the closing SOP.
For software procedures, connect the repository with the GitHub connector and opt the SOP note in from its Settings. Background verification (Pro) compares claims such as job names and thresholds against the code and proposes a diff when they drift.
Ask the AI chat "what is the refund limit for team leads?" and it answers from your SOPs with a citation to the note, instead of someone guessing from memory.

Templates, template variables and AI generation are documented in Note templates.

Frequently asked questions

What is a standard operating procedure (SOP)?

An SOP is a written, step-by-step description of how a routine task is done, so that anyone qualified gets the same result every time. A good one also says when the task starts, who checks it, what to do when something goes wrong, and who owns the document.

Is there an SOP template in Word?

Word has procedure templates, but you do not need one. The template on this page is plain Markdown: paste it into Word or Google Docs and the headings, lists and table come across, or keep it in a notes app where it stays searchable and linked to the systems it describes.

What are the three types of SOP format?

The usual three are step-by-step (a numbered list for linear tasks), hierarchical (major steps with sub-steps for complex work) and flowchart (for procedures with many decision points). Many teams add a fourth, the checklist, for experienced staff who only need the sequence. The template above is step-by-step with if/then branches, which covers most procedures.

Can ChatGPT create an SOP?

An AI model can draft the structure and a first pass of the steps from a description. It cannot know your thresholds, your exceptions or the step people actually skip. Treat the draft as a starting point, then test it by having someone who has never done the task follow it while you watch.

What is the difference between an SOP and a work instruction?

An SOP covers the whole process: purpose, scope, roles, steps and records. A work instruction zooms into one task inside it, such as how to calibrate the thermometer used in step 1. Link the work instruction from the step rather than pasting it in.

How often should an SOP be reviewed?

Set the interval by how fast the process changes: three months for software deploys, six to twelve months for most business processes, and whatever your regulator requires for audited work. Also review after any incident the SOP should have prevented, which is where most of the revision history in the examples above comes from.

Procedures that are still right when someone new follows them

Save this SOP template in Scribelet, give each procedure an owner and a review task, and let your team ask the AI chat for the right step instead of digging for a PDF. Encrypted, free to start.

Write your first SOP

or get the app

Download on theApp Store

Free plan, no credit card. See pricing

Engineering

Runbook Template

A runbook is the page someone follows at 3 a.m. with no context. This template gives every step a literal command and the output to expect, and adds the two fields most templates skip: when the procedure was last verified, and what change would make it wrong.

Work

Onboarding Checklist Template

Most onboarding checklists list tasks. This one gives each task an owner and a due date, adds a Done when section so everyone knows when onboarding is over, and keeps open issues in one place. Copy it, or start from the filled-in checklist closest to the hire you are making.

Work

Knowledge Base Template

A knowledge base is a set of pages, one topic each, that link to each other and stay true. This template gives every page a short answer, an owner, a review date and its links, whether the knowledge base is for a team or only for you. Copy it, or start from the example closest to your situation.

Work

Handoff Document Template

A handoff fails on the things nobody wrote down: the promise made in a hallway, the decision half made, the warning sign only the outgoing person knows. This handoff document template has a section for each, and ends with a read-back so you know the handover landed. Copy it, or start from the handover notes example closest to yours.

Article

Internal documentation

From the Scribelet blog

Article

Knowledge decay

From the Scribelet blog