SOP examples: 10 real procedures, annotated
By Annie, our AI research assistant · Reviewed and edited by Jessica WhiteMost SOP examples online are formatting demos. They show you what a procedure looks like, not what makes one get followed. Across several thousand published procedures and templates, the difference comes down to six elements, and almost every failed SOP is missing the same three.
There is no shortage of SOP examples on the internet. There is a serious shortage of useful ones.
The typical example is a clean template with a header, a numbered list, and a revision table. It demonstrates a format. It does not tell you why one procedure becomes the thing a team actually opens on a Tuesday afternoon, while the person who normally does the task is out sick, and another becomes a file nobody has touched since the day it was written.
That distinction is what this article is about. Below are ten procedures, stripped to their working parts and annotated: what makes each one function, and the specific way each one tends to break. They are composites drawn from patterns across published templates and documentation samples rather than any single company's files, so nothing here is somebody's confidential process.
What every SOP that works has in common
Before the examples, the pattern. Procedures that hold up share six elements. Procedures that get abandoned are usually missing the last three.
A trigger. Not a title, a trigger. "Refund process" is a filing label. "When a customer requests a refund within 30 days of purchase" tells a person whether they are in the right document.
A named owner. A role, not a committee. Someone whose name is attached and who is expected to notice when the procedure is wrong.
Steps in the order a human does them. Including the boring ones. The step everyone skips writing down is usually the step that causes the error.
Decision branches written as if-then. Most real work forks. A procedure that pretends it does not fork sends people back to asking a person the moment reality gets complicated.
An escalation path. What to do when the procedure does not cover the situation. This is the single most commonly missing element, and its absence is why teams default to interrupting the owner.
A last-reviewed date. Trust in documentation is close to binary. One stale answer teaches a team that the whole library is unreliable, and a visible review date is the cheapest credibility signal available.
A procedure that cannot tell you what to do when it does not apply is not a system. It is a suggestion.
The 10 examples
1. New client onboarding
Trigger: A signed agreement is received. Owner: Account manager.
The shape: confirm what was sold and at what price, send the welcome message within one business day, collect intake information through a form rather than an email thread, schedule the kickoff, create the client's workspace from a standard folder template, and set the first internal check-in for day 14.
What makes it work: The best onboarding procedures include a "confirm what was sold" step before anything else happens. It looks redundant. It catches the mismatch between what the salesperson promised and what the delivery team believes was promised, which is the origin of a large share of unhappy first months.
Where it breaks: Intake information collected conversationally. The moment intake lives in an email thread instead of a form, the procedure has no completion state and nobody can tell whether it finished.
2. New hire first week
Trigger: An offer is accepted. Owner: Hiring manager, with an IT or operations counterpart for access.
The shape: accounts and access requested five business days before the start date, equipment confirmed, a first-day schedule sent in advance, a named buddy assigned, day-one access verified before the new person logs in, role-specific reading assigned across the first week rather than dumped on day one, and a 30-day check-in scheduled on the day the offer is accepted.
What makes it work: Strong versions of this procedure schedule the 30-day check-in immediately, not later. Later never arrives, and month two is where new hires quietly conclude that nobody is coming to help them.
Where it breaks: The firehose. Procedures that assign everything on day one produce a new hire who has read nothing and understood less. Sequencing over volume, every time.
3. Refund or return request
Trigger: A customer requests money back, through any channel. Owner: Support lead.
The shape: log the request, verify the purchase date and condition against policy, then branch. If it is inside the window and meets policy, process it and tell the customer the timeline in days. If it is outside the window, offer the defined alternative, which might be credit or a partial refund. If it exceeds a stated dollar threshold, escalate to a named person. Record the reason code either way.
What makes it work: The dollar threshold. Procedures that name an amount ("over $500, escalate to the operations manager") let a support person act with confidence up to that line and stop guessing above it. Confidence in this context is just a clearly drawn boundary.
Where it breaks: No reason code. Without one, the company processes refunds forever and never learns what is causing them.
4. Invoicing and accounts receivable follow-up
Trigger: Work is delivered, or the billing date arrives. Owner: Whoever owns billing, which in a small business is usually the owner until it very much should not be.
The shape: invoice within one business day of delivery, terms stated on the invoice, then a scheduled follow-up ladder. A friendly reminder at day 7 past due, a firmer one at day 14, a phone call at day 30, and a defined decision point at day 45 about pausing work or escalating.
What makes it work: The ladder is written in advance, so nobody has to decide in the moment how aggressive to be. Removing that decision is the whole point. Collections stall not because people forget but because each follow-up feels like a small confrontation to initiate.
Where it breaks: Nobody owns day 30. The early automated reminders happen and the human step does not, so invoices age quietly.
5. Inbound lead intake
Trigger: A new inquiry arrives by form, phone, or referral. Owner: Whoever is on intake duty that day, named explicitly.
The shape: log the lead with its source within four business hours, respond within the same window, qualify against three or four written criteria, then route. Qualified leads go to a scheduled call, unqualified leads get a polite decline with a referral where possible, and unclear leads go to one named person for a judgment call.
What makes it work: Source logging on the first touch, before anyone is excited about the deal. Attribution collected later is fiction, and a business that cannot say where its leads come from cannot decide where to spend.
Where it breaks: "Respond promptly." Procedures that use adjectives instead of numbers are unenforceable. Four hours is a standard. Promptly is a mood.
6. Month-end close
Trigger: The first business day of the month. Owner: Bookkeeper or finance lead.
The shape: reconcile every account, chase outstanding receivables, categorize uncategorized transactions, review the P&L against the prior month, flag any line item that moved more than an agreed percentage, and deliver a short summary to the owner by a fixed date.
What makes it work: The variance threshold. Naming a percentage turns a review into a filter, so the person doing it knows what deserves a sentence of explanation and what does not.
Where it breaks: The summary is optional. When the deliverable at the end is undefined, the close becomes a data-entry ritual that produces no decisions.
7. Customer complaint escalation
Trigger: A customer expresses dissatisfaction that the first responder cannot resolve. Owner: Support lead, with a named backup.
The shape: acknowledge within one hour, document what happened factually, attempt resolution within defined authority, and escalate on stated conditions. Escalate if the customer requests a manager, if the issue involves a safety or legal claim, if resolution exceeds the authority limit, or if it is the second complaint from the same customer in 90 days.
What makes it work: Escalation conditions expressed as facts rather than feelings. "If the customer seems really upset" produces wildly different behavior between two employees. "Second complaint in 90 days" produces the same behavior from both.
Where it breaks: No backup owner. Escalation paths that route to a single person fail the day that person is on vacation, which is disproportionately the day something goes wrong.
8. Publishing or delivery quality check
Trigger: Work is ready to go to a client or the public. Owner: The reviewer, who is never the creator.
The shape: a short checklist run before anything ships. Facts and figures verified against source, links tested, names and numbers checked, brand and format standards applied, required disclosures present, and a final read for whether it does what it was supposed to do.
What makes it work: Separating reviewer from creator. Self-review procedures perform reliably worse, for the same reason people cannot proofread their own writing. The checklist is not the mechanism. The second set of eyes is the mechanism, and the checklist is what makes those eyes efficient.
Where it breaks: Checklist inflation. A 40-item quality check gets skipped. Ten items get done. There is a real ceiling on how much attention a pre-flight check can demand before it becomes theater.
9. Employee offboarding
Trigger: A resignation, termination, or contract end. Owner: Hiring manager plus whoever controls systems access.
The shape: access revoked on a stated timeline tied to the last day, equipment returned and logged, files and accounts transferred to a named person, client and vendor relationships reassigned in writing, a knowledge transfer session recorded, final pay and benefits confirmed, and an exit conversation held.
What makes it work: The access checklist is enumerated system by system rather than described. "Remove all access" is not a step. It is a wish. The strongest versions list every tool by name, which also doubles as an accidental inventory of what the company actually pays for.
Where it breaks: Knowledge transfer scheduled for the last week. The departing person is checked out and the receiving person is overwhelmed, so the session produces a recording nobody watches. Earlier is better, and documented earlier still is better than both.
10. Something is broken and the person who fixes it is unavailable
Trigger: A system is down, a key vendor fails, or the person who normally handles it cannot be reached. Owner: Named incident lead with a named backup.
The shape: assess impact against defined severity levels, notify the people affected inside a stated window, apply the documented workaround if one exists, escalate to the vendor or the backup expert with contact details listed right there in the procedure, communicate status on a fixed interval even when there is nothing new to report, and write a short review afterward.
What makes it work: Contact details inside the document. Not in a directory, not in someone's phone, in the procedure. Under pressure, every extra lookup is a point of failure.
What makes it work, part two: The fixed communication interval. Updating stakeholders every 30 minutes even with no news is what separates a handled incident from a panicked one.
Where it breaks: It was never written, because the person who knows how to fix things has always been reachable. This is the procedure most businesses only write immediately after the first time they needed it.
What the abandoned ones have in common
Failed procedures repeat the same four traits.
They describe instead of instruct. "Ensure customer satisfaction is maintained" cannot be performed. "Call the customer within one business day" can be.
They have no owner, so nobody notices when they go stale, and stale documentation poisons trust in the whole library.
They stop at the happy path, which means the first exception sends the reader to find a person, and once a person answers, the procedure has lost.
They live somewhere nobody works. A perfect document in a folder nobody opens loses to a wrong answer from a coworker who is right there.
Every procedure competes with the fastest human who can answer the question. Most lose on speed, not on quality.
How to use these examples
Do not copy them. Copied procedures describe a company that is not yours, and a team can tell within about one paragraph.
Use them as a shape test instead. Take a procedure you already have, and check it against the six elements: trigger, owner, real steps, if-then branches, escalation path, review date. Most existing documentation has the first three. The gap is almost always the last three, and closing that gap costs an afternoon rather than a rewrite.
Audit one procedure this week
Pick the process your team asks about most. Read it against the six elements above and mark which are missing. Then find the person who most recently asked a question that procedure should have answered, and ask them what they looked for and where they looked first. Their answer tells you whether you have a writing problem or a placement problem, and those have completely different fixes.
Where the format goes next
One pattern worth naming, because it is new and it is going to matter.
Documented procedures are turning into the context that AI assistants need in order to be useful inside a business. A team with clear, current, structured procedures can hand an AI tool the actual rules of the company. A team without them gets generic output, because generic input is all it has to give. The same six elements that make a procedure legible to a distracted employee make it legible to a machine, which is worth taking seriously!
