RevOps

RevOps (revenue operations) is the practice of running marketing, sales and customer success as one revenue process instead of three relay teams that each keep their own numbers. It gives those teams one set of funnel definitions, one trusted customer record, explicit hand-offs with service levels, one forecast, and revenue metrics defined once, so leaders can see where revenue is created, where it leaks and what to fix.

Most of the work is unglamorous: agreeing what a “qualified lead” or an “opportunity” is, deciding which system holds the truth about each customer object, routing a new lead in minutes rather than days, and making sure the number given to the board on Monday is the number Finance books at quarter end.

Written for beginners, RevOps practitioners, CRM and data engineers, go-to-market leaders, and the Finance partners who share the numbers. Sources were last verified on 2026-10-23.

Marketing, sales and customer success operations exist in some form wherever a company sells and renews. RevOps asks a different question: do those pieces form one system? The middle column lists typical symptoms; it describes no real firm.

Analyst evidence describes the same pain. A Forrester analyst reports that in Forrester’s 2024 survey, Asia-Pacific B2B leaders cite “misaligned technology, conflicting metrics, and inadequate processes” as their key operations obstacles.^[1] A Gartner analyst said in 2021 that functional silos handing clients from one function to the other, “using different technologies, people and processes, are a barrier to revenue growth”.^[2] These are analysts’ framings, not measurements of your business. The practical test: can you answer, with one number each, how many qualified opportunities you created last quarter, how long new leads waited for a first touch, and how much recurring revenue you kept?

• Not an org chart. Forrester calls revenue operations “a commercial execution strategy, not an organizational structure”.^[3] Its analysts list “it requires headcount centralization” among nine myths and describe successful structures that span “a completely decentralized model” to “a structurally unified centralized operations structure”.^[4]
• Not SalesOps renamed. A RevOps team that only runs the sales forecast and the CRM for sellers is sales operations with a new name. The difference shows in scope: marketing-to-sales and sales-to-success hand-offs, and post-sale revenue.
• Not the chief revenue officer. In CNBC’s report on LinkedIn’s 2023 list, the job description says the head of revenue operations position “is also often labeled as ‘chief revenue officer’ or ‘head of revenue management’”.^[5] The first two are different jobs: a CRO owns the revenue target and the teams that pursue it; a RevOps leader owns the system those teams run on. Confusing the two puts the referee on one of the teams.
• Not revenue management, the third title in that description. Revenue management is the pricing and availability discipline of airlines and hotels; the INFORMS Revenue Management and Pricing Section frames the question as “what price do I offer when the next customer walks in the door”.^[6]
• Not healthcare revenue cycle management. In healthcare, the revenue cycle “comprises all the activities that lead to payment for services provided” (registration, coding, claims, collections);^[7] that belongs to HealthOps.
• Not revenue recognition. Bookings, ARR and pipeline are operating measures; recognised revenue follows accounting standards such as IFRS 15 and the US Topic 606.^[8] RevOps feeds Finance; it does not replace the accountants.

The practice is older than the label. Sales operations, marketing operations and customer success operations existed as separate teams long before “RevOps” became a job title. Only milestones traceable to sources are listed here.

Two cautions. The Gartner figure is a prediction; no source opened for this page measures whether it came true. And the LinkedIn ranking measures growth in job titles, which says the label spread quickly, not that the work is new.

• Go-to-market (GTM): the teams and systems that find, win and keep customers: marketing, sales, customer success, partners.
• Lead, contact, account: a person not yet qualified; a person linked to a customer organisation; the organisation itself. In Salesforce, a qualified lead can be converted “to an account, contact, and, optionally, an opportunity”.^[18]
• Lifecycle stage: where a person or company is in the customer journey. HubSpot’s defaults are Subscriber, Lead, Marketing Qualified Lead, Sales Qualified Lead, Opportunity, Customer, Evangelist and Other, and its default automatic updates only move the stage forward.^[19]
• MQL, SAL, SQL: a lead marketing judges ready for sales; a lead sales has accepted for follow-up; a lead sales has qualified as a potential customer. Names and criteria differ by company; that is why RevOps writes them down.
• Opportunity and its stages: a potential deal with an amount, a close date and a stage; each stage needs entry and exit criteria (what must be true to enter it and to leave it).
• Buying group: the several people who make or influence a purchase. Forrester’s 2021 Waterfall release states that “95% of current purchases involve three or more people across two or more departments”.^[11]
• Hand-off SLA: a written service level between two teams, for example: sales accepts or rejects an MQL within two working days.
• Bookings, ACV, TCV: the value of contracts signed in a period; annual contract value; total contract value. Bookings and revenue “aren’t the same thing”.^[20]
• ARR / MRR: annual / monthly recurring revenue, an operating measure, not accounting revenue (defined in metrics).
• GRR / NRR: gross / net revenue retention: revenue kept from existing customers excluding / including expansion.
• CAC, CAC payback, LTV: cost to acquire a customer; months of gross margin to recover it; lifetime value of a customer.
• Forecast category: a seller’s or manager’s judgement of a deal for the forecast, such as Pipeline, Best case, Commit; HubSpot’s forecast tool, for one, defines its categories by order of likelihood rather than by name.^[21] (SalesOps owns the category rules.)
• Forecast of record and renewal base: the one forecast version, frozen at an agreed snapshot, that goes to Finance and is scored later; and the contracts whose term ends in a period, with their ARR, renewal date and risk.
• Role and system abbreviations: SDR (sales development representative, who qualifies leads and books meetings); AE (account executive, who owns a deal to signature); CSM (customer success manager: onboarding, adoption, renewal); CoE (centre of excellence, a shared team serving several functions); FP&A (the Finance team that owns plans and forecasts); CPQ (configure, price, quote: software that builds quotes and orders).
• System of record (SoR): the one system whose value wins for a given object or field.

Hold three pictures at once:

1. A relay race. The customer is the baton; marketing, sales and success are runners; races are lost in the hand-off zones. RevOps marks the zones, times them and makes someone responsible for every dropped baton.
2. A ledger. Every team writes to the same book of definitions and records. A “qualified opportunity” or “ARR” has one entry, one owner and a history of changes.
3. A control loop. The forecast is a measurement of the system’s future output. Comparing forecast with actual, every week and every quarter, tells you whether the system is understood.

Most RevOps failures are one of these pictures breaking: a dropped hand-off, two ledgers, or a loop nobody closes.

RevOps is the integrator; most neighbours are specialists that own one segment of the same customer journey. The figure labels the main artefact on each two-way boundary; the table names the owners.

%%{init: {"flowchart": {"wrappingWidth": 140, "nodeSpacing": 14, "rankSpacing": 34}}}%%
flowchart LR
  BZ["BizOps: targets and cadence"] --> R
  PV["PrivacyOps: consent and objections"] -.-> R
  CX["CXOps, SupportOps: customer signals"] -.-> R
  R["RevOps: definitions, hand-offs, forecast, stack decisions"]
  R <-->|"SLA report"| MO["MarketingOps: campaigns, scoring"]
  R <-->|"forecast calendar"| SO["SalesOps: quotas, new-business call"]
  R <-->|"renewal base"| CO["CustomerOps: health, renewal call"]
  R -->|"field map"| MT["MarTechOps: stack plumbing"]
  R -->|"definition cards"| AN["AnalyticsOps: metric layer"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class R core
  class BZ,MO,SO,CO,MT,AN,PV,CX neutral

This charter is this Atlas’s proposal; no official RevOps manifesto exists.

Mission. Make the revenue process one measured system, from first signal to renewal, that teams trust and leaders can steer.

Principles.

1. Capabilities before boxes. Decide what must work (definitions, data, routing, forecast) before deciding who reports to whom; Forrester’s analysts argue the structure should be tailored.^[4]
2. Define once, use everywhere. Each stage, field and metric has one definition, one owner and a version history.
3. Every hand-off has an owner, a clock and an exit. Accept, reject or recycle; never leave a record waiting.
4. One system of record per object. Conflicts are settled by the decision log, not by whoever synced last.
5. Forecasts are measurements, targets are decisions. Keep them separate and score the forecast.^[22]
6. Measure from the customer’s side as well. Response time and time to value matter as much as internal conversion.
7. Change the system on a cadence. Batch, test and announce changes to fields, stages and routing.

Non-goals. RevOps does not own quotas or territories, campaign creative, customer success playbooks or accounting policy. It does not “own revenue”; the CRO and the business own the number.

Invariants (must stay true). Every open opportunity has an owner, a stage that meets its entry criteria, an amount and a close date in the future. Every MQL is actioned within the SLA. Every contract ending within 120 days has a renewal record. The ARR in the board deck reconciles to the finance model. No metric definition changes without a version note.

Forrester’s definition names four ingredients: data, processes, technology and talent.^[3] This page adds a fifth, definitions, because in practice that is where most teams start, and it is the part no tool supplies.

Common roles (titles vary): head of RevOps (owns definitions, operating cadence and stack decisions); GTM systems administrators and architects (CRM, automation, integrations); revenue analysts (funnel, forecast, retention analysis); deal desk and order management (often in SalesOps); enablement (teaches the process). GitLab’s handbook documents one arrangement: its Field Operations group contains, among others, Sales Operations, Deal Desk, Sales Commissions, Data Intelligence, Sales Systems, Field Enablement and Customer Success Operations, and states that “Data Intelligence (DI) is a part of Field Operations reporting to Revenue Operations”.^[23] One company’s arrangement, not a template.

Three structures appear in practice, and Forrester’s analysts suggest the hybrid may be ideal for many, with a centre of excellence for “data, analytics, and technology”.^[4]

RACI for the decisions RevOps is accountable for (R = responsible, A = accountable, C = consulted, I = informed). This is a proposal; adapt names to your organisation.

Two points deserve comment. RevOps defines, compiles and scores the forecast of record, but the CRO is accountable for its committed value: the referee does not score the goals. And Finance is accountable for metric formulas that reach investors, because those numbers sit next to audited financials.

A recurring-revenue business has two halves: winning the customer, and keeping and growing them. Winning by Design presents its “bow tie” as “a common language and data model for recurring revenue businesses”^[24]; Forrester’s 2021 Waterfall likewise treats renewal, cross-sell and upsell as opportunity types.^[11] The figure uses generic stage names.

flowchart TB
  subgraph ACQ["Acquire"]
    A1["Target accounts and buying groups"] --> A2["Engaged: MQL or hand-raise"]
    A2 --> A3["Accepted and qualified"]
    A3 --> A4["Opportunity: stages with exit criteria"]
  end
  A4 --> W{"Closed won?"}
  W -- "No" --> NR["Closed lost: reason, nurture, recycle"]
  W -- "Yes" --> H["Sales-to-success hand-off"]
  subgraph KEEP["Keep and grow"]
    H --> K1["Onboard to first value"]
    K1 --> K2["Adopt and renew"]
    K2 --> K3["Expand: upsell and cross-sell"]
  end
  K3 -.-> A4
  NR -.-> A2
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class A1,A2,A3,A4,H,K1,K2,K3 core
  class W decision
  class NR risk

RevOps governance is mostly a calendar and a set of decision rights. A proposed cadence:

GitLab documents a similar habit: its Field Operations team delivers changes “in a batched, bi-weekly release cadence”,^[23] and its field communications team grades each change high, medium or low impact and scales the announcement to the grade — sales-stage launches are high impact, “new high-priority fields” medium, a new field on a page low.^[25]

Escalation. Hand-off disputes (sales rejects too many MQLs; success refuses an under-documented hand-off) go first to the weekly health check, then to the functional leaders, then to the CRO and CMO. A definition dispute is never settled by editing the field: it goes to the definitions council.

The architecture question in RevOps is less “which tools” than “which system is the truth for which object, and how do the others learn about changes”. The figure shows a common shape for a B2B subscription business.

%%{init: {"flowchart": {"wrappingWidth": 150, "nodeSpacing": 22, "rankSpacing": 34}}}%%
flowchart TB
  MAP["Marketing automation: engagement, consent"] <--> CRM
  CS["CS platform: health, success plans"] <--> CRM
  CRM["CRM: leads, contacts, accounts, opportunities"] --> CPQ["CPQ: quotes, orders"]
  CPQ --> BILL["Billing: subscriptions, invoices, ARR"]
  BILL --> CRM
  PROD["Product: usage events"] --> WH
  CRM --> WH["Warehouse: joined history and snapshots"]
  BILL --> WH
  WH --> BI["Metric definitions and dashboards"]
  WH -.-> CRM
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  class CRM,BILL core
  class MAP,PROD,CS,CPQ neutral
  class WH,BI decision

Write the decisions down as a table. This example is illustrative; your systems will differ.

Three design rules follow. Read-only copies are labelled as copies (a sales rep cannot edit ARR in the CRM). Derived scores come from one place (a score computed in the warehouse is written back, not recomputed in three tools). Snapshots are kept weekly, because most CRM reports show the current state and you cannot measure forecast accuracy or stage slippage without history.

The sequence below follows one buying group through the hand-offs that RevOps governs. Each arrow that crosses a team boundary carries a clock.

sequenceDiagram
  participant M as Marketing
  participant S as SDR
  participant A as Account exec
  participant C as Success
  M->>S: MQL routed (clock 1)
  S->>S: Accept, reject or recycle
  S->>A: Qualified meeting (clock 2)
  A->>A: Stages with exit criteria
  A->>C: Won deal and checklist (clock 3)
  C->>C: Onboard to value (clock 4)
  C->>A: Expansion signal (clock 5)
  C->>C: Renewal call before term end (clock 6)

Happy path. A lead from a known target account fills in a demo form at 10:02; routing assigns an SDR at 10:02; the SDR calls at 10:20 and books a meeting; the account executive accepts the same day and creates an opportunity once the meeting confirms a problem, a buying group and a timeline. The deal closes eleven weeks later; closed-won creates a hand-off task with the success plan fields completed; customer success runs a kickoff within five working days.

Exception paths. RevOps designs for these, because they are where revenue leaks:

Five practices carry most of the value — the stage dictionary, routing and hand-off SLAs, the forecast of record, CRM data quality and stack change control. The playbooks below give the steps; the artefacts and labs in the next part let you try each one.

1. Inventory the current meanings. Pull the stage and status picklists from every system (CRM, marketing automation, CS platform) and ask each team how they report “pipeline”, “qualified” and “customer”. Differences are the backlog.
2. Choose the unit of the funnel. Lead-based funnels count people; opportunity-based funnels count potential deals with a buying group. Forrester argues for the second, reporting that “fewer than 1% of leads convert to closed deals” and describing the shift as moving “from managing individual leads to identifying, prioritizing, and advancing opportunities with connected buying groups”.^[26][27] Many companies keep MQLs as an operational trigger but measure pipeline on opportunities.
3. Write entry and exit criteria for each stage as observable facts (“a meeting held with an economic buyer”, not “good call”). Use Artefact 1 as a template.
4. Encode the rules. Required fields and validation at each stage; forward-only automatic stage changes (HubSpot’s lifecycle automation, for example, only moves stages forward by default).^[19]
5. Publish and teach. One page, linked from every report that uses the stages; examples of borderline cases.
6. Version it. Every change gets a version, an effective date and a note on how history is treated.

Acceptance criteria. Every report labelled “pipeline” uses the dictionary; open opportunities failing entry criteria fall below an agreed level (for example 2%); the dictionary has a named owner. Rollback. Keep the old stage values mapped for one quarter so historical reports still run.

Speed matters because buyers who ask for contact move on. Oldroyd, McElheran and Elkington wrote in Harvard Business Review that “most companies are not responding nearly fast enough” to online leads.^[28] (One author was then chief executive of InsideSales.com, a sales-software vendor; the widely repeated multipliers from that article are behind a paywall and are not used here.)

1. Match before you route. Normalise the email domain and company name, find duplicates, and match the person to an existing account; HubSpot, for instance, deduplicates contacts by email and companies by domain, but not companies created through its API.^[29] A lead from a customer or an active opportunity goes to the existing owner.
2. Order the rules from specific to general and end with a default rule, so no record can fall through.
3. Handle incomplete data explicitly. A record without country or company size goes to an exception queue with an owner, not to a random seller.
4. Distribute fairly and visibly. Round robin skips people who are away; capacity rules are written down. HubSpot’s workflow action, for one, assigns records equally within a team by default, with round robin and load balancing options.^[30]
5. Start the clock. Measure creation-to-first-touch and creation-to-accept for every record, in business hours if your SLA is in business hours.
6. Close the loop. Every MQL ends accepted, rejected with a reason, or recycled; rejection reasons by source go to marketing.

Acceptance criteria. Unassigned leads older than 30 minutes: zero on most days; SLA attainment reported weekly by team. Lab 2 builds a small rule engine with these properties.

A forecast is a measurement of what the system will produce; a target is what the company wants. The forecasting textbook by Hyndman and Athanasopoulos puts it plainly: “setting targets is different from producing forecasts, and the two should not be confused”, and “Forecasters and users should be clearly segregated”.^[22]

In a recurring-revenue business the number Finance and the board need is not the new-business commit alone but the movement of ARR: new business plus expansion minus what is lost at renewal — the bridge Lab 3 builds after the fact, and the split Forrester’s 2021 Waterfall makes when it adds renewal, cross-sell and upsell opportunity types.^[11] RevOps owns the forecast of record: the one version, frozen at an agreed snapshot, that combines the components, goes to Finance and is scored later.

flowchart TB
  P["Weekly snapshots: pipeline, renewal base"] --> F["Component calls by their owners"]
  F --> J["Judgement adjustments with reasons"]
  J --> N["Forecast of record, separate from target"]
  N --> A["Actual ARR movements at period end"]
  A --> E["Error and bias by component and week"]
  E --> C["Owners recalibrate their calls"]
  C --> F
  E --> D["Fix definitions, hygiene, coaching"]
  D --> P
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  class P,F,N,A core
  class J,E,C,D decision

1. Fix the calendar and the snapshot rule. Submission day and cut-off time each week, quarter weeks numbered, and one named snapshot (for example the end of week 4) that becomes the forecast of record. Later versions are kept and scored too.
2. Use one unit for every component. If the board sees ARR, forecast new business, expansion and losses in ARR under the Artefact 2 definition, not bookings for one part and ARR for another.
3. Build the renewal base from billing: every contract whose term ends in the period, by renewal date, with a renewal record and a written risk band. A contract ending without a renewal record is a data defect, not a surprise.
4. Snapshot everything weekly: pipeline, renewal base and each submission; without history there is no accuracy.
5. Document every adjustment. Hyndman and Athanasopoulos note that judgemental adjustments carry biases, and that having to “document and justify” them makes overriding harder.^[22]
6. Score each component and the total every quarter, with the sign stated (this page uses e = actual − forecast; see metrics); errors in the parts can cancel in the total, as Lab 4 shows.
7. Return each bias to its owner. SalesOps recalibrates stage probabilities and commit rules; customer success revisits its risk bands. RevOps does not quietly correct someone else’s call.

The split with the specialists. SalesOps runs the new-business categories, pipeline inspection, the forecast call and its accuracy log by caller and method; customer success runs the renewal review (CustomerOps). RevOps owns the definition of the forecast of record, its snapshots and their retention, the roll-up, and the component scorecard reported to Finance and the board. The CRO is accountable for its committed value.

1. Decide fitness for use: which fields each decision needs (routing needs country and size; forecast needs amount, close date, stage; retention needs contract dates).
2. Make required fields stage-dependent, so early records are light and late records are complete.
3. Run a weekly scorecard: required-field completeness, duplicates, close dates in the past, opportunities without an owner or contact role, accounts without a segment.
4. Fix at the source. Route defects to the record owner with a due date; repeated defects become a validation rule.
5. Merge carefully. Merges are hard to undo; keep a merge log and run them in batches with a backup export. The export is a copy of personal data: store it with restricted access and delete it on a set date.

GitLab describes data governance as including “data definitions, policies, processes and procedures for our data”, with data stewardship formalising accountability for day-to-day procedures.^[31]

1. Request through one intake form (Artefact 5); every change names the records, reports, automations and integrations it touches.
2. Classify impact (high, medium, low) and scale testing and announcements to it, as GitLab does (see operating model).
3. Test in a sandbox on synthetic or masked records that reproduce real routing and reporting cases, and compare before-and-after report totals. A full-copy sandbox holds personal data: limit access, record where it lives and delete it on a set date.
4. Release on a cadence, with notes and enablement, and a rollback plan (old values mapped, automation versions kept).
5. Watch for a week: SLA reports, routing exceptions, integration errors.

There is no formal standard for revenue operations. What exists is a mix of analyst frameworks, consultancy models, vendor conventions, accounting and securities rules, and general forecasting science. Separate them by authority:

The SEC guidance deserves attention even outside listed companies: alongside a key metric it expects “A clear definition of the metric and how it is calculated”, a statement of why management uses it, and, when the method changes, disclosure of the differences and effects and consideration of whether to recast prior periods.^[33] A good discipline for any board deck.

Tool categories matter more than brands; brands change. The examples are illustrative and were checked on 2026-10-18, not endorsed.

Lock-in and maintenance. The expensive lock-in is not the licence; it is years of custom fields, automations and reports that encode your process. Keep a field register and retire unused fields yearly. Vendor categories are also consolidating (see the 2025 row of the timeline); expect product names to move.

Automation is mature for the deterministic parts — routing, field updates, stage validation, hand-off tasks, SLA alerts, renewal reminders. Write those rules down and test them like code. Machine-learning and generative features (predictive lead and deal scores, call summaries, next-step suggestions, forecast predictions) are now common in CRM and forecasting tools. Two governance points apply.

1. A score you cannot inspect still needs a test. HubSpot’s predictive lead scoring, for example, estimates “the probability that your open contacts will close as customers within 90 days”, and its properties “cannot be edited”.^[40] Test such scores the way you test stage probabilities: compare predictions with outcomes using a proper scoring rule such as the Brier score, which “measures the mean squared difference between the predicted probability and the actual outcome”.^[41]
2. Keep humans accountable for commitments. An AI forecast is an input to the submitted number, not the number. Record which source (rollup, model, manager) produced each figure so you can score each one.

Failure modes: scores trained on yesterday’s motion (a new segment or product breaks them); summaries that put words in a customer’s mouth (keep the recording or transcript as the record); and automated outreach that ignores objections recorded in another system (see privacy).

These artefacts belong to an invented company, ExampleCo, a B2B software firm selling annual subscriptions with an SDR team, account executives and customer success managers. Adapt names, numbers and stages; the structure is the point.

Record types. Following the split Forrester’s Waterfall makes between acquisition, renewal, upsell and cross-sell opportunities,^[32] ExampleCo uses three:

“Pipeline” in every ExampleCo report means new-business and expansion opportunities in stages 2 to 5; Discovery is tracked but not counted, and renewals are reported as the renewal base, never as pipeline. That sentence prevents most “two pipeline numbers” arguments.

Example status: syntax-checked YAML, not executed (ExampleCo is fictional; a metrics tool or a review process would consume it).

# metrics.yaml: revenue metric definitions for ExampleCo (illustrative)
version: 3
effective_from: 2026-07-01
owners:
  finance: fpa-lead@example.com     # accountable for formulas shown to the board
  revops: revops-lead@example.com   # responsible for the definitions and data
metrics:
  - id: arr
    name: Annual recurring revenue
    definition: >-
      Annualised value of active subscription contracts at the snapshot date:
      contract value / days in term * 365. Excludes one-off services and usage
      above commitment. Constant currency at start-of-year rates.
    system_of_record: billing
    grain: [customer, snapshot_date]
    changes:
      - version: 3
        date: 2026-07-01
        note: Usage above commitment excluded; history recast back to 2024-07-01.
  - id: grr
    name: Gross revenue retention, 12 months
    formula: (arr_start - contraction - churn) / arr_start
    cohort: customers with arr > 0 at the start snapshot
    excludes: [new customers, expansion]
  - id: nrr
    name: Net revenue retention, 12 months
    formula: (arr_start + expansion - contraction - churn) / arr_start
    cohort: customers with arr > 0 at the start snapshot
  - id: pipeline_created
    name: Qualified pipeline created
    definition: >-
      Sum of amount for new-business and expansion opportunities that entered
      stage 2 (Qualified) in the period, at the amount recorded on entry.
  - id: forecast_of_record
    name: Forecast of record, net new ARR
    definition: >-
      New + expansion - renewal losses (churn and contraction), in contract ARR,
      as submitted at the end of week 4; later versions are kept and scored.
    components: [new, expansion, renewal_losses]
  - id: mql_sla
    name: MQL hand-off SLA attainment
    formula: mqls_actioned_within_2_working_days / mqls_created

The changes list is the part most teams skip and most regret skipping: it lets anyone explain why last year’s NRR in this year’s deck differs from last year’s deck.

Example status: illustrative template.

SERVICE LEVEL AGREEMENT: MQL TO OPPORTUNITY (ExampleCo, version 2, from 2026-07-01)
Parties     Marketing (MarketingOps lead), Sales development (SDR manager),
            Sales (regional VPs). Steward: RevOps.
Marketing   Delivers MQLs that meet the stage dictionary, with source, country
commits     and company size filled. Forecasts MQL volume monthly by region.
SDRs commit First touch within 60 business minutes of routing.
            Accept, reject (with reason code) or recycle within 2 working days.
AEs commit  Accept or reject a qualified meeting within 1 working day;
            create the opportunity in Discovery on the day of the first meeting.
Exceptions  Unassigned > 30 min -> fallback queue owner. Out of office -> skipped
            by round robin. Missing data -> ops-review queue (RevOps, 4 hours).
Reporting   Weekly: SLA attainment, unactioned MQLs, rejection reasons by source.
Review      Quarterly at the definitions council; changes need both VPs.

• Signed order and start date in billing; ARR visible read-only in the CRM
• Buying group with roles: economic buyer, champion, technical owner, users
• The customer’s stated success criteria in their words, and the date they expect them
• Commitments made during the sale (integrations, roadmap items, discounts and their expiry)
• Known risks: competitor still in place, internal opponents, budget timing
• Kick-off scheduled within 5 working days; customer success manager introduced by the account executive

Example status: illustrative template.

GTM CHANGE REQUEST
Title / requester / date:
Problem (what fails today, evidence):
Change type: [ ] stage or lifecycle [ ] field [ ] routing rule [ ] automation
             [ ] integration [ ] new tool [ ] metric definition
Objects, reports, automations and integrations affected:
Teams affected (marketing / SDR / sales / CS / Finance / partners):
Impact class (high: revenue- or customer-impacting; medium: daily work; low: info):
History treatment (recast, map old values, leave):
Test plan (sandbox cases, report totals before/after):
Rollback plan:
Release date (next GTM release) and enablement owner:
Approvals: RevOps systems lead / definitions council (if a definition changes)

Four labs on synthetic data only: bash, Python 3.8 or later, standard library only, no accounts and no cost. Each lab was run on 2026-10-18 exactly as printed (Python 3.8.10, Ubuntu Linux, isolated home directory); the expected outputs are copied from those runs.

Objective. Measure an MQL cohort through acceptance, opportunity and win; find leads that were never actioned; see why a period-based conversion ratio misleads. Prerequisites. bash and Python 3.8+. Time. 20 minutes. Risk. None.

1. Create the folder and the data.

Example status: verified by execution on 2026-10-18 (bash, Linux).

mkdir -p ~/revops-labs/lab1 && cd ~/revops-labs/lab1
cat > mqls.csv <<'CSV'
lead_id,source,mql_date,accepted_date,rejected_date,opp_date,close_date,outcome
L01,webinar,2026-01-05,2026-01-06,,2026-01-20,2026-03-10,won
L02,webinar,2026-01-06,2026-01-07,,2026-01-28,2026-04-02,lost
L03,paid_search,2026-01-08,,2026-01-09,,,
L04,paid_search,2026-01-09,2026-01-15,,,,
L05,content,2026-01-12,2026-01-13,,2026-02-03,,
L06,content,2026-01-14,,,,,
L07,partner,2026-01-15,2026-01-15,,2026-01-22,2026-03-30,won
L08,webinar,2026-01-19,2026-01-21,,,,
L09,paid_search,2026-01-20,,2026-01-21,,,
L10,content,2026-01-22,,,,,
L11,partner,2026-01-26,2026-01-27,,2026-02-16,,
L12,webinar,2026-01-28,2026-02-02,,2026-02-20,2026-04-15,lost
L13,webinar,2026-02-02,2026-02-03,,2026-02-24,,
L14,content,2026-02-04,2026-02-05,,,,
L15,paid_search,2026-02-09,,2026-02-10,,,
L16,partner,2026-02-11,2026-02-11,,2026-02-18,,
L17,content,2026-02-16,,,,,
L18,webinar,2026-02-18,2026-02-19,,,,
L19,paid_search,2026-02-23,2026-02-24,,,,
L20,partner,2026-02-25,2026-02-26,,,,
CSV

2. Save the script as funnel.py.

Example status: verified by execution on 2026-10-18 (Python 3.8.10, standard library).

"""Cohort funnel, hand-off SLA and leakage from MQL records (standard library)."""
import csv
from datetime import date, timedelta
from statistics import median

SNAPSHOT = date(2026, 4, 30)   # data extracted on this date
SLA_DAYS = 2                   # accept or reject within 2 working days (Mon-Fri)

def d(s):
    return date.fromisoformat(s) if s else None

with open("mqls.csv", newline="") as f:
    rows = [{k: d(v) if k.endswith("_date") else v for k, v in r.items()}
            for r in csv.DictReader(f)]

def working_days(start, end):
    """Weekdays after start, up to and including end (no holiday calendar)."""
    return sum((start + timedelta(n)).weekday() < 5
               for n in range(1, (end - start).days + 1))

def pct(n, base):
    return f"{100 * n / base:.1f}%" if base else "n/a"

def first_action(r):
    return r["accepted_date"] or r["rejected_date"]

def cohort(month):
    return [r for r in rows if r["mql_date"].month == month]

jan = cohort(1)
actioned = [r for r in jan if first_action(r)]
in_sla = [r for r in actioned
          if working_days(r["mql_date"], first_action(r)) <= SLA_DAYS]
accepted = [r for r in jan if r["accepted_date"]]
leaked = [r["lead_id"] for r in jan if not first_action(r)]
opps = [r for r in jan if r["opp_date"]]
closed = [r for r in opps if r["close_date"] and r["close_date"] <= SNAPSHOT]
won = [r for r in closed if r["outcome"] == "won"]
days_to_accept = [working_days(r["mql_date"], r["accepted_date"]) for r in accepted]

print(f"January MQL cohort, snapshot {SNAPSHOT}")
print(f"  MQLs {len(jan)} | actioned {len(actioned)} | "
      f"never actioned {len(leaked)} {leaked}")
print(f"  Hand-off SLA ({SLA_DAYS} working days) met: "
      f"{len(in_sla)}/{len(jan)} = {pct(len(in_sla), len(jan))}")
print(f"  Accepted {len(accepted)} ({pct(len(accepted), len(jan))} of MQLs), "
      f"median working days to accept {median(days_to_accept)}")
print(f"  Opportunities {len(opps)} ({pct(len(opps), len(accepted))} of accepted)")
print(f"  Closed {len(closed)}, won {len(won)} "
      f"(win rate {pct(len(won), len(closed))} of closed)")

feb = cohort(2)
opps_dated_feb = [r for r in rows if r["opp_date"] and r["opp_date"].month == 2]
feb_cohort_opps = [r for r in feb if r["opp_date"]]
print("February, two ways to say 'MQL to opportunity'")
print(f"  Period ratio : {len(opps_dated_feb)} opps created in Feb / "
      f"{len(feb)} Feb MQLs = {pct(len(opps_dated_feb), len(feb))}")
print(f"  Cohort ratio : {len(feb_cohort_opps)} opps from Feb MQLs / "
      f"{len(feb)} Feb MQLs = {pct(len(feb_cohort_opps), len(feb))} (still maturing)")

3. Run python3 funnel.py.

Expected output.

January MQL cohort, snapshot 2026-04-30
  MQLs 12 | actioned 10 | never actioned 2 ['L06', 'L10']
  Hand-off SLA (2 working days) met: 8/12 = 66.7%
  Accepted 8 (66.7% of MQLs), median working days to accept 1.0
  Opportunities 6 (75.0% of accepted)
  Closed 4, won 2 (win rate 50.0% of closed)
February, two ways to say 'MQL to opportunity'
  Period ratio : 5 opps created in Feb / 8 Feb MQLs = 62.5%
  Cohort ratio : 2 opps from Feb MQLs / 8 Feb MQLs = 25.0% (still maturing)

Validation. By hand: L04 (4 working days) and L12 (3) were actioned late and L06 and L10 never, so 8 of 12 met the SLA. The clock counts weekdays, as Artefact 3’s SLA does; real reports also need a holiday calendar and time zones. The February period ratio divides opportunities that came mostly from January MQLs (L05, L11, L12) by February MQLs; it looks better than either cohort. Report cohort ratios with the cohort’s age, or the funnel will mislead you every time volume changes.

Troubleshooting. ValueError: Invalid isoformat string: a date has a space or a different format; dates must be YYYY-MM-DD. AttributeError: 'NoneType' object has no attribute 'month': an MQL row lacks mql_date.

Teardown. rm -rf ~/revops-labs/lab1

Objective. Route leads with ordered first-match rules (existing account owner first, an exception queue for incomplete data, round robin that skips absent people), then measure a 60-minute first-touch SLA. Prerequisites. Lab 1. Time. 30 minutes. Risk. None.

1. Create the data.

Example status: verified by execution on 2026-10-18 (bash, Linux).

mkdir -p ~/revops-labs/lab2 && cd ~/revops-labs/lab2
cat > accounts.csv <<'CSV'
domain,account_owner
acme.example,ana
globex.example,ben
CSV
cat > leads.csv <<'CSV'
lead_id,email_domain,country,employees,created_at,first_touch_at
R01,acme.example,US,5000,2026-03-02T09:00,2026-03-02T09:20
R02,initech.example,DE,2500,2026-03-02T09:05,2026-03-02T10:40
R03,umbrella.example,US,1200,2026-03-02T09:10,2026-03-02T09:35
R04,hooli.example,FR,80,2026-03-02T09:30,2026-03-02T09:50
R05,globex.example,NL,300,2026-03-02T10:00,
R06,vandelay.example,US,40,2026-03-02T10:15,2026-03-02T12:30
R07,stark.example,DE,4000,2026-03-02T11:00,2026-03-02T11:30
R08,wayne.example,US,15,2026-03-02T11:20,2026-03-02T11:45
R09,tyrell.example,BR,,2026-03-02T11:40,
CSV

2. Save the rules as rules.json. Order matters: the first matching rule wins, and the last rule matches everything.

Example status: verified by execution on 2026-10-18 (JSON, loaded by the script below).

{
  "sla_minutes": 60,
  "snapshot": "2026-03-02T17:00",
  "rules": [
    {"name": "existing-account",
     "match": {"has_account_owner": true}, "assign": "account_owner"},
    {"name": "incomplete-data",
     "match": {"missing_any": ["country", "employees"]}, "assign": "queue:ops-review"},
    {"name": "emea-enterprise",
     "match": {"country_in": ["DE", "FR", "NL", "GB"], "min_employees": 1000},
     "assign": "team:emea-ent"},
    {"name": "enterprise",
     "match": {"min_employees": 1000}, "assign": "team:na-ent"},
    {"name": "default", "match": {}, "assign": "team:smb"}
  ],
  "teams": {
    "emea-ent": ["carla", "dev"],
    "na-ent": ["erin"],
    "smb": ["finn", "gita", "hal"]
  },
  "unavailable": ["gita"]
}

3. Save the router as route.py.

Example status: verified by execution on 2026-10-18 (Python 3.8.10, standard library).

"""First-match lead routing with round robin, then a speed-to-lead SLA check."""
import csv
import json
from datetime import datetime
from statistics import median

cfg = json.load(open("rules.json"))
with open("accounts.csv", newline="") as f:
    owners = {r["domain"]: r["account_owner"] for r in csv.DictReader(f)}
with open("leads.csv", newline="") as f:
    leads = list(csv.DictReader(f))

cursor = {team: 0 for team in cfg["teams"]}   # round-robin position per team

def matches(lead, m):
    size = int(lead["employees"]) if lead["employees"] else None
    if m.get("has_account_owner") and lead["email_domain"] not in owners:
        return False
    if "missing_any" in m and not any(lead[k] == "" for k in m["missing_any"]):
        return False
    if "country_in" in m and lead["country"] not in m["country_in"]:
        return False
    if "min_employees" in m and (size is None or size < m["min_employees"]):
        return False
    return True

def next_member(team):
    members = cfg["teams"][team]
    for _ in members:                          # at most one lap round the team
        person = members[cursor[team] % len(members)]
        cursor[team] += 1
        if person not in cfg["unavailable"]:
            return person
    return "queue:" + team                     # nobody available: team queue

def route(lead):
    for rule in cfg["rules"]:
        if matches(lead, rule["match"]):
            target = rule["assign"]
            if target == "account_owner":
                return rule["name"], owners[lead["email_domain"]]
            if target.startswith("team:"):
                return rule["name"], next_member(target[5:])
            return rule["name"], target
    raise ValueError("no rule matched: add a default rule")

ts = datetime.fromisoformat
snapshot = ts(cfg["snapshot"])
met, waits = 0, []
print(f"{'lead':5} {'rule':17} {'owner':17} {'minutes':>7}  SLA")
for lead in leads:
    rule, owner = route(lead)
    touched = bool(lead["first_touch_at"])
    end = ts(lead["first_touch_at"]) if touched else snapshot
    minutes = int((end - ts(lead["created_at"])).total_seconds() // 60)
    ok = touched and minutes <= cfg["sla_minutes"]
    met += ok
    if touched:
        waits.append(minutes)
    status = "met" if ok else ("BREACH" if touched else "BREACH (no touch yet)")
    print(f"{lead['lead_id']:5} {rule:17} {owner:17} {minutes:>7}  {status}")
print(f"SLA {cfg['sla_minutes']} min met: {met}/{len(leads)} = "
      f"{100 * met / len(leads):.1f}%; median minutes to first touch "
      f"(touched leads) = {median(waits)}")

4. Run python3 route.py.

Expected output.

lead  rule              owner             minutes  SLA
R01   existing-account  ana                    20  met
R02   emea-enterprise   carla                  95  BREACH
R03   enterprise        erin                   25  met
R04   default           finn                   20  met
R05   existing-account  ben                   420  BREACH (no touch yet)
R06   default           hal                   135  BREACH
R07   emea-enterprise   dev                    30  met
R08   default           finn                   25  met
R09   incomplete-data   queue:ops-review      320  BREACH (no touch yet)
SLA 60 min met: 5/9 = 55.6%; median minutes to first touch (touched leads) = 25

Validation. R06 went to hal because round robin skipped the unavailable gita; R05 matched its account owner ben although it is a small Dutch company, because the account rule comes first; R09 landed in the exception queue because company size is missing. Note the median (25 minutes) looks healthy while the SLA attainment (55.6%) does not: untouched leads never enter a “time to first touch” average, which is why you must report attainment and open breaches, not only the average.

Troubleshooting. KeyError: 'email_domain': the CSV header was changed. ValueError: no rule matched: you removed the default rule; keep a catch-all last. Real systems also need business-hour calendars and time zones; this lab uses clock minutes.

Teardown. rm -rf ~/revops-labs/lab2

Objective. Build an ARR bridge (start + new + expansion − contraction − churn = end) from two snapshots, compute GRR and NRR, and see how the ARR definition changes them. Prerequisites. Lab 1. Time. 25 minutes. Risk. None.

1. Create the data: committed contract value and monthly usage revenue at 2025-09-30 and 2026-09-30.

Example status: verified by execution on 2026-10-18 (bash, Linux).

mkdir -p ~/revops-labs/lab3 && cd ~/revops-labs/lab3
cat > customers.csv <<'CSV'
customer,committed_arr_start,committed_arr_end,usage_mrr_start,usage_mrr_end
C1,100000,120000,0,0
C2,80000,80000,2000,6000
C3,60000,0,0,0
C4,50000,40000,1000,500
C5,120000,120000,0,0
C6,0,90000,0,1000
C7,40000,40000,3000,0
C8,0,30000,0,0
CSV

2. Save the script as arr.py.

Example status: verified by execution on 2026-10-18 (Python 3.8.10, standard library).

"""ARR bridge, GRR and NRR under two ARR definitions (standard library only).

Snapshots: start = 2025-09-30, end = 2026-09-30 (a 12-month window).
Definition A (contract ARR): committed annual value only.
Definition B (run-rate ARR): committed value plus 12 x the month's usage revenue.
"""
import csv

with open("customers.csv", newline="") as f:
    rows = [{k: (v if k == "customer" else float(v)) for k, v in r.items()}
            for r in csv.DictReader(f)]

def arr(r, when, definition):
    usage = r[f"usage_mrr_{when}"] * 12 if definition == "B" else 0.0
    return r[f"committed_arr_{when}"] + usage

def bridge(definition):
    keys = ("start", "new", "expansion", "contraction", "churn", "end")
    b = dict.fromkeys(keys, 0.0)
    for r in rows:
        s, e = arr(r, "start", definition), arr(r, "end", definition)
        b["start"] += s
        b["end"] += e
        if s == 0 and e > 0:
            b["new"] += e
        elif s > 0 and e == 0:
            b["churn"] += s
        elif e > s:
            b["expansion"] += e - s
        else:
            b["contraction"] += s - e
    check = b["start"] + b["new"] + b["expansion"] - b["contraction"] - b["churn"]
    assert abs(check - b["end"]) < 0.01, "bridge does not reconcile"
    kept = b["start"] - b["contraction"] - b["churn"]
    b["grr"] = kept / b["start"]
    b["nrr"] = (kept + b["expansion"]) / b["start"]
    return b

for definition, label in (("A", "contract ARR"), ("B", "run-rate ARR incl. usage")):
    b = bridge(definition)
    k = {key: round(val / 1000, 1) for key, val in b.items()}
    print(f"Definition {definition} ({label}), in thousands")
    print(f"  start {k['start']} + new {k['new']} + expansion {k['expansion']}"
          f" - contraction {k['contraction']} - churn {k['churn']} = end {k['end']}")
    print(f"  GRR {b['grr']:.1%}   NRR {b['nrr']:.1%}")

3. Run python3 arr.py.

Expected output.

Definition A (contract ARR), in thousands
  start 450.0 + new 120.0 + expansion 20.0 - contraction 10.0 - churn 60.0 = end 520.0
  GRR 84.4%   NRR 88.9%
Definition B (run-rate ARR incl. usage), in thousands
  start 522.0 + new 132.0 + expansion 68.0 - contraction 52.0 - churn 60.0 = end 610.0
  GRR 78.5%   NRR 91.6%

Validation. Definition A by hand: GRR = (450 − 10 − 60) ÷ 450 = 84.4%; NRR = (450 + 20 − 10 − 60) ÷ 450 = 88.9%. Under B, customer C2’s usage growth counts as expansion and C7’s usage drop as contraction, so NRR rises and GRR falls. Neither is wrong; they are different metrics with the same name, and listed companies choose differently (see metrics).

Troubleshooting. AssertionError: bridge does not reconcile: a row has a negative or non-numeric value. Customers that churn and return within the window need a rule (new or reactivation); this lab has none.

Teardown. rm -rf ~/revops-labs/lab3

Objective. Score six quarters of a forecast of record for net new ARR by component (new business, expansion, renewal losses); see how two opposite biases can hide inside an accurate total; then roll the owners’ calls for the next quarter into one forecast of record. Prerequisites. Labs 1–3. Time. 30 minutes. Risk. None.

1. Create the data: the week-4 forecast of record and the actuals for six quarters (ARR, in thousands), and the contracts that come up for renewal.

Example status: verified by execution on 2026-10-18 (bash, Linux).

mkdir -p ~/revops-labs/lab4 && cd ~/revops-labs/lab4
cat > history.csv <<'CSV'
quarter,new_fc,new_act,expansion_fc,expansion_act,losses_fc,losses_act
2025-Q2,900,820,300,320,400,330
2025-Q3,950,880,320,300,420,350
2025-Q4,1000,930,340,350,430,370
2026-Q1,1100,990,360,380,470,370
2026-Q2,1050,1000,380,360,450,400
2026-Q3,1150,1060,400,410,480,400
CSV
cat > renewals.csv <<'CSV'
contract,renewal_date,arr_k,risk
K01,2026-10-15,400,low
K02,2026-10-31,250,medium
K03,2026-11-14,300,low
K04,2026-11-30,180,high
K05,2026-12-05,500,medium
K06,2026-12-20,220,high
K07,2027-01-10,350,high
K08,2026-12-31,600,low
CSV

2. Save the script as forecast.py.

Example status: verified by execution on 2026-10-18 (Python 3.8.10, standard library).

"""Forecast of record: score each component, then build next quarter's (stdlib)."""
import csv
from datetime import date

def load(name):
    with open(name, newline="") as f:
        return list(csv.DictReader(f))

# 1. Score six quarters of the week-4 forecast of record (ARR, thousands).
#    e = actual - forecast, so a negative mean error means the forecast was too high.
history = load("history.csv")

def value(q, part, kind):
    if part == "net":   # net new ARR = new + expansion - losses
        return (value(q, "new", kind) + value(q, "expansion", kind)
                - value(q, "losses", kind))
    return float(q[f"{part}_{kind}"])

print("component  mean error     MAE   MAPE")
for part in ("new", "expansion", "losses", "net"):
    errs = [value(q, part, "act") - value(q, part, "fc") for q in history]
    ape = [abs(e) / value(q, part, "act") for e, q in zip(errs, history)]
    mae = sum(abs(e) for e in errs) / len(errs)
    print(f"{part:10} {sum(errs) / len(errs):+9.1f}k {mae:6.1f}k "
          f"{sum(ape) / len(ape):6.1%}")

# 2. Next quarter: roll up the owners' calls into one forecast of record.
START, END = date(2026, 10, 1), date(2026, 12, 31)
LOSS_RATE = {"low": 0.05, "medium": 0.25, "high": 0.60}  # written risk bands
calls = {"new": 1200.0, "expansion": 420.0}   # SalesOps call; account mgmt call
start_arr = 12000.0                            # contract ARR on 2026-09-30
base = [r for r in load("renewals.csv")
        if START <= date.fromisoformat(r["renewal_date"]) <= END]
due = sum(float(r["arr_k"]) for r in base)
losses = sum(float(r["arr_k"]) * LOSS_RATE[r["risk"]] for r in base)
end_arr = start_arr + calls["new"] + calls["expansion"] - losses
print(f"Renewal base {START} to {END}: {len(base)} contracts, {due:.0f}k due, "
      f"expected losses {losses:.1f}k")
print(f"Forecast of record: {start_arr:.0f} + new {calls['new']:.0f}"
      f" + expansion {calls['expansion']:.0f} - losses {losses:.1f}"
      f" = end ARR {end_arr:.1f}k")

3. Run python3 forecast.py.

Expected output.

component  mean error     MAE   MAPE
new            -78.3k   78.3k   8.3%
expansion       +3.3k   16.7k   4.8%
losses         -71.7k   71.7k  19.5%
net             -3.3k   10.0k   1.1%
Renewal base 2026-10-01 to 2026-12-31: 7 contracts, 2450k due, expected losses 492.5k
Forecast of record: 12000 + new 1200 + expansion 420 - losses 492.5 = end ARR 13127.5k

Validation. Errors follow the textbook convention e = actual − forecast,^[34] so a negative mean error means the forecast was too high. The total looks excellent (MAPE 1.1%) only because two biases cancel: new business was over-forecast by 78.3k a quarter, and renewal losses by 71.7k (customer success expected more churn than happened, which adds back to net ARR). If customer success fixed its pessimism alone, the error on the total would grow to about −75k a quarter: one component would improve and the forecast of record would look worse. Score every component, show each owner its own bias, and fix the two together. In part 2, contract K07 renews in January and stays out of the quarter’s renewal base. The 492.5k of expected losses comes from risk bands that history suggests are pessimistic: raise that with customer success and record any adjustment with its reason, rather than editing the number quietly.

Troubleshooting. ZeroDivisionError: a component’s actual is 0 (possible for expansion in a small segment, or for net new ARR in a flat quarter); percentage errors are undefined at zero, one of the limits Hyndman and Athanasopoulos list for them,^[34] so report the error in currency. KeyError in LOSS_RATE: a renewal row uses a risk band the table does not define.

Teardown. rm -rf ~/revops-labs/lab4 (and rmdir ~/revops-labs when all labs are done).

Documented practice: GitLab’s Field Operations. GitLab’s handbook shows one company’s version of this work — a vision to “Manage field business processes, systems, architecture, enablement, champion data integrity, provide insights and predictability through analytics”, and tenets of clarity (“for definitions, processes and events”), predictability and scalability; the team structure and release habits appear under roles and operating model.^[23] The handbook documents choices, not results.

This page defines the cross-funnel metrics once for the Atlas. The formulas are this page’s definitions; companies, including listed ones, define the same names differently (see Lab 3). Function-specific measures live on the specialist pages: win rate, sales cycle and pipeline coverage in SalesOps; campaign metrics in MarketingOps; health and churn drivers in CustomerOps.

Why these choices: listed companies define the same names differently. Datadog computes net retention on ARR that includes usage, Snowflake on two years of product revenue for a cohort, and Workday’s gross retention excludes add-ons;^[42][43][44] hence the SEC’s expectation of a clear definition for every key metric (see methods).^[33] The ARR bridge follows the split of net ARR into new, expansion and churned ARR that Skok describes.^[45] Gross margin in payback, and capped or discounted lifetimes, are this page’s choices.

CAC variants. Skok computes CAC as total sales and marketing cost ÷ deals closed, and suggests a second version that counts only marketing programme costs.^[35] a16z writes both of its versions with total acquisition cost on top and changes the customers counted: blended CAC divides by “total new customers acquired across all channels”, paid CAC by “new customers acquired through paid marketing”.^[20] Paid CAC therefore needs a channel-attribution rule that says which customers came through paid marketing. This page’s default is the fully loaded, blended version; show any variant beside it, labelled.

LTV caveats. a16z defines LTV as “the present value of the future net profit from the customer over the duration of the relationship” and calls an estimate based on revenue or gross margin a common mistake.^[20] The simple LTV here follows Skok’s form (lifetime = 1 ÷ churn rate)^[35] with gross margin and no discount, so read it as an upper bound.

Leading and lagging. Speed to lead, SLA attainment, buying-group coverage and qualified pipeline created lead; bookings, ARR, NRR and GRR lag by months. Steer weekly on the leading ones, judge quarterly on the rest.

Vanity traps. MQL volume as a goal (see Scenario 2); “pipeline influenced” without a sourcing rule; average response time that ignores untouched leads; NRR that quietly switches definition; forecast accuracy measured only on the total, or only in the last week of the quarter.

Dashboards and data limits. One page per audience: a weekly operational view (SLAs, stuck records, forecast changes), a monthly funnel view (cohorts), a quarterly board view (ARR bridge, retention, efficiency). CRM history is incomplete unless you snapshot it; amounts and close dates are opinions until the contract is signed.

Nothing here is legal advice; it orients RevOps teams so they know when to involve PrivacyOps and counsel. Statements are dated October 2026.

Business contacts are personal data. Under the EU GDPR, personal data is “any information relating to an identified or identifiable natural person”;^[46] a named buyer’s work email and call notes qualify. Direct marketing “may be regarded as carried out for a legitimate interest” (recital 47),^[47] a possibility to assess, not a blanket permission, and it does not settle email. The ePrivacy Directive allows email for direct marketing only to subscribers who have given prior consent (Art. 13(1)); a company that obtained a customer’s email address in a sale may market its own similar products to it, if the customer could object easily and free of charge when the address was collected and can do so in every message (Art. 13(2)); protection of legal persons, and so of many company addresses, is left to national law (Art. 13(5)).^[48] Member states implement these rules differently. The UK ICO says you “can email or text any corporate body”, but sole traders and some partnerships are treated as individuals (guidance under review after the Data (Use and Access) Act).^[49] The US FTC says CAN-SPAM “makes no exception for business-to-business email” and opt-outs must be honoured within 10 business days;^[50] California’s CCPA exemptions for business-to-business and employment information expired on 31 December 2022.^[51] MarketingOps covers consent capture under these rules in more depth.

For RevOps the duty is architectural. A person may object at any time to direct marketing, and their data “shall no longer be processed for such purposes”.^[52] An objection recorded in one system must therefore suppress outreach in every system (marketing automation, CRM sequences, enrichment, sales engagement tools), and an objection that a seller or support agent hears must reach the consent record through one write path within a set time. This page proposes one business day; CAN-SPAM’s 10 business days is a legal limit for US email, not a design target.

Security of the revenue record. The CRM holds the customer list, pricing and pipeline: treat it as sensitive. Give access by role and territory where practical; restrict bulk export and API tokens to named integration users with the minimum scopes; remove access for departing sellers on their last day (see IdentityOps); keep field history on amount, stage, close date and owner. Only billing (or order management) should write ARR and subscription terms.

Financial control. If you are a US public company, the SEC reminds companies of the requirement to maintain effective disclosure controls when key metrics come from their own information;^[33] in practice, reconcile CRM bookings with billing monthly, keep an audit trail for metric definitions and changes, and review commission inputs before payroll.

The visible cost of RevOps is people and licences; the hidden cost is complexity. Licences for CRM, marketing automation, forecasting and engagement tools are commonly priced per user, per contact or per record tier (price lists change often). Integrations need maintenance every time a vendor changes an API or a team adds a field. Data vendors charge for records whose accuracy decays.

Track cost per unit of the system rather than chasing benchmarks: GTM tool spend per seller, change requests delivered per month, share of fields unused for a year, and admin hours spent on fixes versus improvements. Capacity is a queue: limit work in progress, release on a cadence, and say no to changes that add a field without retiring one.

Environmental impact is small next to other Ops domains. The material lever is data minimisation: deleting stale contacts and unused data reduces storage, privacy risk and enrichment spend together.

How do you know the system works, not just the dashboard? Five recurring checks (the weekly data-quality scorecard is in the CRM data-quality playbook):

Leading risk indicators: rising unassigned leads, rising rejection rates from one source, more manual forecast adjustments, deals whose close date moved two or more times, and change requests waiting longer than one release.

%%{init: {"flowchart": {"wrappingWidth": 130, "nodeSpacing": 16, "rankSpacing": 30}}}%%
flowchart TB
  A["Forecast moved sharply"] --> Q1{"Definitions, snapshot, rates unchanged?"}
  Q1 -- "No" --> D1["Measurement change: recast, compare"]
  Q1 -- "Yes" --> Q2{"Which component, which deals?"}
  Q2 --> D2["Slipped: exit criteria, activity"]
  Q2 --> D3["Lost: reasons, competitor"]
  Q2 --> D4["Never in pipeline: creation shortfall"]
  Q2 --> D5["Renewal loss: risk missed, no record"]
  D2 --> F["Re-submit with reasons and a range"]
  D3 --> F
  D4 --> F
  D5 --> F
  D1 --> F
  F --> R["Retrospective: recalibrate, fix rules, coach"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class A,F,R core
  class Q1,Q2 decision
  class D1,D2,D3,D4,D5 risk

• “Rename sales ops and call it done.” Scope, not title, makes RevOps. If marketing-to-sales and sales-to-success hand-offs are not measured, nothing changed.
• “Centralise everyone on day one.” Forrester’s analysts warn that combining all ops functions without creating new capabilities “loses the big picture”.^[4]
• “The tool will align us.” A new CRM or forecasting product moves the argument into a new system. Agree definitions first.
• “MQL volume proves marketing works.” See Scenario 2.
• “The forecast is the target with a haircut.” Targets are decisions; forecasts are measurements.^[22]
• “The forecast is the sales commit.” Where revenue recurs, renewal losses can move the number as much as new business does; forecast and score both.
• “We will fix the data later.” Without snapshots and required fields now, you cannot measure accuracy or conversion later.
• “RevOps owns revenue.” It owns the system. When RevOps owns the number, it stops being a neutral referee.
• “Our NRR is 120%, theirs is 110%, so we are better.” Not if the definitions differ (see Lab 3).
• Myth: “RevOps is only for SaaS.” The definitions, hand-offs and forecast discipline apply to any B2B business with a sales team; recurring-revenue metrics (ARR, NRR) apply only where revenue recurs.

Use it when two or more teams hand the same customer to each other (marketing to sales, sales to success, partners to sales), when leaders argue about which number is right, when the forecast regularly surprises, or when revenue recurs and retention matters as much as new business.

Do not build a RevOps function (yet) in these situations:

• Founder-led or single-team selling. With one or two sellers and no separate marketing or success team there are few hand-offs to govern; one part-time, accountable owner of the CRM and the definitions is enough.
• Pure self-serve with no sales team. The questions are product analytics and pricing; see AnalyticsOps and BizOps.
• Transactional or retail selling without pipelines or opportunities. Funnel definitions still help, but the forecast is a demand forecast, not a pipeline roll-up.
• When the real problem is strategy. If the company has not chosen its target customers or pricing, better hand-offs only move the wrong customers faster.

Hidden responsibilities come with adoption: leaders must give time to a definitions council; Finance must co-own metric formulas; somebody must say no to unplanned changes; history must be snapshotted and stored. Without these, a RevOps team becomes a CRM help desk with a grander title.

Exit conditions. If a centralised team has become a bottleneck (requests wait longer than a release cycle for months), move specialist work back to functional ops and keep the centre for definitions, data and systems: the hybrid model.

The tree below helps decide whether you need a RevOps capability and which structure to start with. Thresholds are editorial heuristics of this Atlas, not research findings.

flowchart TB
  S["Revenue problems to solve"] --> Q1{"Two or more teams hand customers on?"}
  Q1 -- "No" --> N1["No RevOps team: one owner of CRM and definitions"]
  Q1 -- "Yes" --> Q2{"Agreed definitions and one forecast today?"}
  Q2 -- "Yes" --> N2["Keep functional ops; add a definitions council"]
  Q2 -- "No" --> Q3{"Strong functional ops teams already?"}
  Q3 -- "Yes" --> H["Hybrid: shared centre for data, systems, analytics"]
  Q3 -- "No" --> Q4{"One GTM motion and a clear executive sponsor?"}
  Q4 -- "Yes" --> C["Centralised RevOps team"]
  Q4 -- "No" --> H
  H --> G["Then: dictionary, SLAs, snapshots, forecast scoring"]
  C --> G
  N2 --> G
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class S,H,C,G core
  class Q1,Q2,Q3,Q4 decision
  class N1,N2 neutral

For a structured comparison, score each option from 1 to 5 against weighted criteria. The weights and scores below are an illustration for a 300-person company with three ops teams and two GTM motions:

The arithmetic for the hybrid option: 0.30×4 + 0.25×4 + 0.20×4 + 0.15×3 + 0.10×4 = 3.85. Change the weights and the answer can change; that is the point of writing them down.

This five-level model is this Atlas’s proposal, not an industry standard. Levels describe observable behaviour.

Typical constraints: level 2 stalls without an executive sponsor; level 3 without snapshots; level 4 needs Finance as a co-owner; level 5 needs volumes large enough to experiment.

Dependencies: an executive sponsor (often the CEO, COO or CRO and CFO together), admin rights to the systems, and Finance time. Milestone at day 90: one pipeline definition in every deck, an SLA report reviewed weekly, and a scored forecast.

Quick start (first week)

• Name one accountable owner for definitions and one for the CRM
• List every system that stores customers, leads, deals or subscriptions
• Start a weekly snapshot of open pipeline and forecast submissions
• Add a default routing rule and a fallback queue with an owner

Before changing a definition

• Change request filed; reports, automations and integrations affected listed
• History treatment decided (recast, map, or leave) and written in the version note
• Compensation owner and Finance consulted
• Sandbox test with before-and-after report totals
• Announcement and enablement scheduled with the release

Weekly operating review

• SLA attainment, open breaches and unassigned leads
• Forecast-of-record changes since last week, by component, with reasons
• Contracts ending within 120 days without a renewal record
• Deals with close dates moved twice or more; stale committed deals
• Data-quality scorecard trend

Quarterly governance audit

• Assurance checks done; each forecast bias returned to its component owner
• Access review of CRM admins, export rights and integration users
• Objection and unsubscribe suppression tested across all outreach tools

After a forecast miss follow the worked runbook.

One-page RevOps charter

REVOPS CHARTER (<company>, version <n>, <date>)
Mission     One revenue process, measured end to end, that teams trust.
Scope       Definitions; routing and hand-off SLAs; forecast process; revenue
            metric formulas (with Finance); system-of-record decisions.
Not scope   Quotas and territories; campaign content; CS playbooks; accounting.
Sponsor     <executive>      Accountable lead: <RevOps lead>
Forums      Weekly hand-off check; monthly funnel review; quarterly definitions
            council and forecast retrospective; GTM release every two weeks.
Measures    SLA attainment; speed to lead; qualified pipeline created; forecast
            error and bias by component; GRR; NRR; data completeness.
Decision    Definition changes need the council; metric formulas need Finance.
rights      System-of-record changes need the RevOps systems lead.
Review      Charter reviewed yearly or when the go-to-market motion changes.

Metric definition card

METRIC: <name>                     ID: <id>        VERSION: <n> from <date>
Question it answers:
Formula (in words and symbols):
Population / cohort, and exclusions:
Grain and time window:
System of record and snapshot rule:
Owner (accountable) / steward (responsible):
Known limits and common misreadings:
Change history (version, date, what changed, history recast?):

Forecast-of-record review agenda (30 minutes)

1. Forecast of record vs last week, by component (5 min) - RevOps prepares, CRO chairs
2. New-business deals that moved category or close date, with reasons (10 min)
3. Renewals: risk changes; contracts without a renewal record (5 min)
4. Risks and upside not in the CRM (5 min) - recorded as adjustments
5. Submission and range; actions with owners (5 min)

Definitions council decision record

DECISION <id>: <title>                       Date: <date>   Status: approved
Context: what is inconsistent today, with evidence
Options considered: A / B / C with consequences
Decision and effective date:
History treatment: recast from <date> / map old values / no change
Who must act: report owners, automation owners, compensation, Finance
Review date:

The boundaries table says who owns what; this one says where a problem does not belong to RevOps.

Is RevOps a team or a way of working? Both, depending on the company (see what RevOps is not). Decide the capabilities first and the structure second.

Should RevOps report to the CRO, the CFO or the COO? No evidence-based answer exists. Reporting to the CRO keeps it close to sales but risks becoming sales operations; the CFO or COO helps neutrality but can feel remote. Whatever the line, give RevOps decision rights over definitions and the stack, and keep the committed forecast with the CRO.

Do we still need MQLs? As an operational trigger, often yes: something must start routing. As a target, no (see Scenario 2). Keep MQL-to-acceptance as a hand-off metric.

Who forecasts renewals? Customer success makes the renewal call, contract by contract, in a renewal review. RevOps supplies the renewal base from billing, agrees with customer success what each risk band means, rolls the call into the forecast of record and scores it.

Who owns the CRM? The business owns its data; RevOps owns the configuration, definitions and change process; IT or security often owns access standards and the platform contract. Write the split down.

Can AI replace the forecast call? It can add a model-based estimate and spot risky deals. Score it like any other forecaster (error, bias, Brier score for deal probabilities)^[41] and keep a person accountable for the committed number.

How big should a RevOps team be? No credible public ratio fits your motion; ignore benchmarks quoted without definitions. Size it from the work — systems administration, analytics, the change queue, the governance calendar — and check the queue length every quarter.

What is the difference between bookings, ARR and revenue? Bookings are signed contract value in a period; ARR is an annualised run-rate of active recurring contracts; revenue is recognised under accounting standards as performance obligations are satisfied.^[20][8] They move at different times.

• Usage-based revenue (active practice, definitions unsettled). When usage dominates, ARR, NRR and forecasting change shape; public companies already use different bases (Lab 3).
• AI in forecasting and seller workflows (fast-moving vendor area). The vendor market is still forming (2025 row of the timeline); treat feature claims as claims until tested on your data.
• Warehouse-centred GTM data (established pattern, varied maturity). Joined history in a warehouse, metrics defined once in a semantic layer, derived fields written back to the CRM; see AnalyticsOps and DataOps.

• Prerequisites: spreadsheets; the basic B2B sales process; a profit-and-loss statement.
• One-day primer: read What RevOps is, the stage dictionary and the metrics table; run Lab 1.
• One week: run Labs 2–4; map your company’s systems of record; draft a stage dictionary for your team.
• Thirty days: follow the first 30 days of the roadmap; score one quarter of your forecast of record by component; reconcile CRM and billing ARR for twenty customers.
• Specialisations: GTM systems administration (with MarTechOps and IntegrationOps); revenue analytics and forecasting; deal desk and quote-to-cash (with SalesOps); retention analytics (with CustomerOps).
• Portfolio projects: a versioned metric dictionary with a history recast; a routing rule engine with audit logs; a forecast scoring report covering four quarters; a CRM-to-billing reconciliation.

Assumptions. Both options cost about the same; the ops staff are competent; the CFO will co-own metric definitions under either option; the company has one main sales motion and a growing self-serve tier.

Option A, centralise now. For: one leader can impose definitions quickly; clear accountability. Against: Forrester’s analysts count required centralisation among RevOps myths;^[4] marketing and success lose specialists just when self-serve needs them; and reporting to the CRO, the team may score its own leader’s forecast.

Option B, centre of excellence first. For: keeps specialist depth; the shared centre owns exactly what is broken (definitions, data, systems, forecast scoring); lower political cost. Against: slower; a centre without decision rights becomes a ticket queue.

How to decide. The problems on the table (two numbers, a biased forecast) are definition and measurement problems, which a centre with decision rights can fix within a quarter. Centralisation solves a different problem (fragmented capacity and priorities), which nobody has shown exists here.

Recommendation (reasoned, not proven). Option B with teeth: a centre that owns the stage dictionary, metric definitions with Finance, the GTM release and forecast scoring, reporting jointly to the CRO and CFO; review in two quarters against explicit criteria (one pipeline number, forecast bias near zero, change queue under one release). If capacity conflicts dominate by then, centralise. Why the attractive option can be wrong: centralisation feels decisive but moves boxes before fixing the definitions that caused the pain, and removes the neutrality the forecast needs. Uncertainty: no study tests these two options for a company like ExampleCo; a strong leader can make either work.

After this page you should be able to:

1. Explain what RevOps is and is not, and how it differs from SalesOps and the CRO’s job.
2. Write stage entry and exit criteria and a hand-off SLA.
3. Design ordered routing rules with fallbacks and measure speed to lead correctly.
4. Calculate an ARR bridge, GRR, NRR, CAC payback and a capped LTV, and explain how definitions change them.
5. Run a forecast of record that combines new business, expansion and renewals, stays separate from the target, and is scored by component.
6. Choose a structure (decentralised, hybrid, centralised) with stated assumptions.

Self-check questions

1. Marketing reports 62.5% MQL-to-opportunity conversion for February; the cohort figure is 25%. Which do you publish, and why?

2. Your median time to first touch is 25 minutes against a 60-minute SLA. Is the SLA being met?

3. Start ARR 5.0 m; expansion 0.6 m; contraction 0.2 m; churn 0.3 m; new 0.9 m. Compute GRR and NRR.

4. A competitor publishes NRR of 120%; yours is 108%. Your CEO asks why you are worse. What do you check first?

5. Sales leadership wants the forecast set equal to the quarterly target minus 5% “to stay ambitious”. What is wrong?

6. For six quarters your forecast of record has been within about 1% of actual net new ARR. The CFO proposes to stop scoring the components. What do you advise?

7. A prospect in Germany objected to direct marketing in your marketing automation platform. A seller’s sequencing tool emails them a week later. Which design failure is this, and how do you fix it?

8. Your company has eight sellers, no separate marketing team and one customer success manager. The board asks you to hire a head of RevOps. What do you advise?

RevOps is less a department than a promise: that the people who find, win and keep customers work from the same definitions, hand customers to each other on time, and see the same numbers. Three ideas carry most of the value. Write the definitions down and version them, because every argument about pipeline, ARR or retention is first an argument about meaning. Put a clock on every hand-off, because revenue leaks in the gaps between teams, not inside them. Score the forecast, because a system you cannot predict is a system you do not understand.

The label is recent; the work is old. A company with a careful operations lead, a one-page stage dictionary and a weekly snapshot is doing RevOps; a company with a new title, a new tool and three definitions of pipeline is not. One test: ask marketing, sales and Finance for last quarter’s qualified pipeline and net revenue retention, separately. If you get one answer each, the system works.

All sources were opened on 2026-10-18 unless marked otherwise; the sources added or re-checked during the review round were opened on 2026-10-19; the three merger and Magic Quadrant sources were re-opened on 2026-10-23. Vendor and product statements are as of October 2026. Legal sources are for orientation only; for EU law, check the official text on EUR-Lex.

Further reading.

• Forrester’s paid reports on revenue operations organisational design and the full B2B Revenue Waterfall stage definitions (not read for this page; client access required).
• Adobe Marketo Engage documentation and Dynamics 365 Sales: product documentation for two systems named in the tooling table.

Changelog. Vendor rows (HubSpot, Salesforce, tool categories) and the legal rows are due for re-verification by 2027-01-18.

• 2026-10-23, post-score polish (reviews/revops-polish.md): exact lab and artefact links; forward pointers from the playbooks; opening verification date fixed; vendor market sources re-opened (unchanged); repeated passages cut.
• 2026-10-19, revision after independent review (reviews/revops-r1.md, response in reviews/revops-r1-response.md): forecast boundary with SalesOps restated (RevOps owns the forecast-of-record definition, snapshots, roll-up and component scorecard; SalesOps runs the categories, inspection, call and accuracy log; both pages now use e = actual − forecast); post-sale half completed in the lifecycle, workflow, artefacts and forecast components (renewal base, renewal records, expansion, roll-up); ePrivacy Directive Article 13 added beside GDPR/PECR/CAN-SPAM with the existing-customer exception and the legal-persons limit; paid/blended CAC per a16z corrected (the denominator varies, not the numerator); Forrester definition title and the Gartner MQ report name fixed; Clari–Salesloft completion cited to the companies’ announcements; LTV churn type and discounting stated; worked LTV added; consent write-path, sandbox and backup-export privacy handling added; glossary abbreviations (SDR, AE, CSM, CoE, FP&A, CPQ) added; sales-engagement tooling row added; duplicated passages cut (MQL myth quoted once, GitLab practice stated once, comparison table merged into a compact decision aid; ~750–800 words of restatement removed, review additions absorbed); sources re-verified 2026-10-19.
• 2026-10-18, first version: research, ledger, four labs executed on synthetic data, seven diagrams; not yet independently fact-checked.