There is a right way to write an SOP and a wrong way. The wrong way produces a document that technically covers the process but requires explanation to use, which means it gets ignored. The right way produces a document that a new person can follow without asking a single question.
The gap between these two is almost entirely about format and specificity. This guide covers exactly how to build an SOP that transfers knowledge reliably, and how to make sure it stays current.
The format of an SOP determines whether someone can follow it under pressure. Paragraphs are for reading. Numbered steps are for executing.
Wrong format:
After a discovery call, the sales rep should review the notes, update the CRM with relevant information, and send a follow-up email within 24 hours.
Right format:
The second version can be executed by someone who has never made a follow-up call before. The first cannot.
Paragraphs are for reading. Numbered steps are for executing.
Every process has moments where judgment is required. A transferable SOP does not paper over these moments, it documents them with explicit criteria.
Wrong approach:
If the lead looks like a good fit, advance them to the Qualified Opportunity stage.
Right approach:
Advance the lead to the Qualified Opportunity stage if ALL of the following are true: company size is between 10 and 200 employees; the contact is a decision-maker (Director, VP, C-suite, or Founder); a specific pain point matching one of our three primary ICP pain points was confirmed; budget authority has been confirmed or a budget conversation is scheduled within 14 days.
The second version eliminates the ambiguity. A new rep knows exactly what to check and exactly what decision to make. The consistency this produces across the whole team is what makes pipeline data reliable.
An SOP without a clear definition of done is incomplete. The person executing needs to know not just what to do but when they are finished.
Wrong:
Complete the follow-up sequence.
Right:
The process is complete when: (1) the opportunity record is updated in the CRM with call notes and any field changes, (2) the follow-up task is scheduled with the correct date, and (3) the follow-up email has been sent and a copy is logged in the CRM activity section.
A definition of done serves two purposes: it tells the executor when to stop, and it tells the manager what to check. Both are necessary for a process to be consistently followed.
Before finalizing any SOP, give the document to someone who was not involved in building it and ask them to execute the process using only the SOP as a guide, no questions allowed. Watch where they get stuck. Watch where they make assumptions. Watch where they do something differently than you intended.
Every one of those moments is a gap in the document. Address the gaps before the SOP is considered final.
Common gaps the transferability test surfaces:
An outdated SOP is worse than no SOP. It teaches people to do the wrong thing, erodes trust in the documentation system, and makes the next update harder because now you have to figure out what the current reality is before you can document it.
The update cadence:
The process change protocol:
When a decision changes how a revenue process works, updating the relevant SOP is a required step in implementing that change, not an afterthought to be handled later. Build this into how decisions about process changes get implemented.
The named owner:
Every SOP needs one named person who is responsible for knowing when it needs updating and making sure the update happens. Without a named owner, SOP maintenance falls into the category of everyone's responsibility, which means nobody's.
Write or rewrite your most critical revenue SOP this week:
Related: What Are SOPs | The SOP Debt Problem
