← All posts

RevOps Playbook Templates: SOPs for the 10 Most Common GTM Processes

Jordan Rogers·

The process that lives in someone's head is the process that breaks first

Every RevOps team has the same vulnerability: critical processes that only one person understands. The lead routing logic that lives in a senior ops person's head. The territory rebalancing cadence that one analyst runs manually every quarter. The forecasting roll-up that relies on a specific sequence of spreadsheet tabs that nobody else has been trained on.

When that person goes on vacation, switches roles, or leaves the company, the process breaks. Not because it was bad, but because it was never documented.

SiriusDecisions research found that organizations with documented, repeatable processes across the revenue cycle achieve 15-20% higher win rates than those operating on institutional knowledge alone. The reason is straightforward: documented processes can be audited, improved, and scaled. Undocumented ones can only be repeated by the person who invented them.

This post provides SOP templates for the ten GTM processes that revenue operations teams run most frequently. Each template includes the trigger, the owner, the steps, the output, and the cadence. They are designed to be adapted, not copied verbatim. Your version should reflect your specific systems, team structure, and stage of growth.


What makes a good RevOps SOP

Before diving into templates, a quick framework for what separates useful SOPs from shelf-ware.

Trigger-based, not calendar-based. The best SOPs define what triggers the process, not just when it runs. "Run data hygiene monthly" is a calendar reminder. "When duplicate rate exceeds 5% or lead-to-account match rate drops below 80%, initiate data hygiene cycle" is a trigger-based SOP that runs when it actually matters.

Owner and RACI defined. Every SOP needs a single owner, not a committee. Research from McKinsey on operational maturity consistently shows that unclear ownership is the primary reason processes break down, not lack of tools or talent.

Inputs and outputs specified. If the SOP requires data from Salesforce, say which report. If it produces a deliverable, specify format and distribution. Ambiguity in inputs and outputs is where most process documentation fails.

Version-controlled. SOPs should have a last-updated date and a change log. A process document from 18 months ago that references a tool you no longer use is worse than no document at all, because someone might follow it.


1. Lead routing and assignment

Trigger: New lead created in CRM (inbound form fill, enrichment complete, manual creation)

Owner: RevOps lead or marketing ops manager

Cadence: Continuous (real-time or near-real-time)

Steps:

  1. Lead enters CRM and triggers enrichment (firmographic, technographic data populated)
  2. Lead-to-account matching runs to check for existing account ownership
  3. Lead scoring evaluates against ICP criteria and engagement signals
  4. Routing rules evaluate in priority order: named account match, territory match, skills-based match, capacity-based assignment
  5. Lead assigned to owner; notification sent via CRM or Slack integration
  6. SLA timer starts for speed-to-lead tracking

Output: Assigned lead with audit trail showing which rule matched and why

Escalation: If no rule matches or assignment fails, lead goes to fallback queue with alert to RevOps

For a deeper breakdown of routing models, see our guide to lead routing best practices. If you are evaluating whether your current routing is working, the lead routing audit checklist covers the diagnostic questions worth asking.


2. Territory planning and rebalancing

Trigger: Quarterly business review, rep attrition/hiring exceeding 15% of team, or account distribution imbalance exceeding 20% variance from target

Owner: RevOps lead or sales ops analyst

Cadence: Quarterly review; ad-hoc rebalance as triggered

Steps:

  1. Pull current territory assignments and account distribution from CRM
  2. Calculate workload index per territory (accounts, weighted pipeline, historical conversion rates)
  3. Identify imbalanced territories using variance threshold (typically greater than 15-20% deviation from median)
  4. Model rebalancing scenarios using territory optimization criteria
  5. Validate proposed changes against quota alignment to avoid mid-quarter disruption
  6. Get sign-off from sales leadership on proposed changes
  7. Implement in CRM with effective date; update routing rules to match

Output: Updated territory map, account assignments, and routing rule changes documented

For the full checklist, our territory planning checklist covers data prep through implementation in detail.


3. Pipeline stage management and hygiene

Trigger: Weekly cadence (pipeline review prep) plus automated alerts for stale deals

Owner: RevOps analyst or sales ops manager

Cadence: Weekly review; daily automated monitoring

Steps:

  1. Run pipeline age report: flag deals exceeding stage-specific time thresholds (e.g., Discovery greater than 21 days, Proposal greater than 14 days)
  2. Identify pipeline coverage ratio by segment and rep; flag any below 3x target
  3. Review stage conversion rates for trailing 90 days; compare against historical benchmarks
  4. Generate stale deal list for sales managers to review in 1:1s
  5. Validate that all Stage 3+ deals have required fields populated (next step, close date, decision maker identified)
  6. Update pipeline management dashboard with current week's data
  7. Distribute pre-read to sales leadership 24 hours before pipeline review meeting

Output: Pipeline health scorecard, stale deal action list, conversion rate trends

Escalation: If pipeline coverage drops below 2.5x for any segment, alert VP of Sales and RevOps leadership


4. Sales forecasting roll-up

Trigger: Weekly forecast submission deadline (typically Monday or Tuesday)

Owner: RevOps lead or FP&A partner

Cadence: Weekly submission; monthly executive review

Steps:

  1. Reps update opportunity fields in CRM: stage, close date, amount, forecast category (commit, best case, pipeline)
  2. Sales managers validate rep forecasts and submit manager-level override where warranted
  3. RevOps pulls automated forecast using weighted pipeline methodology as baseline
  4. Compare rep forecast, manager forecast, and algorithmic forecast; flag variances exceeding 15%
  5. RevOps consolidates into company-level forecast by segment, product line, and time period
  6. Forecast accuracy tracked against actuals at close of each period; historical accuracy trends reviewed quarterly

Output: Weekly forecast summary with variance analysis; monthly accuracy scorecard

The most common forecasting failure is relying on a single methodology. Our sales forecasting methods guide covers when to layer multiple approaches and how to calibrate them against each other.


5. CRM data hygiene cycle

Trigger: Monthly cadence or when data quality metrics fall below thresholds (duplicate rate above 5%, enrichment coverage below 70%, field completion below 80%)

Owner: RevOps data analyst or marketing ops manager

Cadence: Monthly full cycle; continuous monitoring via automation

Steps:

  1. Run data quality audit: duplicate rate, field completion rates, enrichment coverage, decay rate
  2. Execute deduplication logic (automated merge for high-confidence matches; manual review queue for ambiguous)
  3. Run enrichment workflows to backfill firmographic and technographic gaps
  4. Validate picklist values against governance standards; flag non-standard entries
  5. Archive or delete records meeting criteria (e.g., bounced email plus no activity in 12 months)
  6. Update data quality dashboard and distribute scorecard to stakeholders
  7. Log changes in governance changelog for audit trail

Output: Data quality scorecard, deduplication summary, enrichment coverage report

For the complete framework on building a sustainable data hygiene practice, see our CRM data hygiene guide. The cost of skipping this is real: research from Experian shows companies lose up to 12% of revenue due to poor data quality.


6. Lead lifecycle stage management

Trigger: Continuous (lifecycle stage transitions happen in real-time based on lead behavior and sales actions)

Owner: Marketing ops manager, with RevOps governance

Cadence: Continuous automation; quarterly definition review

Steps:

  1. Define lifecycle stages with specific, measurable entry criteria: Raw, MQL, SAL, SQL, Opportunity, Customer
  2. Build automation rules for forward transitions (e.g., MQL triggered by lead score threshold plus behavioral trigger)
  3. Build automation rules for backward transitions (e.g., SQL reverts to MQL if no activity in 30 days)
  4. Implement recycling logic for leads that stall: return to nurture with reason code
  5. Track lifecycle velocity by source, segment, and campaign
  6. Review lifecycle definitions quarterly with marketing and sales leadership; adjust criteria based on conversion data

Output: Lifecycle stage waterfall report, velocity by segment, recycling rate trends

The biggest failure here is treating the lifecycle as linear. Our lead lifecycle management guide covers why the funnel is a useful metaphor but a terrible operational model.


7. Customer onboarding handoff

Trigger: Opportunity marked closed-won in CRM

Owner: CS ops manager or RevOps lead

Cadence: Per-deal (triggered by close event)

Steps:

  1. Closed-won triggers automated notification to CS team with deal summary (ARR, products, key stakeholders, custom requirements)
  2. Account ownership transfers from AE to CSM based on assignment rules (segment, product, capacity)
  3. CSM receives structured handoff document: customer goals, success criteria, technical requirements, timeline commitments made during sales
  4. Onboarding kickoff scheduled within SLA window (typically 48-72 hours of close)
  5. Onboarding milestones tracked against time-to-value benchmarks
  6. 30/60/90-day check-in cadence initiated with health score monitoring

Output: Completed handoff document, onboarding timeline, health score baseline

Escalation: If kickoff not scheduled within SLA, alert CS leadership and account executive


8. QBR preparation and execution

Trigger: 3 weeks before quarter-end (allows time for data collection and analysis)

Owner: RevOps lead

Cadence: Quarterly

Steps:

  1. Pull performance data: quota attainment by rep and segment, pipeline conversion rates, key metrics and KPIs
  2. Calculate territory health metrics: coverage ratios, account distribution, workload balance
  3. Run win/loss analysis: top loss reasons, competitive displacement, deal cycle trends
  4. Compile tech stack utilization data: tool adoption rates, integration health, cost per seat
  5. Draft QBR deck with standardized template: performance summary, pipeline outlook, operational health, strategic recommendations
  6. Pre-circulate data pack to sales, marketing, and CS leadership 5 business days before QBR
  7. Facilitate QBR session; document action items with owners and deadlines
  8. Track action item completion at weekly leadership meetings until next QBR

Output: QBR deck, action item tracker, performance benchmarks for next quarter


9. Tech stack evaluation and procurement

Trigger: Contract renewal approaching (90 days out), new functional requirement identified, or annual tech stack review

Owner: RevOps lead with IT partnership

Cadence: Annual comprehensive review; as-needed for new requirements

Steps:

  1. Document current state: tools in use, contract terms, cost per seat, adoption rates, integration dependencies
  2. Identify gaps and overlaps: functions not served, tools with overlapping capabilities, underutilized licenses
  3. Define requirements for any new evaluation: must-have features, integration requirements, budget constraints, build vs. buy criteria
  4. Vendor evaluation: shortlist 2-3 options, run structured demo process with scoring rubric
  5. Reference checks with peers at similar stage and scale (not vendor-provided references)
  6. Negotiate terms with procurement; ensure contract includes data portability and API access clauses
  7. Build implementation plan with phased rollout, training schedule, and success metrics
  8. Track adoption at 30/60/90 days post-implementation

Output: Tech stack map, vendor evaluation scorecard, implementation plan, adoption dashboard


10. Sales compensation and quota deployment

Trigger: Annual planning cycle (typically Q4 for following year) or mid-year adjustment triggered by significant headcount or territory changes

Owner: RevOps lead with finance and sales leadership

Cadence: Annual with quarterly check-ins

Steps:

  1. Analyze prior year comp plan effectiveness: quota attainment distribution, OTE achievement, accelerator utilization, attrition correlated with comp
  2. Model new quotas using bottoms-up methodology: territory capacity, historical conversion, pipeline assumptions
  3. Validate quotas against territory design to ensure alignment between territory potential and individual targets
  4. Design compensation structure: base/variable split, accelerators, SPIFs, clawback provisions
  5. Build financial model: total comp expense at various attainment scenarios (80%, 100%, 120%)
  6. Get sign-off from CFO, CRO, and VP Sales
  7. Communicate plans to reps with clear documentation: how quotas were calculated, what changed from prior year, how accelerators work
  8. Track quota attainment monthly; flag reps below 60% pacing at mid-quarter for intervention

Output: Comp plan document, quota assignments by rep, financial model, monthly attainment tracker


Building the playbook: where to start

You do not need all ten SOPs documented before any of them deliver value. Start with the two or three that cause the most pain when they break or the most confusion when someone asks "how does this work?"

For most teams, that means starting with lead routing, pipeline hygiene, and forecasting. These three processes touch every function, run at high frequency, and are the first to break when someone leaves or a system changes.

A few principles for building out your playbook:

Store SOPs where work happens. If your team lives in Notion, put them in Notion. If they live in Confluence, put them there. A beautifully formatted Google Doc that nobody can find is not documentation.

Assign ownership, not authorship. The SOP owner is not necessarily the person who writes it. The owner is the person responsible for keeping it current and accurate. When the process changes, the owner updates the document. This is the only way SOPs stay alive past their initial creation.

Review quarterly, not annually. A data strategy or territory plan that was accurate in January may be outdated by April. Build SOP review into your QBR cadence so that documentation stays in sync with how you actually operate.

Version control matters. Every SOP should have a last-updated date visible at the top. When someone follows a procedure and gets unexpected results, the first question should be "is this the current version?" If the answer is not immediately obvious, your documentation system needs work.


From playbooks to systems

SOPs document how things work today. The next step is encoding those processes into systems that execute them automatically: routing rules that assign leads without manual intervention, territory models that rebalance based on data instead of gut feel, and pipeline automation that enforces stage criteria instead of relying on rep discipline.

At RevenueTools, we are building the operational layer that turns these playbooks into production systems. Routing, territory planning, and pipeline execution infrastructure designed by operators who have written (and rewritten) these exact SOPs at multiple companies. See what launches April 14th.

Purpose-built tools for RevOps teams

Cross-channel routing and territory planning, built by operators.

Learn more