How to Write SOPs People Actually Follow (Most Die in a Folder)

Q: What is an SOP and why do businesses need them?

A standard operating procedure is a written, repeatable recipe for a recurring task: the steps, the standards, the edge cases, and who decides what. They matter because undocumented processes live in individual heads — which means quality varies by person and mood, training each new hire takes months of shadowing, the business can't scale past the people who 'just know,' and every departure takes operational knowledge out the door. An SOP converts personal know-how into an organizational asset. In the AI era there's a second payoff: documented processes are exactly what AI agents need to take work over — your SOPs are becoming training data.

Q: How do you write an SOP quickly?

Don't write it — record it. The fastest reliable method: the person who does the task best screen-records themselves doing it once, narrating decisions as they go ('I check this field first because...'). That 15-minute recording captures more real process than three hours of memory-based writing, including the micro-decisions experts forget they make. Then someone else — ideally the least experienced person — converts the recording into a one-page checklist and tests it by following it literally. Where they get stuck is where the document needs work, not where the writer thought it did.

Q: Why do employees ignore SOPs?

Almost always a design failure, not a compliance failure. The usual causes: the document is too long (a 9-page SOP is a novel nobody opens mid-task), it lives somewhere inconvenient (a buried drive folder instead of inside the workflow), it's out of date (one wrong step destroys trust in the whole document), it was written by a manager who doesn't do the task (so it describes the imagined process, not the real one), and there's no maintenance owner. Fix the format — one page, checklist-first, linked where the work happens, owned and dated — and 'people don't follow processes' mostly disappears.

Q: What should an SOP include?

One page where possible: the trigger (when this SOP fires), the owner, the steps as a checklist with screenshots where useful, what 'done' looks like (observable, not vague), the 3-5 most common edge cases with their answers, and the escalation line — when to stop and ask a human, and which human. Skip the corporate preamble, the version-control theater, and the policy language. The test of a good SOP isn't completeness; it's whether a careful new person can execute the task tomorrow without asking questions.

Every founder has the folder: 'Processes — FINAL'. Inside, eleven documents written in a burst of organizational virtue, formatted like legislation, read by no one since the week they were written. The problem was never that SOPs don't work — businesses that run without their owners run on them. The problem is that most SOPs are written by the wrong person, at the wrong altitude, in the wrong format, for a reader who was never consulted. Here's the version that gets used — and why it suddenly matters twice as much in the agent era.

The folder where processes go to die

The scene repeats in almost every business we audit. The founder, mid-tour of their systems, opens a drive folder — "Processes," sometimes "Processes — FINAL," occasionally the fully honest "Processes — FINAL v2" — and inside sit the documents: comprehensive, formatted, six to fourteen pages each, written during some past burst of organizational resolve. I ask when one was last opened by someone actually doing the task. The pause answers before the founder does.

Here's what makes this worth fixing rather than mocking: the businesses that genuinely run without their owners run on documented process. It's the difference between owning a company and owning a job with overhead — the entire thesis of systemization. The folder failed, but the instinct was right. What failed is fixable, and it's the same four things every time.

Why they die: the four design failures

Wrong length. A person mid-task has thirty seconds and one question. A nine-page document answers every question except theirs, behind a wall of preamble. They ask a colleague instead — and the SOP's actual function becomes decorative.
Wrong location. Process documents stored away from the work — in the drive, in the wiki nobody opens — lose to the path of least resistance, which is shouting across the room. The SOP must be closer than the colleague.
Wrong author. SOPs written by managers describe the imagined process — the flowchart version. The real process, with its workarounds and judgment calls and the field you check first because experience taught you to, lives only in the hands of whoever does the task best. Documentation that skips them documents a fiction.
No pulse. Processes drift; documents don't. The first time an SOP's step three points at a button that no longer exists, trust in the entire document — and quietly, the entire folder — dies. An SOP without a maintenance owner isn't an asset; it's a liability with a date of death already set.

Nobody disobeys a good map. When people ignore your SOPs, they're not being difficult — they're telling you the map doesn't match the territory.

The method: record, convert, stuck-test

The expert records, once. Whoever does the task best screen-records themselves doing it for real — narrating decisions aloud: "I check the payment status first, because if it failed there's no point preparing the order." Fifteen minutes. This captures the micro-decisions experts no longer know they make — the exact knowledge that memory-based writing always loses, because expertise is precisely the stuff that became invisible to its owner.
The novice converts. The least experienced suitable person turns the recording into a one-page checklist. Counterintuitive and essential: the expert can't see the gaps (everything is obvious to them); the novice falls into every gap and therefore documents them. The recording is the source; the beginner's confusion is the editor.
The stuck-test. A third person — or the novice a week later — executes the task using only the document, no questions allowed. Every stall, every "wait, which button?" is a defect in the document, not the person. Fix those spots; ignore the spots the original writer worried about. Two rounds of this and the SOP is genuinely executable — which fewer than one in ten folder-SOPs are.

Total cost: about ninety minutes per process. Compare against the alternative you're currently paying: every new hire shadowing for months, every absence becoming a small crisis, every departure exporting know-how to a competitor. (The delegation math is the same as everywhere else — a one-time asset against a forever expense.)

The one-page anatomy

Element	What it is	Example
Trigger	When this SOP fires	"New order marked paid"
Owner	Who maintains this document	One name, not a department
Steps	Checklist, verb-first, screenshots where it helps	"1. Open the orders board → 2. Verify payment status…"
Done =	Observable definition of complete	"Customer has confirmation email; CRM stage = Fulfilled"
Edge cases	The 3–5 most common, with answers	"Payment failed → see step 2a. Address missing → text template C"
Escalate when	The stop-and-ask line, with a name	"Refund over $200, angry customer → Deniz, immediately"

What's deliberately absent: the purpose statement, the scope paragraph, the revision-history table, anything in passive voice. Those serve the document's author at the expense of its user, and the user is the only vote that counts. If the process won't fit a page, it's two processes — split it at the natural handoff and link them.

Keeping them alive

Put the link where the work happens — pinned in the relevant channel, embedded in the task template, attached to the tool. The SOP must be the path of least resistance, or the colleague's shoulder wins.
Whoever finds the drift, fixes the drift — a one-line edit in the moment, not a ticket for someday. One page makes this cheap; ownership makes it happen.
Date-stamp visibly, review on a trigger, not a schedule. Quarterly-review calendars get ignored; instead, any tool change or repeated question triggers a check of the affected page. The repeated question is the system telling you exactly where the gap is.
Make "is there an SOP?" the first answer to every how-do-I question. If yes, send the link (and learn why it wasn't found). If no, the asker records the answer when they get it — the library grows at the speed of actual confusion, which is the correct speed.

The reframe that changes everything

Stop writing SOPs as compliance documents and start writing them as products with one user: a careful stranger, mid-task, with thirty seconds and one question. Every formatting decision follows from serving that person — and so, quietly, does whether your business can ever run without you.

The agent era: SOPs as training data

And the reason this old discipline suddenly carries new stakes: a documented process is one an AI agent can take over. When we build agents for a business, the first thing we ask for is the process documentation — the triggers, steps, edge cases, and escalation rules — because that is the agent's specification. A clean one-page SOP for invoice chasing converts into an automated workflow in days. An undocumented process converts into a discovery project first, billed in weeks.

Which reframes the whole exercise: every SOP you write is no longer just insurance against turnover — it's a candidate for full automation, pre-written. The businesses that documented their boring work are currently handing it to machines at a fraction of the cost of the businesses that kept it all in heads. The folder was never the goal. The handoff was. (Which processes to hand off first: the twelve examples.)

Documented it? Now see what it costs to keep doing it by hand.

The audit maps your processes, prices the manual hours, and shows which SOPs convert straight into agents — before anything is built.

Book a Free Audit →

Frequently asked questions

What is an SOP and why do businesses need them?

A written, repeatable recipe for a recurring task. Undocumented processes live in heads — quality varies, training drags, departures export knowledge. SOPs convert know-how into an asset; in the agent era, they're also automation specifications.

How do you write an SOP quickly?

Record, don't write: the expert screen-records the task with narrated decisions; a novice converts it to a one-page checklist; a third person stuck-tests it by following it literally. Ninety minutes per process.

Why do employees ignore SOPs?

Design failure: too long, buried, stale, or written by someone who doesn't do the task. One page, linked where the work happens, owned and current — and the compliance problem mostly evaporates.

What should an SOP include?

Trigger, owner, verb-first checklist, observable definition of done, top edge cases with answers, and an escalation line with a name. Skip the preamble. The test: a careful new person executes it tomorrow without questions.

About the author

Seçil Sayhan is a behavioral scientist and the founder of MARSA.AI. Trained on both sides of her field — a BA in Business Management, an MSc in Clinical Health Psychology & Wellbeing, an ICF coaching credential, a diploma in neuroplasticity, and advanced training in Lifestyle Medicine from Harvard University — she has spent the past decade helping 7,000+ people across 12 countries rewire the systems running their lives. That decade produced the conviction MARSA is built on: behavior is one science — whether it moves a person, a market, or a machine. Her work draws on the clinical literature throughout: see the full bibliography.