-
1
Lock the seven required fields every SOP must carry
Start by writing the field list that every SOP in the library will inherit. The seven fields that cover a sales ops SOP cleanly are trigger, owner, inputs, steps, outputs, review cadence, and exception handling. Trigger is the event or signal that starts the work. Owner is the named role, not a person, that is accountable for the procedure. Inputs are the data, records, or approvals the owner needs before they begin. Steps are the numbered imperative actions, under ten per SOP. Outputs are the states that must be true when the procedure ends. Review cadence is how often the SOP is re-walked and refreshed. Exception handling is the two or three edge cases that break the main path and the escalation each one takes. Lock the field list before you write a single SOP. If a field feels optional, cut it, because an optional field becomes a blank field inside six weeks.
- Write the seven field list in one page and route it to the frontline manager and sales leader for sign-off
- Define each field in one sentence so writers know exactly what belongs inside
- Reject optional fields in version one of the template; every field is required or it is not in the template
- Pin the field list to the top of the template so writers see the contract before they type
Tip: Resist the pull to add fields like 'KPI', 'stakeholders', or 'related playbook' to version one. Every optional field becomes a blank field in half the SOPs, and the blanks teach writers the template is a suggestion, not a contract.
-
2
Write each field with the writer rules that keep SOPs scannable
Fields on their own do not stop drift. Writer rules per field do. For trigger, require a single sentence that names the event or signal, not a paragraph. For owner, require a role name from the sales org chart, not a person's name, so the SOP does not break when someone changes seats. For inputs, require a bulleted list of three to seven items, each a noun phrase. For steps, require numbered imperative verbs, under ten total, each actionable in under a minute. For outputs, require a bulleted list of state statements like 'opportunity.stage is Discovery' or 'account.owner is set'. For review cadence, require one of quarterly, monthly, or on-change, picked up front. For exception handling, require a short list of two or three edge cases, each with a named escalation. Writer rules make every SOP in the library readable in under 90 seconds.
- Set a hard cap of 10 steps per SOP and reject drafts that run longer; split into two linked SOPs instead
- Require role names in the owner field, never person names, so SOPs survive seat changes
- Require state statements in outputs so adoption can be measured against CRM data later
- Pick one of three review cadences at write time (quarterly, monthly, on-change); never leave it blank
Tip: The 90-second rule is the test for whether a writer rule is working. If a rep cannot read an SOP written against the template in under 90 seconds and know what to do, the rules are too loose. Tighten the step count, trim the inputs, or split the SOP.
-
3
Pilot the template on two real processes before you publish it
A template that works on paper falls apart the first time a real process meets it. Pick two live sales ops processes, ideally one easy motion like inbound lead response and one messy motion like pricing and discount approval, and have the process owners draft against the template. The job in the pilot is not to ship those two SOPs, it is to find the places the template bends or breaks. Watch for fields that the writers skip, fields that always need the same workaround, and processes that force a step count over the cap. Collect every workaround and every skipped field in one document. If three or more writers hit the same gap, the template needs the fix, not the writers. If one writer hit the gap, the writer needs training, not the template.
- Pick one easy motion and one messy motion to stress the template in both directions
- Have the process owners draft against the template, not against a blank page or an old doc
- Record every field skipped, every workaround used, and every step count overflow in one shared doc
- Revise the template only where three or more writers hit the same gap; otherwise train the writer
-
4
Design the review cadence rules so SOPs do not go stale
Most SOP libraries die between months three and six because nothing in the template forces a review. Fix that at the template level. The review cadence field has to pick one of three values at write time: quarterly for operational motions that run every day or every week, monthly for new motions still finding their shape, and on-change for policy-driven motions like discount thresholds that only change when a decision changes. Pair each cadence with a visible review date stamp on the SOP, a named reviewer role, and a lightweight review action: re-walk the SOP with two people who run the motion, check the adoption data if it exists, and update in one tracked-changes pass. Bake the cadence rules into the template so every SOP that writes against the template inherits them automatically.
- Define the three cadences (quarterly, monthly, on-change) and the kind of SOP each one fits
- Require a visible last-reviewed stamp on every SOP so staleness is obvious at a glance
- Require a named reviewer role on every SOP so no review ever falls to nobody
- Schedule the quarterly review windows on the ops calendar at the start of the year
Tip: If a writer wants to pick 'annual' as a review cadence, say no. Annual review on a sales process is a library that is wrong eight months out of twelve, because pricing, segmentation, and competitors move faster than that.
-
5
Design the exception handling block so edge cases do not derail the main path
SOPs that try to document every edge case inside the step list become unreadable. Exception handling is where edges go instead. In the template, require every SOP to list two or three exceptions in a dedicated block at the bottom of the page. Each exception has three pieces: the trigger that identifies the edge case, the branch the owner takes when they hit it, and the named escalation if the branch does not resolve. Keep the main step list clean and focused on the happy path. If a writer tries to add a fourth or fifth exception, that is a signal the process has two different flavors and should be split into two SOPs, each with its own cleaner exception block. The exception block gives reps a predictable place to look when the main path breaks instead of hunting through the steps for a conditional.
- Reserve 2-3 exception slots per SOP, no more, so the main path stays the main path
- Require trigger, branch, and escalation for every exception so a rep knows exactly what to do
- Split any SOP that needs more than 3 exceptions into two SOPs, each with its own clean block
- Name the escalation by role, never by person, so the SOP survives seat changes
-
6
Publish the template to the internal wiki with worked examples
A template that lives in a shared doc nobody can find is a template nobody uses. Publish the template to the internal wiki in a dedicated SOP library space with a stable URL, a one-page explainer, and two or three worked examples showing the template filled out against the pilot processes. The worked examples do more teaching than the template itself, because writers copy structure faster from an example than from a definition. Link to the template from the home page of the SOP library, from the RevOps hub, and from the new-hire ramp plan for sales ops. Every new SOP must link back to the template version it was written against so future reviewers can see the contract that governed the write.
- Publish to one dedicated wiki space with a stable URL that never changes
- Attach 2-3 worked examples using the pilot processes so writers can copy structure
- Link to the template from the SOP library home page, the RevOps hub, and the ramp plan
- Require every new SOP to cite the template version it was written against in a footer
-
7
Train the RevOps and enablement writers on the template in a live session
A template that lands with a wiki announcement never lands. Run a 60-minute live training with every RevOps and enablement writer who will author SOPs. Walk the seven fields, read the writer rules, and have each writer draft a short SOP against the template in the room on a real process they already know. Collect the drafts, mark the top three issues across the room, and run a 10-minute debrief on the fixes. The in-room draft is what moves the template from theory to behavior. Add the training to the onboarding plan for every new RevOps hire so the template keeps landing even as the team grows. Record the live session and embed it inside the template page so future writers hit the training before they hit the blank page.
- Run a 60-minute live training with every writer who will author SOPs
- Have each writer draft a short SOP against the template in the room using a real process
- Mark the top 3 issues across the room and debrief fixes in the last 10 minutes
- Record the session and embed it in the template page so new writers see it on day one
Tip: Add a hard rule that no SOP ships to the library until the author has run one SOP through the template in a live session. Writers who learn the template by doing produce cleaner first drafts than writers who learn it by reading, every time.
-
8
Review the template itself quarterly, not just the SOPs written against it
The template is a living contract and it drifts just like the SOPs do. Lock in a quarterly template review that runs alongside the SOP library refresh. Pull the library, scan every SOP for fields that are consistently blank, workarounds that writers added in the exceptions block, and step counts that are brushing against the cap. Those three signals are where the template is bending under real use. Make one surgical change per quarter at most. Two or more changes per quarter break backward compatibility and force a re-review of every SOP already written against the template. Publish the diff on the template page with a visible changelog, update the worked examples to match, and route the new version to every writer in a short Loom so the change lands as a verbal event, not a silent edit.
- Pull every SOP each quarter and scan for blank fields, exception-block workarounds, and step overflow
- Make one surgical template change per quarter at most to protect backward compatibility
- Publish the diff and a visible changelog on the template page the day the new version ships
- Route the new version to every writer in a short Loom so the change lands verbally, not silently
