SalesOps

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.

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”,^[1] and Gartner’s 2020 State of Sales Operations Survey reported pressure on “heads of sales operations” to forecast accurately.^[2] 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.^[3][4] The practices behind the label have a peer-reviewed literature back to the early 1980s,^[5][6] and the earliest traceable account of a sales operations group (Xerox in the 1970s, see origins) lists jobs this page still covers: planning, compensation, forecasting and territory design.^[7]

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”.^[1] In a later post, Forrester analysts write that “marketing operations, sales operations, and customer operations need to break down silos and integrate their actions”.^[8] So RevOps does not replace sales operations; it changes who coordinates it.

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.

• 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; SalesOps takes over at the agreed hand-off.
• Not customer success. Renewals, adoption and health scores belong to 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).

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.

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).^[9] Gartner reported in 2020 that only 45% of sales leaders and sellers had high confidence in forecast accuracy.^[2] 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.^[10]

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”.^[7] 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.^[11][12]
• 1983: Zoltners and Sinha publish a review and general model of territory alignment.^[5] They co-founded ZS; Kellogg reported in 2010 more than 1,800 applications of the model in 37 countries.^[13][14]
• 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).^[6]
• 2023: Forrester launches a revenue operations research service, framed as a strategy rather than an org chart.^[1]

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.

SalesOps sits in the middle of the revenue engine; the figure shows what crosses each boundary.

%%{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

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.

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.

RACI for the core annual and weekly work (R = responsible, A = accountable, C = consulted, I = informed; one A per row).

Organisations differ: GitLab runs deal desk, commissions, sales systems and sales strategy as separate teams in Field Operations.^[4] What matters: each row (and approval threshold) has exactly one accountable owner, and the team that books an order does not approve its discount.

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.

%%{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

For setting up the function itself, see the 30/60/90-day roadmap.

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.^[4]
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.

Sales operations is mostly a process discipline, but the process lives in software. The architecture below is vendor-neutral; the tooling landscape names examples.

%%{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

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.

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.^[15][16]

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 --> [*]

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.

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 takes the customer.

Exception paths. (1) Non-standard terms: the quote crosses an approval threshold and goes through the deal desk (deal desk playbook). (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.

This part is the centre of the page: each sub-section gives the formula, its assumptions, and the usual error. Lab 2 and Lab 4 let you run the numbers.

%%{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

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.

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.^[5][10] Four criteria trade off against each other:

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).^[17]

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 measures balance and finds the few moves that fix most of it.

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.^[12]

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.

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.^[18]

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.

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”.^[15]
• 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).^[16]

Write the category rules down. An example rule set (adapt it):

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 call is a weekly meeting, but most of the work happens before it: Monday, SalesOps publishes an inspection report per team (Artefact 4); 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).

%%{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

Where a RevOps function exists it governs the company number; SalesOps runs the categories, inspection, call and accuracy log.

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^[19] and the one the 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.^[19] 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.

Compensation design is decided by sales leadership with Finance and PeopleOps; SalesOps models options, writes plan documents, runs calculations and handles disputes.

Design decisions, in order:

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.^[20] 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 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).^[21]

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.^[22] 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).

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”.^[25] 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 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.^[25]

%%{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

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”.^[26]

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).^[27]

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).^[28] Salesforce validation rules block a save when a formula returns true, with a visible error message.^[29]
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) 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”);^[30] retention, access and lawful basis are designed with PrivacyOps.

Enablement (onboarding, training, certification, content, coaching) can be a sibling team, as at GitLab.^[4] 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 and the content lifecycle to ContentOps. The test is the ramp curve: if onboarding works, cohort ramp at months 3 and 6 rises.

No standard body defines sales operations. The useful frameworks are of three kinds; none is mandatory.

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.

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.

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).^[40] Ten deals is a technical minimum, not a sufficient history; judge any model by a backtest on your own data (Lab 4) 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).^[41][42] 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.^[33] 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.

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.

Example status: syntax-checked (YAML), not executed; load it into a data-quality job or use it as the specification for CRM configuration.

# 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]

Example status: syntax-checked (YAML), not executed; most CPQ and case tools can model these fields.

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"}

Example status: syntax-checked (YAML), not executed.

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

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.

-- 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.

-- 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);

"""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).

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.

Example status: illustrative, not executed (no Salesforce org was available); syntax follows the patterns in Salesforce’s Trailhead material.^[29][43][44] Economic_Buyer_Confirmed__c, Next_Step_Date__c and the custom permission Bypass_Commit_Rule are hypothetical.

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),^[44] because any identity holding it can set Commit without evidence. Integration users that only sync data should not edit the forecast category at all.

Example status: verified by execution on 2026-10-18 (Python 3.8.10, standard library); illustrative plan, not a recommendation.

"""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.

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.^[20] And the clawback is charged at the marginal rate (18.75% here), not the average; write which one your plan uses.

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.

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).

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).

"""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.

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;^[45] 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

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).

"""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).

"""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.

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

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).

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).

"""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.

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

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. 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).

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).

"""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.

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

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.^[6] 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.

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.^[46] 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.

Revenue-wide formulas (ARR, NRR, CAC) are defined once in RevOps; the metrics below are the ones SalesOps owns or runs, with governed definitions and dashboards built with AnalyticsOps.

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.

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).
• 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.^[25] Pulled-forward orders can become a disclosure problem for listed companies.^[46]
• 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.^[47] 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”.^[24]
• Personal data. CRM contacts and pay data are personal data where laws such as the GDPR apply;^[30] 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);^[41][42] recording calls also needs notice and, where the law requires it, consent.^[33]
• Separation of duties and audit trail. Field history on amounts and stages; approvals stored with the quote; commission calculations reproducible from booked orders.

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.^[9] 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.

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.^[25]

%%{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

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.

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).
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.^[23]

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.

%%{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

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.

This is this Atlas’s maturity model, not an official standard.

Level 3 is enough to plan credibly; Level 4 matters where the forecast drives external commitments.

Assumes a new SalesOps lead in a 20–60-seller company with an under-used CRM; order matters more than dates.

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.

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)

One-page SalesOps charter

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)

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

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

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

The neighbours answer different questions about the same machine: RevOps, whether teams share definitions, data and one number; MarketingOps, whether marketing creates measurable pipeline; CustomerOps, whether customers stay and grow; BizOps, what the company runs on; 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.

Is SalesOps the same as RevOps? Not in this Atlas: RevOps integrates across functions; SalesOps runs the sales machinery (term status). 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. 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).

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.

What happens to commissions when a deal is cancelled? Whatever the signed plan says, within local law; write the clawback clause before the period.

• 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.^[12] (Established research; no evidence of wide use found.)
• Response-function models for sizing and allocation, in the decision-calculus tradition of the Syntex case.^[6] (Established method; needs analytical skill.)
• Statistical and machine-learning forecasts as challengers, with backtests and explainable factors.^[40] (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”).^[38][48] (Vendor marketing; judge by measured outcomes on your data.)

• Prerequisites: spreadsheet skills; basic statistics (median, percentages); one CRM’s basics.
• One day: read In 30 seconds and the core maths; 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.

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.

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.^[40]
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.^[2] 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.

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.

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?

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.

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.