How to Write an SOP People Follow Under Pressure

The hard part of writing an SOP is not the writing. A standard operating procedure is a few hundred words about a task you already know how to do; any literate operator can produce one in an afternoon, and AI will now produce one in a minute. The hard part is that most SOPs are written to be complete, and completeness is the wrong target. The SOP that works is written for one reader at one moment: a competent person, mid-task, under time pressure, who needs to know the next step and cannot afford to go looking for it.

Medicine learned this the expensive way, and its findings transfer almost embarrassingly well. When Peter Pronovost put a five-item central-line checklist into 103 Michigan ICUs, median infections fell from 2.7 per 1,000 catheter-days to zero in three months (Pronovost et al., NEJM 2006). The checklist contained nothing a physician did not already know. Its power was format and placement: short, checkable, present at the procedure, with someone watching whether it ran. That is the entire craft of SOP writing in one study, and the seven steps below are that craft in sequence.

What belongs in the SOP format, and what does not?

The SOP format is short: the one task it covers, the trigger, the owner, the checkable steps, and the definition of done. A standard operating procedure is the agreed way one recurring task gets done, written so that any qualified person can run it the same way. It is not a policy (why we do things), not a training manual (how to learn the skill), and not a process map (how tasks connect). Those documents have their place, usually in onboarding, and confusing them with the SOP is the first way SOPs bloat. The test for every sentence in your draft: does the person mid-task need this line, right now, to take the next step? If not, it lives somewhere else.

Your team already runs on procedures, by the way. The things that make you angry when they do not happen are a process you never wrote down. Writing the SOP is mostly an act of capture, which is why the second half of this page keeps pointing you back to watching the work rather than imagining it.

How do you write an SOP, step by step?

• One task, one SOP. Scope it to a single task with a clear start and finish. “Run the renewal motion” is a program; “send the 90-day renewal notice” is an SOP. If the draft wants chapter headings, it is several procedures wearing one title, and each deserves its own card.
• Name the trigger. State the exact moment the procedure begins. This is the hardest-working sentence in the document, and the behavioral science is unambiguous about why: Gollwitzer and Sheeran’s meta-analysis of 94 studies found that plans phrased as if-then pairs (“when situation X arises, I will do Y”) produce a medium-to-large jump in follow-through, d = 0.65, over goal intentions alone (Gollwitzer & Sheeran, 2006). An intention waits for someone to remember it. A trigger lets the moment do the reminding.
• Walk the task before you write it. Capture the steps from reality: do the task yourself or sit with the person who does it best. The best process already lives in your best people, and your job is to spread it, not to import a template nobody believes in. Capture tools like Scribe make this nearly free for screen work, as covered in our SOP software comparison.
• Write checkable steps, and keep only the killer items. Each step is one verifiable action. Then cut: aviation checklists, the ancestors of this whole discipline, list the items that kill people when skipped, not every action a pilot takes. Gawande’s WHO surgical checklist ran nineteen items and cut complications from 11 to 7 percent across eight hospitals (Haynes et al., NEJM 2009); its drafts were longer and got better as they got shorter. A step everyone does anyway is not protection, it is padding, and padding teaches readers to skim.
• Give each rule its reason. One line of why, where the why is not obvious. People route around rules they believe are arbitrary, and they defend steps they understand. “Avoid the femoral site” survives because everyone knows what happens when you do not.
• Post it at the work. Put the procedure where the task happens: the card above the station, the checklist in the CRM stage, the prompt in the ticket queue. This is where most SOP programs die, and the numbers are not subtle. In The State of Sales Enablement, teams whose process reached reps in the flow of work hit quota at 49 percent against 15 percent for teams whose process lived in a doc, wiki, or LMS. Same documents. Different shelf.
• Measure use, and revise on triggers. Track whether the steps happen in the flow of real work, because you can only expect what you inspect, and an uninspected SOP is a hope with formatting. Assign one owner, and tie revisions to events (pricing changed, stage renamed, tool swapped) rather than a quarterly calendar that always slips.

Why do well-written SOPs still go unfollowed?

Because writing quality was never the binding constraint. A procedure competes for attention at the worst possible moment, when the person is busy, and it wins or loses on delivery cost. If following the SOP means leaving the task, finding the document, and finding the relevant line, the SOP loses, and it loses to your most conscientious people too, because they are the busiest. This is a system property, not a character flaw. When a team skips a procedure, treat it as data about the procedure’s placement and weight, the way Pronovost treated skipped handwashing: he did not lecture the physicians, he put a nurse and a checklist at the bedside and changed the system.

The other failure mode is decay. A procedure document is most true the day it is written; each process change it does not hear about widens the gap between the page and the work, and one stale step teaches readers to doubt all the others. The cure for both failure modes is the same and it is structural: connect the SOP to the live work, so that use keeps it visible and inspection keeps it true. For sales teams this is exactly the argument of where your sales process should live, and it is the job Supered does for revenue SOPs specifically: the procedure surfaces inside HubSpot or Salesforce at the step where it applies, and adherence is measured in the flow of work, so the writing you did this week is still running in week twenty.

A worked example: the proposal-stage SOP

Theory is cheap, so here is the shape on a real task, a B2B deal moving to proposal:

• Trigger. Deal stage changes to Proposal.
• Step 1. Confirm the economic buyer attended the demo; if not, do not advance, book the exec session first.
• Step 2. Attach the pricing doc to the deal record.
• Step 3. Set the close date from the buyer’s stated decision process, never from the end of our quarter.
• Step 4. Write the one-line next step the buyer agreed to, with a date.
• Why line for step 3. Close dates set by seller hope, rather than buyer reality, are the single largest source of forecast slip we see; the stage should reflect the buyer’s position, not our wish.
• Done. All four fields verified in the CRM, visible to the manager without asking.

Notice what is missing: no paragraph about why proposals matter, no screenshots of the CRM, no history of the pricing model. Four checkable steps and one why. The rest lives in onboarding, where it belongs. A library of these, one card per moment in your process, beats any forty-page playbook (and beats hunting for an sop template, since the format above is the template), and assembling that library is covered across the process documentation guide and the sales process template.

The recommendation

Write your next SOP in two hours, not two weeks: scope one task, name the trigger, walk the work, keep the killer items, post it at the station, and put a number on whether it runs. Then resist the urge to write ten more before the first one has survived contact with a real Tuesday. Our position, consistent with everything above: the format of an SOP is a solved problem you can copy from this page, and the delivery of an SOP is the problem that decides whether the writing mattered. Spend your effort in that order. When the SOPs in question are your sales process, the delivery layer is our actual business, and how it works shows what a measured, in-flow procedure looks like on a live pipeline.