--- title: "SalesOps" slug: salesops category: business term_status: established evidence_status: partially_verified summary: "SalesOps (sales operations) designs and runs the machinery of a sales team: capacity plans, territories, quotas, the CRM, the pipeline and forecast process, commission plans and the deal desk, so sellers can sell and leaders can trust the number." audience: [Beginners, Sales operations analysts, Sales leaders and managers, Finance and RevOps partners, CRM administrators] last_verified: 2026-10-23 key_takeaways: - "SalesOps is an established function with stable jobs (territories, quotas, forecast process, CRM, commissions, deal desk); RevOps integrates marketing, sales and customer success, and the split between the two Atlas pages is an editorial distinction." - "Capacity, not quota, decides what a team can sell: ramp, attrition and what ramped sellers really book usually open a gap that late hires cannot close." - "Derive pipeline coverage from your own conversion history and in-quarter deal creation; a borrowed 3x is a guess." - "A forecast is a measured process: stage exit criteria, category rules, a weekly call, and a recorded error and bias for every method and caller." - "Compensation plans behave like code with legal and accounting consequences: test their invariants, put them in writing, and watch for gaming." - "A handful of sellers do not need a SalesOps team; one accountable owner with written definitions beats a team without them." related: [revops, marketingops, customerops, bizops, martechops, peopleops, analyticsops, cxops] --- ## What SalesOps is ### In 30 seconds **SalesOps (sales operations) is the function that designs and runs the machinery a sales team sells with:** how many sellers the company needs and where they work (capacity and territories), what each is asked to sell (quotas), how deals move and are recorded (stages and the CRM), how the team predicts the quarter (pipeline and forecast), how sellers are paid (commission plans), and how non-standard deals are priced and approved (the deal desk). Sellers win deals; sales leaders coach and decide; SalesOps makes the system they work in fair, predictable and cheap to run: balanced territories, believable quotas, a forecast with a known error range, commission statements right first time. Written for beginners, sales operations analysts, sales leaders, finance and RevOps partners, and CRM administrators. Sources were last verified on **2026-10-23**. ::: note Scope of this page This page concentrates on what is hardest to get right in sales operations: **the maths of capacity and coverage, and how the forecast call is made**. Cross-funnel definitions (MQL, SQL), revenue formulas such as ARR and NRR, and decision rights over the whole go-to-market stack belong to [RevOps](../revops/); this page links there rather than repeat them. ::: ### At a glance | Question | Short answer | |---|---| | Goal | Fair territories and quotas, an accurate forecast, productive sellers, correct pay, clean deal data | | Primary users | Sales operations analysts and managers, sales leaders, frontline managers, finance partners, CRM admins | | In scope | Capacity, territories, quotas, sales stages and exit criteria, CRM hygiene, pipeline management, forecast categories and the forecast call, compensation, deal desk and CPQ, enablement operations, sales metrics | | Handed off | Shared funnel definitions and stack decision rights → [RevOps](../revops/); lead generation and scoring → [MarketingOps](../marketingops/); renewals and expansion → [CustomerOps](../customerops/); company targets and cadence → [BizOps](../bizops/); pay structures and payroll → [PeopleOps](../peopleops/) | | Prerequisites | None; spreadsheet skills help; basic Python helps with the labs | | Key outputs | Capacity model, territory map, quota letters, stage definitions, forecast and accuracy log, compensation plan documents and statements, approval matrix, CRM data dictionary | | Term status | **Established**: a long-standing function with standard titles and analyst coverage; heavily overlapping with RevOps (see below) | | Evidence status | Partially verified: footnoted claims were checked against opened sources; two primary sources could not be fetched; stand-in copies are used and disclosed | ### Term status and the RevOps overlap The label is established. Forrester's revenue operations research service says it continues to "support and expand research for marketing operations leaders and sales operations leaders",[^forr-dec] and Gartner's 2020 State of Sales Operations Survey reported pressure on "heads of sales operations" to forecast accurately.[^gartner-2020] GitLab's handbook documents a Sales Operations team "a part of Field Operations" beside separate Deal Desk, Sales Commissions, Sales Systems, Sales Strategy and Field Enablement teams.[^gl-salesops][^gl-fieldops] The practices behind the label have a peer-reviewed literature back to the early 1980s,[^zs-1983][^syntex] and the earliest traceable account of a sales operations group (Xerox in the 1970s, see [origins](#origins-and-evolution)) lists jobs this page still covers: planning, compensation, forecasting and territory design.[^hbr-2014] The complication is **revenue operations (RevOps)**. Forrester defines it as "a highly configured, iterative commercial execution strategy designed to maximize customer value and company performance" and says it "is a commercial execution strategy, not an organizational structure".[^forr-dec] In a later post, Forrester analysts write that "marketing operations, sales operations, and customer operations need to break down silos and integrate their actions".[^forr-myths] So RevOps does not replace sales operations; it changes who coordinates it. ::: decision Editorial distinction used in this Atlas **RevOps** owns what crosses functions: shared funnel definitions (including the stage dictionary) and inter-team service levels, governance of the forecast process and the single company number, revenue metric formulas, and decision rights over the go-to-market stack. **SalesOps** owns sales-specific mechanics: capacity, territories, quotas, exit criteria and commit rules for sales stages, forecast categories, pipeline reviews and the forecast call, compensation administration, the deal desk, and the CRM as sellers use it. This split is the Atlas's choice (coverage matrix §3.8), not an industry standard. In a company without a RevOps function, SalesOps takes on both. ::: Overlapping names include sales strategy or planning, sales systems, commercial excellence, field operations and sales enablement. Ask which jobs a team owns, not what it is called. ### What SalesOps is not - **Not sales administration only.** A team that only processes requests leaves the expensive problems alone. - **Not the sales leader.** SalesOps proposes territories, quotas and plan designs and runs the forecast process; the sales leader decides and is accountable for the number. - **Not marketing operations.** Lead generation, scoring and campaigns belong to [MarketingOps](../marketingops/); SalesOps takes over at the agreed hand-off. - **Not customer success.** Renewals, adoption and health scores belong to [CustomerOps](../customerops/) in this Atlas, even where account managers sell expansions. - **Not finance.** Finance owns revenue recognition, commission accounting and the plan; SalesOps supplies the data. - **Not surveillance.** Activity data can help coach sellers; scoring individuals by keystrokes or call counts is a different and risky practice (see [Quality, compliance and conduct risk](#quality-compliance-and-conduct-risk)). ### The problem it solves Every company that sells already makes territory, quota and forecast decisions. The question is whether they rest on data and a repeatable process, or on spreadsheets rebuilt each January and a Friday-afternoon guess. | Area | Without working sales operations | With it | |---|---|---| | Capacity | Target set top-down; hiring ignores ramp and attrition | Target tested against a ramp-adjusted capacity model before acceptance | | Territories | Best accounts follow the best-connected sellers; some territories are uncoverable | Territories balanced on potential and workload, with a change process | | Quotas | Same increase for everyone; quotas sum to the target with no buffer | Quotas based on territory potential, with deliberate over-assignment and a relief policy | | CRM | Stages mean different things to different sellers; close dates are wishes | Stage exit criteria, required fields, daily inspection of stale and slipped deals | | Forecast | Each manager adds a private "haircut"; no one knows whose calls are accurate | Categories with written rules, a weekly call, a model as challenger, an accuracy log | The cost of not doing this work is concrete. Salesforce's 2024 State of Sales survey found reps spending 70% of their time on non-selling tasks (5,500 sales professionals in 27 countries, self-reported).[^sf-sos] Gartner reported in 2020 that only 45% of sales leaders and sellers had high confidence in forecast accuracy.[^gartner-2020] And territory-design research describes a pattern worth recognising: an overloaded territory where the seller earns high commissions and is always busy, yet many prospects are never contacted and existing customers complain.[^zsl-2004] ## Origins, vocabulary and neighbours ### Origins and evolution The dates below are the ones a source supports; the longer undocumented history is left out. - **1970s (a recollection, reported second-hand):** as Neil Rackham reported, per Zoltners, Sinha and Lorimer in HBR, Xerox set up a sales operations group in the 1970s for sales planning, compensation, forecasting and territory design; its leader, J. Patrick Kelly, described the work as "all the nasty number things that you don't want to do, but need to do to make a great sales force".[^hbr-2014] Vendor blogs repeating it link to the article. - **1978:** Jacob Gonik's Harvard Business Review article describes a pay scheme (implemented at IBM's Brazilian operations, by Gonik's account) that rewards sellers for forecasting accurately as well as selling; the tension it addresses, between honest forecasts and motivated sellers, is still the core of the forecast call.[^gonik][^chen] - **1983:** Zoltners and Sinha publish a review and general model of territory alignment.[^zs-1983] They co-founded ZS; Kellogg reported in 2010 more than 1,800 applications of the model in 37 countries.[^isms][^kellogg] - **1988:** Lodish and colleagues document how models estimated with managers' judgement helped Syntex Laboratories enlarge and redeploy its sales force, reporting a continuing 8% annual sales increase ([use case](#use-cases-and-scenarios)).[^syntex] - **2023:** Forrester launches a revenue operations research service, framed as a strategy rather than an org chart.[^forr-dec] ### Glossary and mental model | Term | Meaning | Example | |---|---|---| | **Quota** | The sales target assigned to one seller or team for a period | 800,000 of new bookings in the fiscal year | | **On-target earnings (OTE)** | Base salary plus the variable pay earned at 100% of quota | 100,000 base + 100,000 target incentive | | **Accelerator / decelerator; cap; clawback** | Higher (lower) rate above (below) a threshold; maximum payout; recovery on cancellation | 1.5× above quota; cap at 300% | | **SPIFF** | A short sales incentive for a specific product or behaviour | 500 per signed multi-year deal this quarter | | **Ramp** | The months before a new seller reaches full productivity | 0% in months 1–2, 25%, 50%, 75%, then 100% | | **Capacity** | Expected bookings from the sales team: what ramped sellers really book, reduced for ramp and attrition | 6.7 million against a 9 million target | | **Territory; potential; workload** | A set of accounts or a region; what could be sold there; the effort needed to cover it | 24 accounts, potential index 1,080, 460 hours a year | | **Opportunity; stage; exit criteria** | A potential deal in the CRM; its step in the sales process; the evidence needed to move on | "Economic buyer identified" before Propose | | **Pipeline coverage** | Open pipeline dated in a period ÷ target for that period | 4.8 million ÷ 2.25 million = 2.13× | | **Forecast category** | The seller's commitment level for a deal, separate from its stage | Pipeline, Best case, Most likely (between Best case and Commit in Salesforce's cumulative roll-up), Commit, Closed | | **Slippage; push; pull-in** | A deal's close date moving out of the period; a deal closing in an earlier period than it was dated | Pushed from 28 September to 15 October | | **Sandbagging; happy ears** | Forecasting low to beat the number; believing optimistic buyer signals | Commit equals only signed paperwork | | **Deal desk; CPQ** | The team that structures and approves non-standard deals; configure-price-quote software | Approves a 24-month ramp deal | | **Ideal customer profile (ICP)** | The kind of account most likely to buy and succeed, written as firmographic and situational traits | 200–2,000 employees, regulated industry | | **Rules of engagement** | Written rules that decide who owns an account, lead or deal when sellers' claims conflict | Old owner keeps late-stage deals for 60 days after a move | #### A mental model: supply, conversion and a promise Hold three pictures at once. 1. **Supply.** Sellers are capacity: each produces a predictable amount once ramped, new ones produce little for months, and some leave. Territories decide where that capacity points; quotas are a claim on it. 2. **Conversion.** Pipeline converts into bookings at rates you can measure: by stage, category, segment and week of the quarter. Coverage targets come from these rates, not folklore. 3. **A promise.** The forecast is a promise the sales organisation makes to the company, and like any promise it has a track record; SalesOps keeps the record. Most sales operations failures break one picture: overstated supply, imagined conversion rates, or a promise without a track record. ### How SalesOps relates to other Ops SalesOps sits in the middle of the revenue engine; the figure shows what crosses each boundary. ::: figure SalesOps and its neighbours: what crosses each boundary ```mermaid %%{init: {"flowchart": {"wrappingWidth": 150, "nodeSpacing": 18, "rankSpacing": 34}}}%% flowchart TB BZ["BizOps: company targets and planning cadence"] RV["RevOps: shared definitions, forecast governance, stack rights"] MK["MarketingOps: accepted leads, hand-off SLA"] S["SalesOps"] MT["MarTechOps: marketing systems and data"] CU["CustomerOps: renewals, expansion, health"] PO["PeopleOps: pay structures, payroll"] FI["Finance: bookings policy, commission accounting"] BZ -->|"targets"| RV RV -->|"definitions, rules"| S MK -->|"leads"| S MT <-->|"integration"| S S -->|"won deals"| CU S -->|"payouts"| PO S <-->|"forecast, bookings"| FI classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029 class S core class BZ,RV,MK,MT,CU,PO,FI neutral ``` Text equivalent: BizOps passes company targets to RevOps, which passes shared definitions and forecast rules to SalesOps. MarketingOps sends accepted leads to SalesOps; MarTechOps and SalesOps exchange integration work in both directions. SalesOps hands won deals to CustomerOps, commission payouts to PeopleOps for payroll, and exchanges forecasts and bookings with Finance (which has no Atlas page of its own). ::: | Neighbour | SalesOps owns | The neighbour owns | Hand-off artefact | |---|---|---|---| | [RevOps](../revops/) | Exit criteria and commit rules for sales stages (proposed to RevOps), forecast categories in use, the forecast call, sales metrics | The [stage dictionary](../revops/#artefact-1-stage-dictionary-extract) (stage names, what counts as an opportunity), the single company forecast, ARR/NRR formulas, stack decision rights | Stage dictionary; forecast submission | | [MarketingOps](../marketingops/) | What happens after a lead is accepted | Campaigns, lead scoring, routing rules in the marketing platform | Lead acceptance SLA; feedback on rejected leads | | [MarTechOps](../martechops/) | CRM configuration for sales | Marketing systems, data plumbing into the CRM | Integration specification; field ownership | | [CustomerOps](../customerops/) | New-business deals until signature | Onboarding, renewals, expansion, health scores | Closed-won hand-off checklist | | [BizOps](../bizops/) | Testing the target against capacity | The company target, KPI tree and planning calendar | Capacity model; agreed target | | [PeopleOps](../peopleops/) | Commission calculation and quota letters | Pay ranges, payroll, employment terms | Approved plan; payout file | | [AnalyticsOps](../analyticsops/) | Which sales metrics to run on | Governed metric definitions and dashboards | Metric specification | | [CXOps](../cxops/) | Win/loss signals from the sales process | Cross-journey experience measurement | Win/loss feed | ## Principles and operating model ### Charter and principles No official sales operations manifesto exists. The charter below is **this Atlas's proposal** for a team to edit and adopt; its numbers are examples, not benchmarks. **Mission:** give the sales organisation a fair, predictable, low-friction system to sell in, and the company a forecast it can plan on. 1. **Capacity before quota.** No target is accepted until tested against ramp, attrition and realistic productivity. 2. **Fairness is measurable.** Territories and quotas are compared on potential and workload; exceptions are written down. 3. **Definitions before dashboards.** Every stage, category and metric has one written definition and one owner. 4. **The CRM is the record, not a report.** If it is not in the CRM, it did not happen; so keeping it right must be quick. 5. **Forecasts have track records.** Every method and every caller has a measured error and bias. 6. **Pay is a contract.** Plans are written, signed, tested and paid correctly; changes are rare and announced. 7. **Incentives are dangerous medicine.** Watch what targets make people do, not only whether they hit them. **Measurable goals (examples).** Forecast error at week 8 within ±5% for four consecutive quarters; 98% of commission statements correct at first issue; deal desk resolution within one business day; territory potential within ±15% of the mean. **Non-goals.** Owning the sales number (the sales leader does), setting company targets (BizOps and Finance), running marketing programmes, monitoring individuals beyond what coaching and pay need. **Invariants.** Every open opportunity has an owner, stage, amount and future close date; every booked deal traces from quote to order to commission; every seller has a signed plan before the period starts. ### Fundamentals and building blocks Each layer rests on the rows above it: incentives (row 4) on undefined stages (row 2) and untrusted data (row 1) produce disputes, not performance. | Layer | What it contains | Typical artefacts | If it is missing | |---|---|---|---| | 1. Data | Accounts, contacts, opportunities, products, prices, sellers, territories | CRM data dictionary, field ownership, duplicate rules | Every report disagrees | | 2. Process | Sales stages, exit criteria, hand-offs, approvals, booking policy | Stage definitions, deal approval matrix, rules of engagement | Deals move on optimism | | 3. Planning | Capacity model, territory design, quota allocation | Capacity workbook, territory map, quota letters | Targets nobody believes | | 4. Incentives | Compensation plans, SPIFFs, recognition | Plan documents, calculation logic, statements | Pay disputes and gaming | | 5. Cadence | Pipeline reviews, forecast calls, business reviews, plan changes | Calendars, agendas, accuracy log, changelog | Surprises at quarter end | | 6. Insight | Metrics, analyses, models, enablement needs | Scorecards, win/loss analyses, backtests | Decisions by anecdote | ### Roles, ownership and RACI | Role | Accountable for | |---|---| | Chief revenue officer or head of sales | The sales number, sales strategy, final decisions on territories, quotas and plans | | Head of sales operations | The operating system above; plan design proposals; forecast process; sales systems roadmap | | Sales operations analyst | Reporting, pipeline inspection, capacity and quota models, forecast analysis | | Sales systems administrator (CRM) | CRM configuration, validation rules, access, integrations, release notes | | Commissions analyst | Plan calculations, statements, disputes, accrual inputs for finance | | Deal desk analyst | Quote structure, approvals, booking review | | Enablement manager (may be a sibling team) | Onboarding, certification, content, coaching | | Frontline sales manager | Deal reviews, team forecast call, coaching, data quality of the team | | Finance partner | Company plan, bookings policy, commission expense and accounting | **RACI for the core annual and weekly work** (R = responsible, A = accountable, C = consulted, I = informed; one A per row). | Activity | Head of sales | SalesOps | Frontline manager | Finance | PeopleOps | Seller | |---|---|---|---|---|---|---| | Capacity model and hiring plan | A | R | C | C | C | – | | Territory design and assignment | A | R | C | I | – | I | | Quota allocation | A | R | C | C | – | I | | Compensation plan design | A | R | C | C | C | I | | Plan documents signed | C | R | I | I | A | R | | Weekly pipeline inspection (SalesOps runs the report; managers own it) | I | R | A | – | – | R | | Forecast call and submission | A | R | R | I | – | R | | Commission calculation and statements | I | A/R | I | C | C | I | | Deal desk case and booking check | C | A/R | C | C | – | R | | Non-standard deal approval (one approver per threshold) | A (20–30%) | C | A (10–20%) | A (over 30%, terms) | – | I | | CRM changes and releases | C | A/R | C | – | – | I | Organisations differ: GitLab runs deal desk, commissions, sales systems and sales strategy as separate teams in Field Operations.[^gl-fieldops] What matters: each row (and approval threshold) has exactly one accountable owner, and the team that books an order does not approve its discount. ### The planning lifecycle: annual, quarterly, weekly SalesOps work runs on three clocks: the **annual** clock sets the plan, the **quarterly** clock adjusts it, the **weekly** clock runs it. The annual planning sequence, where fairness is won or lost, is drawn below. ::: figure Annual sales planning sequence and its feedback loop ```mermaid %%{init: {"flowchart": {"wrappingWidth": 170, "nodeSpacing": 16, "rankSpacing": 26}}}%% flowchart TB A["Company target from BizOps and Finance"] --> B["Capacity model: heads, ramp, attrition, productivity"] B --> C{{"Capacity covers the target?"}} C -->|"no"| D["Change the target, hire earlier, or change coverage"] D --> B C -->|"yes"| E["Territory design: potential and workload"] E --> F["Quota allocation with over-assignment"] F --> G["Compensation plans written, tested, signed"] G --> H["Kick-off: territories, quotas, plans live"] H --> I["In-year: weekly pipeline and forecast cadence"] I --> J["Mid-year review: relief, rebalancing, re-plan"] J -.->|"lessons and actuals"| A 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,B,E,F,G,H,I,J core class C decision class D risk ``` Text equivalent: The target from BizOps and Finance is tested against a capacity model (heads, ramp, attrition, productivity). If capacity falls short, the target, hiring dates or coverage model change and the test is rerun. Then territories are designed, quotas allocated with over-assignment, plans written, tested and signed, and everything goes live at kick-off. The weekly cadence runs in-year; a mid-year review handles relief and rebalancing, and its lessons feed next year's target (dotted). ::: | Clock | Main events | SalesOps outputs | |---|---|---| | Annual (before the fiscal year) | Capacity model, territory design, quota allocation, plan design, system changes | Capacity workbook, territory map, quota letters, signed plans, release notes | | Quarterly | Quarter-start review, territory exceptions, quota relief requests, quarter close | Coverage report, relief decisions, attainment and payout files, accuracy review | | Monthly | Business review, commission run, plan dispute review | Scorecard, statements, dispute log | | Weekly | Pipeline inspection, forecast call, deal desk queue | Inspection report, forecast submission, approvals | For setting up the function itself, see the [30/60/90-day roadmap](#adoption-roadmap-306090-days). ### Operating model and governance Three governance mechanisms keep the system trustworthy. 1. **Change control.** Territory, quota and plan changes go through a written request, an impact estimate (who gains, who loses, payout effect) and a named approver; changes take effect from a stated date, never silently. CRM changes ship in batched releases with release notes; GitLab ships field operations changes on a batched, bi-weekly cadence with a running changelog.[^gl-fieldops] 2. **A plan exceptions committee.** Head of sales, SalesOps and Finance (PeopleOps for employment questions) meet monthly to decide quota relief, split credits, disputes and SPIFFs, using precedents from a decision log. 3. **Separation of duties.** Whoever calculates commissions does not approve their own team's payouts; the deal desk that books an order does not approve its discount; sellers cannot edit closed-won amounts after booking. **Escalation.** Seller → frontline manager → SalesOps (process or data) or deal desk (deal structure) → exceptions committee → head of sales. Pay disputes have a written deadline (say, 60 days after the statement) and a written answer. ## Architecture and workflow ### Reference architecture: the sales systems stack Sales operations is mostly a process discipline, but the process lives in software. The architecture below is vendor-neutral; the [tooling landscape](#tooling-landscape) names examples. ::: figure Reference architecture: the systems a sales operations team runs and the data that flows between them ```mermaid %%{init: {"flowchart": {"wrappingWidth": 150, "nodeSpacing": 18, "rankSpacing": 30}}}%% flowchart TB MAP["Marketing automation: accepted leads"] --> RT["Routing and enrichment"] PL["Planning: capacity, territories, quotas"] --> RT RT --> CRM["CRM: accounts, opportunities, forecasts (record)"] CRM --> CPQ["CPQ: quotes, approvals"] CPQ --> ERP["Contract, ERP, billing: booked orders"] ERP --> ICM["Incentive compensation: credits, statements"] PL --> ICM ICM --> PAY["Payroll (PeopleOps)"] CRM --> DW["Warehouse: daily snapshots"] ERP --> DW DW --> FC["Forecasting and BI"] FC -.-> CRM classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029 class CRM,PL,ICM,DW core class MAP,RT,CPQ,ERP,PAY,FC neutral ``` Text equivalent: Accepted leads from marketing automation and territory rules from the planning tool feed a routing and enrichment layer that assigns owners in the CRM, the system of record for accounts, opportunities and forecasts. Quotes and approvals happen in CPQ; signed orders are booked in the contract, ERP and billing systems. Booked orders and plan rules from the planning tool feed the incentive compensation system, which sends payouts to payroll. The CRM and ERP feed a warehouse with daily snapshots, which powers forecasting and BI; a model forecast flows back to the CRM (dotted). ::: | Component | Responsibility | Design choice that matters | |---|---|---| | CRM | System of record for accounts, contacts, opportunities, forecast categories, ownership | One opportunity per deal; stage and category stored separately; field history on amount, stage, close date | | Planning | Capacity model, territory hierarchy, quota allocation, what-if scenarios | Territories as data (a mapping table), not as people's memories | | Routing and enrichment | Assigning new accounts and leads to owners by territory rules | A documented precedence for conflicting firmographic sources | | CPQ | Products, prices, discounts, approval rules, quote documents | Approval thresholds in configuration, not in email | | Contract, ERP, billing | Booking, invoicing, revenue | Booking policy written down; the quote amount equals the booked amount | | Incentive compensation (ICM) | Crediting rules, rates, statements, disputes, accrual exports | Credits from booked orders, not from opportunity amounts | | Warehouse and BI | Snapshots, history, metrics, backtests | Daily snapshots of open pipeline, because the CRM overwrites | | Forecasting | Roll-ups, adjustments, model forecasts, accuracy tracking | Every submission stored with its timestamp and author | Three trust boundaries matter: pay data (personal), pricing and discounts (commercially sensitive), and integration service accounts, which can often read and write everything; scope each to the objects it needs and remove access through the joiner-mover-leaver process with [IdentityOps](../identityops/). ### End-to-end workflow: one opportunity from creation to booking The opportunity is the unit of work. Its **stage** describes where the buyer is; its **forecast category**, how sure the seller is that it will close in this period. CRMs map each stage to a default category, sellers can usually override it on the deal, and manager adjustments do not change the underlying opportunity data.[^sf-forecast][^hs-forecast] ::: figure Opportunity stages, their default forecast categories and the exits that move a deal ```mermaid stateDiagram-v2 state "1 Qualify (Pipeline)" as Q state "2 Discover (Pipeline)" as D state "3 Propose (Best case)" as P state "4 Negotiate (Commit if criteria met)" as N state "Closed won (Closed)" as W state "Closed lost (left out)" as L [*] --> Q: accepted lead or seller-sourced Q --> D: pain and owner confirmed D --> P: criteria and process mapped P --> N: verbal selection N --> P: terms reopened N --> W: order signed and booked Q --> L D --> L P --> L N --> L: lost or no decision W --> [*] L --> [*] ``` Text equivalent: An opportunity enters Qualify (default category Pipeline) from an accepted lead or a seller's own prospecting. It moves to Discover (Pipeline) when the buyer's problem and owner are confirmed, to Propose (Best case) when the decision criteria and process are mapped, and to Negotiate (Commit only if the commit criteria are met) on a verbal selection. Reopened terms send it back to Propose. It ends as Closed won (category Closed) when the order is signed and booked, or Closed lost (out of the forecast) from any stage, including "no decision". ::: **Exit criteria** turn stages from moods into evidence: each stage lists what a manager can inspect before the deal moves on (e.g. "decision criteria and process written; economic buyer met" to leave Discover). The full set, with commit rules and required fields, is [Artefact 1](#artefact-1-stage-definitions-and-commit-rules). **Happy path.** A lead accepted from marketing becomes an opportunity; the seller qualifies, discovers and proposes; the manager inspects evidence at each exit; the deal reaches Negotiate and moves to Commit when it meets the commit rules; the quote passes standard approval in CPQ; the order is signed; the deal desk checks order, quote and opportunity match; finance books it; the commission system credits the seller from the booked order; [CustomerOps](../customerops/) takes the customer. **Exception paths.** (1) *Non-standard terms*: the quote crosses an approval threshold and goes through the deal desk ([deal desk playbook](#playbook-deal-desk-and-cpq)). (2) *Slipped close date*: the inspection report flags it; the seller updates date and category, and the forecast records the push. (3) *Territory conflict*: rules of engagement decide; the exceptions committee hears appeals. (4) *Booking mismatch*: the deal returns to the seller before booking. (5) *Cancellation*: the plan's clawback clause applies. ## The core maths: capacity, territories, quotas and the forecast This part is the centre of the page: each sub-section gives the formula, its assumptions, and the usual error. [Lab 2](#lab-2-intermediate-capacity-and-coverage-plan) and [Lab 4](#lab-4-advanced-backtest-four-forecast-methods) let you run the numbers. ::: figure From the annual target to the leads the team needs: the capacity and coverage chain ```mermaid %%{init: {"flowchart": {"wrappingWidth": 190, "nodeSpacing": 16, "rankSpacing": 26}}}%% flowchart TB T["Annual bookings target"] --> C["Capacity: what ramped sellers really book, after ramp and attrition"] C --> G{{"Gap between target and capacity?"}} G -->|"yes"| H["Hire earlier, change the target or change the coverage model"] G -->|"no"| Q["Quarterly targets by team"] Q --> P["Starting pipeline = target × (1 − new-deal and pull-in share) ÷ start win rate"] P --> O["Opportunities = pipeline ÷ average deal size"] O --> M["Meetings or accepted leads = opportunities ÷ conversion rate"] M --> MK["Demand request to MarketingOps and prospecting plan"] MK -.->|"actual conversion rates"| P 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 T,C,Q,P,O,M,MK core class G decision class H risk ``` Text equivalent: The annual target is compared with adjusted capacity; a gap means hiring earlier, changing the target or the coverage model. Otherwise it is split into quarterly targets. Required starting pipeline = target × (1 − share from new deals and pull-ins) ÷ start win rate; ÷ average deal size gives opportunities; ÷ conversion rate gives meetings or leads, which become a demand request to MarketingOps and a prospecting plan. Actual conversion rates feed back (dotted). ::: ### Capacity planning **Formula.** For each seller and month, expected bookings = ramped monthly productivity × ramp share for their tenure, and zero before they start or after they leave. Capacity is the sum over sellers and months. - **Ramped productivity** is what a fully ramped seller in this role books in a year: the mean bookings of ramped sellers in your history, or their quota × their mean attainment. Use one base, once: multiplying historical bookings by attainment again counts the shortfall twice; a new, higher quota is a target, not productivity. - **The mean, not the median.** Capacity is a sum, and the expected sum is heads × mean; the stars' bookings are real. The median describes the typical seller but understates a skewed team total. If leadership wants a cushion, add a named planning buffer everyone can see. - **Ramp share** comes from your own cohorts: bookings of month-3, month-6 and month-9 sellers compared with ramped sellers. Measure it by role and segment; longer cycles mean longer ramps. - **Attrition** removes capacity twice: the leaver's remaining months and the backfill's ramp. **Worked example** (synthetic, from Lab 2). Ten seats at a 900,000 quota look like a 9,000,000 target; ramped sellers book 85% of quota (765,000), one seat is a new hire, and two leavers are each replaced after a one-month vacancy. Capacity is **6,725,625**, a gap of 2,274,375. Six extra sellers starting in month 3 close the gap; starting in month 7 it takes fifteen. The lesson is not "hire fifteen people": **late hiring cannot rescue an annual target**, so the target conversation belongs at the start of the year. ::: caution Capacity models fail quietly Four errors: counting heads instead of ramped heads, using quota as productivity, ignoring the backfill's ramp, applying attainment twice. The first three make the plan look achievable until the third quarter; the fourth makes it look hopeless and triggers needless hiring. ::: ### Territory design A territory is a set of accounts (or a geography) assigned to a seller. Zoltners and Sinha described territory alignment as grouping small sales coverage units into territories "acceptable according to managerially relevant alignment criteria"; their later work ties alignment to sales force performance.[^zs-1983][^zsl-2004] Four criteria trade off against each other: | Criterion | What it means | How to measure | Typical tension | |---|---|---|---| | Balanced potential | Each seller has a similar opportunity to sell | Sum of an account potential index per territory; max ÷ min and coefficient of variation | Moving accounts breaks relationships | | Balanced workload | Each seller has a similar amount of work | Hours needed to cover the accounts at the planned call frequency | High-potential accounts are often high-workload | | Continuity | Customers keep their seller where it matters | Number of accounts or bookings that change owner | Continuity preserves imbalance | | Travel and coherence | A territory is reachable and makes sense to customers | Drive time, time zones, industry focus | Coherent regions are rarely balanced | **Account potential** is the hardest input: proxies include firmographics (employees, revenue, sites), installed base, category spend, or a propensity score. Whatever the proxy, write it down, version it, and let sellers challenge it. GitLab's handbook shows one documented implementation: accounts are segmented by the maximum employee count in the hierarchy and routed by the top parent's headquarters address; a routing tool compares these inputs with a single territory mapping file and outputs the next approved owner. Sellers request overrides with a stated source; Ops responds approved, rejected, or needs approval or more information; approved changes re-populate typically in 24–48 hours; accounts with a populated effective date are re-routed nightly to that owner. Named, public-sector and channel accounts are excluded and assigned manually (as of the page's June 2024 revision).[^gl-gtm] **Rebalancing rules that limit damage:** protect accounts with late-stage deals; cap moves per seller; move at a period boundary; give transition credit for late-stage deals; publish the rules before the map. [Lab 3](#lab-3-intermediate-measure-and-rebalance-territories) measures balance and finds the few moves that fix most of it. ### Quota setting and allocation A quota is both a forecast of what a seller can sell and a lever on what they will try to sell: if a seller's own forecast becomes their quota, the seller "will try to turn in the lowest possible forecast", as Chen summarises Gonik's problem.[^chen] **Methods**, from simplest to most defensible: 1. **Top-down split:** target ÷ sellers, or last year plus a uniform increase. Fast; unfair wherever territories differ. 2. **Historical with growth:** prior bookings plus a percentage. Punishes last year's over-achievers (the "ratchet") and rewards sandbagging. 3. **Potential-based:** proportional to territory potential, adjusted for ramp. Fairer, but only as good as the potential index. 4. **Blended:** for example 50% potential, 30% history, 20% judgement, with written reasons. Explainable, which matters most. **Over-assignment.** Allocate quotas totalling more than the company target, because some sellers will miss, leave or be on leave. Size the buffer from your attainment distribution and attrition, not habit, and say it exists: hidden over-assignment is discovered at the first plan dispute. **Quota relief.** Write in advance when relief is granted (territory change after period start, extended leave, a withdrawn product) and how it is calculated (pro rata by days or by potential moved). Decide it at the exceptions committee, record it in the decision log, and never grant it because the quarter is going badly. ::: example Illustrative scenario: allocating a regional quota A region has a 4,000,000 target and four ramped sellers. With 10% over-assignment, quotas must total 4,400,000. Territory potential indexes are 1,220, 1,170, 1,120 and 1,080 (total 4,590). Potential-based quotas are 4,400,000 × share: 1,169,500; 1,121,600; 1,073,600; 1,035,300 (rounded to the nearest hundred). A blended method giving 30% weight to each seller's prior-year bookings would move these numbers; the point is that each number can be explained to the seller in one sentence. ::: ### Pipeline coverage, derived rather than borrowed **Pipeline coverage** is open pipeline dated in a period ÷ the target for that period. A rule of thumb of 3× (or 3–4×) is often quoted; even a vendor publishing the metric calls it "a heuristic, not a law" and says the principled target is the inverse of your win rate.[^metabase] The inverse win rate is a start but still too simple: some of a quarter's bookings do not come from pipeline dated in the quarter on day one — deals created during the quarter, and pull-ins (open on day one, dated later). A better derivation uses three historical rates: > Required starting pipeline = quarter target × (1 − share of bookings from deals created in the quarter − share from pull-ins) > ÷ value win rate of pipeline that was open and dated in the quarter on its first day. **Worked example** (from Lab 2): a 2,250,000 quarter, 15% of bookings created in-quarter, 5% from pull-ins, 30% of starting pipeline closing won: 2,250,000 × 0.8 ÷ 0.30 = **6,000,000**, (2.67×). The team has 4,800,000 (2.13×). A borrowed 3× rule would have demanded 6,750,000, chasing 750,000 the team did not need; at a 20% start win rate the same arithmetic demands 4×, and the 3× rule would have hidden a real gap. Three refinements: compute the rates **by segment** (enterprise and small-business pipeline convert differently); compute them **at the same week of the quarter** you measure; and use **value** win rates, because a few large deals dominate. ### Forecast categories: how a number is built A forecast is built from opportunities, but not by summing them: CRMs provide categories that express the seller's commitment and roll up the hierarchy: - **Salesforce** shows each category as a column and supports single or cumulative roll-ups, in which "Best Case" includes Most Likely, Commit and Closed; manager adjustments "don't change the underlying opportunity data".[^sf-forecast] - **HubSpot's** defaults are Most likely, Best case, Pipeline and Commit, with Not forecasted and Closed won also available; categories come from the deal stage, can be overridden on the deal, and the weighted amount multiplies amount by deal probability (as of September 2026; Sales Hub or Service Hub Professional or Enterprise).[^hs-forecast] **Write the category rules down.** An example rule set (adapt it): | Category | Rule | Expected conversion (measure yours) | |---|---|---| | Commit | Stage 4; economic buyer confirmed budget and timing; paper process started; no unresolved legal blocker; close date inside the period | High; track it and aim for a stable figure | | Best case | Stage 3 or 4; buyer agreed a close plan with dates; at least one open risk | Medium | | Pipeline | Any open opportunity dated in the period that does not meet the above | Low | | Left out | Dated outside the period, or stalled with no activity for an agreed number of days | Not counted | **Three ways to build the number**, which Lab 4 compares: 1. **Roll-up of judgement:** managers submit calls; leaders adjust. Knows deal news; prone to sandbagging and optimism. 2. **Weighted pipeline:** amount × a stage or category probability. Only as good as untested probabilities. 3. **Historical conversion:** closed to date + each category's open value × its past conversion at the same week + an allowance for deals not yet created. Calibrated, but blind to deal news. ### The forecast call The call is a weekly meeting, but most of the work happens before it: Monday, SalesOps publishes an inspection report per team ([Artefact 4](#artefact-4-weekly-pipeline-inspection-query)); by Tuesday sellers update stages, amounts, close dates and categories, and frontline managers inspect the evidence behind Commit and Best case deals and submit team calls with their top risks; Wednesday, second-line leaders submit region calls; Thursday, the head of sales, SalesOps and Finance agree one number with a range, the model forecast as a challenger, and each caller's historical accuracy on the table (Figure 6). ::: figure The weekly forecast call: who hands what to whom ```mermaid %%{init: {"sequence": {"actorMargin": 24, "width": 120, "messageMargin": 30, "boxMargin": 6, "noteMargin": 6, "diagramMarginX": 8}}}%% sequenceDiagram participant R as Seller participant M as Manager participant L as Sales leader participant O as SalesOps participant F as Finance Note over R,M: Monday: SalesOps report R->>M: Deals updated M->>R: Evidence for commits? M->>L: Team call, top risks O->>L: Model, caller accuracy L->>O: Final call O->>F: Number, range, history F->>O: Quarter actuals ``` Text equivalent: A note marks Monday's inspection report, which SalesOps sends to sellers and managers. The seller updates deals; the manager asks for the evidence behind each commit, then gives the sales leader the team call and its top risks. SalesOps gives the sales leader the model forecast and each caller's past accuracy; the leader returns a final call, which SalesOps submits to Finance as one number with a range and its history. After the quarter, Finance returns actual bookings for the accuracy log. The "Sales leader" lane stands for both the second-line leader and the head of sales. ::: Where a RevOps function exists it governs the company number; SalesOps runs the categories, inspection, call and accuracy log. ### Measuring forecast accuracy and bias A forecast without a measured error is an opinion: record every submission (method, caller, week, value) and compare with actuals after the quarter. - **Forecast error** e = actual − forecast for a period. This is the textbook convention[^fpp3] and the one the [RevOps](../revops/) page uses: a positive error is an under-call, a negative error an over-call. - **Percentage error** = 100 × e ÷ actual; **MAPE** is the mean of absolute percentage errors; **bias** is the mean of signed percentage errors (positive = forecasting low, typical of sandbagging). Hyndman and Athanasopoulos note that percentage errors are undefined or extreme when the actual is zero or near zero, penalise negative errors (over-calls, in this sign) more heavily than positive ones, and assume a meaningful zero.[^fpp3] Sales actuals are rarely zero, but small teams and new segments have tiny quarters: report absolute error in currency next to the percentage, and judge accuracy at a fixed week (say week 8 of 13), because accuracy in the last week says little about planning value. **Worked calculation.** A team called 1,640 (thousands) at week 8 and booked 1,810: e = 1,810 − 1,640 = +170; percentage error = 170 ÷ 1,810 = **+9.4%**, an under-call. Over six quarters of the Lab 4 data this caller's MAPE is 13.2% and bias +13.2%: every error is an under-call, the signature of sandbagging, not bad luck. ## Other practices, frameworks and tools ### Playbook: compensation plan design and administration Compensation design is decided by sales leadership with Finance and [PeopleOps](../peopleops/); SalesOps models options, writes plan documents, runs calculations and handles disputes. **Design decisions, in order:** | Decision | Options | What to check | |---|---|---| | Role and measure | New bookings, ARR, margin, units; individual or team | The seller influences it and the company values it | | Pay mix and OTE | Base/variable split by role | More variable pay where the seller has more influence | | Rate structure | Flat rate; decelerator below a threshold; accelerators above quota | **At 100% attainment the plan pays exactly the target incentive** | | Period | Annual quota with monthly or quarterly payout; quarterly bonuses | Long periods let sellers fall behind early without noticing | | Caps and windfalls | Uncapped; capped; windfall review for unusual deals | Caps cut the incentive to keep selling after a big quarter | | Crediting rules | Who is credited (splits, overlays, partners); when (booking, invoice, cash) | Credit from booked orders, not opportunity amounts | | Clawbacks and holds | Recovery on cancellation or non-payment within a window | Legal in each jurisdiction? Written in the signed plan? | | SPIFFs | Short incentives for a product or behaviour | Rare, announced in writing, with an end date | **Evidence on rate structures.** A field study of a large firm's sales force (Chung, Steenburgh and Sudhir, *Marketing Science* 2014) found bonuses enhanced productivity across all segments, overachievement commissions "help sustain the high productivity of the best performers even after attaining quotas", and quarterly bonuses acted as "pacers" helping weak performers towards annual quotas.[^chung] It is one company's data with a structural model; frame questions with it, not as a universal rule. **Test the plan like code.** Before launch, run the calculation on last year's bookings for every seller and on edge cases (zero, exactly 100%, the cap, cancellation). One invariant catches an easy design error: a decelerator below 50% attainment without a raised rate between 50% and 100% — with 0.6× below 50% and 1.0× up to quota, a seller who hits quota earns 80,000 of a 100,000 target incentive. The [reference implementation](#reference-implementation-operating-artefacts) includes a calculator with that check built in. **Write it down and get it signed.** Rules differ by jurisdiction. In California, commission agreements must be written, state how commissions are computed and paid, and be signed by both parties with a copy to the employee (Labor Code §2751, as summarised by the California Chamber of Commerce; not legal advice).[^calchamber] **Accounting is not optional either.** ASC 340-40-25-1 and IFRS 15.91 require incremental costs of obtaining a contract (commissions are the standard example) to be recognised as an asset if the entity expects to recover them, and amortised on a systematic basis (340-40-35-1, IFRS 15.99); as a practical expedient an entity *may* expense them when the amortisation period would be one year or less (340-40-25-4, IFRS 15.94). A 2015 FASB–IASB staff paper quotes these paragraphs and discusses renewal commissions as a judgement question, while disclaiming either standard's application.[^trg] SalesOps does not make these accounting calls, but must give Finance credit data detailed enough to make them (deal, contract term, renewal or new, amount, payee). ::: warning Incentives change behaviour, including the behaviour you did not want Regulators and researchers have documented targets driving misconduct: Sears' early-1990s auto-centre goal of $147 an hour led staff to overcharge and recommend unnecessary repairs,[^ggw] and in 2016 the CFPB fined Wells Fargo 100 million dollars after employees, "Spurred by sales targets and compensation incentives", opened accounts customers may not have authorised.[^cfpb] Both are consumer businesses, but the mechanism — a high-powered target with weak monitoring — exists in B2B sales too: side letters, pulled-forward orders, deals booked before they are real. ::: ### Playbook: deal desk and CPQ A **deal desk** structures, reviews and approves non-standard deals so that what is sold can be delivered, billed, recognised and paid. GitLab describes its Deal Desk mission as "to streamline the opportunity management process while acting as a trusted business partner for field sales".[^gl-dealdesk] Its public handbook (revised October 2026) is a documented example: - **Scope:** building and validating complex quotes, checking deal structure against booking policy, auditing approvals, approving bookings against quote data, month-end close duties; explicitly **out of scope**: standard quotes (sellers create them), opportunity creation, forecast management. - **Service levels:** for example 6 business hours to first response and 8 to resolution for basic quote help, 6 and 24 for ramp deals, when the request is complete; a quarterly satisfaction survey with a 92% target. - **Proactive review:** each week in the last month of a quarter, the team reviews opportunities closing in-quarter with Net ARR (GitLab's annual-recurring-revenue measure on opportunities; [RevOps](../revops/) defines ARR) of 100,000 dollars or more at stage 4 or 5, looking for anything that would stop a clean booking. - **Non-standard deal elements:** since November 2024, quote fields for deferred payments, price locks, release-contingent deals, free secondary instances and non-standard ramps trigger approvals through an automated workflow.[^gl-dealdesk] ::: figure Deal desk workflow with its exception paths ```mermaid %%{init: {"flowchart": {"wrappingWidth": 160, "nodeSpacing": 18, "rankSpacing": 28}}}%% flowchart TB A["Seller builds the quote in CPQ"] --> B{{"Standard price and terms?"}} B -->|"yes"| C["Auto-approved; order form generated"] B -->|"no"| D["Deal desk case: structure, margin, terms"] D --> E{{"Which thresholds are crossed?"}} E -->|"discount band"| F["Sales leader approves"] E -->|"payment terms, price lock"| G["Finance approves"] E -->|"non-standard legal terms"| H["Legal reviews"] F --> I["Signed order"] G --> I H --> I C --> I I --> J{{"Order, quote and opportunity match?"}} J -->|"no"| K["Back to seller; fix before booking"] K --> J J -->|"yes"| L["Booked; billing and CustomerOps notified"] 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,C,D,F,G,H,I,L core class B,E,J decision class K risk ``` Text equivalent: The seller builds the quote in CPQ. Standard price and terms are auto-approved and generate an order form. Otherwise a deal desk case reviews structure, margin and terms and routes approvals by threshold: discount bands to the sales leader, payment terms and price locks to Finance, non-standard legal terms to Legal. All paths lead to a signed order. A booking check compares order, quote and opportunity; a mismatch returns the deal to the seller to fix before booking; a match is booked and billing and CustomerOps are notified. ::: **Discount governance.** Publish a matrix (up to 10% seller, 10–20% manager, 20–30% sales leader, above 30% or any price lock Finance), review the discount distribution monthly, and watch for clustering just under a threshold — a sign of gaming. As Marn and Rosiello's HBR summary puts it, "The right price can boost profit faster than increasing volume will".[^marn] **CPQ** software encodes products, prices, discounts and approval chains. Buy it when quotes are complex (bundles, ramps, usage tiers) or approvals are frequent; before that, a price book, a template and a written matrix are enough. Products change: Salesforce's CPQ is "end of sale, not end of life", with Revenue Cloud Advanced as successor and no end-of-life date (July 2026).[^sf-cpq] ### Playbook: CRM hygiene and data governance The CRM is only as useful as the least careful seller's records. Hygiene is a product problem — make the right action easy — not a policing problem. 1. **Fewer, required fields at the right moment.** Require fields when a deal enters a stage, not at creation. HubSpot's conditional stage properties require them on manual stage moves (the documentation describes manual changes; check your imports, workflows and integrations).[^hs-pipelines] Salesforce validation rules block a save when a formula returns true, with a visible error message.[^sf-vr] 2. **Field ownership.** For each field decide who may change it (seller, manager, deal desk, integration) and lock the rest; closed-won amounts change only through the deal desk. 3. **Daily inspection, not quarterly clean-ups.** The Monday report ([Artefact 4](#artefact-4-weekly-pipeline-inspection-query)) is the hygiene programme. 4. **Duplicates and hierarchies.** Account duplicates break territory assignment and quota credit; define matching rules and a merge owner. 5. **History.** Track field history on stage, amount, close date and category, and snapshot open pipeline daily; without history you cannot measure slippage or backtest a forecast. 6. **Personal data.** Contact records are personal data wherever laws such as the GDPR apply ("any information relating to an identified or identifiable natural person");[^gdpr4] retention, access and lawful basis are designed with [PrivacyOps](../privacyops/). ### Playbook: enablement operations Enablement (onboarding, training, certification, content, coaching) can be a sibling team, as at GitLab.[^gl-fieldops] SalesOps contributes onboarding plans tied to the capacity model's ramp, certification records, content usage data and skill-gap analysis. Course delivery belongs to [EduOps](../eduops/) and the content lifecycle to [ContentOps](../contentops/). The test is the ramp curve: if onboarding works, cohort ramp at months 3 and 6 rises. ### Methods, standards and frameworks No standard body defines sales operations. The useful frameworks are of three kinds; none is mandatory. | Kind | Examples | What it is good for | Caveat | |---|---|---|---| | Analytical models | Territory alignment models;[^zs-1983] decision-calculus sizing models;[^syntex] forecast accuracy measures[^fpp3] | Sizing, alignment, accuracy | Need data and judgement; outputs are proposals | | Qualification frameworks | MEDDPICC (Metrics, Economic buyer, Decision criteria, Decision process, Paper process, Implicate the pain, Champion, Competition); BANT (budget, authority, need, timing) | Stage exit criteria and commit rules | MEDDPICC is promoted by a training firm, which says MEDDIC began at PTC in 1996;[^meddicc] the origin is uncorroborated | | Incentive research | Forecast-truthful pay schemes;[^chen] bonus structures;[^chung] side effects of goals[^ggw] | Plan design and its risks | Field studies of single companies; context matters | | Accounting and law | ASC 340-40 and IFRS 15 on commission costs;[^trg] written commission plans (California)[^calchamber] | Plan administration | Jurisdiction-specific; not advice | ### Tooling landscape Categories first, brand names second. Product names are examples verified on vendor pages on 2026-10-18, not recommendations; capabilities change, so check current documentation. | Category | Job it does | Examples (as of October 2026) | Selection criteria | Risks | |---|---|---|---|---| | CRM | System of record for opportunities, forecasts, territories | Salesforce Sales Cloud (forecasting, Sales Territories),[^sf-forecast][^sf-territories] HubSpot Sales Hub,[^hs-forecast] Microsoft Dynamics 365 Sales[^ms-forecast] | Data model fit, admin skills available, integration ecosystem | Over-customisation; licence creep | | Planning (territory, quota, capacity) | Scenarios, hierarchies, quota allocation | Varicent sales planning;[^varicent] Xactly Plan;[^xactly] spreadsheets for small teams | Scenario modelling, CRM sync, audit trail | A model nobody but its builder understands | | Incentive compensation (ICM) | Crediting, rates, statements, disputes | Varicent, Xactly Incent, Spiff (Salesforce since February 2024)[^varicent][^xactly][^spiff] | Plan complexity supported, statement clarity, accrual exports | Logic only the vendor's consultant can change | | CPQ and deal management | Quotes, pricing rules, approvals | Salesforce Revenue Cloud Advanced (CPQ end of sale), Zuora CPQ (used by GitLab)[^sf-cpq][^gl-dealdesk] | Product and pricing complexity, billing integration | Pricing logic duplicated in billing | | Forecasting and revenue intelligence | Roll-ups, models, deal inspection, call analysis | CRM-native forecasting; Clari Forecast (Clari and Salesloft completed a merger in December 2025); Gong Forecast[^clari-salesloft][^gong] | Evidence of accuracy on your data; explainability | Recording and analysing calls has legal duties | | Enablement | Content, training, coaching | Highspot (part of Seismic since their merger completed in August 2026)[^seismic-highspot] | Adoption, CRM integration | Content sprawl | | Warehouse and BI | Snapshots, metrics, backtests | Any warehouse with governed metrics ([AnalyticsOps](../analyticsops/)) | Snapshot design, metric governance | Two versions of every metric | **Editorial rule:** fix definitions and process in the CRM first; buy a specialist tool when a spreadsheet process has an owner and a countable, expensive error. ### Automation and AI Automate where the rule is clear and the volume high: routing, required fields, approvals, commission calculation, inspection. **AI and statistical forecasting** can be a useful challenger to judgement, with conditions. Microsoft's premium forecasting, for example, requires more than 10 closed opportunities with actual values and dates and warns that fewer opportunities mean lower accuracy and that test data skews the model (as of May 2026; not in all regions).[^ms-premium] Ten deals is a technical minimum, not a sufficient history; judge any model by a backtest on your own data ([Lab 4](#lab-4-advanced-backtest-four-forecast-methods)) over several quarters. **Limits and duties.** Models cannot see what is not in the data (a champion leaving, a procurement freeze told to the seller over lunch). Conversation analysis and seller scoring raise legal questions: in the EU, AI systems intended "to monitor and evaluate the performance and behaviour of persons" in work relationships are classed as high-risk under the AI Act, with those rules applying from 2 December 2027 according to the European Commission (as of October 2026).[^aiact-annex][^ec-aiact] Microsoft states that its forecasting feature "isn't intended for use in making decisions that affect the employment of an employee", and tells customers to notify people that communications may be monitored or recorded and to obtain consent where the law requires it.[^ms-forecast] Keep forecasts for planning and coaching; base pay and employment decisions on the written plan and human review. **Generative AI** can draft account plans and summarise calls; it is no source of truth for amounts, dates or categories. ## SalesOps in practice ### Reference implementation: operating artefacts **Assumptions.** A business-to-business software company with about 40 quota-carrying sellers in two segments, one CRM, a CPQ tool, a spreadsheet capacity model, and a SalesOps team of four (lead, analyst, CRM administrator, commissions and deal desk analyst). Every artefact below is a template to adapt; none is a standard. #### Artefact 1: stage definitions and commit rules _Example status: syntax-checked (YAML), not executed; load it into a data-quality job or use it as the specification for CRM configuration._ ```yaml # Sales stages, exit criteria and forecast category rules (version 2026-10) owner: sales-operations approved_by: head-of-sales stages: - id: 1 name: Qualify default_category: Pipeline exit_criteria: [problem_confirmed, budget_owner_known, icp_fit] required_fields: [amount, close_date, primary_contact] - id: 2 name: Discover default_category: Pipeline exit_criteria: [decision_criteria_written, decision_process_written, economic_buyer_met] required_fields: [competitor, use_case] - id: 3 name: Propose default_category: Best case exit_criteria: [proposal_delivered, mutual_close_plan_agreed] required_fields: [proposal_date, close_plan_link] - id: 4 name: Negotiate default_category: Best case exit_criteria: [verbal_selection, paper_process_known] required_fields: [legal_status, procurement_contact] commit_rules: # all must be true for category = Commit - stage_at_least: 4 - economic_buyer_confirmed_budget_and_timing: true - paper_process_started: true - close_date_in_period: true - open_legal_blockers: 0 stale_after_days: 21 closed_lost_requires: [loss_reason, competitor_or_no_decision] ``` #### Artefact 2: deal desk intake form _Example status: syntax-checked (YAML), not executed; most CPQ and case tools can model these fields._ ```yaml deal_desk_request: opportunity_id: "OPP-000123" requested_by: seller@example.com needed_by: 2026-10-30 deal_type: new_business # new_business | expansion | renewal term_months: 24 ramp: {non_standard: true, schedule: "users +50 every 6 months"} discount_percent: 22 payment_terms: annual_in_advance # prepaid | annual_in_advance | custom price_lock_requested: false contingent_on_future_feature: false non_standard_legal_terms: ["liability cap 2x fees"] competitor: "Competitor A" justification: "Multi-year commitment; displaces Competitor A; reference customer" approvals_required: # filled from the approval matrix - {role: sales_leader, reason: "discount 20-30%"} - {role: finance, reason: "non-standard ramp"} - {role: legal, reason: "liability cap change"} ``` #### Artefact 3: territory or quota change request _Example status: syntax-checked (YAML), not executed._ ```yaml change_request: id: TQ-2026-031 type: territory_move # territory_move | quota_relief | split_credit effective_date: 2026-10-01 # never retroactive without a written decision accounts: [ACC-1042, ACC-1043] from_owner: seller-north to_owner: seller-south reason: "Rebalance potential after two enterprise wins in north" impact: potential_moved_index: 380 open_pipeline_moved: 210000 late_stage_deals_protected: [OPP-0789] # stays with the current owner quota_change: {seller-north: -95000, seller-south: 95000} approvals: [head-of-sales, sales-operations, finance] communicated_to_sellers_on: 2026-09-24 ``` #### Artefact 4: weekly pipeline inspection query _Example status: verified by execution on 2026-10-18 with SQLite 3.31.1 (Python `sqlite3`) on the seven sample rows below; date functions differ in other warehouses._ ```sql -- Monday inspection (SQLite): one row per issue, so a deal can appear twice. -- Scope: open deals dated in the quarter now OR in last week's snapshot, -- so a deal pushed out of the quarter is still caught. WITH q AS ( SELECT * FROM opp WHERE close_date <= :quarter_end OR prev_close_date <= :quarter_end ), flags AS ( SELECT opp_id, 'pushed out of the quarter' AS issue FROM q WHERE prev_close_date <= :quarter_end AND close_date > :quarter_end UNION ALL SELECT opp_id, 'pushed within the quarter' FROM q WHERE close_date > prev_close_date AND close_date <= :quarter_end UNION ALL SELECT opp_id, 'close date in the past' FROM q WHERE close_date < :today UNION ALL SELECT opp_id, 'commit before stage 4' FROM q WHERE category = 'Commit' AND stage < 4 UNION ALL SELECT opp_id, 'commit without next step' FROM q WHERE category = 'Commit' AND COALESCE(next_step, '') = '' UNION ALL SELECT opp_id, 'no activity for 21 days' FROM q WHERE julianday(:today) - julianday(last_activity) > 21 ) SELECT q.opp_id, q.owner, q.stage, q.category, q.amount, flags.issue FROM flags JOIN q ON q.opp_id = flags.opp_id ORDER BY q.amount DESC, q.opp_id, flags.issue; ``` To reproduce, save the query as `inspect.sql`, the synthetic rows below as `sample.sql`, and the runner as `run.py`; then run `python3 run.py`. ```sql -- Synthetic open deals; prev_close_date comes from last week's snapshot. CREATE TABLE opp (opp_id TEXT, owner TEXT, stage INT, category TEXT, amount INT, close_date TEXT, last_activity TEXT, next_step TEXT, prev_close_date TEXT); INSERT INTO opp VALUES ('A','ana', 4,'Commit', 120000,'2026-09-26','2026-09-18','Legal call','2026-09-26'), ('B','ben', 3,'Commit', 95000,'2026-09-29','2026-08-20','', '2026-09-29'), ('C','chen',4,'Commit', 150000,'2026-10-15','2026-09-19','Procurement','2026-09-28'), ('D','dara',3,'Best case', 80000,'2026-09-30','2026-09-17','Demo', '2026-09-22'), ('E','ana', 2,'Pipeline', 60000,'2026-09-15','2026-09-10','Call', '2026-09-15'), ('F','ben', 2,'Pipeline', 40000,'2026-11-20','2026-09-01','', '2026-11-20'), ('G','chen',4,'Best case', 70000,'2026-09-24','2026-09-20','Signature', NULL); ``` ```python """Run the inspection query on the sample rows (Python standard library only).""" import sqlite3 db = sqlite3.connect(":memory:") with open("sample.sql") as f: db.executescript(f.read()) with open("inspect.sql") as f: query = f.read() for row in db.execute(query, {"today": "2026-09-21", "quarter_end": "2026-09-30"}): print(" | ".join(str(v) for v in row)) ``` **Expected output** (today 2026-09-21, quarter end 2026-09-30). ```text C | chen | 4 | Commit | 150000 | pushed out of the quarter B | ben | 3 | Commit | 95000 | commit before stage 4 B | ben | 3 | Commit | 95000 | commit without next step B | ben | 3 | Commit | 95000 | no activity for 21 days D | dara | 3 | Best case | 80000 | pushed within the quarter E | ana | 2 | Pipeline | 60000 | close date in the past ``` Deal C was dated 28 September last week and 15 October now: a query scoped to in-quarter deals only would miss the push that matters most. Deal B fails three rules at once, so it gets three rows; deal F is stale but dated in November, out of scope. Each flag is one review question, not an accusation. #### Artefact 5: a CRM validation rule _Example status: illustrative, not executed (no Salesforce org was available); syntax follows the patterns in Salesforce's Trailhead material.[^sf-vr][^sf-vr-project][^sf-vr-bypass] `Economic_Buyer_Confirmed__c`, `Next_Step_Date__c` and the custom permission `Bypass_Commit_Rule` are hypothetical._ ```text Rule name: Commit_requires_evidence (Opportunity) Error condition formula: AND( NOT($Permission.Bypass_Commit_Rule), ISPICKVAL(ForecastCategoryName, "Commit"), OR( NOT(Economic_Buyer_Confirmed__c), ISBLANK(Next_Step_Date__c), Next_Step_Date__c < TODAY() ) ) Error message: "Commit needs a confirmed economic buyer and a future next-step date." ``` Test it in a sandbox with the four combinations of the two conditions. A data load on old records may need a bypass: grant the custom permission through a permission set assigned only for the load (Trailhead suggests a session-based permission set, so everyone obeys the rule by default),[^sf-vr-bypass] because any identity holding it can set Commit without evidence. Integration users that only sync data should not edit the forecast category at all. #### Artefact 6: commission calculator with a plan invariant _Example status: verified by execution on 2026-10-18 (Python 3.8.10, standard library); illustrative plan, not a recommendation._ ```python """Annual commission: decelerator, two accelerator tiers and a cap (illustrative plan).""" TARGET_INCENTIVE = 100_000 # variable pay at 100% attainment (on-target earnings - base) QUOTA = 800_000 BASE_RATE = TARGET_INCENTIVE / QUOTA # 12.5% of bookings, before multipliers # (lower bound of attainment band, upper bound, multiplier on BASE_RATE) TIERS = [(0.0, 0.5, 0.6), (0.5, 1.0, 1.4), (1.0, 1.5, 1.5), (1.5, None, 2.0)] CAP = 3 * TARGET_INCENTIVE # payout cap: 300% of target incentive def commission(bookings): paid = 0.0 for low, high, mult in TIERS: lo, hi = low * QUOTA, (high * QUOTA if high is not None else bookings) if bookings > lo: paid += (min(bookings, hi) - lo) * BASE_RATE * mult return min(paid, CAP) # Plan invariant: hitting quota exactly must pay exactly the target incentive. assert round(commission(QUOTA)) == TARGET_INCENTIVE, commission(QUOTA) for b in (300_000, 600_000, 800_000, 1_000_000, 1_400_000, 2_400_000): pay = commission(b) print(f"bookings {b:>9,} attainment {b / QUOTA:6.1%} commission {pay:>9,.0f}" f" effective rate {pay / b:5.1%}") # Clawback: a 120,000 deal cancelled inside the plan's clawback window before, after = commission(1_000_000), commission(880_000) print(f"clawback, 120,000 deal cancelled at 1,000,000 bookings: {before - after:,.0f}") ``` **Output.** ```text bookings 300,000 attainment 37.5% commission 22,500 effective rate 7.5% bookings 600,000 attainment 75.0% commission 65,000 effective rate 10.8% bookings 800,000 attainment 100.0% commission 100,000 effective rate 12.5% bookings 1,000,000 attainment 125.0% commission 137,500 effective rate 13.8% bookings 1,400,000 attainment 175.0% commission 225,000 effective rate 16.1% bookings 2,400,000 attainment 300.0% commission 300,000 effective rate 12.5% clawback, 120,000 deal cancelled at 1,000,000 bookings: 22,500 ``` Two design facts appear in the output. The **effective rate falls at the cap** (12.5% at 300%) — the moment a capped seller has least reason to keep selling, the behaviour Chung and colleagues' overachievement finding warns about.[^chung] And the **clawback is charged at the marginal rate** (18.75% here), not the average; write which one your plan uses. ### Hands-on labs Four labs on **synthetic data only**: Python 3.8 or later and a bash shell, standard library only, no accounts, no cost. Each lab was run on 2026-10-18 exactly as printed (Python 3.8.10, Ubuntu Linux); expected outputs are copied from those runs. ::: warning Never practise on a real CRM export on a laptop Real pipeline and pay data are commercially sensitive and contain personal data. Use the synthetic files below, or an approved, access-controlled environment. ::: #### Lab 1 (beginner): funnel metrics from a CRM export **Objective.** Compute win rate by count and by value, cycle length, average deal size and sales velocity, and see why the definitions matter. **Prerequisites.** Python 3.8+. **Time.** 20 minutes. **Risk.** None (synthetic data). 1. Create the export. _Example status: verified by execution on 2026-10-18 (bash, Linux)._ ```bash mkdir -p ~/salesops-labs/lab1 && cd ~/salesops-labs/lab1 cat > opportunities.csv <<'CSV' opp_id,owner,created,closed,outcome,amount O-101,ana,2026-01-12,2026-04-08,won,42000 O-102,ana,2026-02-03,2026-04-21,lost,65000 O-103,ben,2026-01-20,2026-05-02,won,88000 O-104,ben,2026-03-02,2026-05-15,lost,30000 O-105,chen,2026-02-14,2026-05-29,won,51000 O-106,chen,2026-03-10,2026-06-05,lost,120000 O-107,dara,2026-01-05,2026-06-12,won,150000 O-108,dara,2026-04-01,2026-06-19,lost,24000 O-109,ana,2026-03-18,2026-06-26,won,36000 O-110,ben,2026-04-07,2026-06-30,lost,47000 O-111,chen,2026-02-24,2026-06-30,lost,58000 O-112,dara,2026-03-25,2026-06-30,won,73000 O-113,ana,2026-05-11,,open,61000 O-114,ben,2026-05-20,,open,90000 O-115,chen,2026-06-02,,open,44000 O-116,dara,2026-06-15,,open,105000 CSV ``` 2. Save the script as `funnel.py`. _Example status: verified by execution on 2026-10-18 (Python 3, standard library)._ ```python """Win rate, cycle length, deal size and sales velocity from a CRM export.""" import csv from datetime import date from statistics import mean, median PERIOD = (date(2026, 4, 1), date(2026, 6, 30)) # Q2 2026 with open("opportunities.csv", newline="") as f: rows = list(csv.DictReader(f)) def d(s): return date.fromisoformat(s) if s else None closed = [r for r in rows if r["outcome"] in ("won", "lost") and PERIOD[0] <= d(r["closed"]) <= PERIOD[1]] won = [r for r in closed if r["outcome"] == "won"] open_opps = [r for r in rows if r["outcome"] == "open"] amt = lambda rs: sum(int(r["amount"]) for r in rs) win_rate_count = len(won) / len(closed) win_rate_value = amt(won) / amt(closed) cycle = [(d(r["closed"]) - d(r["created"])).days for r in won] avg_deal = amt(won) / len(won) print(f"Closed in period: {len(closed)} (won {len(won)}, lost {len(closed) - len(won)})") print(f"Win rate by count : {win_rate_count:.1%}") print(f"Win rate by value : {win_rate_value:.1%}") print(f"Cycle length (won): median {median(cycle)} days, mean {mean(cycle):.1f} days") print(f"Average won deal : {avg_deal:,.0f}") # Sales velocity = opportunities x deal value x win rate / cycle length (per day) velocity = len(open_opps) * avg_deal * win_rate_count / median(cycle) print(f"Open opportunities: {len(open_opps)} worth {amt(open_opps):,}") print(f"Sales velocity : {velocity:,.0f} per day (median cycle, count win rate)") print("By owner (won/closed):") for owner in sorted({r["owner"] for r in closed}): c = [r for r in closed if r["owner"] == owner] w = [r for r in c if r["outcome"] == "won"] print(f" {owner:<5} {len(w)}/{len(c)} won value {amt(w):>7,}") ``` 3. Run `python3 funnel.py`. **Expected output.** ```text Closed in period: 12 (won 6, lost 6) Win rate by count : 50.0% Win rate by value : 56.1% Cycle length (won): median 101.0 days, mean 107.8 days Average won deal : 73,333 Open opportunities: 4 worth 300,000 Sales velocity : 1,452 per day (median cycle, count win rate) By owner (won/closed): ana 2/3 won value 78,000 ben 1/3 won value 88,000 chen 1/3 won value 51,000 dara 2/3 won value 223,000 ``` **Validation.** By hand: won value 440,000 ÷ closed value 784,000 = 56.1%. Won cycles are 86, 97, 100, 102, 104 and 158 days, so the median is (100 + 102) ÷ 2 = 101 and the mean 107.8: one slow deal (O-107) pulls the mean up; hence the median. Sales velocity uses Salesforce's published formula, (opportunities × deal value × win rate) ÷ cycle length;[^sf-velocity] it is a composite indicator, not a forecast, and it mixes a count win rate with a value-weighted deal size, so state your choices. **Troubleshooting.** `ValueError: Invalid isoformat string`: a date has the wrong format; the script expects `YYYY-MM-DD`. `ZeroDivisionError`: no deals closed in the period; check `PERIOD`. **Teardown.** `rm -rf ~/salesops-labs/lab1` #### Lab 2 (intermediate): capacity and coverage plan **Objective.** Compare a target with ramp- and attrition-adjusted capacity, see why late hiring fails, and derive pipeline coverage from history. **Prerequisites.** Lab 1. **Time.** 30 minutes. **Risk.** None. 1. Save as `capacity.py` in `~/salesops-labs/lab2`. _Example status: verified by execution on 2026-10-18 (Python 3, standard library)._ ```python """Ramp-adjusted sales capacity versus a bookings target (fiscal year = 12 months).""" TARGET = 9_000_000 # new-business bookings target for the year SEATS = 10 # quota-carrying positions in the plan QUOTA = 900_000 # quota per ramped seat (last year's and this year's) MEAN_ATTAINMENT = 0.85 # mean attainment of ramped sellers against that quota # One productivity base, applied once: what a ramped seller really books in a year. RAMPED_PRODUCTIVITY = QUOTA * MEAN_ATTAINMENT # 765,000 = mean bookings of ramped reps RAMP = {1: 0.0, 2: 0.0, 3: 0.25, 4: 0.5, 5: 0.75} # tenure month -> share; then 1.0 # Roster: (rep, month they start, month they leave or None). Month 1 = first month. ROSTER = [ ("r01", -24, None), ("r02", -18, None), ("r03", -12, None), ("r04", -12, None), ("r05", -6, None), ("r06", -3, None), ("r07", -1, None), ("r08", -30, 7), ("r09", -20, 9), ("r10", 2, None), ("b08", 8, None), ("b09", 10, None), # backfills for r08 and r09 ] def monthly_capacity(start, leave, month): """Expected bookings in a calendar month for one rep.""" if month < start or (leave is not None and month >= leave): return 0.0 tenure = month - start + 1 return RAMPED_PRODUCTIVITY / 12 * RAMP.get(tenure, 1.0) def plan(roster): return sum(monthly_capacity(s, l, m) for _, s, l in roster for m in range(1, 13)) base = plan(ROSTER) stay = plan([(r, s, None) for r, s, l in ROSTER if not r.startswith("b")]) print(f"Target : {TARGET:>12,.0f}") print(f"Naive capacity (seats x quota): {SEATS * QUOTA:>12,.0f}") print(f"Ramp/attrition-adjusted : {base:>12,.0f}") print(f"Gap : {TARGET - base:>12,.0f}") print(f"Leavers' cost net of backfills: {stay - base:>12,.0f}") for start in (3, 7): # how many extra hires starting in this month close the gap? roster, extra = list(ROSTER), 0 while plan(roster) < TARGET and extra < 20: extra += 1 roster.append((f"new{extra}", start, None)) print(f"Hires needed if they start in month {start}: {extra} " f"(capacity then {plan(roster):,.0f})") ``` 2. Save as `coverage.py`. _Example status: verified by execution on 2026-10-18 (Python 3, standard library)._ ```python """Pipeline coverage needed at the start of a quarter, derived from your own history.""" QUARTER_TARGET = 2_250_000 IN_QUARTER_SHARE = 0.15 # share of bookings from deals created in the quarter PULL_IN_SHARE = 0.05 # share from deals open on day one but dated in a later quarter START_PIPE_WIN_RATE = 0.30 # value share of start-of-quarter pipeline (dated this # quarter) that historically closes won this quarter START_PIPELINE = 4_800_000 needed_from_start = QUARTER_TARGET * (1 - IN_QUARTER_SHARE - PULL_IN_SHARE) required_pipeline = needed_from_start / START_PIPE_WIN_RATE print(f"Bookings needed from existing pipeline: {needed_from_start:,.0f}") print(f"Required starting pipeline : {required_pipeline:,.0f}") print(f"Required coverage of target : {required_pipeline / QUARTER_TARGET:.2f}x") print(f"Actual coverage : {START_PIPELINE / QUARTER_TARGET:.2f}x") print(f"Pipeline gap : {required_pipeline - START_PIPELINE:,.0f}") print(f"Rule-of-thumb 3x would ask for : {3 * QUARTER_TARGET:,.0f}") ``` 3. Run both: `python3 capacity.py && python3 coverage.py`. **Expected output.** ```text Target : 9,000,000 Naive capacity (seats x quota): 9,000,000 Ramp/attrition-adjusted : 6,725,625 Gap : 2,274,375 Leavers' cost net of backfills: 525,938 Hires needed if they start in month 3: 6 (capacity then 9,211,875) Hires needed if they start in month 7: 15 (capacity then 9,116,250) Bookings needed from existing pipeline: 1,800,000 Required starting pipeline : 6,000,000 Required coverage of target : 2.67x Actual coverage : 2.13x Pipeline gap : 1,200,000 Rule-of-thumb 3x would ask for : 6,750,000 ``` **Validation.** Productivity is applied once: 900,000 × 0.85 = 765,000 a year, so a ramped month is 63,750. The roster yields 105.5 ramped months = 6,725,625. The leavers take away 10 ramped months and their backfills return only 1.75 (525,938 net). A month-3 hire adds 6.5 ramped months (414,375), a month-7 hire only 2.5 (159,375). With an explicit planning buffer, multiply the capacity by it in one visible line, not inside the productivity figure. **Troubleshooting.** If the hiring loop stops at 20, the gap cannot be closed with that start month: the answer is to change the target, not to raise the loop limit. **Teardown.** `rm -rf ~/salesops-labs/lab2` #### Lab 3 (intermediate): measure and rebalance territories **Objective.** Measure territory balance on potential and workload and find the few account moves that fix most of the imbalance within a disruption budget. **Prerequisites.** Lab 1. **Time.** 30 minutes. **Risk.** None. 1. Create the account file. _Example status: verified by execution on 2026-10-18 (bash, Linux)._ ```bash mkdir -p ~/salesops-labs/lab3 && cd ~/salesops-labs/lab3 cat > accounts.csv <<'CSV' account,owner,potential,workload_hours,protected A01,north,420,160,yes A02,north,380,140,no A03,north,300,120,no A04,north,260,90,no A05,north,240,100,no A06,north,200,80,no A07,south,150,60,yes A08,south,140,70,no A09,south,120,50,no A10,south,100,40,no A11,south,90,40,no A12,south,80,30,no A13,east,310,130,yes A14,east,220,90,no A15,east,180,80,no A16,east,160,70,no A17,east,120,50,no A18,east,90,40,no A19,west,330,150,yes A20,west,210,90,no A21,west,170,80,no A22,west,150,60,no A23,west,110,50,no A24,west,60,30,no CSV ``` 2. Save as `balance.py`. _Example status: verified by execution on 2026-10-18 (Python 3, standard library)._ ```python """Measure territory balance and propose a few low-disruption moves.""" import csv from statistics import mean, pstdev MAX_MOVES = 3 # disruption budget: each move breaks a customer relationship with open("accounts.csv", newline="") as f: accounts = list(csv.DictReader(f)) for a in accounts: a["potential"] = int(a["potential"]) a["workload_hours"] = int(a["workload_hours"]) def totals(accts, field="potential"): t = {} for a in accts: t[a["owner"]] = t.get(a["owner"], 0) + a[field] return t def cv(t): v = list(t.values()) return pstdev(v) / mean(v) def report(label, accts): t = totals(accts) parts = " ".join(f"{k}={v}" for k, v in sorted(t.items())) print(f"{label}: {parts} max/min={max(t.values()) / min(t.values()):.2f}" f" CV={cv(t):.3f}") w = totals(accts, "workload_hours") print(f" workload hours: {' '.join(f'{k}={v}' for k, v in sorted(w.items()))}" f" CV={cv(w):.3f}") report("Before", accounts) moves = [] for _ in range(MAX_MOVES): t = totals(accounts) best = None for a in accounts: if a["protected"] == "yes": continue for target in t: if target == a["owner"]: continue old = a["owner"] a["owner"] = target score = cv(totals(accounts)) a["owner"] = old if best is None or score < best[0]: best = (score, a, target) if best is None or best[0] >= cv(t): break _, acct, target = best moves.append((acct["account"], acct["owner"], target, acct["potential"])) acct["owner"] = target for m in moves: print(f"Move {m[0]} from {m[1]} to {m[2]} (potential {m[3]})") report("After ", accounts) ``` 3. Run `python3 balance.py`. **Expected output.** ```text Before: east=1080 north=1800 south=680 west=1030 max/min=2.65 CV=0.355 workload hours: east=460 north=690 south=290 west=460 CV=0.299 Move A02 from north to south (potential 380) Move A06 from north to west (potential 200) Move A23 from west to south (potential 110) After : east=1080 north=1220 south=1170 west=1120 max/min=1.13 CV=0.046 workload hours: east=460 north=470 south=480 west=490 CV=0.024 ``` **Validation.** North's potential falls by 380 + 200 = 580 to 1,220; south gains 380 + 110 = 490 to 1,170. The coefficient of variation (standard deviation ÷ mean) drops from 0.355 to 0.046 with three moves, and protected accounts (A01, A07, A13, A19) never move. Workload happens to balance too because potential and hours are correlated in this data; in real data check both, and expect to trade one against the other. **Troubleshooting.** No moves printed: every candidate account is protected, or no move reduces the coefficient of variation. **Extension.** Add a rule that a seller may lose at most one account, and compare the result. **Teardown.** `rm -rf ~/salesops-labs/lab3` #### Lab 4 (advanced): backtest four forecast methods **Objective.** Compare a manager's call, "closed plus commit", CRM-weighted pipeline and historical conversion rates at week 8 of a 13-week quarter, measured by MAPE and bias, without look-ahead. **Prerequisites.** Labs 1–2; the [accuracy section](#measuring-forecast-accuracy-and-bias). **Time.** 45 minutes. **Risk.** None. 1. Create one snapshot per quarter (amounts in thousands): bookings closed by week 8, open value by category, what each category eventually won, deals created and won after week 8, and the manager's call. _Example status: verified by execution on 2026-10-18 (bash, Linux)._ ```bash mkdir -p ~/salesops-labs/lab4 && cd ~/salesops-labs/lab4 cat > snapshots.csv <<'CSV' quarter,closed_wk8,commit,best_case,pipeline,won_commit,won_best,won_pipeline,won_new,manager_call 2024Q3,610,900,700,1500,760,250,120,40,1500 2024Q4,580,1000,800,1700,830,300,160,60,1580 2025Q1,700,950,650,1400,780,210,90,30,1640 2025Q2,820,1200,900,2000,1010,380,200,50,2000 2025Q3,640,980,760,1600,690,240,130,40,1600 2025Q4,600,1050,820,1750,900,330,150,70,1650 2026Q1,710,1100,700,1500,850,200,100,50,1760 2026Q2,800,1250,950,2100,1040,360,170,60,2050 CSV ``` 2. Save as `backtest.py`. _Example status: verified by execution on 2026-10-18 (Python 3, standard library)._ ```python """Backtest four forecast methods at week 8 of a 13-week quarter (amounts in 000s).""" import csv with open("snapshots.csv", newline="") as f: rows = [{k: (v if k == "quarter" else float(v)) for k, v in r.items()} for r in csv.DictReader(f)] for r in rows: r["actual"] = (r["closed_wk8"] + r["won_commit"] + r["won_best"] + r["won_pipeline"] + r["won_new"]) CRM_WEIGHTS = {"commit": 0.9, "best_case": 0.5, "pipeline": 0.1} # set by an admin CATS = ("commit", "best_case", "pipeline") WON = {"commit": "won_commit", "best_case": "won_best", "pipeline": "won_pipeline"} def historical_rates(history): """Value conversion of each category in earlier quarters only (no look-ahead).""" return {c: sum(h[WON[c]] for h in history) / sum(h[c] for h in history) for c in CATS} results = {"manager call": [], "closed + commit": [], "CRM weights": [], "history rates": []} for i, r in enumerate(rows): if i < 2: continue # need two prior quarters to estimate conversion rates rates = historical_rates(rows[:i]) new_avg = sum(h["won_new"] for h in rows[:i]) / i fc = { "manager call": r["manager_call"], "closed + commit": r["closed_wk8"] + r["commit"], "CRM weights": r["closed_wk8"] + sum(r[c] * CRM_WEIGHTS[c] for c in CATS), "history rates": r["closed_wk8"] + sum(r[c] * rates[c] for c in CATS) + new_avg, } for name, value in fc.items(): results[name].append((r["quarter"], value, r["actual"])) print(f"{'method':<16}{'MAPE':>7}{'bias':>8} per-quarter error % (actual - forecast)") for name, res in results.items(): errs = [100 * (act - fc) / act for _, fc, act in res] mape = sum(abs(e) for e in errs) / len(errs) bias = sum(errs) / len(errs) print(f"{name:<16}{mape:6.1f}%{bias:+7.1f}% " + " ".join(f"{e:+5.1f}" for e in errs)) print("Actuals:", " ".join(f"{q}={a:,.0f}" for q, _, a in results["manager call"])) ``` 3. Run `python3 backtest.py`. **Expected output.** ```text method MAPE bias per-quarter error % (actual - forecast) manager call 13.2% +13.2% +9.4 +18.7 +8.0 +19.5 +7.9 +15.6 closed + commit 12.3% +12.3% +8.8 +17.9 +6.9 +19.5 +5.2 +15.6 CRM weights 10.0% -10.0% -11.6 -3.7 -18.5 -3.9 -15.2 -7.4 history rates 5.9% -1.8% -5.3 +4.9 -10.6 +5.4 -7.0 +2.2 Actuals: 2025Q1=1,810 2025Q2=2,460 2025Q3=1,740 2025Q4=2,050 2026Q1=1,910 2026Q2=2,430 ``` **Validation.** For 2025Q1 the history method uses only 2024Q3 and 2024Q4: commit converted 1,590 ÷ 1,900 = 83.7%, best case 550 ÷ 1,500 = 36.7%, pipeline 280 ÷ 3,200 = 8.75%, plus 50 of late-created deals: 700 + 795.0 + 238.3 + 122.5 + 50 = 1,905.8, an over-call: e = (1,810 − 1,905.8) ÷ 1,810 = −5.3%. **How to read it:** the manager's call is always low (positive errors) and almost equals "closed plus commit" (a sandbagging signature); the administrator's weights are always high (negative errors); the calibrated method has the smallest error and almost no bias. These data were **constructed to show typical patterns**; the ranking is not evidence about any real team. On your data any method can win, which is why you backtest. **Troubleshooting.** `KeyError`: a column name in the CSV does not match the script. Very large errors in early quarters: too few prior quarters to estimate rates; start evaluating later. **Teardown.** `rm -rf ~/salesops-labs/lab4` ### Use cases and scenarios #### Scenario 1: sizing and redeploying a sales force at Syntex Laboratories (documented) **Problem and context.** A pharmaceutical company needed to size its sales force and allocate its calls, with data too thin for a purely statistical model. **Method.** From 1982, subjectively parameterised models were built; managers and salespeople estimated how each product's sales would respond to effort, using a modified Delphi technique. **Result as reported:** the estimated response functions predicted each product's sales two years ahead better than the existing forecasts; the company decided to enlarge its sales force and change its deployment; the authors report "a documented continuing $25,000,000, eight percent annual sales increase" and a shift towards product markets with better potential.[^syntex] **Trade-offs and lesson.** The models encode managers' beliefs; their value came from structuring and testing them. A capacity decision can be made rigorous with judgement-based inputs, if the inputs are explicit and later checked against outcomes. #### Scenario 2: quarter-end pull-forwards at Under Armour (documented regulatory case) **Problem.** With internal forecasts short against analysts' estimates in late 2015, the company, according to the SEC's order, "accelerated, or 'pulled forward,' a total of $408 million in existing orders that customers had requested be shipped in future quarters" over six consecutive quarters, without disclosing it, and agreed to pay a 9 million dollar penalty in 2021 without admitting or denying the findings.[^sec-ua] **Why it belongs here.** Pulling business forward is a forecast-pressure behaviour any sales organisation can fall into; it borrows from next quarter and hides the gap. **Controls that make it visible:** track bookings whose requested delivery or start date is in a later period; report "pulled-in" value separately; and make Finance, not the sales team, the owner of the booking policy. **Caveat:** a public consumer-products company and an investor-disclosure case; a private company faces different rules but the same arithmetic. #### Scenario 3: a mid-year capacity gap at a software scale-up (illustrative) ::: example Illustrative scenario (fictional company, realistic pattern) A 60-seller company reaches July at 41% of its annual target. Rerun with actual start dates, the model shows eight sellers planned for March started in June and ramp is slower than assumed. Hiring ten more now adds little this year (a month-7 hire gives about a fifth of a ramped year, as in Lab 2), so it lowers the target, moves two enterprise sellers to the shorter mid-market cycle, sizes a pipeline request with the coverage formula, and pulls next year's hiring into Q1. **Success measure:** week-8 forecast error inside ±5% for two quarters; capacity model updated monthly. ::: ## Measure, govern, pay ### Metrics and KPIs Revenue-wide formulas (ARR, NRR, CAC) are defined once in [RevOps](../revops/); the metrics below are the ones SalesOps owns or runs, with governed definitions and dashboards built with [AnalyticsOps](../analyticsops/). | KPI | Definition / formula | Leading or lagging | Pitfall | Cadence | |---|---|---|---|---| | Win rate | Won ÷ (won + lost) closed in the period, by count and by value | Lagging | Excluding "no decision" losses flatters it | Monthly, by segment | | Sales cycle length | Median days from creation to close, won deals | Lagging | Means hide long tails; creation dates get backdated | Quarterly | | Pipeline coverage | Open pipeline dated in the period ÷ target, at a fixed week | Leading | Borrowed 3×; stale deals inflate it | Weekly | | Pipeline creation | Value of new qualified opportunities per week, by source | Leading | Counting unqualified deals | Weekly | | Stage conversion | Share of deals entering stage n that reach n + 1 | Leading | Stage skipping breaks the denominator | Monthly | | Forecast error and bias | (Actual − forecast) ÷ actual at week 8, positive = under-call; MAPE and mean signed error | Lagging | Judging only the final week | Quarterly, per caller and method | | Slippage rate | Value whose close date moved out of the period ÷ value dated in it at week 1 | Leading | Hidden by editing dates without history | Weekly | | Quota attainment distribution | Share of ramped sellers at ≥ 100%; median attainment | Lagging | Average attainment hides a few stars carrying the team | Quarterly | | Ramp time | Months until a cohort reaches 100% of ramped productivity | Lagging | Measured on survivors only | Per cohort | | Discount rate | Average discount; share of deals needing approval; clustering below thresholds | Leading | List prices that nobody pays | Monthly | | Deal desk service level | Cases meeting first-response and resolution targets | Leading | Clock starts only when the request is complete | Weekly | | Commission accuracy | Statements correct at first issue ÷ statements issued; disputes per 100 sellers | Lagging | Counting only disputes raised | Monthly | | Cost of sales (variable) | Variable compensation paid ÷ bookings | Lagging | Ignoring accelerators earned late in the year | Quarterly | **Worked calculation (one quarter, synthetic).** Coverage was 2.13× against a needed 2.67× (Lab 2); week-1 pipeline that slipped out of the quarter was 900,000 ÷ 4,800,000 = 18.8% slippage. Bookings 2,050,000 against a week-8 commit of 1,650,000: forecast error = (2,050,000 − 1,650,000) ÷ 2,050,000 = +19.5%, an under-call. Of 40 statements, 38 were correct at first issue: 95% commission accuracy. Read together: coverage was short and a fifth slipped, yet the call was still low — check whether the Commit rules are too strict. **Target setting:** start from your baseline, prefer trends to borrowed benchmarks, and remember a paid metric gets gamed. ### Quality, compliance and conduct risk Nothing here is legal or accounting advice; each point names jurisdiction and date. - **Written plans and accounting.** Signed plans before the period, and credit data that supports commission accounting ([compensation playbook](#playbook-compensation-plan-design-and-administration)). - **Booking policy and side agreements.** Every term that changes what the customer pays or receives (price locks, contingencies, extended payment, free instances) goes on the order form through approvals, never in email; GitLab's non-standard quote fields are one documented control.[^gl-dealdesk] Pulled-forward orders can become a disclosure problem for listed companies.[^sec-ua] - **Conduct risk of incentives.** The UK FCA's consumer-credit guidance lists risky incentive features: pay based on volume, pay that is "largely or entirely variable", payments that depend on targets or thresholds, and sales competitions.[^fca] It is guidance (supporting CONC 2.11) for UK credit-related regulated activity; elsewhere it is a useful checklist for a plan review. The Wells Fargo case shows what happens when incentive programmes are not "monitored carefully".[^cfpb] - **Personal data.** CRM contacts and pay data are personal data where laws such as the GDPR apply;[^gdpr4] restrict pay data to the people who calculate and approve it. - **AI that evaluates sellers.** Scoring or conversation-analysis tools used to monitor or evaluate sellers' performance are high-risk under AI Act Annex III 4(b) in the EU (rules applying from 2 December 2027, as of October 2026);[^aiact-annex][^ec-aiact] recording calls also needs notice and, where the law requires it, consent.[^ms-forecast] - **Separation of duties and audit trail.** Field history on amounts and stages; approvals stored with the quote; commission calculations reproducible from booked orders. ### Cost, capacity and efficiency The largest costs SalesOps influences are **variable compensation and seller time**, not its own headcount: track variable pay ÷ bookings by segment and seller time on administration.[^sf-sos] The cost of its absence is harder to see: mis-sized hiring, wrong commissions, discount leakage, slow deals. Track **cost per booked deal** next to deal desk service levels, so savings do not come from slower deals, and count licences against active users quarterly. ### Assurance of the operating model How the sales leader knows the machinery works without trusting SalesOps' word for it: - **Forecast accuracy log** by method and caller, reviewed each quarter (in this Atlas's view, the best single health signal). - **Commission audit:** each quarter recompute a sample of statements from booked orders and compare. - **Data-quality trend:** share of open deals failing inspection rules, per team each week. - **Fairness review:** territory potential and quota versus attainment by seller, segment and demographic group where lawful, to catch systematic disadvantage. - **Change log review:** every territory, quota and plan change in the period has a request, approver and effective date. - **Survey of sellers and managers** on the service, after GitLab's quarterly deal desk survey.[^gl-dealdesk] ## When things go wrong ### Common failures and troubleshooting | Symptom | Likely cause | Diagnosis | Fix | Prevention | |---|---|---|---|---| | Forecast misses low every quarter | Sandbagging; commit rules too strict | Bias by caller in the accuracy log | Show callers their bias; calibrate with history | Measure bias publicly each quarter | | Forecast misses high | Happy ears; stale deals; slippage | Slippage rate; age of Commit deals | Enforce commit rules; inspection report | Exit criteria with evidence | | Pipeline looks healthy, quarter fails | Pipeline dated in quarter but not real; coverage borrowed | Start-of-quarter win rate by segment | Purge stale deals; derive coverage | Snapshot-based coverage | | Half the team misses quota | Capacity overstated; quotas top-down | Capacity model vs. actual ramp | Mid-year relief by written rule | Capacity test before quotas | | Commission disputes spike | Crediting rule unclear; territory change | Dispute categories | Fix rule; recalculate | Plan test on last year's data | | Deals stall at approval | Thresholds too low; approvers unavailable | Time in approval by approver | Raise thresholds; delegates | Service levels and a queue view | | Two sellers claim one account | Duplicate accounts; unclear rules of engagement | Duplicate and hierarchy report | Merge; decide by written rule | Matching rules; rules of engagement | ### Worked incident: double-credited deals after a territory change ::: example Illustrative incident (fictional company, realistic pattern) On 1 July, thirty accounts move from seller A to seller B. The CRM owner field changes, but the incentive compensation system credits by an account-team table; a week later someone adds seller B to it without removing seller A. In August, three deals on moved accounts are booked; both sellers are credited and the August run pays both. Seller B notices and raises it in September. ::: ::: figure Runbook for a commission overpayment caused by double crediting ```mermaid %%{init: {"flowchart": {"wrappingWidth": 170, "nodeSpacing": 16, "rankSpacing": 26}}}%% flowchart TB A["Dispute or audit finds double credit"] --> B["Hold further payouts on the affected deals"] B --> C["Find all affected deals: credits vs. owner history"] C --> D{{"Does the plan define a split or transition credit?"}} D -->|"yes"| E["Recalculate per the written rule"] D -->|"no"| F["Exceptions committee decides and records a precedent"] E --> G["Tell affected sellers in writing before any recovery"] F --> G G --> H["Recover or adjust per plan and local law"] H --> I["Root cause: two ownership sources; fix the sync"] classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029 classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029 classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 class A risk class D decision class B,C,E,F,G,H,I core ``` Text equivalent: When a dispute or audit finds double credit, hold further payouts on the affected deals and find all affected deals by comparing credits with ownership history. If the plan defines a split or transition credit, recalculate by that written rule; otherwise the exceptions committee decides and records a precedent. Tell the affected sellers in writing before any recovery, then recover or adjust according to the plan and local law, and fix the root cause: two sources of ownership that were not synchronised. ::: **Runbook steps, owners and timings.** **Contain** (commissions analyst, same day): hold payouts on affected deals; do not claw back yet. **Scope** (SalesOps analyst, 2 days): join booked deals with owner history since 1 July: three deals, 41,000 double-paid. **Decide** (exceptions committee, within a week): the plan keeps late-stage deals with the old owner for 60 days; two deals qualify (seller B's credits reversed), the third goes to seller B. **Communicate** (sales leader, before recovery): written calculation to both sellers; recovery over three months as the plan and local law allow; Finance adjusts accruals. **Fix** (CRM administrator): one ownership source with effective dates; a weekly check for deals credited beyond their split. **Lesson.** The territory change was correct; the ownership sync was not. Territories belong in data with effective dates, and every change request lists its effect on crediting. ### Anti-patterns and myths 1. **Peanut-butter quotas:** everyone gets last year plus 20%. *Instead:* potential-based quotas with written adjustments. 2. **"3× coverage"** as a law. *Instead:* coverage derived from your own conversion history. 3. **Stage = probability:** weights set once by an administrator and never tested. *Instead:* backtest them (Lab 4). 4. **The CRM as a reporting tax:** fields added for every request. *Instead:* fewer fields, required at the right stage. 5. **Plan changes mid-year** to fix a budget problem. *Instead:* relief by written rule; redesign next year. 6. **Uncapped SPIFFs** for every product launch. *Instead:* rare, written, with an end date and a conduct review. 7. **Renaming SalesOps to RevOps** without changing scope or decision rights. *Instead:* decide what crosses functions and who owns it ([RevOps](../revops/)). 8. **Myth: "a better tool will fix the forecast."** Tools change the interface; the definitions, the cadence and the accuracy log fix the forecast. 9. **Myth: "targets only motivate."** Research on goal setting documents side effects, including unethical behaviour and narrowed focus.[^ggw] ## Deciding and adopting ### When to use and when not to use **Build a deliberate sales operations function when** several of these hold: more than about eight quota-carrying sellers (an editorial heuristic); more than one segment, region or sales motion; a forecast Finance has stopped trusting; monthly commission disputes; non-standard deals that take days to approve; or a planning cycle that rebuilds spreadsheets each year. **Do not build a team yet when** a founder-led team works one market with simple pricing: one accountable owner, written stage definitions, a CRM with required fields, a one-page commission plan and a weekly pipeline review are enough. **Do not** rename an existing team to RevOps or SalesOps to signal maturity; change the jobs, not the title. **Alternatives:** a fractional consultant (knowledge leaves with them), Finance running quotas and commissions (accurate but slow for sellers), a CRM partner (skills without ownership). **Hidden work:** disputes, hygiene, integrations and annual planning need named time, or the function decays into report production. ### Decision framework ::: figure Decision tree: do you need a SalesOps function, and how should it start? ```mermaid %%{init: {"flowchart": {"wrappingWidth": 160, "nodeSpacing": 16, "rankSpacing": 26}}}%% flowchart TB S["Start: sellers, segments, deal complexity"] --> Q1{{"More than about 8 quota-carrying sellers?"}} Q1 -->|"no"| A["No team: one owner, written definitions, simple plan"] Q1 -->|"yes"| Q2{{"Separate marketing and CS ops teams already?"}} Q2 -->|"no"| E["SalesOps generalist: CRM, forecast, plans, reporting"] Q2 -->|"yes"| Q3{{"Frequent hand-off and definition disputes?"}} Q3 -->|"yes"| R["RevOps integration above a SalesOps specialist team"] Q3 -->|"no"| K["SalesOps under sales leadership, dotted line to Finance"] E --> Q4{{"Complex deals: bundles, ramps, special terms?"}} R --> Q4 K --> Q4 Q4 -->|"yes"| D["Add a deal desk from the start"] Q4 -->|"no"| N["Approval matrix in CPQ; no deal desk yet"] classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029 classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029 class Q1,Q2,Q3,Q4 decision class A,R,K,D,E,N core class S neutral ``` Text equivalent: With about eight or fewer quota-carrying sellers, do not build a team: one owner, written definitions and a simple plan. With more, if separate marketing and customer success operations teams already exist and hand-off disputes are frequent, put a RevOps integration layer above a SalesOps specialist team; if disputes are rare, keep SalesOps under sales leadership with a dotted line to Finance. Without those teams, start a generalist SalesOps team covering CRM, forecast, plans and reporting. Whatever the shape, ask one more question: if deals are complex (bundles, ramps, special terms), add a deal desk from the start; otherwise an approval matrix in CPQ is enough for now. ::: The thresholds are **editorial heuristics**. Reporting line is a real trade-off: under the sales leader SalesOps is close to the field but can be pressed to bend numbers; under Finance it is independent but slower to help sellers. A compromise: report to sales, with Finance co-owning forecast and commission controls. ### Maturity model This is **this Atlas's maturity model**, not an official standard. | Level | Observable behaviours | Evidence | Exit criteria (to move up) | |---|---|---|---| | 1. Reactive | Reports on request; quotas top-down; forecast is the leader's guess; commissions in spreadsheets | Ad hoc files | Written stage definitions and one signed plan per seller | | 2. Defined | Stages with exit criteria; required fields; weekly pipeline review; plans tested before launch | Definitions, inspection report | Capacity model used to agree the target; forecast submissions stored | | 3. Planned | Capacity-tested targets; potential-based territories and quotas; deal desk with an approval matrix | Capacity workbook, territory map, approval log | Accuracy log for four quarters; commission accuracy ≥ 98% | | 4. Measured | Forecast error and bias tracked by caller and method; coverage derived from history; fairness review | Accuracy log, backtests, audits | Week-8 error within the agreed band for four quarters | | 5. Adaptive | Plans, territories and methods changed on evidence; experiments with written results | Decision log, experiment notes | Sustain; improvements are routine | Level 3 is enough to plan credibly; Level 4 matters where the forecast drives external commitments. ### Adoption roadmap: 30/60/90 days Assumes a new SalesOps lead in a 20–60-seller company with an under-used CRM; order matters more than dates. | Phase | Actions | Metrics | Milestone | |---|---|---|---| | Days 1–30: see the system | Interview sellers, managers, Finance; map stages, fields and reports; list plans and disputes; snapshot pipeline daily | Baselines: slippage, stale deals, forecast error last 4 quarters, dispute count | Current-state map and baseline scorecard agreed | | Days 31–60: fix definitions and the cadence | Stage exit criteria and commit rules; Monday inspection report; forecast call agenda; deal approval matrix; plan calculator tested on last year | Inspection failures falling; submissions stored weekly | First month of the new cadence run end to end | | Days 61–90: plan with numbers | Capacity model; territory balance measured; coverage derived by segment; quota relief policy; accuracy log published | Capacity gap known; coverage by segment; first accuracy review | Next year's planning calendar and method approved | **Quick wins:** a weekly list of past-close-date deals; one approval matrix; stored forecast submissions; a dispute form with a deadline. **Dependencies:** CRM admin time, Finance agreement on booking policy, sales leadership support. ## Toolkit ### Checklists **Annual planning readiness** - [ ] Target tested against a ramp- and attrition-adjusted capacity model - [ ] Territory potential index documented and versioned; balance measured - [ ] Quota method, over-assignment and relief policy written - [ ] Plans tested on last year's bookings and edge cases; invariant holds at 100% - [ ] Plans signed before the period starts; jurisdictions checked with counsel - [ ] CRM changes for the new year released with notes **Weekly forecast cadence** - [ ] Inspection report published Monday; every Commit deal meets the rules - [ ] Submissions stored with caller, method and timestamp - [ ] Model forecast and caller accuracy presented next to the call - [ ] Top risks named with owners and dates **Quarter close** - [ ] Bookings reconciled: order, quote, opportunity, commission credit - [ ] Pulled-forward and non-standard deals listed for Finance - [ ] Forecast error and bias recorded per caller and method - [ ] Relief and dispute decisions logged with precedents **Governance audit (twice a year)** - [ ] Every territory, quota and plan change has a request, approver and effective date - [ ] Access to pay data limited to named roles; integration users scoped - [ ] Sample of statements recomputed from booked orders - [ ] Incentive features reviewed against a conduct-risk checklist (for example the FCA list) ### Templates **One-page SalesOps charter** ```text SALES OPERATIONS CHARTER (version, date, approver) Mission: a fair, predictable, low-friction system to sell in, and a forecast the company can plan on Owns: capacity model, territories, quota allocation (proposal), stages and exit criteria, forecast categories and call, CRM for sales, commission administration, deal desk Does not own: the sales number (head of sales), company target (BizOps/Finance), funnel definitions across teams (RevOps), pay ranges (PeopleOps) Service levels: deal desk first response <= 1 business day; statements correct at first issue >= 98%; inspection report every Monday 12:00 Measures: week-8 forecast error and bias; slippage; dispute rate; data quality; deal desk service level Decision rights: proposes territories, quotas, plans; decides definitions and CRM configuration; escalates exceptions to the committee Review: quarterly with head of sales and Finance ``` **Forecast call agenda (30 minutes per team)** ```text 1. Since last week (5 min): closed, pushed, new in Commit, removed from Commit 2. Commit review (10 min): evidence for each deal against the commit rules 3. Best case (8 min): what must happen, by when, owner 4. Risks and asks (5 min): help needed from leaders, deal desk, product 5. Submission (2 min): commit, best case, confidence; recorded with timestamp ``` **Quota relief decision record** ```text ID / date: QR-2026-07 / 2026-10-12 Seller and role: [name], mid-market new business Request: reduce Q4 quota by 150,000 Rule invoked: policy 3.2 (territory change after period start) Facts: 12 accounts moved on 2026-10-01; potential index 210 Calculation: pro rata by potential moved: 210 / 1,120 x 800,000 / 4 Decision: approved 37,500 for Q4; precedent noted Approvers: head of sales, SalesOps, Finance Communicated: 2026-10-13, in writing ``` **Monthly SalesOps scorecard** ```text Metric Target Last month Trend Owner Week-8 forecast error +/-5% +9.4% better SalesOps Slippage rate <15% 18.8% worse Sales managers Commit deals failing rules <5% 7% better Sales managers Commission accuracy >=98% 95% same Commissions Deal desk first response <=1 day 0.6 days same Deal desk Stale deals (no activity 21d) <10% 12% better Sellers ``` ### Deep comparisons: SalesOps and the other revenue-function pages The neighbours answer different questions about the same machine: [RevOps](../revops/), whether teams share definitions, data and one number; [MarketingOps](../marketingops/), whether marketing creates measurable pipeline; [CustomerOps](../customerops/), whether customers stay and grow; [BizOps](../bizops/), what the company runs on; [CXOps](../cxops/), whether experiences improve. This page asks the sales question — can this team sell the target, and will it? Choose it for capacity, quota, forecast-call and commission problems; RevOps for cross-functional disputes. ### FAQ **Is SalesOps the same as RevOps?** Not in this Atlas: RevOps integrates across functions; SalesOps runs the sales machinery ([term status](#term-status-and-the-revops-overlap)). A company can practise RevOps with separate ops teams. **Is sales enablement part of SalesOps?** Sometimes; it can be a sibling team (as at GitLab). SalesOps supplies the ramp data showing whether enablement works. **Should SalesOps report to sales or to Finance?** Either can work; see the [decision framework](#decision-framework). The tests: is the forecast independent of pressure to look good, and do sellers get help quickly? **Is 3× pipeline coverage right for us?** Only by coincidence — if, say, a third of your starting pipeline converts and nothing else contributes. Derive your own figure ([coverage](#pipeline-coverage-derived-rather-than-borrowed)). **Who decides a quota: SalesOps or the sales leader?** SalesOps proposes with a documented method; the sales leader decides and is accountable; Finance confirms the total covers the plan. **Can an AI forecast replace the forecast call?** It can replace much of the arithmetic and should challenge the call, but cannot see what is not in the data; see [the judgement call](#a-judgement-call-should-a-model-replace-the-forecast-call). **What happens to commissions when a deal is cancelled?** Whatever the signed plan says, within local law; write the clawback clause before the period. ## Going further ### Advanced topics and emerging direction - **Forecast-truthful incentives.** Under Gonik's scheme a seller who expects to sell x does best by forecasting x; Chen's model finds it "dominated by a menu of linear contracts" because it cannot induce different effort for different conditions.[^chen] *(Established research; no evidence of wide use found.)* - **Response-function models for sizing and allocation,** in the decision-calculus tradition of the Syntex case.[^syntex] *(Established method; needs analytical skill.)* - **Statistical and machine-learning forecasts** as challengers, with backtests and explainable factors.[^ms-premium] *(In products; value depends on data volume and stability.)* - **Consumption and usage-based pricing,** which blurs bookings and revenue and complicates quota and commission design. *(Active practice; little independent research found for this page.)* - **"Agentic" sales tools** promoted by vendors in 2026 ("revenue AI", "agentic go-to-market").[^gong][^highspot] *(Vendor marketing; judge by measured outcomes on your data.)* ### Learning path - **Prerequisites:** spreadsheet skills; basic statistics (median, percentages); one CRM's basics. - **One day:** read [In 30 seconds](#in-30-seconds) and [the core maths](#the-core-maths-capacity-territories-quotas-and-the-forecast); do Lab 1. - **One week:** Labs 2–4; write stage exit criteria and commit rules for a team you know; draft a call agenda. - **Thirty days:** run the Monday inspection report and store forecast submissions for four weeks; build a capacity model with your own ramp data; test your commission plan on last year's bookings. - **Specialisation:** territory and quota design (operations research), incentive compensation (plan design and law), forecasting (statistics), deal desk and CPQ (pricing and contracts). - **Portfolio project:** a backtest of three forecast methods on four or more quarters of your own (anonymised) data, with a recommendation and its uncertainty. ## Wrap-up ### Executive recap and cheat sheet **Decide:** the target only after a capacity test; the territory potential index; the quota method and relief rules; stage exit and commit rules; the reporting line; deal desk approvals. **Practise:** Monday inspection; the weekly call with stored submissions; explained potential-based quotas; tested, signed plans; booking review before credit. **Measure:** week-8 forecast error and bias; coverage derived from history; slippage; attainment distribution; commission accuracy; deal desk service level. **Watch out for:** borrowed ratios; heads not ramped heads; mid-year plan changes; pulled-forward deals; incentives without monitoring; two sources of truth for ownership. ### A judgement call: should a model replace the forecast call? **The situation.** A 50-seller company's CFO, tired of quarters called 10–20% low, proposes replacing the weekly roll-up with a statistical forecast (option A). Option B: keep the call, add the model as a challenger, publish each method's error and bias every quarter. **Assumptions.** Six quarters of snapshots exist; the top ten deals are about 40% of each quarter's bookings; product and segments stable; the company is private. **Where option A breaks under these assumptions.** 1. **Lumpiness.** When a few large deals decide the quarter, a model built on historical conversion rates cannot know one champion has left; the managers often do. 2. **Thin history.** Six quarters is enough to show bias, not to prove a model better; a product's technical minimum (more than ten closed opportunities) says nothing about that.[^ms-premium] 3. **Accountability.** If the number is the model's, leaders stop owning it and the inspection discipline that improves data quality weakens. 4. **The bias is fixable.** A consistent under-call (as in Lab 4) can be shown to callers and corrected faster than a new model can be validated. **What option A gets right:** judgement is biased — Gartner's 2020 survey found fewer than half of sales leaders and sellers highly confident in forecast accuracy.[^gartner-2020] So option B needs teeth: the model appears in every call, each method's MAPE and bias are published, and the **default switches** to whichever method has the lower error over four consecutive quarters, keeping manager judgement for the largest deals. **Decision: option B**, reviewed after four quarters — a reasoned recommendation, not a proven result. ### Learning objectives and mastery check You should now be able to **explain** how SalesOps differs from its neighbours; **build** a ramp-adjusted capacity model; **derive** pipeline coverage; **measure** territory balance; **allocate** quotas; **write** stage exit criteria and commit rules; **run** a forecast cadence and **measure** its error; **test** a commission plan; **decide** how to set up the function. ::: answer 1. Ten sellers with a 900,000 quota each are planned against a 9,000,000 target. Why might this fail? Quota is not productivity and heads are not ramped heads: ramped sellers booked 85% of quota on average, new sellers ramp, leavers stop producing, backfills ramp again. Lab 2's roster delivers about 6.7 million. Test the target against capacity before accepting it. ::: ::: answer 2. Starting pipeline converts at 25% by value and 20% of bookings come from new deals and pull-ins. What coverage do you need? Required coverage = (1 − 0.20) ÷ 0.25 = 3.2× the quarter's target; the borrowed 3× leaves a gap of 0.2× of target. ::: ::: answer 3. A manager's calls over six quarters came in 9%, 19%, 8%, 20%, 8% and 16% below actual bookings. What does that tell you? A consistent under-call (positive bias, with e = actual − forecast) from sandbagging or strict commit rules, not random error. Show the bias, check the commit rules, add a calibrated challenger. ::: ::: answer 4. A plan adds a 0.6× decelerator below 50% attainment and keeps 1.0× from 50% to 100%. What is wrong? At 100% attainment it pays 0.5 × 0.6 + 0.5 × 1.0 = 80% of the target incentive. Raise the 50–100% multiplier to 1.4× (or change the bands) so quota pays exactly the target incentive; add the invariant as a test. ::: ::: answer 5. Thirty accounts move between sellers on 1 July. Name three things to settle before the move. Effective date and protected late-stage deals; the crediting rule and the single ownership source the commission system reads; written, approved quota changes for both sellers. Communicate before the date. ::: ::: answer 6. A 6-seller start-up asks you to design its SalesOps team. What do you recommend? No team yet: one accountable owner, written stage definitions and commit rules, required CRM fields, a one-page tested plan, a weekly pipeline review. Revisit at eight or more sellers, a second segment or complex deals. ::: ::: answer 7. Sales wants to pay a SPIFF for every opportunity created this quarter. What risk do you raise? Paying for a leading indicator invites fake or premature opportunities, inflating coverage and slippage. Use a SPIFF only on opportunities that reach a later stage, with an end date, and monitor for gaming. ::: ### Conclusion Sales operations is the part of the company that turns "we should sell more" into numbers that can be tested: how many sellers, where, asked for what, paid how, and how sure we are about this quarter. Three habits carry most of the value: **test the target against capacity before anyone signs a quota**; **define stages and categories by evidence and measure every forecast against what happened**; and **treat incentives as powerful instruments that need written rules and monitoring**. A small team with clear definitions and an honest accuracy log is doing sales operations; a large team with expensive tools and a forecast nobody has ever scored is not. One test: can you say, before the quarter starts, how wrong your forecast is likely to be, and why? ## Sources and further reading All sources were opened on 2026-10-18 (two re-checked on 2026-10-19, five on 2026-10-23); the evidence ledger records what each supports and what could not be fetched. Legal and accounting sources are for orientation, not advice. [^forr-dec]: [Revenue Operations: Driving Better Customer Experiences And Growth](https://www.forrester.com/blogs/forrester-decisions-for-revenue-operations/) — Forrester blog (C. De Martini), 2023-06-04. 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 (L. Cross), 2023-09-15. Checked 2026-10-18. [^gartner-2020]: [Gartner Says Less Than 50% of Sales Leaders and Sellers Have High Confidence in Forecasting Accuracy](https://www.webwire.com/ViewPressRel.asp?aId=254916) — Gartner press release, 2020-02-12, as distributed by WebWire (Gartner's own page could not be fetched automatically). Checked 2026-10-18. [^gl-salesops]: [Sales Operations](https://handbook.gitlab.com/handbook/sales/field-operations/sales-operations/) — GitLab Handbook, updated 2026-09-24. Checked 2026-10-18. [^gl-fieldops]: [Field Operations](https://handbook.gitlab.com/handbook/sales/field-operations/) — GitLab Handbook, updated 2025-04-30. Checked 2026-10-18. [^gl-dealdesk]: [Deal Desk Handbook](https://handbook.gitlab.com/handbook/sales/field-operations/sales-operations/deal-desk/) — GitLab Handbook, updated 2026-10-12. Checked 2026-10-18. [^gl-gtm]: [Sales Operations Go To Market](https://handbook.gitlab.com/handbook/sales/field-operations/sales-operations/go-to-market/) — GitLab Handbook, updated 2024-06-27. Checked 2026-10-23. [^hbr-2014]: [Why Sales Ops Is So Hard to Get Right](https://hbr.org/2014/12/why-sales-ops-is-so-hard-to-get-right) — A. A. Zoltners, P. Sinha and S. E. Lorimer, Harvard Business Review, 2014-12-29 (only the opening paragraph, which carries the Xerox account, is readable without a subscription). Checked 2026-10-18. [^zs-1983]: [Sales Territory Alignment: A Review and Model](https://ideas.repec.org/a/inm/ormnsc/v29y1983i11p1237-1256.html) — A. A. Zoltners and P. Sinha, Management Science 29(11):1237–1256, 1983 (abstract via RePEc). Checked 2026-10-18. [^zsl-2004]: [Sales Territory Alignment](https://ideas.repec.org/h/pal/palchp/978-0-230-51492-8_8.html) — A. A. Zoltners, P. Sinha and S. E. Lorimer, in Sales Force Design for Strategic Advantage, Palgrave Macmillan, 2004 (abstract via RePEc). Checked 2026-10-18. [^syntex]: [Sales Force Sizing and Deployment Using a Decision Calculus Model at Syntex Laboratories](https://ideas.repec.org/a/inm/orinte/v18y1988i1p5-20.html) — L. M. Lodish, E. Curtis, M. Ness and M. K. Simpson, Interfaces 18(1):5–20, 1988 (abstract via RePEc). Checked 2026-10-18. [^kellogg]: [Writing the Books on Sales Forces](https://insight.kellogg.northwestern.edu/article/writing_the_books_on_sales_forces) — Kellogg Insight, 2010-09-01. Checked 2026-10-18. [^isms]: [In Memoriam: Andy Zoltners](https://connect.informs.org/isms/in-memoriam/andy-zoltners) — INFORMS Society for Marketing Science, June 2024. Checked 2026-10-18. [^sf-territories]: [Manage Territories and Crush Your Sales Goals](https://trailhead.salesforce.com/content/learn/modules/sales-territories-and-forecasting/manage-territories-and-crush-your-sales-goals) — Salesforce Trailhead. Checked 2026-10-18. [^sf-forecast]: [Configure Forecasting in Salesforce](https://trailhead.salesforce.com/content/learn/modules/sales-forecasting/configure-sales-forecasting-in-salesforce) — Salesforce Trailhead. Checked 2026-10-18. [^hs-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-23. [^hs-pipelines]: [Set up and customize pipelines](https://knowledge.hubspot.com/object-settings/set-up-and-customize-pipelines) — HubSpot Knowledge Base, updated 2026-09-29. Checked 2026-10-18. [^ms-forecast]: [Configure forecasts in your organization](https://learn.microsoft.com/en-us/dynamics365/sales/configure-forecast) — Microsoft Learn, 2026-05-29. Checked 2026-10-18. [^ms-premium]: [Enable premium forecasting](https://learn.microsoft.com/en-us/dynamics365/sales/configure-premium-forecasting) — Microsoft Learn, 2026-05-06. Checked 2026-10-18. [^fpp3]: [Evaluating point forecast accuracy (section 5.8)](https://otexts.com/fpp3/accuracy.html) — R. J. Hyndman and G. Athanasopoulos, Forecasting: Principles and Practice, 3rd ed., OTexts (online version updated 2026-10-17). Checked 2026-10-18. [^chen]: [Salesforce Incentives, Market Information, and Production/Inventory Planning](https://business.columbia.edu/sites/default/files-efs/pubfiles/4339/chen_salesforce.pdf) — F. Chen, Management Science 51(1):60–75, 2005 (author copy). Checked 2026-10-18. [^gonik]: [Tie Salesmen's Bonuses to Their Forecasts](https://hbr.org/1978/05/tie-salesmens-bonuses-to-their-forecasts) — J. Gonik, Harvard Business Review, May 1978 (only the page header was readable; content via Chen 2005). Checked 2026-10-18. [^metabase]: [Pipeline Coverage: Definition, Formula & How to Track It](https://www.metabase.com/metrics/pipeline-coverage) — Metabase (vendor documentation), undated. Checked 2026-10-18. [^sf-velocity]: [How to Supercharge Your Sales Velocity for Quicker Wins](https://www.salesforce.com/blog/sales-velocity/) — Salesforce blog (E. Hueffner), 2024-03-12. Checked 2026-10-18. [^sf-vr]: [Create Validation Rules](https://trailhead.salesforce.com/content/learn/modules/point_click_business_logic/validation_rules) — Salesforce Trailhead, module Formulas and Validations. Checked 2026-10-18. [^sf-vr-bypass]: [Bypass Your Validation Rules](https://trailhead.salesforce.com/content/learn/modules/validation-rules/bypass-your-validation-rules) — Salesforce Trailhead, module Validation Rules. Checked 2026-10-18. [^sf-vr-project]: [Create a Validation Rule](https://trailhead.salesforce.com/content/learn/projects/improve-data-quality-for-a-cleaning-supply-app/create-a-validation-rule) — Salesforce Trailhead project. Checked 2026-10-18. [^sf-sos]: [Sales AI statistics 2024 (State of Sales, 6th edition)](https://www.salesforce.com/news/stories/sales-ai-statistics-2024/) — Salesforce News, 2024-07-25 (vendor survey of 5,500 sales professionals, 8 March–18 April 2024). Checked 2026-10-18. [^chung]: [Do Bonuses Enhance Sales Productivity? A Dynamic Structural Analysis of Bonus-Based Compensation Plans](https://dash.harvard.edu/handle/1/10304562) — D. J. Chung, T. Steenburgh and K. Sudhir, Marketing Science 33(2):165–187, 2014 (Harvard DASH record). Checked 2026-10-18. [^trg]: [Incremental costs of obtaining a contract (TRG Agenda ref 23)](https://www.ifrs.org/content/dam/ifrs/meetings/2015/january/trg-rev/rev-rec/ap23-costs-obtain-contract.pdf) — FASB–IASB Joint Transition Resource Group staff paper, 2015-01-26 (Appendix A quotes ASC 340-40 and IFRS 15 paragraphs 91–94 and 99; a staff discussion, not authoritative guidance). Checked 2026-10-18. [^calchamber]: [Am I required to have a written agreement with employees paid on commission?](https://p-hrcalifornia.calchamber.com/hr-library/qa/employees-paid-commission-required-written-agreement-employment-contract-employees) — HRCalifornia, California Chamber of Commerce (summary of Labor Code §2751; the statute site could not be fetched automatically). Checked 2026-10-18. [^ggw]: [Goals Gone Wild: The Systematic Side Effects of Over-Prescribing Goal Setting](https://www.hbs.edu/ris/Publication%20Files/09-083.pdf) — L. D. Ordóñez, M. E. Schweitzer, A. D. Galinsky and M. H. Bazerman, HBS Working Paper 09-083, 2009. Checked 2026-10-18. [^cfpb]: [CFPB fines Wells Fargo $100 million for widespread illegal practice of secretly opening unauthorized accounts](https://www.consumerfinance.gov/about-us/newsroom/consumer-financial-protection-bureau-fines-wells-fargo-100-million-widespread-illegal-practice-secretly-opening-unauthorized-accounts/) — US Consumer Financial Protection Bureau, 2016-09-08. Checked 2026-10-18. [^marn]: [Managing Price, Gaining Profit](https://hbr.org/1992/09/managing-price-gaining-profit) — M. V. Marn and R. L. Rosiello, Harvard Business Review, September–October 1992 (summary only). Checked 2026-10-18. [^sf-cpq]: [Navigating the Future of Salesforce CPQ: Product End of Sale (Not End of Life)](https://www.salesforce.com/sales/cpq/end-of-life/) — Salesforce (A. Wright), 2026-07-10. Checked 2026-10-23. [^sec-ua]: [SEC Charges Under Armour Inc. With Disclosure Failures (press release 2021-78)](https://www.sec.gov/news/press-release/2021-78) — US Securities and Exchange Commission, 2021-05-03. Checked 2026-10-18. [^gdpr4]: [Art. 4 GDPR: Definitions](https://gdpr-info.eu/art-4-gdpr/) — gdpr-info.eu (unofficial text of Regulation (EU) 2016/679). Checked 2026-10-18. [^aiact-annex]: [Annex III: High-risk AI systems referred to in Article 6(2)](https://artificialintelligenceact.eu/annex/3/) — artificialintelligenceact.eu (unofficial text of Regulation (EU) 2024/1689). Checked 2026-10-18. [^ec-aiact]: [AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) — European Commission, updated 2026-10-19. Checked 2026-10-23. [^fca]: [FG18/2: Staff incentives, remuneration and performance management in consumer credit firms](https://www.fca.org.uk/publications/finalised-guidance/fg18-2-proposals-staff-incentives) — UK Financial Conduct Authority, first published 2018-03-27, updated 2026-10-09. Checked 2026-10-18. [^meddicc]: [MEDDPICC Sales Methodology](https://meddicc.com/what-is-meddpicc) — MEDDICC (commercial training firm), undated. Checked 2026-10-18. [^varicent]: [Varicent](https://www.varicent.com/) — vendor home page. Checked 2026-10-18. [^xactly]: [Xactly](https://www.xactlycorp.com/) — vendor home page. Checked 2026-10-18. [^spiff]: [Salesforce signs definitive agreement to acquire Spiff](https://www.salesforce.com/news/stories/salesforce-signs-definitive-agreement-to-acquire-spiff/) — Salesforce News, editor's note: completed 2024-02-01. Checked 2026-10-18. [^clari-salesloft]: [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, 2025-12-03 (clari.com still redirected to salesloft.com on 2026-10-23). Checked 2026-10-23. [^gong]: [Gong](https://www.gong.io/) — vendor home page. Checked 2026-10-18. [^highspot]: [Highspot](https://www.highspot.com/) — vendor home page. Checked 2026-10-18. [^seismic-highspot]: [Seismic completes merger with Highspot to create a new leader in Go-to-Market Performance](https://www.highspot.com/blog/seismic-completes-highspot-merger/) — Seismic press release republished on the Highspot blog, 2026-08-18; intent announced 2026-02-12 per [Seismic announces intent to merge with Highspot](https://www.seismic.com/newsroom/press-releases/seismic-highspot-merger-intent) — Seismic, 2026-02-12. Checked 2026-10-19. **Further reading (not opened for this page beyond the abstracts cited above).** - A. A. Zoltners, P. Sinha and S. E. Lorimer, *Sales Force Design for Strategic Advantage* (Palgrave Macmillan, 2004): sizing, structure and territory alignment in depth. **Changelog.** Time-sensitive rows (tool ownership, CPQ status, AI Act dates, HubSpot editions) are due for re-verification by 2027-01-23. - 2026-10-18, first version: research ledger, nine diagrams, four labs and two artefacts executed on synthetic data. - 2026-10-19, revision 1 after the independent fact-check: capacity maths corrected (one productivity base, mean not median, backfills); forecast error now actual − forecast, as in the textbook and on the RevOps page; the inspection query catches pushes out of the quarter and publishes its sample rows; Xerox origin sourced to HBR; vendor mergers dated; RACI, decision tree, coverage pull-ins and several precision fixes; about 700 words cut. - 2026-10-19, revision 2 after review r1: GitLab territory-override description corrected to the source's three response statuses with nightly re-routing scoped to accounts holding an effective date; Seismic–Highspot intent date re-verified and cited; about 920 words cut to return to the 8,000–15,000 band. - 2026-10-23, post-score polish: five time-sensitive sources re-checked (facts unchanged, AI Act as-of date updated); forecast-call figure spacing tightened; three repeated passages cut.