--- title: "RevOps" slug: revops category: business term_status: established evidence_status: partially_verified summary: "RevOps (revenue operations) aligns marketing, sales and customer success around one set of funnel definitions, one trusted customer record, governed hand-offs and one forecast, so the revenue process can be measured and improved end to end." audience: [Beginners, RevOps and go-to-market operations practitioners, CRM and data engineers, Sales, marketing and customer success leaders, Finance partners] last_verified: 2026-10-23 key_takeaways: - Forrester treats RevOps as a strategy rather than an org chart: decentralised, hybrid and centralised set-ups all exist, so design capabilities before boxes. - "The core asset is a shared definition set: stage entry and exit criteria, one owner per object and field, and revenue metrics defined once with Finance." - "Revenue leaks at hand-offs: measure time to accept, time to first touch and stuck records at every boundary, not only stage conversion." - "ARR, NRR and GRR have no standard formula and public companies define them differently; write yours down, version it and never change it silently." - "One forecast of record covers new business, expansion and renewal losses: keep it apart from the target, document every adjustment, and score each component, because errors can cancel in the total." - "Do not build a RevOps department too early: with a small go-to-market team, one accountable owner of definitions and the CRM is usually enough." related: [salesops, marketingops, customerops, martechops, bizops, cxops, supportops, analyticsops] --- ## What RevOps is ### In 30 seconds **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**. ::: note Scope of this page This page is the **integrator** for the go-to-market pages of the Atlas: it owns shared funnel definitions, hand-offs, forecast governance, revenue metric formulas and decision rights over the stack. The specialists are [SalesOps](../salesops/) (territories, quotas, deal desk, the new-business forecast call), [MarketingOps](../marketingops/) (campaigns, lead scoring) and [CustomerOps](../customerops/) (health scores, the renewal call). The split is an **editorial distinction** of this Atlas, not an industry standard. ::: ### At a glance | Question | Short answer | |---|---| | Goal | One revenue process, measured end to end: shared definitions, clean hand-offs, a credible forecast, trusted revenue metrics | | Primary users | RevOps teams, sales, marketing and customer success leaders, Finance (financial planning and analysis, FP&A), go-to-market (GTM) system owners | | In scope | Funnel stage definitions and SLAs between teams, the CRM as system of record, lead routing, the forecast of record (new business, expansion, renewals), revenue metric formulas (ARR, NRR, GRR, CAC, LTV), decision rights over the GTM stack | | Prerequisites | None; spreadsheet skills help, SQL helps more | | Key outputs | Stage dictionary, metric definitions, routing rules and SLAs, forecast process, data-quality scorecard, stack decision log | | Term status | **Established** as a function and role name, with analyst coverage and a large practitioner community; no standards body and no single definition | | Evidence status | Partially verified: footnoted claims were checked against opened sources; sources that could not be opened are listed in the ledger | ### The problem it solves 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. | Area | Without a working RevOps model | With one | |---|---|---| | Definitions | "Pipeline" means one thing to marketing, another to sales, a third to Finance | One stage dictionary with entry and exit criteria, owned and versioned | | Hand-offs | Leads wait days for a first call; some are never touched | Every hand-off has an owner, an SLA and a stuck-record report | | Data | Duplicate accounts, missing amounts, close dates in the past | Required fields at each stage, deduplication, a data-quality scorecard | | Forecast | The number changes with the person asked; churn surprises the board | One forecast of record across new business, expansion and renewals; adjustments documented; each part scored | | Metrics | ARR and NRR differ between the board deck and the finance model | Formulas defined once with Finance, changes disclosed and back-calculated | | Tools | Every team buys its own tools; integrations break silently | Decision rights per object and system; changes released on a cadence | 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.[^forr-radar] 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".[^gartner-2021] 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? ### What RevOps is not: naming and boundaries - **Not an org chart.** Forrester calls revenue operations "a commercial execution strategy, not an organizational structure".[^forr-def] 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".[^forr-myths] - **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'".[^cnbc-linkedin] 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".[^informs-rm] - **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);[^hfma-rcm] that belongs to [HealthOps](../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.[^ifrs15] RevOps feeds Finance; it does not replace the accountants. ## Where RevOps comes from and where it sits ### Origins and evolution 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. | Year | Milestone | |---|---| | 2012 | A revised SiriusDecisions "Demand Waterfall" separates inbound and outbound inquiries and adds automated qualified, teleprospecting and sales-generated leads before the sales-qualified lead and the close, as a practitioner summarised at the time[^ct-waterfall] | | 2019 | Forrester completes its acquisition of SiriusDecisions, a B2B research firm, for $245 million in cash[^forr-sirius] | | 2021 | Forrester releases the B2B Revenue Waterfall, "formerly known as the SiriusDecisions Demand Unit Waterfall", adding renewal, cross-sell and upsell opportunities[^forr-waterfall] | | 2021 | Gartner predicts: "By 2025, 75% of the highest growth companies in the world will deploy a revenue operations (RevOps) model"[^gartner-2021] | | 2023 | LinkedIn's Jobs on the Rise list for the US ranks "Head of Revenue Operations" first, on title growth from January 2018 to July 2022[^cnbc-linkedin] | | 2023 | Forrester launches a dedicated research service, Forrester Decisions for Revenue Operations[^forr-launch], and a "Saying Goodbye to MQLs" series arguing for opportunity and buying-group measurement[^forr-mql-myths] | | 2025 | Gartner publishes a Magic Quadrant for Revenue Action Orchestration Platforms dated 15 December 2025, as cited by a vendor;[^outreach-mq] Clari and Salesloft, announced as merging in August, complete their merger in December[^forr-clari][^salesloft-merger] | 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. ::: note Is "established" the right status? Yes, with a caveat: an analyst firm runs a research service for the function and publishes a definition,[^forr-launch][^forr-def] a second made adoption predictions about it,[^gartner-2021] the title topped LinkedIn's 2023 growth list[^cnbc-linkedin] and a practitioner community claims more than 21,000 members.[^revops-coop] But no standards body or certification authority defines the scope, and companies draw its boundary differently. "Established" describes the function and the role name, not a settled scope. ::: ### Glossary and mental model - **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".[^sf-leads] - **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.[^hubspot-lifecycle] - **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".[^forr-waterfall] - **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".[^a16z] - **ARR / MRR:** annual / monthly recurring revenue, an operating measure, not accounting revenue (defined in [metrics](#metrics-and-kpis)). - **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.[^hubspot-forecast] ([SalesOps](../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. #### A mental model: a relay, a ledger and a control loop 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. ### How RevOps relates to other Ops 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. ::: figure RevOps and its neighbours: what crosses each boundary ```mermaid %%{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 ``` Text equivalent: Three neighbours feed RevOps: BizOps (targets and planning cadence, solid line), PrivacyOps (consent and objection rules, dotted) and CXOps with SupportOps (customer signals, dotted). RevOps exchanges artefacts in both directions with three specialists — MarketingOps through the SLA report, SalesOps through the forecast calendar, CustomerOps through the renewal base — and hands stack decisions to MarTechOps as a field map and metric definitions to AnalyticsOps as definition cards. Green: RevOps. Grey: neighbouring pages. ::: | Neighbour | RevOps owns | The neighbour owns | Hand-off artefact | |---|---|---|---| | [MarketingOps](../marketingops/) | MQL definition and the marketing-to-sales SLA | Campaign operations, scoring models, the marketing automation platform | Stage dictionary; SLA report | | [SalesOps](../salesops/) | Stage dictionary (what counts as an opportunity and as pipeline); the one forecast of record (the CRO is accountable for its value) and its component scoring | Territories, quotas, capacity, deal desk; sales-stage exit criteria and commit rules; the new-business forecast call and its accuracy log by caller and method | Forecast calendar; component scorecard | | [CustomerOps](../customerops/) | NRR/GRR formulas, the sales-to-success hand-off, the renewal record type | Health scores, renewal and expansion playbooks, the renewal call | Hand-off checklist; renewal base; retention bridge | | [MarTechOps](../martechops/) | Which system is the record for which object | Architecture and integration of the marketing stack | Decision log; field map | | [BizOps](../bizops/) | Funnel metrics that feed the company metric tree | Company OKRs, planning cadence, headcount plan | Revenue plan inputs | | [AnalyticsOps](../analyticsops/) | The business definition of revenue metrics (with Finance) | Metric cards, semantic layer, certified dashboards | Definition card per metric | | [CXOps](../cxops/), [SupportOps](../supportops/) | Using journey and service signals in revenue processes | NPS/CSAT design; tickets and SLAs | Signals in the CRM | | [PrivacyOps](../privacyops/) | Applying consent and objection rules in GTM systems | Records of processing, lawful-basis decisions | Suppression lists; field-level rules | | [PeopleOps](../peopleops/) | Supplying clean attainment data | Pay structures and pay governance for sales roles | Plan rules; payroll inputs | ::: tip Compensation is a shared boundary RevOps rarely designs sales compensation (that is [SalesOps](../salesops/) with [PeopleOps](../peopleops/) and Finance), but every commission plan pays on a RevOps definition: what counts as a booking, when a deal closes, who gets credit. Change a definition without telling the compensation owner and you change people's pay. ::: ## Principles and operating model ### Charter and principles 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.[^forr-myths] 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.[^fpp-judg] 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. ### Fundamentals and building blocks Forrester's definition names four ingredients: data, processes, technology and talent.[^forr-def] This page adds a fifth, **definitions**, because in practice that is where most teams start, and it is the part no tool supplies. | Building block | What it contains | Typical first artefact | |---|---|---| | Definitions | Stage dictionary, lifecycle rules, metric formulas, attribution rules | One-page stage dictionary | | Data | Objects (lead, contact, account, opportunity, subscription), required fields, deduplication, enrichment | Field ownership map | | Process | Routing, hand-off SLAs, forecast cadence, deal and renewal reviews, change control | Routing rules and SLA document | | Technology | CRM, marketing automation, CPQ, billing, CS platform, warehouse, BI, routing and forecasting tools | Stack decision log | | Talent and cadence | Roles, RACI, rituals, enablement on definitions | RACI and operating calendar | ### Roles, ownership and RACI 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](../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".[^gl-fieldops] 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".[^forr-myths] | Structure | How it works | Works when | Watch for | |---|---|---|---| | Decentralised | Marketing, sales and CS ops stay in their functions; a council owns shared definitions | Few products, strong informal trust | Definitions drift; nobody owns cross-funnel metrics | | Hybrid (centre of excellence) | Shared CoE for data, systems and analytics; functional ops keep specialist work | Most mid-size and large companies | CoE becomes a ticket queue without decision rights | | Centralised | One RevOps leader owns all GTM ops staff | Strong mandate, one GTM motion | Specialist depth lost; seen as a "land grab"[^forr-myths] | 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. | Decision | RevOps | Marketing (Ops) | Sales (Ops) | Customer success (Ops) | Finance | |---|---|---|---|---|---| | Stage dictionary and lifecycle rules | A, R | C | C | C | I | | Sales-stage exit criteria and commit rules | C | I | A, R | I | I | | MQL definition (criteria and SLA) | A | R | C | I | I | | Lead scoring model | C | A, R | C | I | I | | Health score model | C | I | I | A, R | I | | Lead routing rules and SLAs | A, R | C | C | I | I | | Forecast of record: components, calendar, snapshots, scoring | A, R | I | C | C | C | | New-business forecast call | C | I | A (CRO), R | I | C | | Renewal and churn forecast call | C | I | I | A, R | C | | Committed value of the forecast of record | R (compiles) | I | A (CRO) | C | C | | ARR, NRR, GRR, CAC formulas | R | C | C | C | A | | System of record per object | A, R | C | C | C | C | | Territories and quotas | C | I | A, R | I | C | 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. ### The revenue lifecycle 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"[^wbd]; Forrester's 2021 Waterfall likewise treats renewal, cross-sell and upsell as opportunity types.[^forr-waterfall] The figure uses generic stage names. ::: figure The revenue lifecycle: acquisition, hand-offs and the post-sale half ```mermaid 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 ``` Text equivalent: In the acquire half, target accounts and buying groups become engaged (an MQL or a hand-raise), then accepted and qualified, then an opportunity with stage exit criteria. A lost deal gets a reason and is recycled to engagement (dotted). A won deal passes a sales-to-success hand-off into the keep-and-grow half: onboarding to first value, adoption and renewal, and expansion through upsell and cross-sell, which creates new opportunities (dotted line back). Red: the lost path. Amber: the decision. ::: ### Operating model and governance RevOps governance is mostly a calendar and a set of decision rights. A proposed cadence: | Cadence | Forum | Inputs | Decisions and outputs | |---|---|---|---| | Weekly | Forecast-of-record review (after the sales and renewal reviews; prepared by RevOps, chaired by the CRO) | Component calls, changes since last week, slipped deals and at-risk renewals | Forecast of record with a range; risks; data fixes | | Weekly | Hand-off health check | SLA reports, stuck records, routing exceptions | Re-routes, owner nudges, rule fixes | | Monthly | Funnel review (marketing, sales, CS, Finance) | Cohort conversion, velocity, retention bridge | Bottleneck owners and actions | | Quarterly | Definitions council | Change requests to stages, fields, metrics | Approved changes with versions and dates | | Quarterly | Forecast retrospective | Forecast vs actual by component and week | Each component's bias back to its owner | | Every two weeks | GTM release | Tested changes to CRM, routing, automation | Release notes; enablement | GitLab documents a similar habit: its Field Operations team delivers changes "in a batched, bi-weekly release cadence",[^gl-fieldops] 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.[^gl-spekit] **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. ## Architecture and workflow ### Reference architecture: systems of record per object 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. ::: figure Reference architecture: one system of record per object ```mermaid %%{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 ``` Text equivalent: Marketing automation (engagement and consent) and the CS platform (health and success plans) sync both ways with the CRM, which holds leads, contacts, accounts and opportunities. The CRM sends quotes and orders through CPQ to billing (subscriptions, invoices, ARR); billing returns subscription data to the CRM. Usage events, CRM data and billing data flow into the warehouse, which keeps joined history and snapshots, feeds metric definitions and dashboards, and can push derived fields back to the CRM (dotted). Green: the two main systems of record. Amber: the insight layer. ::: Write the decisions down as a table. This example is illustrative; your systems will differ. | Object or field | System of record | Who may write | Synced to | |---|---|---|---| | Consent, objections, unsubscribes | Marketing automation (or a consent platform) | Marketing; the person; any channel that hears an objection (sellers, support), through one write path | CRM and every outreach tool, within one business day (proposal) | | Lead, contact, account, opportunity, renewal record | CRM (renewal records created from billing term dates) | Sales, SDRs, CSMs, RevOps admins | Marketing automation, warehouse | | Subscription, price, term, ARR | Billing | Order management, Finance | CRM (read-only), warehouse | | Account health, success plan | CS platform | Customer success | CRM summary fields | | Product usage | Product event store | Product engineering | Warehouse; derived fields to CRM | | Forecast submissions | CRM forecast module or forecasting tool | Sales managers | Warehouse snapshots | 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. ### End-to-end workflow: from first signal to renewal The sequence below follows one buying group through the hand-offs that RevOps governs. Each arrow that crosses a team boundary carries a clock. ::: figure Hand-offs from first signal to renewal, with the clocks RevOps measures ```mermaid 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) ``` Text equivalent: Marketing routes an MQL to a sales development representative (SDR), starting clock 1, time to first touch. The SDR accepts, rejects or recycles it. A qualified meeting goes to the account executive (clock 2, time to accept), who runs the opportunity through stages with exit criteria. A won deal goes to customer success with a hand-off checklist (clock 3, time to kick-off). Customer success onboards to first value (clock 4, time to value) and sends expansion signals back to the account executive (clock 5, time to engage). Before each term ends, customer success records a renewal call with its risk and expected ARR (clock 6, days of notice before the renewal date). ::: **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: | Exception | Rule (proposal) | Report that catches it | |---|---|---| | Lead has no owner (routing rule failed, owner left) | Fallback queue with a named queue owner; alert after 30 minutes | Unassigned leads older than 30 minutes | | Sales rejects the MQL | Reason code required; recycle to nurture | Rejection reasons by source, monthly | | Deal stalls in a stage | Ageing threshold per stage; manager review | Stage ageing over threshold | | Closed won with missing hand-off fields | Stage cannot close until required fields are set | Hand-off completeness | | Contract nears its end without a renewal record | Record created automatically from billing 120 days before term end | Contracts ending within 120 days without a renewal record | ## Practices, frameworks and tools ### Core practices and playbooks 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](#reference-implementation-operating-artefacts) and [labs](#hands-on-labs) in the next part let you try each one. #### Playbook: one funnel, written down 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".[^forr-mql-bye][^forr-guide] 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](#artefact-1-stage-dictionary-extract) 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).[^hubspot-lifecycle] 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. #### Playbook: lead routing and the speed-to-lead SLA 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.[^hbr-leads] (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.[^hubspot-dedupe] 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.[^hubspot-rotate] 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](#lab-2-intermediate-lead-routing-rules-and-the-speed-to-lead-sla) builds a small rule engine with these properties. #### Playbook: one forecast of record 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".[^fpp-judg] 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](#lab-3-intermediate-arr-bridge-grr-and-nrr-under-two-definitions) builds after the fact, and the split Forrester's 2021 Waterfall makes when it adds renewal, cross-sell and upsell opportunity types.[^forr-waterfall] 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. | Component | What it covers | Who makes the call | What RevOps defines | |---|---|---|---| | New business | First contracts with new customers in the period | Sales leadership, through the SalesOps forecast call | Stage dictionary; close-date and amount rules | | Expansion | Upsell and cross-sell to existing customers | Account management or customer success | Expansion record type and stages | | Renewal losses | Churn and contraction among contracts whose term ends in the period | Customer success, in the renewal review | Renewal record per contract; renewal date from billing; written risk bands | | Roll-up | Net new ARR and end-of-period ARR | RevOps compiles; the CRO commits; Finance is consulted | One ARR definition (Artefact 2); the snapshot rule | ::: figure The forecast of record as a control loop ```mermaid 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 ``` Text equivalent: Weekly snapshots of the pipeline and the renewal base feed the component calls, each made by its owner. Judgement adjustments with written reasons produce a forecast of record kept separate from the target. At period end the actual ARR movements are compared with it to compute error and bias by component and week. That analysis feeds back in two ways: owners recalibrate their calls, and RevOps fixes definitions, data hygiene and coaching. Amber: the steps where people judge and learn. ::: 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.[^fpp-judg] 6. **Score each component and the total** every quarter, with the sign stated (this page uses e = actual − forecast; see [metrics](#metrics-and-kpis)); errors in the parts can cancel in the total, as [Lab 4](#lab-4-advanced-score-the-forecast-of-record-by-component) 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](../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](../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. #### Playbook: CRM data quality 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.[^gl-dg] #### Playbook: changing the GTM stack safely 1. **Request** through one intake form ([Artefact 5](#artefact-5-gtm-change-request-form)); 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](#operating-model-and-governance)). 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. ### Methods, standards and frameworks 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: | Source | What it gives you | Status | |---|---|---| | Forrester's definition and B2B Revenue Waterfall | A definition; an opportunity- and buying-group-based demand model with acquisition, renewal, upsell and cross-sell opportunity types[^forr-def][^forr-target] | Analyst framework (details for clients) | | SiriusDecisions Demand Waterfall (earlier versions) | Lead-stage vocabulary such as sales-accepted and sales-qualified leads;[^ct-waterfall] CRMs still ship lead stages, for example HubSpot's default MQL and SQL lifecycle stages[^hubspot-lifecycle] | Historical analyst framework | | Bow-tie models (for example Winning by Design) | A customer-journey and data model that includes the post-sale half[^wbd] | Consultancy model, proprietary | | SEC guidance on key performance indicators (US) | Define metrics clearly, explain them, disclose method changes, keep controls[^sec-kpi] | Regulatory guidance for US public companies | | IFRS 15 / Topic 606 | When contract revenue is recognised[^ifrs15] | Accounting standards | | *Forecasting: Principles and Practice* | Error measures; principles for judgemental forecasts[^fpp-acc][^fpp-judg] | Textbook, general method | | Practitioner metric guides (Skok; a16z) | Common formulas and rules of thumb for SaaS metrics[^skok-1][^a16z] | Practitioner opinion | 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.[^sec-kpi] A good discipline for any board deck. ### Tooling landscape Tool categories matter more than brands; brands change. The examples are illustrative and were checked on 2026-10-18, not endorsed. | Category | Job | Examples (as of October 2026) | Selection questions | |---|---|---|---| | CRM | System of record for people, accounts, opportunities | Salesforce, HubSpot, Microsoft Dynamics 365; open source SuiteCRM (AGPLv3)[^suitecrm] and Twenty[^twenty] | Data model fit, API limits, admin skills available, total seat cost | | Marketing automation | Engagement, scoring, consent | Adobe Marketo Engage, HubSpot Marketing Hub, Salesforce Account Engagement | Sync behaviour with the CRM, consent model | | Routing and orchestration | Matching, routing, scheduling | Native CRM rules; LeanData, which describes itself as routing buyer signals and enforcing business rules[^leandata] | Rule transparency, audit log, fallback handling | | Forecasting and revenue intelligence | Forecast roll-ups, call analysis, deal risk | Clari Forecast (sold by Salesloft since their merger in December 2025),[^salesloft-merger] Gong, CRM-native forecasting | Snapshot history, explainability, data residency | | Sales engagement and revenue action orchestration | Sequenced outreach, activity capture, buyer signals for sellers | Outreach,[^outreach-mq] Salesloft,[^salesloft] CRM-native sequences | Suppression synced with the consent record; activity logged to the CRM; who may edit sequences | | CPQ and billing | Quotes, orders, subscriptions, invoices | CRM-native CPQ, dedicated CPQ, subscription billing platforms | Which system owns price and ARR | | CS platform | Health, success plans, renewals | Gainsight and others (see [CustomerOps](../customerops/)) | Health score transparency | | Warehouse and BI | Joined history, metric definitions | Cloud warehouses, BI tools, semantic layers (see [AnalyticsOps](../analyticsops/)) | Who owns definitions; write-back rules | | Enrichment | Firmographics, contacts | Data vendors; check lawful basis | Accuracy, licence terms, privacy | **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](#origins-and-evolution)); expect product names to move. ### Automation and AI 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".[^hubspot-predict] 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".[^brier] 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](#quality-security-privacy-and-compliance)). ## RevOps in practice ### Reference implementation: operating artefacts 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. #### Artefact 1: stage dictionary (extract) | Stage | Entry criteria (observable) | Exit criteria | Owner | Required fields | |---|---|---|---|---| | MQL | Fit score ≥ threshold **and** a hand-raise or engagement threshold | Accepted, rejected with reason, or recycled within 2 working days | SDR team | Source, country, company size | | 1. Discovery | Meeting held; a problem stated by the prospect | Problem, buying group and timeline confirmed | Account executive | Amount (estimate), close date | | 2. Qualified | Economic buyer identified; problem has a cost; timeline under 9 months | Evaluation plan agreed with the buyer | Account executive | Contact roles, competitor | | 3. Evaluation | Evaluation plan in writing | Technical and commercial fit confirmed | Account executive | Next step, next-step date | | 4. Proposal | Proposal or quote sent | Verbal selection, procurement started | Account executive | Quote ID, discount approval | | 5. Negotiation | Contract in legal or procurement review | Signed or lost | Account executive | Signature path, start date | | Closed won | Signed order booked | Hand-off checklist complete | AE then CSM | Term, ARR, products, success plan | | Closed lost | Lost or disqualified | None | Account executive | Loss reason, competitor | **Record types.** Following the split Forrester's Waterfall makes between acquisition, renewal, upsell and cross-sell opportunities,[^forr-target] ExampleCo uses three: | Record type | Created when | Stages | Amount means | Owner | |---|---|---|---|---| | New business | First meeting held | Stages 1 to 5 above | New ARR | Account executive | | Expansion | A customer's sponsor confirms a new need | Stages 2 to 5 above | Added ARR | Account manager or CSM | | Renewal | Automatically, 120 days before a contract's term ends | Open, Risk assessed, Terms proposed; then Renewed, Contracted or Churned | ARR up for renewal; the outcome records ARR kept | CSM | "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. #### Artefact 2: revenue metric definitions as code _Example status: syntax-checked YAML, not executed (ExampleCo is fictional; a metrics tool or a review process would consume it)._ ```yaml # 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. #### Artefact 3: hand-off SLA between marketing, sales development and sales _Example status: illustrative template._ ```text 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. ``` #### Artefact 4: sales-to-success hand-off checklist - [ ] 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 #### Artefact 5: GTM change request form _Example status: illustrative template._ ```text 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) ``` ### Hands-on labs 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. ::: warning Do not practise on real customer data CRM exports contain personal data about real people. Use the synthetic files below, or anonymised data under your company's rules; never copy a CRM export to a personal laptop for practice. ::: #### Lab 1 (beginner): cohort funnel, hand-off SLA and leakage **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)._ ```bash 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)._ ```python """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.** ```text 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` #### Lab 2 (intermediate): lead routing rules and the speed-to-lead SLA **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)._ ```bash 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)._ ```json { "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)._ ```python """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.** ```text 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` #### Lab 3 (intermediate): ARR bridge, GRR and NRR under two definitions **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)._ ```bash 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)._ ```python """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.** ```text 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](#metrics-and-kpis)). **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` #### Lab 4 (advanced): score the forecast of record by component **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)._ ```bash 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)._ ```python """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.** ```text 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,[^fpp-acc] 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,[^fpp-acc] 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). ### Use cases and scenarios | Scenario | Context | Method | Trade-off | Success measure | |---|---|---|---|---| | Two pipeline numbers | Board sees marketing's and sales' pipeline differ | Stage dictionary, one pipeline definition, recast history | Short-term embarrassment of restating | One number in all decks; disputes fall | | From MQL targets to opportunities | Marketing rewarded on MQL volume; sales ignores MQLs | Opportunity-based measurement; MQL kept as trigger | Marketing loses an easy number | Qualified pipeline created; acceptance rate | | Self-serve meets sales | Product sign-ups and a sales team overlap | Usage signals routed to sales; rules of engagement | Sales may chase users who would self-convert | Expansion ARR; conversion of signalled accounts | | Two CRMs after an acquisition | Different stages, fields and ARR rules | Map, merge, freeze definitions, then migrate | Months of dual reporting | Reconciled ARR; one forecast | | Documented practice: GitLab | Public handbook of a listed software company | Field Operations structure, release cadence, change tiers | One company's choices | Not measured here | ::: example Scenario 1 (illustrative): two pipeline numbers at the board meeting ExampleCo's CMO reports 18 million of pipeline created last quarter; the CRO reports 11 million. Both are right by their own definitions: marketing counts every opportunity with a marketing touch at any stage, sales counts stage-2-and-later opportunities at their current amount. **Method.** The definitions council adopts "qualified pipeline created = amount at entry to stage 2", assigns sourcing and influence as two separate reports, and recasts the last eight quarters. **Pitfalls.** Recasting history without a note; letting each team keep its old report "for continuity". **Success.** One number in board, marketing and sales decks within one quarter; the definitions page is linked from every pipeline report. ::: ::: example Scenario 2 (illustrative): moving marketing from MQL targets to opportunity measurement Marketing has hit its MQL target for six quarters while sales complains about lead quality. RevOps shows that most MQLs from two sources are rejected within a day, and that several accounts generated many MQLs for one eventual deal — Forrester's "multiple 'leads' will contribute to a single opportunity", from the series that also lists MQL volume as a measurement myth.[^forr-mql-bye][^forr-mql-myths] **Method.** Keep MQLs as an operational trigger for routing; change marketing's goal to qualified pipeline created in target accounts, with buying-group coverage (contacts per open opportunity) as a leading indicator. **Trade-off.** Marketing's metric moves more slowly and depends partly on sales; agree the attribution rules first. **Success.** Acceptance rate up, qualified pipeline per target account up, and no rise in unworked MQLs. ::: ::: example Scenario 3 (illustrative): self-serve sign-ups meet a sales team ExampleCo adds a free tier. Within weeks, sellers are calling every new sign-up, and self-serve customers complain. **Method.** RevOps defines a product signal (for example, a workspace that invites ten colleagues and connects a data source), routes only signalled accounts above a size threshold to sales, and writes rules of engagement for who owns an account both self-serve and in an open opportunity. ARR definitions are reviewed because usage revenue now matters; [Lab 3](#lab-3-intermediate-arr-bridge-grr-and-nrr-under-two-definitions) shows how much the choice moves NRR. **Pitfalls.** A signal that is a proxy for company size; sales commission on revenue that would have arrived anyway. **Success.** Higher conversion of signalled accounts than of a hold-out group, measured before roll-out. ::: ::: example Scenario 4 (illustrative): two CRMs after an acquisition ExampleCo buys a competitor with its own CRM, stages and ARR rules. **Method.** Freeze definitions first (one stage dictionary and ARR definition for both), map old values to new ones, report both businesses in the new definitions from a shared warehouse before migrating any records, then migrate in waves, reconciling account counts, open pipeline and ARR at each wave. **Pitfalls.** Migrating before agreeing definitions; dropping history the forecast needs. **Success.** One forecast and one ARR figure for the combined company, reconciled to billing. ::: **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](#roles-ownership-and-raci) and [operating model](#operating-model-and-governance).[^gl-fieldops] The handbook documents choices, not results. ## Measure, govern, pay ### Metrics and KPIs 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](#lab-3-intermediate-arr-bridge-grr-and-nrr-under-two-definitions)). Function-specific measures live on the specialist pages: win rate, sales cycle and pipeline coverage in [SalesOps](../salesops/); campaign metrics in [MarketingOps](../marketingops/); health and churn drivers in [CustomerOps](../customerops/). | Metric | Definition / formula | Data source | Pitfall | Cadence | |---|---|---|---|---| | Hand-off SLA attainment | MQLs accepted or rejected within the SLA ÷ MQLs created, by creation cohort | CRM timestamps | Averages hide never-actioned records | Weekly | | Speed to lead | Median and 90th percentile minutes from creation to first touch; plus count of open breaches | CRM, sales engagement tool | Excludes untouched leads unless you count them | Weekly | | Stage conversion (cohort) | Records entering stage n+1 ÷ records entering stage n, for one entry cohort, at a stated age | Stage history snapshots | Period ratios mix cohorts | Monthly | | Qualified pipeline created | Sum of amounts at entry to the qualified stage in the period | Opportunity history | Amount edits after entry; double counting | Monthly | | Forecast error, APE, bias | e = actual − forecast; APE = \|e\| ÷ actual; bias = mean e; for each component and the total, at a fixed week | Forecast-of-record snapshots | Scoring only the total, or only the final week | Quarterly | | Renewal records in place | Contracts ending within 120 days that have a renewal record ÷ all contracts ending within 120 days | Billing, CRM | Contracts missing from the billing export | Weekly | | ARR bridge | start + new + expansion − contraction − churn = end | Billing snapshots | Reactivations and FX moves unclassified | Monthly | | GRR | (start ARR − contraction − churn) ÷ start ARR, same customers, 12 months | Billing | Including expansion by mistake | Quarterly | | NRR | (start ARR + expansion − contraction − churn) ÷ start ARR, same customers | Billing | Usage swings; method changes | Quarterly | | CAC (fully loaded, blended) | Sales and marketing cost of acquiring new customers ÷ all new customers won in the period; variants below | Finance ledger, CRM | Mixing expansion cost into acquisition; unlabelled variants | Quarterly | | CAC payback (months) | CAC ÷ (new ARR per customer × gross margin ÷ 12) | Finance, billing | Ignoring gross margin | Quarterly | | LTV (simple) | ARR per customer × gross margin × expected lifetime (1 ÷ annual churn rate; say which churn; capped or discounted) | Billing, finance | Uncapped lifetimes inflate it | Half-yearly | | Data completeness | Records meeting required fields for their stage ÷ records in that stage | CRM | Default values that pass validation | Weekly | 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;[^ddog][^snow][^wday] hence the SEC's expectation of a clear definition for every key metric (see [methods](#methods-standards-and-frameworks)).[^sec-kpi] The ARR bridge follows the split of net ARR into new, expansion and churned ARR that Skok describes.[^skok-2] 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.[^skok-1] 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".[^a16z] 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.[^a16z] The simple LTV here follows Skok's form (lifetime = 1 ÷ churn rate)[^skok-1] with gross margin and no discount, so read it as an upper bound. #### A worked calculation ::: example ExampleCo, financial year to 2026-09-30 (illustrative numbers) **Retention.** ARR on 2025-09-30 was 10.0 million. During the year: new 1.8 m, expansion 1.1 m, contraction 0.4 m, churn 0.7 m. End ARR = 10.0 + 1.8 + 1.1 − 0.4 − 0.7 = **11.8 m**. GRR = (10.0 − 0.4 − 0.7) ÷ 10.0 = **89.0%**. NRR = (10.0 + 1.1 − 0.4 − 0.7) ÷ 10.0 = **100.0%**: expansion exactly replaced what was lost. **Acquisition.** 60 new customers brought the 1.8 m of new ARR: 30,000 each. Sales and marketing cost attributed to acquiring them was 2.7 m, so fully loaded, blended CAC = 2,700,000 ÷ 60 = **45,000**. With an 80% gross margin, each new customer contributes 30,000 × 0.80 ÷ 12 = 2,000 of gross margin a month, so CAC payback = 45,000 ÷ 2,000 = **22.5 months**. **Lifetime value, three ways.** The churn rate here is gross revenue churn, 1 − GRR = 11%. It includes contraction, so 1 ÷ 0.11 ≈ 9.1 years is how long a unit of ARR lasts on average, not how long a customer stays (Skok's formula uses the customer churn rate). Uncapped: LTV ≈ 30,000 × 0.80 × 9.1 ≈ 218,000, so LTV:CAC ≈ **4.8**. Capped at five years: 30,000 × 0.80 × 5 = 120,000, LTV:CAC ≈ **2.7**. Discounted at 10% a year (this page's arithmetic: with margin received yearly and the churn rate applied each year, the discounted lifetime is 1 ÷ (churn + rate) = 1 ÷ 0.21 ≈ 4.8 years): LTV ≈ 114,000, LTV:CAC ≈ **2.5**. Against Skok's rule of thumb of 3,[^skok-1] the verdict flips with an assumption. Show the variants, and say which one the board sees. **Forecast.** In week 4 of the last quarter the forecast of record for net new ARR was 0.50 m; the actual was 0.45 m. Error e = 0.45 − 0.50 = −0.05 m (over-forecast); APE = 0.05 ÷ 0.45 = 11.1%. Score each component the same way, because a total can hide offsetting errors ([Lab 4](#lab-4-advanced-score-the-forecast-of-record-by-component)). ::: **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](#use-cases-and-scenarios)); "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. ### Quality, security, privacy and compliance Nothing here is legal advice; it orients RevOps teams so they know when to involve [PrivacyOps](../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";[^gdpr4] a named buyer's work email and call notes qualify. Direct marketing "may be regarded as carried out for a legitimate interest" (recital 47),[^gdpr-r47] 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)).[^eprivacy] 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).[^ico-pecr] The US FTC says CAN-SPAM "makes no exception for business-to-business email" and opt-outs must be honoured within 10 business days;[^ftc-canspam] California's CCPA exemptions for business-to-business and employment information expired on 31 December 2022.[^ccpa] [MarketingOps](../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".[^gdpr21] 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](../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;[^sec-kpi] in practice, reconcile CRM bookings with billing monthly, keep an audit trail for metric definitions and changes, and review commission inputs before payroll. ### Cost, capacity and sustainability 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. ### Assurance of the operating model 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](#playbook-crm-data-quality)): | Check | How | Signal of trouble | |---|---|---| | Definition drift audit (quarterly) | Compare report filters and automation conditions with the stage dictionary | Reports that count stages the dictionary excludes | | Routing audit (monthly) | Trace a random sample of 20 leads through the rules | Hits on the default rule above an agreed share | | ARR reconciliation (monthly) | CRM ARR versus billing ARR by customer | Differences above a tolerance (for example 0.5%) | | Forecast retrospective (quarterly) | Error and bias by component and week; adjustment log | Persistent bias in one component, even when the total looks right | | Renewal-base check (monthly) | Compare billing term-end dates with renewal records | Contracts ending soon without a renewal record | 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. ## When things go wrong ### Common failures and troubleshooting | Symptom | Likely cause | Diagnosis | Fix | Prevention | |---|---|---|---|---| | Leads sit unworked | Routing rule gap, owner left, round robin includes absent people | Unassigned and breach reports; rule-hit log | Fallback queue with owner; re-route | Default rule; availability sync; weekly audit | | Sales rejects most MQLs | MQL criteria not agreed or scoring drifted | Rejection reasons by source and score band | Re-agree criteria; change scoring | Definitions council; quarterly calibration | | Two numbers for pipeline or ARR | Different filters, snapshots or definitions | Compare the definitions, then the snapshots, then the code | Pick the canonical definition; recast | Versioned definitions; one source per metric | | Forecast surprises | Optimistic probabilities, slipped close dates, sandbagging | Error and bias by week; slippage report | Recalibrate; enforce exit criteria | Snapshots, scoring, documented adjustments | | Churn surprises at quarter end | Renewals outside the forecast; untested risk bands | Contracts that ended without a renewal record; loss error by band | Renewal records from billing; score the loss component | Monthly renewal-base check | | Duplicate accounts and contacts | Imports, API-created records, no matching | Duplicate rate by source | Merge with a log | Match before create; unique keys | | Integration silently stops | Expired token, API limit, schema change | Sync error logs; record counts per day | Restore; replay missed changes | Monitoring on record counts; named integration users | | Hand-off to success loses context | No checklist, optional fields | Kick-off delays; first-90-day churn reasons | Required hand-off fields at closed won | Checklist as a stage gate | | Commission disputes | Credit and booking rules unclear | Disputes by rule type | Publish rules; one dispute process | Definitions owned with Finance and SalesOps | ### Worked runbook: a forecast miss found in week 9 (illustrative) ::: example Incident: the new-business commit falls 15% in one week **Situation.** ExampleCo's new-business commit, stable at 2.6 m for eight weeks, drops to 2.2 m in week 9 of a 13-week quarter. The CFO asks whether the drop is real and what the forecast of record now says. **1. Stabilise the number (day 1).** Freeze this week's snapshot. Tell leadership the figure is under review and give a range, not a new point estimate. **2. Rule out a measurement change.** Compare this week's definition and snapshot with last week's: did a stage, filter, currency rate or integration change? Here, no. **3. Decompose the gap by component, then by deal.** The renewal and expansion calls had not moved, so all 0.4 m sat in new business: 0.25 m slipped (close dates moved to next quarter), 0.10 m lost, 0.05 m reduced in amount. Nothing was missing from the pipeline: all the deals had been in commit since week 3. **4. Find the mechanism.** The four slipped deals had all sat in Negotiation without a signature path recorded, their last activity more than 21 days old. The exit criteria were not enforced, and the stage probabilities were optimistic (a back-test, which [SalesOps](../salesops/) runs, would have shown it). **5. Act.** Managers re-submit with written reasons; RevOps adds "signature path" as a required field for Negotiation, flags committed deals without activity for 14 days, and publishes the revised forecast with a range. **6. Learn (retrospective in week 1 of the next quarter).** Score the forecast of record by component and week; SalesOps recalibrates Negotiation's probability from history; track how often close dates move twice. **Outcome measures.** Week-9 error in later quarters; share of committed deals with a signature path; slippage rate. ::: ::: figure Triage: why did the forecast move? ```mermaid %%{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 ``` Text equivalent: When the forecast moves sharply, first ask whether definitions, the snapshot and exchange rates are unchanged. If not, it is a measurement change: recast and compare again. If they are unchanged, locate the component and the deals: slipped deals (check exit criteria and activity), lost deals (loss reasons, competitor), deals that were never in the pipeline (a creation shortfall weeks earlier), or renewal losses the risk bands missed or that had no renewal record. Every branch ends in a re-submission with written reasons and a range, followed by a retrospective that recalibrates probabilities, fixes rules and coaches. Red: the five diagnoses. ::: ### Anti-patterns and myths - **"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".[^forr-myths] - **"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](#use-cases-and-scenarios). - **"The forecast is the target with a haircut."** Targets are decisions; forecasts are measurements.[^fpp-judg] - **"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](#lab-3-intermediate-arr-bridge-grr-and-nrr-under-two-definitions)). - **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. ## Deciding and adopting ### When to use RevOps and when not to **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](../analyticsops/) and [BizOps](../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. ### Decision framework 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. ::: figure Decision tree: do you need RevOps, and in which shape? ```mermaid 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 ``` Text equivalent: With fewer than two teams handing customers on, do not create a RevOps team; one person owns the CRM and the definitions. With agreed definitions and one forecast already in place, keep functional ops and add a definitions council. Otherwise start hybrid — a shared centre for data, systems and analytics — unless there is one go-to-market motion and a clear executive sponsor, in which case start centralised. Every route then builds the stage dictionary, SLAs, snapshots and forecast scoring. ::: 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: | Criterion (weight) | Decentralised + council | Hybrid CoE | Centralised | |---|---|---|---| | Speed to one set of definitions (30%) | 2 | 4 | 5 | | Keeps specialist depth (25%) | 5 | 4 | 2 | | Change capacity and focus (20%) | 2 | 4 | 4 | | Political cost of the change (15%) | 5 | 3 | 1 | | Clear accountability for data (10%) | 2 | 4 | 5 | | **Weighted score** | **3.20** | **3.85** | **3.45** | 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. ### Maturity model This five-level model is **this Atlas's proposal**, not an industry standard. Levels describe observable behaviour. | Level | Observable behaviour | Evidence to look for | Exit criterion (to move up) | |---|---|---|---| | 1. Fragmented | Each team has its own definitions, reports and tools | Different "pipeline" numbers in different decks | A written stage dictionary adopted by all teams | | 2. Defined | Shared dictionary and SLAs exist; data quality is uneven | SLA reports exist but are not acted on | SLA attainment reviewed weekly with actions | | 3. Managed | Routing, SLAs and data quality are run weekly; pipeline snapshots stored | Fewer stuck records; snapshot history | Forecast error and bias scored for two quarters | | 4. Measured | Forecast of record scored by component; ARR bridge reconciled to billing; definitions versioned | Bias trending to zero; recasts documented | Changes tested and released on a cadence; metrics feed planning | | 5. Adaptive | Experiments on routing, signals and hand-offs with hold-out groups; capacity planned from funnel data | Decisions cite experiment results | Sustain; revisit definitions when the GTM motion changes | 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. ### Adoption roadmap: 30/60/90 days | Window | Actions | Owner | Output | Measure | |---|---|---|---|---| | Days 1–30 | Inventory definitions and systems; interview each team; start weekly pipeline snapshots; publish a draft stage dictionary; add a fallback queue, a default routing rule, an unassigned-lead alert; remove obviously dead fields | RevOps lead and admin | Inventory, draft dictionary, snapshot job, rules in production | Snapshots stored weekly; unassigned leads over 30 minutes | | Days 31–60 | Adopt the dictionary at a definitions council; write the MQL SLA; required fields by stage; first SLA and data-quality scorecards; agree ARR, GRR, NRR formulas with Finance; reconcile CRM with billing | RevOps with functional leaders and Finance | Signed dictionary and SLA; scorecards; metric definitions v1 | SLA attainment baseline; completeness; reconciliation difference | | Days 61–90 | Forecast-of-record calendar, components and adjustment log; renewal records from billing; first component score; GTM release cadence and change form; sales-to-success hand-off checklist as a stage gate; retention bridge monthly | RevOps with sales and CS leadership | Forecast process; release notes; gate live; bridge | Error and bias baseline; hand-off completeness | 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. ## Toolkit ### Checklists **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](#assurance-of-the-operating-model) 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](#worked-runbook-a-forecast-miss-found-in-week-9-illustrative). ### Templates **One-page RevOps charter** ```text REVOPS CHARTER (, version , ) 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 Accountable 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** ```text METRIC: ID: VERSION: from 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)** ```text 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** ```text DECISION : 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: ``` ### Deep comparisons The [boundaries table](#how-revops-relates-to-other-ops) says who owns what; this one says where a problem does not belong to RevOps. | Situation | Take it to | Because | |---|---|---| | Sellers miss quota in one region | [SalesOps](../salesops/) | Territories, capacity and compensation are sales-side design | | Campaigns convert poorly while leads are accepted on time | [MarketingOps](../marketingops/) | Scoring and campaign execution sit inside marketing | | Churn clusters in one segment | [CustomerOps](../customerops/) | Health scores and renewal plays are success-side work | | Two systems disagree about the same field | [MarTechOps](../martechops/) | Integration architecture is the plumbing question | | The company metric tree contradicts the funnel | [BizOps](../bizops/) | Planning spans more than revenue | | Experience scores fall while retention holds | [CXOps](../cxops/), [SupportOps](../supportops/) | Journey and service measurement are theirs | ### FAQ **Is RevOps a team or a way of working?** Both, depending on the company (see [what RevOps is not](#what-revops-is-not-naming-and-boundaries)). 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](#use-cases-and-scenarios)). 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)[^brier] 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.[^a16z][^ifrs15] They move at different times. ## Going further ### Advanced topics and emerging direction - **Usage-based revenue (active practice, definitions unsettled).** When usage dominates, ARR, NRR and forecasting change shape; public companies already use different bases ([Lab 3](#lab-3-intermediate-arr-bridge-grr-and-nrr-under-two-definitions)). - **AI in forecasting and seller workflows (fast-moving vendor area).** The vendor market is still forming (2025 row of the [timeline](#origins-and-evolution)); 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](../analyticsops/) and [DataOps](../dataops/). ### Learning path - **Prerequisites:** spreadsheets; the basic B2B sales process; a profit-and-loss statement. - **One-day primer:** read [What RevOps is](#what-revops-is), the [stage dictionary](#artefact-1-stage-dictionary-extract) and the [metrics table](#metrics-and-kpis); run [Lab 1](#lab-1-beginner-cohort-funnel-hand-off-sla-and-leakage). - **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](#adoption-roadmap-306090-days); score one quarter of your forecast of record by component; reconcile CRM and billing ARR for twenty customers. - **Specialisations:** GTM systems administration (with [MarTechOps](../martechops/) and [IntegrationOps](../integrationops/)); revenue analytics and forecasting; deal desk and quote-to-cash (with [SalesOps](../salesops/)); retention analytics (with [CustomerOps](../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. ## Wrap-up ### Executive recap and cheat sheet | Topic | Remember | |---|---| | What it is | One revenue process across marketing, sales and success: shared definitions, governed hand-offs, one forecast, metrics defined once | | First decisions | Unit of the funnel (leads or opportunities); system of record per object; who chairs the definitions council | | Essential practices | Stage dictionary; routing with a default rule; hand-off SLAs; weekly snapshots; a forecast of record scored by component; change releases | | Core metrics | SLA attainment, speed to lead, qualified pipeline created, forecast error and bias by component, ARR bridge, GRR, NRR, CAC payback | | Tool classes | CRM, marketing automation, routing, forecasting, CPQ and billing, CS platform, warehouse and BI | | Watch-outs | Silent definition changes; period ratios; uncapped LTV; MQL targets; a forecast without renewals; RevOps owning the number | | Next actions | The [quick-start checklist](#checklists), then a draft dictionary and an ARR definition agreed with Finance | ### A judgement call: centralise now, or build a centre of excellence first? ::: decision The dilemma ExampleCo (300 people, three functional ops teams, a new CRO) has two pipeline numbers and a forecast that missed by 12% two quarters running. The CRO proposes moving all twelve ops staff into one RevOps team reporting to her within a month. The CMO and VP of customer success want to keep their ops teams and create a shared centre for data and systems instead. ::: **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;[^forr-myths] 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. ### Learning objectives and mastery check 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? ::: answer Answer Publish the cohort figure with its age ("25% at 9 to 12 weeks, still maturing": the February MQLs are 9 to 12 weeks old at the lab's 30 April snapshot), or wait until the cohort matures. The period ratio divides opportunities created in February, mostly from January MQLs, by February MQLs: it mixes cohorts and moves with volume, not quality. Lab 1 reproduces this. ::: 2. Your median time to first touch is 25 minutes against a 60-minute SLA. Is the SLA being met? ::: answer Answer Not necessarily. The median includes only touched leads; never-touched and slow leads are hidden. Report attainment (the share of all leads touched within the SLA) and the count of open breaches. In Lab 2 the median is 25 minutes but attainment is 55.6%. ::: 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. ::: answer Answer GRR = (5.0 − 0.2 − 0.3) ÷ 5.0 = 90.0%. NRR = (5.0 + 0.6 − 0.2 − 0.3) ÷ 5.0 = 102.0%. New ARR (0.9 m) appears in neither: both measure only customers present at the start. ::: 4. A competitor publishes NRR of 120%; yours is 108%. Your CEO asks why you are worse. What do you check first? ::: answer Answer The definitions: ARR or revenue base, whether usage counts, cohort and window, averaging method, currency, treatment of acquisitions; listed companies differ on each (see [metrics](#metrics-and-kpis)). Compare trends in your own consistent series before comparing levels. ::: 5. Sales leadership wants the forecast set equal to the quarterly target minus 5% "to stay ambitious". What is wrong? ::: answer Answer It confuses a target (a decision) with a forecast (a measurement). The forecasting literature recommends keeping them separate and forecasters distinct from the users of forecasts: a forecast tied to the target cannot warn you of a miss. Submit a forecast from the pipeline with documented adjustments; keep the target separate. ::: 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? ::: answer Answer Keep scoring them. An accurate total can hide offsetting biases: in Lab 4, new business is over-forecast by 78.3k a quarter and renewal losses by 71.7k, so the total's mean error is only −3.3k. When one owner fixes their bias alone, the total gets worse. Report each component's error and bias to its owner. ::: 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? ::: answer Answer The objection did not propagate across systems. Under the GDPR, after an objection to direct marketing the data must no longer be processed for that purpose. Make the marketing platform the system of record for consent and objections, give sellers and support one way to record an objection in it, sync suppression to every outreach tool, test it in the quarterly audit. ::: 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? ::: answer Answer Probably not yet. With few hand-offs, assign one accountable owner for the CRM and definitions, start pipeline snapshots and forecast scoring, and write the stage dictionary. Revisit when separate marketing and success teams exist or numbers conflict. ::: ### Conclusion 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. ## Sources and further reading 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. [^forr-def]: [Revenue Operations: Driving Better Customer Experiences And Growth](https://www.forrester.com/blogs/forrester-decisions-for-revenue-operations/) — Forrester blog, Cristina De Martini, 2023-06-04. Checked 2026-10-19. [^forr-launch]: [New Forrester Decisions Research Services To Help B2B Leaders Drive Scalable And Sustained Business Growth](https://www.forrester.com/press-newsroom/forrester-decisions-services-revenue-ecosystem-alignment/) — Forrester press release, 2023-06-05. Checked 2026-10-18. [^forr-myths]: [Revenue Operations: Nine Myths And Two Realities](https://www.forrester.com/blogs/revenue-operations-nine-myths-and-two-realities/) — Forrester blog, Laura Cross with Christian Jibilian, 2023-09-15. Checked 2026-10-18. [^forr-radar]: [Why Revenue Operations (RevOps) Should Be On Your Radar](https://www.forrester.com/blogs/why-revenue-operations-revops-should-be-on-your-radar/) — Forrester blog, Jerry Zhao, 2024-08-20. Checked 2026-10-18. [^forr-waterfall]: [Forrester Debuts Next-Generation B2B Revenue Waterfall To Help Firms Accelerate Revenue Growth](https://www.forrester.com/press-newsroom/forrester-debuts-next-generation-b2b-revenue-waterfall-to-help-firms-accelerate-revenue-growth/) — Forrester press release, 2021-05-04. Checked 2026-10-18. [^forr-target]: [Putting Forrester's B2B Revenue Waterfall Into Action: Six Tips For Laser-Focused Targeting](https://www.forrester.com/blogs/putting-forresters-b2b-revenue-waterfall-into-action-six-tips-for-laser-focused-targeting/) — Forrester blog, Alisa Groocock and Robert Muñoz, 2021-07-22. Checked 2026-10-18. [^forr-guide]: [Drive Revenue Engine Performance (B2B Revenue Waterfall guide)](https://www.forrester.com/resources/b2b-marketing-planning/revenue-waterfall-guide) — Forrester, undated. Checked 2026-10-18. [^forr-mql-myths]: [Saying Goodbye To MQLs: Six MQL Myths Squashed To Shift Your Leads-Based Culture](https://www.forrester.com/blogs/saying-goodbye-to-mqls-6-mql-myths-squashed-to-shift-your-leads-based-culture/) — Forrester blog, Amy Hawthorne, Terry Flaherty, Maria Alexandrou, 2023-10-30. Checked 2026-10-18. [^forr-mql-bye]: [Saying Goodbye To MQLs: A Parting That Is All Sweet And No Sorrow](https://www.forrester.com/blogs/saying-goodbye-to-mqls-sweet-and-no-sorrow/) — Forrester blog, Simon Daniels, 2023-11-21. Checked 2026-10-18. [^forr-sirius]: [Forrester Completes Acquisition Of SiriusDecisions (Exhibit 99.1 to Form 8-K)](https://www.sec.gov/Archives/edgar/data/1023313/000119312519001157/d659979dex991.htm) — Forrester Research via SEC EDGAR, 2019-01-03. Checked 2026-10-18. [^forr-clari]: [Clari-Salesloft Merger: A Bold, High-Stakes Bid For Market Dominance](https://www.forrester.com/blogs/clari-salesloft-merger-a-bold-high-stakes-bid-for-market-dominance/) — Forrester blog, Anthony McPartlin, 2025-08-14 (written when the merger was announced; the post says the deal was expected to close in early Q4). Checked 2026-10-23. [^gartner-2021]: [Gartner Predicts 75% of the Highest Growth Companies in the World Will Deploy a RevOps Model by 2025](https://web.archive.org/web/20260218130426/https://www.gartner.com/en/newsroom/press-releases/2021-05-17-gartner-predicts-75--of-the-highest-growth-companies-) — Gartner press release, 2021-05-17 (read via the Internet Archive; gartner.com blocked automated access). Checked 2026-10-18. [^cnbc-linkedin]: [The 10 fastest-growing jobs in the U.S. right now](https://www.cnbc.com/2023/01/18/the-10-fastest-growing-jobs-in-the-us-right-now-many-pay-over-100000.html) — CNBC, 2023-01-18 (report on LinkedIn's Jobs on the Rise 2023). Checked 2026-10-18. [^revops-coop]: [RevOps Co-op](https://www.revopscoop.com/) — community home page (member count is the community's own claim). Checked 2026-10-18. [^ct-waterfall]: [The new Demand Waterfall from SiriusDecisions; An Introduction](https://customerthink.com/the_new_demand_waterfall_from_siriusdecisions_an_introduction/) — CustomerThink, Paul Mosenson, 2012-05-24 (practitioner summary). Checked 2026-10-18. [^informs-rm]: [About us](https://connect.informs.org/rmp/about/about-us) — INFORMS Revenue Management and Pricing Section. Checked 2026-10-18. [^hfma-rcm]: [Revenue Cycle Management](https://www.hfma.org/revenue-cycle/revenue-cycle-management/) — Healthcare Financial Management Association. Checked 2026-10-18. [^ifrs15]: [IFRS 15 Revenue from Contracts with Customers](https://www.ifrs.org/issued-standards/list-of-standards/ifrs-15-revenue-from-contracts-with-customers/) — IFRS Foundation. Checked 2026-10-18. [^wbd]: [Winning by Design Releases Updated Bowtie Model and Benchmarks](https://winningbydesign.com/press/winning-by-design-releases-updated-bowtie-model-and-benchmarks-to-provide-go-to-market-teams-with-a-standardized-customer-journey-and-data-model/) — Winning by Design press release, 2023-10-11. Checked 2026-10-18. [^sf-leads]: [Track Prospects with Salesforce Leads](https://trailhead.salesforce.com/content/learn/modules/prospect-tracking-with-salesforce-leads-quick-look/track-prospects-with-salesforce-leads) — Salesforce Trailhead. Checked 2026-10-18. [^hubspot-lifecycle]: [Use lifecycle stages](https://knowledge.hubspot.com/records/use-lifecycle-stages) — HubSpot Knowledge Base, updated 2026-07-17. Checked 2026-10-18. [^hubspot-forecast]: [Set up the forecast tool](https://knowledge.hubspot.com/forecast/set-up-the-forecast-tool) — HubSpot Knowledge Base, updated 2026-09-09. Checked 2026-10-18. [^hubspot-dedupe]: [Deduplication of records](https://knowledge.hubspot.com/records/deduplication-of-records) — HubSpot Knowledge Base, updated 2026-09-08. Checked 2026-10-18. [^hubspot-rotate]: [Assign and rotate record owners using workflows](https://knowledge.hubspot.com/workflows/assign-and-rotate-record-owners-using-workflows) — HubSpot Knowledge Base, updated 2026-09-23. Checked 2026-10-18. [^hubspot-predict]: [Determine likelihood to close with predictive lead scoring](https://knowledge.hubspot.com/articles/kcs_article/contacts/determine-likelihood-to-close-with-predictive-lead-scoring) — HubSpot Knowledge Base, updated 2026-01-11. Checked 2026-10-18. [^hbr-leads]: [The Short Life of Online Sales Leads](https://hbr.org/2011/03/the-short-life-of-online-sales-leads) — James B. Oldroyd, Kristina McElheran and David Elkington, Harvard Business Review, March 2011 (only the free introduction was read). Checked 2026-10-18. [^sec-kpi]: [Commission Guidance on Management's Discussion and Analysis of Financial Condition and Results of Operations, Release No. 33-10751](https://www.sec.gov/rules/interp/2020/33-10751.pdf) — US Securities and Exchange Commission, 2020-01-30. Checked 2026-10-18. [^ddog]: [Datadog, Inc. Form 10-K for the year ended 31 December 2025](https://www.sec.gov/Archives/edgar/data/1561550/000162828026008819/ddog-20251231.htm) — SEC EDGAR, 2026 (sections on ARR and dollar-based net retention rate). Checked 2026-10-18. [^snow]: [Snowflake Inc. Form 10-K for the year ended 31 January 2026](https://www.sec.gov/Archives/edgar/data/1640147/000164014726000008/snow-20260131.htm) — SEC EDGAR, 2026 (section "Net Revenue Retention Rate"). Checked 2026-10-18. [^wday]: [Workday, Inc. Form 10-K for the year ended 31 January 2026](https://www.sec.gov/Archives/edgar/data/1327811/000132781126000014/wday-20260131.htm) — SEC EDGAR, 2026 (section "Gross Revenue Retention Rate"). Checked 2026-10-18. [^skok-1]: [SaaS Metrics – A Guide to Measuring and Improving What Matters](https://www.forentrepreneurs.com/saas-metrics/) — David Skok, For Entrepreneurs, c. 2010. Checked 2026-10-18. [^skok-2]: [SaaS Metrics 2.0 – A Guide to Measuring and Improving What Matters](https://www.forentrepreneurs.com/saas-metrics-2/) — David Skok, For Entrepreneurs, undated. Checked 2026-10-18. [^a16z]: [16 Startup Metrics](https://a16z.com/16-startup-metrics/) — Jeff Jordan, Anu Hariharan, Frank Chen and Preethi Kasireddy, Andreessen Horowitz, 2015-08-21. Checked 2026-10-18. [^fpp-acc]: [Forecasting: Principles and Practice (3rd ed.), Evaluating point forecast accuracy](https://otexts.com/fpp3/accuracy.html) — Rob J Hyndman and George Athanasopoulos, OTexts, 2021. Checked 2026-10-18. [^fpp-judg]: [Forecasting: Principles and Practice (3rd ed.), Judgmental forecasts](https://otexts.com/fpp3/judgmental.html) — Rob J Hyndman and George Athanasopoulos, OTexts, 2021 (sections 6.2 and 6.7). Checked 2026-10-18. [^brier]: [sklearn.metrics.brier_score_loss](https://scikit-learn.org/stable/modules/generated/sklearn.metrics.brier_score_loss.html) — scikit-learn 1.9.1 documentation. Checked 2026-10-18. [^gl-fieldops]: [Field Operations](https://handbook.gitlab.com/handbook/sales/field-operations/) — GitLab Handbook, last modified 2025-04-30. Checked 2026-10-18. [^gl-spekit]: [Spekit for Operations/Process/Tools Updates](https://handbook.gitlab.com/handbook/sales/field-operations/release-schedule/) — GitLab Handbook, last modified 2026-07-28. Checked 2026-10-18. [^gl-dg]: [Data Governance](https://handbook.gitlab.com/handbook/sales/field-operations/data-intelligence/data-governance/) — GitLab Handbook, last modified 2024-06-27. Checked 2026-10-18. [^outreach-mq]: [Outreach named a Leader in the 2025 Gartner Magic Quadrant for Revenue Action Orchestration Platforms](https://www.outreach.ai/resources/blog/gartner-magic-quadrant-2025) — Outreach blog (vendor), 2025-12-18; the post names the report "Magic Quadrant for Revenue Action Orchestration Platforms", 15 December 2025 (Rietberg, Gottlieb). Checked 2026-10-23. [^salesloft]: [Salesloft home page](https://www.salesloft.com/) — Salesloft (clari.com returned HTTP 301 to this page on 2026-10-18; the page lists Clari Forecast). Checked 2026-10-18. [^salesloft-merger]: [Clari and Salesloft Complete Merger and Appoint Steve Cox as CEO to Build the First Predictive Revenue System](https://salesloft.com/company/newsroom/clari-salesloft-merger) — Salesloft newsroom (vendor statement about its own merger), 2025-12-03. Completion terms were not verified beyond this announcement. Checked 2026-10-23. [^leandata]: [LeanData home page](https://www.leandata.com/) — LeanData (vendor self-description). Checked 2026-10-18. [^suitecrm]: [salesagility/SuiteCRM](https://github.com/salesagility/SuiteCRM) — GitHub, AGPLv3. Checked 2026-10-18. [^twenty]: [twentyhq/twenty](https://github.com/twentyhq/twenty) — GitHub (open-source CRM project). Checked 2026-10-18. [^gdpr4]: [Art. 4 GDPR: Definitions](https://gdpr-info.eu/art-4-gdpr/) — gdpr-info.eu (unofficial text). Checked 2026-10-18. [^gdpr-r47]: [Recital 47 GDPR: Overriding legitimate interest](https://gdpr-info.eu/recitals/no-47/) — gdpr-info.eu (unofficial text). Checked 2026-10-18. [^gdpr21]: [Art. 21 GDPR: Right to object](https://gdpr-info.eu/art-21-gdpr/) — gdpr-info.eu (unofficial text). Checked 2026-10-18. [^eprivacy]: [Directive 2002/58/EC concerning the processing of personal data and the protection of privacy in the electronic communications sector (Directive on privacy and electronic communications), consolidated text of 19.12.2009, Article 13](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02002L0058-20091219) — EUR-Lex (official consolidated text). Checked 2026-10-19. [^ico-pecr]: [Electronic mail marketing (guide to PECR)](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guide-to-pecr/electronic-and-telephone-marketing/electronic-mail-marketing/) — UK Information Commissioner's Office (under review). Checked 2026-10-18. [^ftc-canspam]: [CAN-SPAM Act: A Compliance Guide for Business](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) — US Federal Trade Commission, August 2023 (edited January 2024). Checked 2026-10-18. [^ccpa]: [California Consumer Privacy Act (CCPA)](https://oag.ca.gov/privacy/ccpa) — California Department of Justice, updated 2026-08-28 (FAQ A.11). Checked 2026-10-18. **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](https://experienceleague.adobe.com/en/docs/marketo/using/home) and [Dynamics 365 Sales](https://www.microsoft.com/en-us/dynamics-365/products/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.