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. If you are still making the case internally for why documentation is worth the investment, the SOP debt problem covers what undocumented revenue processes are already costing you.
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.
If you want the broader context on what SOPs do for a revenue business before getting into format, what SOPs actually do and why growing companies need them before they think they do is worth reading first.
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.
A 90-minute diagnostic that scores all nine engines driving your revenue. Walk away with a clear picture of what's working, what's leaking, and where to focus first.
Book Your DiagnosticAn 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. What makes an SOP actually transferable covers the full criteria if you want to pressure-test your draft against the standard.
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. Where to store SOPs so the team actually uses them is the practical companion question once the SOP is written.
Write or rewrite your most critical revenue SOP this week:
If you want ThriveSide to run the SOPs engine diagnostic across your revenue operations and identify the highest-risk documentation gaps, book a RevOps Strategy Session.
Related: What Are SOPs | The SOP Debt Problem
