SOP Examples: Five Formats, One Part They All Skip

A recipe card and a binder are both paper. Only one of them is on the counter while the food is cooking.

The same distinction separates SOP examples that become part of daily work from the ones that sit in a shared drive folder, last opened on the day they were uploaded. The format of an SOP matters less than where it lives and whether it has a mechanism that checks it was followed. Plenty of good examples stop at the recipe card and never say where the card should be when someone needs it.

SOP examples are working instances of a standard operating procedure document, and they come in five main formats: step-by-step procedures, hierarchical procedures, flowcharts and decision trees, checklists, and video or screen recordings, each suited to a different kind of task. Knowing which format to reach for is the first skill. The second is adding the part templates tend to leave out, a check that the procedure was followed.

What are the five main SOP formats?

Each format is a different tool. Reaching for the wrong one is like bringing a road map to a pre-flight check. It is still a document, and it is the wrong one.

Step-by-step procedure. The default format is a numbered list of actions in order. It is the right choice when the task is linear, the same steps in the same order every time, with no branches. New account setup in a CRM, expense report submission, data export from a reporting tool. It breaks the moment the task has a fork (“if the prospect has a HubSpot contract already, do X; otherwise do Y”), the numbered list fails, because step 3 cannot be two different things at once.

Hierarchical procedure. A step-by-step procedure with sub-steps: 1, 1.1, 1.2, 2, 2.1, and so on. Useful for complex processes with multiple phases, where the phases need to stay visible while the individual actions are detailed. An enterprise sales proposal process, a product launch plan, a regulatory compliance review. It is hard to use under time pressure. A rep scanning a seven-level outline for the one step that applies right now would be faster with no SOP at all.

Flowchart or decision tree. A visual diagram that maps the if-then logic of a process. The diamond shapes are the decisions; the rectangles are the actions. It is the right format for any task that involves a judgment call, such as objection handling, deal qualification, incident triage, or pricing approvals. A flowchart follows the order a person thinks in during the work. They decide, act, and then face the next decision. Keep each one to a single page and one decision path, because a sprawling flowchart is unreadable.

Checklists. A checklist is a completion tracker, a list of items that must be done before the task counts as complete. The surgical checklist research by Atul Gawande and the WHO Safe Surgery team (published in The New England Journal of Medicine, 2009) tested a 19-item checklist at eight hospitals across high- and low-income countries and found it reduced major complications by 36% and in-hospital deaths by 47%. The surgeons already knew what to check. The checklist made sure the items they sometimes skipped under pressure got done every time (Gawande et al., NEJM, 2009). Sales can borrow that mechanism whole. A deal-close checklist, a new hire’s Day 1 schedule, and a renewal risk review all work better as checklists than as prose, because a box is either ticked or it is not.

Video or screen recordings. A screen-capture walkthrough of a UI-heavy task. Use it for updating a field in the CRM, running a report in a specific tool, or formatting a proposal in the company template. The advantage is that “click the blue button in the top right” is far less ambiguous when you can see the screen. The cost is decay, because the UI changes faster than anyone re-records. A 90-second Loom from 18 months ago describing a button that no longer exists is worse than no SOP, because it trains people to distrust all the others.

What makes a real SOP example effective?

Format is the easy decision. What goes inside it decides whether anyone follows it, and four elements do most of that work.

• A clear trigger. The SOP must state the specific event that starts it, not a vague “when applicable.” An SDR marks a meeting as booked. A deal reaches Stage 3. A severity-1 ticket is opened. Without a trigger, the SOP is a procedure with no moment of application.
• One action per step. “Update CRM and send follow-up email” is two steps. Split them. A person who skips one cannot be coached unless the SOP is specific enough to surface the skip.
• A definition of done. What complete and correct looks like, stated so that two different people would agree. Not “call notes logged.” The specific fields, within a specific time window, with a binary outcome.
• An inspection hook. The mechanism that checks adherence in the flow of work, before the audit. More on it below, since it is the part standard operating procedure examples tend to leave out.

Two of those four need more room.

A definition of done. Step 7 on a discovery call SOP might say “log call notes in the CRM.” That is ambiguous. Does it mean any notes? Notes with specific fields filled in? Notes within 24 hours, or before the next meeting? A definition of done states what “complete and correct” looks like, unambiguously, so the person doing the work and the manager inspecting it are looking at the same thing. Without it, the SOP lists activities and sets no standard.

An inspection hook. The hook decides whether a procedure is followed or only documented. An inspection hook is the mechanism that checks adherence in the flow of work, built into the process rather than added as a separate audit. A discovery call SOP that requires a specific field to be populated before a deal can advance to the next CRM stage enforces itself, because the software catches the skip at the moment it happens. A discovery call SOP filed in a shared drive folder requires the rep to remember it exists, find it, consult it, follow it, and log the output without any prompt. The first design relies on the system. The second relies on memory and discipline, and quota pressure drains both.

B.J. Fogg’s research on behavior design, formalized in Tiny Habits (2019), identified three elements that determine whether a behavior occurs: motivation, ability, and a prompt (Fogg, Tiny Habits, 2019). A filed SOP improves ability (knowing what to do) but provides no prompt at the moment of the action. An inspection hook built into the workflow is the prompt. The closer the prompt sits to the action, the more reliably the action occurs. Gawande’s checklist worked for the same reason. The surgeon could not close the patient without the team running through the list, because the list was present at the operating table, not in an office.

For a deeper look at the structure of an SOP that gets followed, including the six parts and how they fit together, the post on how to write an SOP goes step by step.

Why do most SOP examples fail in the real world?

When an SOP fails, look first at where and when it shows up. A well-written procedure filed in a shared drive requires a rep to remember to consult it, find it, and read it before acting, all while the work in front of them demands attention. In the middle of a live call, that sequence rarely happens. The procedure might as well not exist.

Jeffrey Pfeffer and Robert Sutton documented the pattern in The Knowing-Doing Gap (2000). Organizations routinely build knowledge assets (playbooks, SOPs, training materials) and then discover that knowing the right thing to do does not reliably produce doing it (Pfeffer & Sutton, The Knowing-Doing Gap, Stanford University Press, 2000). In the companies they studied, people generally knew what they should be doing. The gap was context. The moment of work did not put the knowledge in front of them when it was needed.

For SOP design, that means a procedure has to be reachable at the moment it is needed, or it does not function. An SOP for an objection handling sequence has to be available during the objection, not in a training folder the rep bookmarked three months ago. An SOP for CRM data hygiene has to surface when the rep is in the CRM, not when they happen to attend the monthly ops review.

Ask one design question of any SOP example. Where is this visible while the work is being done? If it lives “in a folder” or “on a wiki page they have to search for,” the procedure has a location problem that no format can fix.

For the process documentation side of this, the process documentation pillar covers when and how to document, and the post on workflow documentation shows how to capture the handoffs between people, where SOPs tend to go silent.

What a practical SOP example looks like, by job type

The three abbreviated examples below each have the inspection hook written in.

Discovery call SOP (sales). Trigger: an SDR marks a meeting as booked. Steps: confirm contact, company, and deal size in CRM; send pre-call agenda; run the call using the question sequence; log notes in the “Discovery Summary” field within two hours; advance deal to “Qualified” stage if at least four of five qualification criteria are met. Definition of done: “Discovery Summary” field populated, deal stage updated or stage advance declined with a reason. Inspection hook: a CRM workflow prevents stage advance without the “Discovery Summary” field.

New employee onboarding SOP (operations). Trigger: new hire start date confirmed. Steps: provision accounts on Day -1; send welcome email with first-week schedule on Day -1; complete IT setup by 9 AM Day 1; run culture orientation session by noon Day 1; assign 30-60-90 buddy and document in the HR system. Definition of done: all seven provisioning tasks checked, buddy assignment logged. Inspection hook: HR system checklist auto-assigned to the onboarding coordinator with a deadline; manager receives a status flag if any item is overdue by more than 24 hours.

Deal close sequence SOP (sales). Trigger: verbal yes from the decision maker. Steps: confirm legal signatory, send contract via e-signature tool, schedule kick-off meeting before contract signing, get signed contract, log in CRM, hand off to customer success with deal context note. Definition of done: contract in the CRM, kick-off meeting scheduled, customer success handoff note completed. Inspection hook: deal cannot move to “Closed Won” without the contract attachment and the handoff note field.

All three share a clear trigger, short steps, an unambiguous definition of done, and an inspection hook that does not rely on the person remembering to check themselves.

What we recommend

Pick the format that matches the task type: step-by-step for linear tasks, flowcharts for decisions, checklists for safety-critical sequences. Write each SOP short enough to read in under two minutes under pressure. Add a definition of done that leaves no ambiguity about what complete looks like.

Then add the inspection hook, the step that turns a document into a standard people run. The hook does not have to be software (if it is, the SOP software graded by the job it does shows which tools carry an inspection record and which only store the page). A pre-meeting checklist taped beside the phone, a required field in a form, or a stage gate in a CRM all work. The test is whether the system catches the skip when it happens. A retroactive audit arrives too late to change anything.

A well-formatted SOP that lives in a folder will not be followed reliably. A moderately formatted SOP posted where the work happens, with a mechanism that checks it was completed, will be. You still need the recipe card. What makes it useful is that it sits on the counter, open, while the pan is hot.

From here: the full six-part structure in how to write an SOP, the reusable blank format and SOP template examples in SOP template, and the documentation strategy it fits into in process documentation.