CustomerOps

CustomerOps, as this Atlas uses the word, is customer success operations: the people, data, processes and systems that make sure customers who have already bought reach the outcome they bought for, so that renewals and expansion are predictable and risk is visible months before a contract ends. A CustomerOps team rarely talks to customers itself. It designs the coverage model (who gets a named manager, who gets automated programmes), the onboarding path to first value, the success-plan template, the health score and its alerts, the renewal calendar and risk review, and the joined account data behind them.

The label is not standardised: “customer operations” has at least three meanings (see the naming problem). Read this page as a treatment of one meaning.

Who this page is for: beginners, CS operations practitioners, CS leaders, analysts asked to “make the health score predictive”, and RevOps or support partners who need to know where their work ends.

Know which “CustomerOps” a speaker means. Three usages are documented:

1. An umbrella for everything behind customer-facing teams. Front calls customer operations “the strategic management of the behind-the-scenes systems, data, and processes that allow front-line teams to function properly” and groups support, customer success and customer experience operations under it.^[1] A 2018 Workato article called customer ops “a fairly new term” and quoted the investor Tomasz Tunguz describing it as the software and metrics for the whole customer journey.^[2]
2. The operations behind customer service and support. Kaizo, a support-quality vendor, defines customer operations as “the function that builds and runs the machinery behind customer support: processes, tools, staffing, quality assurance and reporting”, calls support operations “usually the support-specific slice of customer operations” and notes that in smaller companies the two are one team; the same page also offers a broad umbrella definition.^[3] A 2021 CustomerThink post names the roles behind customer service, such as staff scheduling and contact volume analysis, but uses the term for how customer service works with other departments.^[4]
3. Customer success operations (CS Ops). Forrester has published research on this role since at least 2019, describing it as distinct because it focuses on existing customers,^[5] and a 2023 role profile of the CS operations manager as the partner of the CS leader who implements processes at scale.^[6]

One US patent even uses “CustomerOps” as a software platform name.^[7] No standards body defines the term.

• Not customer service. CustomerOps may use ticket data as a signal; it does not run the queue.
• Not the CSM job. Customer success managers (CSMs) work accounts; CS operations builds the system they work in. Forrester’s analysts call it the air traffic control tower for the pilots.^[8]
• Not CX measurement. Forrester’s analysts separate customer success (post-sale, judged on customer and company outcomes) from customer experience (broad, mostly indirect, judged on sentiment such as NPS and CSAT).^[9]
• Not a health score. A score is one artefact; a configured platform without plays and validation is a dashboard.

Recurring revenue is earned after the sale: a customer who never adopts can leave at the first renewal. Without a CustomerOps function the same patterns repeat: coverage by accident (loud accounts get attention, small ones get nothing until they cancel); onboarding that ends at go-live, with nobody owning the time to the customer’s first outcome; renewals discovered late, without a record, owner or risk call; health scores that are opinions, never checked against churn; and churn reasons nobody can use.

With the function in place, each of these has an owner and a record, and value shows up in the drivers of retention (Metrics and KPIs), not in activity counts.

No origin date for the label can be documented. What can be traced:

• Customer success as a function grew with subscription software. Lincoln Murphy’s widely used definition: customers achieve their Desired Outcome through their relationship with the vendor (he now writes the Desired Outcome as goal plus appropriate experience).^[10]
• Lifecycle models gave the work a shape: TSIA’s LAER model (Land, Adopt, Expand, Renew).^[11]
• Operations roles followed, visible in Forrester’s 2019 report and 2023 role profile.^[5][6]
• A tool category formed: Gartner’s first Magic Quadrant for Customer Success Management Platforms is dated 28 October 2024, as reported by a vendor in it,^[12] and the market consolidated: Totango and Catalyst closed a merger in early 2024,^[13] and as of October 2026 Totango’s site reads “Totango is now Odie”.^[14]

Mental model: a control loop around value. Signals feed a view of risk; the view triggers plays; renewal outcomes return months later and test whether signals and plays worked. Most failures are a broken link in that loop.

%%{init: {"flowchart": {"wrappingWidth": 140, "nodeSpacing": 22, "rankSpacing": 46}}}%%
flowchart TB
  SO["SalesOps: new business"]
  RV["RevOps: definitions, hand-offs, forecast"]
  SU["SupportOps: tickets, SLAs"]
  KN["KnowledgeOps: help content"]
  CO["CustomerOps: coverage, onboarding, health, renewals"]
  CX["CXOps: surveys, journey governance"]
  AN["AnalyticsOps: metric layer, models"]
  SO -->|"hand-off"| CO
  RV <-->|"formulas, renewal base; renewal call"| CO
  SU -->|"ticket signals"| CO
  KN -.->|"self-service"| CO
  CO <-->|"churn reasons; survey signals"| CX
  CO -->|"model requests"| AN
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class CO core
  class RV,SO,SU,CX,AN,KN neutral

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

Mission. Make customer value after the sale visible, managed and improvable, so that retention and expansion follow from customers succeeding rather than from late heroics.

1. Outcome before activity. Measure whether customers reach objectives and renew, not how many calls were logged.
2. Every account has a service model. Tech-touch is a designed service, not neglect.
3. Scores are hypotheses. Published with inputs, weights and a validation record; retired when they stop predicting.
4. Signals need owners and plays. An alert without a named owner and response is noise.
5. Renewals start at onboarding, through the success plan.
6. One customer record, joined on one account key; no parallel spreadsheet truth.
7. Learn from every loss with a coded reason.

Non-goals: running the support queue, designing the NPS programme, owning revenue definitions, setting quotas, or optimising for a high average health score.

Typical roles: CS leader (accountable for retention), CSMs (a book of accounts), renewal or account managers (commercial renewal and expansion), CS operations (segments, playbooks, scores, tools, reporting) and an analyst who builds and validates models. R = responsible, A = accountable, C = consulted, I = informed.

The health-score row follows the boundary recorded on the RevOps page. Who is accountable for the commercial renewal varies by company; what matters is exactly one accountable role per contract.

%%{init: {"flowchart": {"wrappingWidth": 160, "nodeSpacing": 18, "rankSpacing": 30}}}%%
flowchart TB
  H["Hand-off from sales: goals, stakeholders, promises"] --> O["Onboard: kickoff, success plan, first value date"]
  O --> V{"First value reached on time?"}
  V -- "No" --> R1["Onboarding risk play: unblock, re-plan, escalate"]
  R1 --> O
  V -- "Yes" --> A["Adopt: use cases, breadth, active users"]
  A --> E["Expand: signals to account owner"]
  A --> RN["Renewal prep: record, risk call, review"]
  E --> RN
  RN --> D{"Renews?"}
  D -- "Yes" --> A
  D -- "No or partial" --> L["Loss review: coded reason, pattern check"]
  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 H,O,A,E,RN core
  class V,D decision
  class R1,L risk

The stages follow TSIA’s Land–Adopt–Expand–Renew model,^[11] with the hand-off and the loss review made explicit because that is where data is most often lost. TSIA’s Steve Frost asserts that whether a customer has expanded is a leading predictor of renewal;^[15] the post shows no data, so test it in your own backtest.

Escalations run CSM → CS leader → executive sponsor; support escalations use the SupportOps process.

For a business function, the architecture is about where each fact lives and how it reaches the person who must act.

%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 14, "rankSpacing": 34}}}%%
flowchart TB
  subgraph SRC["Sources of record"]
    BILL["Billing: contracts, ARR, end dates"]
    CRM["CRM: accounts, owners, renewals"]
    PROD["Product: usage events"]
    SUP["Helpdesk: tickets"]
    BILL ~~~ PROD
    CRM ~~~ SUP
  end
  BILL --> WH["Warehouse: joined account history and snapshots"]
  CRM --> WH
  PROD --> WH
  SUP --> WH
  WH --> HM["Health model: signals, weights, bands"]
  HM --> CSP["CS platform: score, alerts, playbooks, success plans"]
  CSP --> PLAY["Plays: CSM tasks or automated journeys"]
  PLAY --> OUT["Outcomes: renewal, contraction, churn, expansion"]
  OUT --> WH
  WH -.->|"quarterly backtest"| HM
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  class WH,HM,CSP core
  class BILL,CRM,PROD,SUP neutral
  class PLAY,OUT decision

Trade-offs. Platform scorecards are quick to set up; warehouse models are easier to version and backtest; many teams compute in the warehouse and push the score to the platform. Snapshot weekly either way, and assign an owner for account-key problems: GitLab’s handbook shows a Salesforce account merge leaving a CS-platform copy for CS operations to review.^[16]

%%{init: {"flowchart": {"wrappingWidth": 150, "nodeSpacing": 18, "rankSpacing": 30}}}%%
flowchart TB
  W["Contract signed: renewal record created from billing"] --> K["Kickoff and success plan within agreed days"]
  K --> M["Monitor: usage, outcomes, tickets, sentiment"]
  M --> Q{"Signal crosses a trigger?"}
  Q -- "No" --> T{"120 days before end?"}
  Q -- "Yes" --> P["Play: owner, steps, due date"]
  P --> X{"Risk resolved?"}
  X -- "Yes" --> M
  X -- "No" --> ESC["Escalate: sponsor, product, commercial options"]
  ESC --> T
  T -- "No" --> M
  T -- "Yes" --> RC["Renewal review and risk call"]
  RC --> OUT["Outcome recorded with coded reason"]
  OUT --> BT["Feeds backtest and churn review"]
  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 W,K,M,RC,OUT,BT core
  class Q,X,T decision
  class P,ESC risk

The 120-day mark is illustrative. GitLab’s handbook opens a renewal task four months before the renewal date and expects the customer conversation within 30 days, leaving about three months to act.^[17] Choose a lead time longer than your slowest mitigation. Exception paths to design in advance: a contract with no renewal record (Lab 3), a usage feed that stops (worked runbook), a non-renewal announced before any signal fired (missed-signal review), and an account merged or split mid-term.

Segmentation and coverage. Forrester’s analysts argue that post-sale segments should reflect traits that drive adoption, maturity and growth, not revenue alone, each with a defined engagement model, and should change as customers mature.^[18] They distinguish scaled customer success (human and digital, one-to-many) from digital-led (mainly automated, built on self-sufficiency).^[19] Gainsight publishes starting heuristics, four tiers from high-touch to tech-touch with suggested ARR bands and CSM-to-account ratios;^[20] treat them as one vendor’s starting point, not benchmarks.

Onboarding to first value. Define first value as the customer’s objective, not your product’s activation. GitLab’s handbook starts CSM onboarding at the negotiating stage, requires an internal hand-off before the CSM meets the customer, targets the kickoff within 14 days of the start date and first value within 30 days (measured there by a product proxy: at least 10% of production licences activated), and flags customer-caused delays as risk.^[21] See the playbook template. The hand-off checklist itself is a RevOps stage gate; Forrester’s analysts recommend it hold what only sellers know.^[22]

Success planning. GitLab tracks “verifiable outcomes” from proposed to accepted, delivered and verified, the last meaning the customer has confirmed completion.^[23] Customer confirmation is what separates outcomes from activity.

Business reviews and expansion. Expansion is the account owner’s commercial work; CustomerOps supplies the evidence. GitLab holds an executive business review at month 6 (early enough to correct adoption, late enough to show milestones) and at least one per customer a year.^[24] Use the review to verify success-plan outcomes with the customer and reset objectives; then send the account owner a written expansion note: the evidence (new teams, use cases, seat headroom), the customer contact and the date. GitLab’s handbook lists 90% licence utilisation among example seat-expansion cues, and below 75% (excluding onboarding customers) as a seat-reduction sign.^[25]

Loss review. Code one primary reason from a short list, agreed by CSM and renewal owner within a week (Artefact 4).

No standard or regulation defines customer success operations. These optional frameworks each serve one job:

Categories first; product names are examples verified on 2026-10-23, not recommendations.

Two documented score engines (as of October 2026). Gainsight scorecards group measures with percentage weights in each group and overall (each capped at 100%), work at company or relationship level, and, when measures become NA, redistribute the weight among the other groups in proportion.^[34][35] HubSpot health scores add or subtract points through groups of either events or properties, cap each group, map totals to labelled thresholds, and need Service Hub Professional or Enterprise and a Service seat (several scores only in Enterprise).^[30] The missing-data rule matters: a redistributed weight keeps showing a colour made of the remaining signals. GitLab sets stale usage measures to “NA” after 60 days on purpose, preferring no value to an outdated one.^[25]

Automation helps where the action is standard and the trigger reliable: onboarding emails, renewal reminders, alert routing, draft account summaries. A 2026 Forrester post describes AI agents that detect falling engagement, start an executive outreach play and update the success plan, and reports Gainsight support for the Model Context Protocol; the post contains no data and no discussion of risk.^[36] Before letting an agent act: decide which actions need approval (messages to executives, renewal calls and discounts do); log every action against the account; test it against a random holdout; and check privacy rules for per-user data (Quality, privacy and compliance). Explainability matters too: GitLab’s handbook records that its first “black box” health calculation was neither understandable nor actionable for CSMs.^[25]

Illustrative scenario: a B2B subscription business with about 1,200 customers, eight CSMs, a renewals manager and one CS operations lead. Adapt the numbers; keep the structure.

Kept under version control next to the configuration that implements it.

Example status: syntax-checked as YAML, not executed (documentation format, not a product format).

health_score:
  name: account_health_v3
  owner: cs-operations
  purpose: >-
    Rank accounts by risk of churn or contraction at their next renewal,
    so CSMs work the riskiest accounts their capacity allows.
  level: account
  refresh: daily
  snapshot: weekly, kept 3 years (needed for backtests)
  signals:
    - name: licence_utilisation
      definition: active seats in last 28 days / purchased seats
      weight: 0.35
      stale_after_days: 14
    - name: use_case_breadth
      definition: use cases with weekly activity / use cases in success plan
      weight: 0.20
      stale_after_days: 14
    - name: success_plan_progress
      definition: objectives verified or on track / objectives accepted
      weight: 0.15
      stale_after_days: 90
    - name: severe_ticket_load
      definition: P1 or P2 tickets in last 30 days, capped at 5, inverted
      weight: 0.15
      stale_after_days: 30
    - name: csm_sentiment
      definition: red/yellow/green set by the CSM, with a written reason
      weight: 0.15
      stale_after_days: 90
  missing_signal_rule: >-
    Show the score as "incomplete" when a signal with weight >= 0.20 is
    stale; never redistribute its weight silently.
  bands:
    red: "< 50"
    yellow: "50-74"
    green: ">= 75"
  override: csm_sentiment red forces red, with a reason and a review date
  plays:
    red: risk play R1 within 5 working days
    yellow: adoption play A2 at next cadence call
  validation:
    method: backtest on last 4 closed renewal quarters, scored 120 days out
    last_run: 2026-10-01
    results: see validation record VR-2026-Q3
  retire_if: AUC below 0.60 on two consecutive quarterly backtests

It borrows GitLab’s sentiment override and staleness rules^[25] but shows “incomplete” instead of redistributing a missing signal’s weight; the retirement threshold is illustrative.

The “red for 2 weeks” and “14 days inactive” triggers adapt Gainsight’s suggested escalation triggers.^[20] Accounts per CSM come from capacity maths (Cost, capacity and coverage economics).

1. Day −180: renewal record exists (created at signature from billing); CS ops runs the completeness check weekly.
2. Day −150: internal renewal review: success-plan status, health trend, stakeholders, expected commercial changes.
3. Day −120: the CSM asks a soft renewal question and records the answer; GitLab uses the same device three to four months out.^[24]
4. Day −120 to −60: risk found → risk play with owner and due date; escalate to an executive sponsor after 30 days.
5. Day −90: commercial terms sent; renewal call (commit, likely, at risk, lost) enters the forecast of record.
6. Day 0: outcome recorded (renewed, contracted with lost ARR, churned); primary reason coded within five working days.

Contingency: no contract reaches day −90 without an owner; the weekly risk review assigns a deputy.

The taxonomy is useful only if two people would code the same loss the same way.

Labs 2 and 3 generate synthetic data; no customer data is needed or wanted.

• Prerequisites: a description of your current score or a blank sheet; 60 minutes; one CSM and one analyst. No cost or risk.

1. Write the score’s purpose in one sentence: which outcome, how far ahead, for which accounts.
2. List each signal with definition, source, refresh and staleness rule; mark those set by hand.
3. Write what happens at each band: play, owner, deadline. A band without a play is a finding.
4. Choose the backtest cohort (last four quarters’ renewals at a fixed lead time); no history for those dates means starting snapshots first.
5. Set pass criteria in advance, e.g. red-band churn rate at least twice the base rate and a red band the team can work.

• Expected output: a card shaped like Artefact 1 plus a backtest plan.
• Validation: a colleague can say which play applies to any account. Troubleshooting: no agreed purpose means the score is a dashboard; restart at step 1.
• Teardown: none.

• Prerequisites: Python 3.8 or later, no third-party packages; 20 minutes. Synthetic data; no cost or risk.

Example status: executed on 2026-10-23 with Python 3.8.10; the output below is copied from that run.

"""Backtest two health-score designs against renewal outcomes.

Synthetic data only: 1,000 accounts scored 120 days before renewal.
Standard library only (Python 3.8+). Deterministic with the seed below.
"""
import random

random.seed(42)
RED, GREEN = 50, 75  # bands: red < 50, yellow 50-74, green >= 75


def make_accounts(n=1000):
    rows = []
    for i in range(n):
        usage = random.random()                 # share of licences in use
        tickets = random.random()               # normalised ticket load
        sentiment = 0.3 * usage + 0.7 * random.random()  # CSM view, noisy
        risk = 0.03 + 0.35 * (1 - usage) ** 2 + 0.05 * tickets
        churned = random.random() < risk        # outcome at renewal
        score_a = 100 * (0.2 * usage + 0.2 * (1 - tickets) + 0.6 * sentiment)
        score_b = 100 * (0.6 * usage + 0.2 * (1 - tickets) + 0.2 * sentiment)
        rows.append({"id": f"ACC{i:04d}", "a": round(score_a),
                     "b": round(score_b), "churned": churned})
    return rows


def auc(rows, key):
    """P(a churner scores lower than a renewer); ties count one half."""
    churn = [r[key] for r in rows if r["churned"]]
    stay = [r[key] for r in rows if not r["churned"]]
    wins = 0.0
    for c in churn:
        for s in stay:
            wins += 1.0 if c < s else 0.5 if c == s else 0.0
    return wins / (len(churn) * len(stay))


def top_decile_lift(rows, key):
    ranked = sorted(rows, key=lambda r: r[key])          # riskiest first
    top = ranked[: len(rows) // 10]
    base = sum(r["churned"] for r in rows) / len(rows)
    return (sum(r["churned"] for r in top) / len(top)) / base


def band(score):
    return "red" if score < RED else "yellow" if score < GREEN else "green"


def report(rows, key, label):
    churners = sum(r["churned"] for r in rows)
    print(f"--- {label} ---")
    print(f"AUC {auc(rows, key):.3f}   top-decile lift "
          f"{top_decile_lift(rows, key):.2f}")
    for name in ("red", "yellow", "green"):
        group = [r for r in rows if band(r[key]) == name]
        lost = sum(r["churned"] for r in group)
        rate = lost / len(group) if group else 0.0
        print(f"{name:<6} accounts {len(group):>4}  churned {lost:>3}  "
              f"churn rate {rate:6.1%}  share of churners "
              f"{lost / churners:6.1%}")


if __name__ == "__main__":
    data = make_accounts()
    n_churn = sum(r["churned"] for r in data)
    print(f"accounts {len(data)}  churned {n_churn}  "
          f"base rate {n_churn / len(data):.1%}")
    report(data, "a", "Score A (60% CSM sentiment)")
    report(data, "b", "Score B (60% licence usage)")

1. Save as backtest.py and run python3 backtest.py.
2. Compare AUC and top-decile lift, then the band tables. Which score would you keep, and what is wrong with both band designs?

Expected output:

accounts 1000  churned 149  base rate 14.9%
--- Score A (60% CSM sentiment) ---
AUC 0.623   top-decile lift 1.54
red    accounts  476  churned  95  churn rate  20.0%  share of churners  63.8%
yellow accounts  432  churned  48  churn rate  11.1%  share of churners  32.2%
green  accounts   92  churned   6  churn rate   6.5%  share of churners   4.0%
--- Score B (60% licence usage) ---
AUC 0.689   top-decile lift 2.21
red    accounts  477  churned 105  churn rate  22.0%  share of churners  70.5%
yellow accounts  379  churned  34  churn rate   9.0%  share of churners  22.8%
green  accounts  144  churned  10  churn rate   6.9%  share of churners   6.7%

• Validation: Score B ranks better (AUC 0.689 vs 0.623; riskiest tenth churns at 2.21 times the base rate). The script’s AUC matches Fawcett’s definition.^[26]
• Read the result with care: the generator makes churn depend on usage and tickets, and sentiment is mostly noise, so Score B wins by construction. The lab teaches the procedure, not which signal is better; in real data CSM sentiment can carry signal (GitLab lets a red sentiment override its score).^[25]
• The finding that matters: both designs put almost half the book in red, which no team of eight can work. Set the red threshold from capacity (e.g. the riskiest 10–15%) and re-run.
• Troubleshooting: different numbers mean an edited seed or formula; above about 20,000 accounts use a rank-based AUC or sklearn.metrics.roc_auc_score.
• Teardown: delete backtest.py.

• Prerequisites: Python 3.8 or later (built-in sqlite3); 15 minutes. In-memory synthetic data; no cost or risk.

Example status: executed on 2026-10-23 with Python 3.8.10; the output below is copied from that run.

"""Renewal base check and retention drivers in SQLite (synthetic data)."""
import sqlite3

AS_OF = "2026-07-01"
con = sqlite3.connect(":memory:")
con.executescript("""
CREATE TABLE contracts (account TEXT, arr INTEGER, end_date TEXT);
CREATE TABLE renewals  (account TEXT, end_date TEXT, outcome TEXT,
                        renewed_arr INTEGER, reason TEXT);
INSERT INTO contracts VALUES
 ('Acme',   120000, '2026-07-31'), ('Birch',  60000, '2026-08-15'),
 ('Cobalt',  90000, '2026-09-30'), ('Delta',  30000, '2026-10-20'),
 ('Ember',   45000, '2026-10-29'), ('Fjord',  80000, '2027-02-01'),
 ('Garnet',  25000, '2026-06-30'), ('Harbor', 50000, '2026-06-15');
INSERT INTO renewals VALUES
 ('Acme',   '2026-07-31', 'open',     NULL,   NULL),
 ('Birch',  '2026-08-15', 'open',     NULL,   NULL),
 ('Cobalt', '2026-09-30', 'open',     NULL,   NULL),
 ('Garnet', '2026-06-30', 'churned',  0,      'no adoption'),
 ('Harbor', '2026-06-15', 'renewed',  40000,  'seat reduction');
""")

print("Contracts ending in the next 120 days with no renewal record:")
for row in con.execute("""
    SELECT c.account, c.arr, c.end_date
    FROM contracts c
    LEFT JOIN renewals r
      ON r.account = c.account AND r.end_date = c.end_date
    WHERE c.end_date >  :as_of
      AND c.end_date <= date(:as_of, '+120 days')
      AND r.account IS NULL
    ORDER BY c.end_date""", {"as_of": AS_OF}):
    print("  ", row)

print("Closed renewals: ARR at risk, kept, lost, and why")
for row in con.execute("""
    SELECT r.outcome, r.reason, c.arr AS start_arr,
           r.renewed_arr, c.arr - r.renewed_arr AS lost_arr
    FROM renewals r JOIN contracts c
      ON c.account = r.account AND c.end_date = r.end_date
    WHERE r.outcome IN ('renewed', 'churned')"""):
    print("  ", row)

start, kept = con.execute("""
    SELECT SUM(c.arr), SUM(MIN(r.renewed_arr, c.arr))
    FROM renewals r JOIN contracts c
      ON c.account = r.account AND c.end_date = r.end_date
    WHERE r.outcome IN ('renewed', 'churned')""").fetchone()
print(f"Renewal-cohort gross retention: {kept} / {start} = {kept / start:.1%}")

1. Save as renewals.py and run python3 renewals.py.
2. The first list shows contracts that will reach their end date with nobody preparing the renewal.

Expected output:

Contracts ending in the next 120 days with no renewal record:
   ('Delta', 30000, '2026-10-20')
   ('Ember', 45000, '2026-10-29')
Closed renewals: ARR at risk, kept, lost, and why
   ('churned', 'no adoption', 25000, 0, 25000)
   ('renewed', 'seat reduction', 50000, 40000, 10000)
Renewal-cohort gross retention: 40000 / 75000 = 53.3%

• Validation: 75,000 of ARR in two missing records is the week’s most urgent finding. “Renewal-cohort gross retention” (dollars kept from contracts that came due) is not the GRR on the RevOps page, which covers the whole starting base over twelve months; label the two.
• Troubleshooting: an empty first list usually means a date-window error (the window ends 2026-10-29, inclusive). In a real CRM, join on a contract ID, not on name and date.
• Teardown: nothing persists; delete renewals.py.

1. GitLab’s public handbook (sourced). GitLab’s score weights product 50%, risk 25%, outcomes 10%, voice of the customer 5% and engagement 10%, maps 75–100 points to green and 0–49 to red, and lets a red CSM sentiment override the total. It lists “backtested and validated” as a success criterion but publishes no results, so outsiders cannot judge its predictive power.^[25]

2. Retention targeting (sourced research). Eva Ascarza’s 2018 Journal of Marketing Research paper, as summarised by its publisher, the American Marketing Association, used field data from a wireless provider and a membership organisation and found that targeting retention offers by how customers respond reduced churn more than targeting by churn risk; in some cases targeting the customers most likely to leave increased churn.^[29][37] The settings were consumer subscriptions, but the lesson transfers: test plays on a random part of eligible accounts and measure churn against that holdout.

3. Scaling coverage without hiring (illustrative).

4. EU cloud switching (illustrative, regulation sourced). The EU Data Act has applied since 12 September 2025 and removes switching charges, including data egress charges, for data processing services from 12 January 2027.^[38] For providers in scope, leaving becomes cheaper for EU customers, so retention must rest on verified outcomes rather than friction, and the renewal SOP should include the contractual switching process. Success measure: GRR in EU contracts. Scope is a question for counsel, PrivacyOps and ComplianceOps.

GRR and NRR are defined once for the Atlas on the RevOps page: GRR = (start ARR − contraction − churn) ÷ start ARR for the same customers over twelve months; NRR adds expansion. This page adds the drivers CustomerOps can move and the measures that show whether the health score works.

Onboarding speed, plan progress and utilisation lead; retention lags by months. Vanity traps: average health score, number of business reviews, “accounts touched”, and a red band that moves with configuration rather than with customers.

Validate a health score like any prediction; the loop below is this page’s recommended procedure.

%%{init: {"flowchart": {"wrappingWidth": 160, "nodeSpacing": 18, "rankSpacing": 30}}}%%
flowchart TB
  S["Snapshot scores weekly"] --> C["Pick a closed cohort: renewals of the last 4 quarters"]
  C --> L["Take each account's score at a fixed lead time, e.g. 120 days"]
  L --> M["Measure: AUC, top-decile lift, band churn rates, red-band load"]
  M --> G{"Meets the pass criteria set in advance?"}
  G -- "Yes" --> K["Keep; publish the validation record"]
  G -- "No" --> F["Inspect misses: churned greens, renewed reds"]
  F --> R["Reweight, add or drop signals, reset bands"]
  R --> C
  K --> S
  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 S,C,L,M,K core
  class G decision
  class F,R risk

• AUC tests ranking (0.5 is chance). In Fawcett’s words, “the AUC of a classifier is equivalent to the probability that the classifier will rank a randomly chosen positive instance higher than a randomly chosen negative instance.”^[26] It says nothing about whether bands fit your capacity.
• Top-decile lift answers the retention team’s real question (how much worse is the riskiest tenth?); churn studies use it because campaigns target a small fraction of customers.^[39]
• Churn rate per band tells CSMs what red means in practice.
• Brier score applies to probability outputs; scikit-learn’s documentation notes that a lower Brier score does not by itself mean better calibration.^[27]
• Survival curves handle contracts still open (right-censored, in the lifelines documentation’s terms).^[28]

Three traps: leakage (scoring with today’s values; use snapshots), base rates (at 7.5% churn, calling everyone green is 92.5% “accurate”; report lift and recall) and plays that change outcomes (saved red accounts make the score look worse; keep a holdout). Method matters commercially: in a churn-model tournament reported in the Journal of Marketing Research, the authors estimate that the accuracy differences between entries could change a churn campaign’s profitability by hundreds of thousands of dollars (telecom data).^[40]

Not legal advice; it signals when to involve PrivacyOps, counsel and security.

• Personal data inside account scores. B2B scores describe companies, but inputs are often per-user logins, email engagement or meeting attendance. Under the UK GDPR, profiling is automated processing to analyse, evaluate or predict aspects of a person, and stricter rules apply to solely automated decisions with legal or similarly significant effects; the ICO updated this guidance on 31 March 2026 for the Data (Use and Access) Act 2025 (marked draft).^[41] Other jurisdictions have their own rules.
• AI analysis of emails or calls is a new processing purpose: check notices, lawful basis, retention and vendor terms first.
• Renewal and cancellation. For US consumer subscriptions, the Eighth Circuit vacated the FTC’s “Click to Cancel” rule on 8 July 2025 on procedural grounds; ROSCA, the FTC Act and state automatic-renewal laws remain in force;^[42] the FTC issued an advance notice of proposed rulemaking on 11 March 2026;^[43] a search on 2026-10-23 found no proposed rule since (status as of October 2026). B2B contracts follow their own renewal clauses.
• Access and audit. Least privilege in the CS platform (CSMs see their book; exports restricted); a change log for weights, bands and playbooks; retained validation records.

The main cost is people time, so the central calculation is capacity.

Other costs: CS platform licences and administration, data engineering for usage signals, and CSM time lost to reporting. A useful unit measure is cost to serve per retained ARR: with eight CSMs at an illustrative fully loaded 150,000 each and 21.3 m retained, about 5.6 cents per retained dollar. Compute it per segment, where coverage is decided. Environmental sustainability is not material for this function beyond travel for on-site reviews.

• “We bought a CS platform, so we have CustomerOps.” Without segments, plays, data owners and validation it holds a guess.
• Weights from a workshop. A starting hypothesis; publish and backtest them.
• Twenty signals. Start with three to five you trust; add one when a missed-signal review shows a gap.
• Riskiest first, by default. Response to a play can matter more than risk (use case 2); test plays.
• NPS as the health score. Sparse responses from few contacts; one input at most (CXOps owns survey design).

Build a CustomerOps capability (first a named owner, later perhaps a team) when revenue depends on renewals or ongoing usage; individual CSMs can no longer hold the whole picture; churn or contraction is material and poorly understood; or several teams touch the same customer without a shared view.

Do not, or not yet, when:

• You have a handful of large accounts. A renewal calendar and an account lead who knows each customer do the job; a model trained on ten renewals is noise.
• There is no repeatable renewal motion. Start with the renewal SOP and reason codes, not scores.
• The product is transactional. One-off purchases need support and marketing, not success plans.
• The real problem is support capacity. Fund SupportOps first.
• RevOps already runs renewal operations well. Write down who owns the score and the renewal call instead of adding a team.

Hidden responsibilities: platform administration, usage-data engineering, quarterly validation and change management with CSMs.

%%{init: {"flowchart": {"wrappingWidth": 150, "nodeSpacing": 16, "rankSpacing": 30}}}%%
flowchart TB
  Q1{"Revenue depends on renewals or ongoing usage?"} -- "No" --> N1["Do not build it: support and marketing suffice"]
  Q1 -- "Yes" --> Q2{"Every contract has a renewal record and owner?"}
  Q2 -- "No" --> S1["Start: renewal SOP, completeness check, reason codes"]
  Q2 -- "Yes" --> Q3{"More accounts than CSMs can know personally?"}
  Q3 -- "No" --> S2["Keep it light: success plans and a renewal review"]
  Q3 -- "Yes" --> Q4{"At least ~50 closed renewals and usage data?"}
  Q4 -- "No" --> S3["Segment and design coverage; snapshot signals"]
  Q4 -- "Yes" --> S4["Build and backtest a health score; test plays with holdouts"]
  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 Q1,Q2,Q3,Q4 decision
  class S1,S2,S3,S4 core
  class N1 risk

The threshold of about 50 closed renewals is this page’s rule of thumb; with fewer outcomes, one surprise churn moves every measure. For the organisational choice:

This is this Atlas’s proposed model, not an industry standard.

Quick wins: the completeness check, coding last year’s losses, shrinking red to capacity. Dependencies: billing access, a usage feed on account keys, and RevOps agreement on who owns renewal fields in the CRM.

Quick start: see the first 30 days of the roadmap.

Onboarding readiness (per customer)

• Hand-off checklist complete before first customer contact
• First value defined with the customer, with a date
• Success plan accepted by the customer sponsor
• Usage data arriving under the right account key

Renewal preflight (by day −120)

• Success-plan status and verified outcomes reviewed
• At least two active contacts, including a decision-maker
• Soft renewal question asked and recorded

Before changing the health score

• Change and reason written on the card; old and new versions backtested on the same cohort
• Red-band size checked against capacity; CSMs told before go-live

Quarterly governance and audit

• Validation record published; renewal-call accuracy reviewed by caller
• Churn review held with product and support; actions owned
• Per-user signals and AI features reviewed with PrivacyOps; platform roles least-privilege

Example status: plain-text template; not executable.

SUCCESS PLAN - <Customer> - version <n> - <date>
Customer sponsor: <name, role>     Vendor owner: <CSM>
Why they bought (from hand-off): <one sentence>

Objective 1: <business outcome, in the customer's words>
  Baseline: <value, date>   Target: <value>   By: <date>
  Success criteria: <how both sides will verify it>
  Initiatives: <what each side will do>   Owners: <names>
  Status: proposed | accepted | delivered | verified by customer

Risks and dependencies: <customer-side blockers, product gaps>
Next review: <date>          Renewal date: <date>

Example status: plain-text template (this Atlas’s proposal); not executable.

ONBOARDING PLAYBOOK - segment <name> - version <n> - owner <CS ops>
First value (customer's words): <outcome>  Evidence: <source>  Confirmed by: <role>
Stage           Due (from start)  Owner           Done when
1 Hand-off      before kickoff    <seller + CSM>  hand-off checklist complete
2 Kickoff       day <14>          <CSM>           goals, contacts, value date agreed
3 Success plan  day <30>          <CSM>           sponsor accepts objective 1
4 First value   day <n>           <CSM>           customer confirms the outcome
5 To adoption   after stage 4     <CS ops>        TTFV recorded; cadence set
Late-value trigger: stage 4 not done by day <n> -> risk play <id>, owner, due date
Customer-caused delay (no reply, no usage): flag risk, record reason, review escalation
Digital segment: same stages, automated steps, human trigger at <condition>

RISK <id> - <Account> - opened <date> by <name>
Signal: <what was observed, with source and date>
Cause (hypothesis): <champion left | no adoption | budget | ...>
ARR at risk: <amount>     Renewal date: <date>
Play: <play id>   Owner: <name>   Due: <date>
Escalation: <sponsor or team, if unresolved by date>
Outcome: <resolved | accepted loss | churned>, closed <date>

VALIDATION RECORD VR-<yyyy>-Q<n> - score <name> version <v>
Cohort: renewals closed <from> to <to>; n = <accounts>, churned = <k>
Lead time: score as of <days> before each renewal (snapshots)
Results: AUC <x>; top-decile lift <x>; red precision <x>; red recall <x>
Band churn rates: red <x>%, yellow <x>%, green <x>%
Red-band size vs capacity: <accounts> vs <accounts>
Pass criteria (set on <date>): <criteria>   Result: pass | fail
Misses reviewed: <n> churned greens, <n> renewed reds; findings: <...>
Decision: keep | reweight | retire   Approved by: <CS leader>

DECISION <id> - <date> - Coverage change for segment <name>
Context: <why now: capacity, retention trend, cost to serve>
Options considered: <A, B, C with trade-offs>
Decision: <what changes, for how many accounts, from when>
Expected effect: <metric, size, by when>; how measured: <holdout?>
Customer communication: <what customers are told, by whom>
Review date: <date>; reversal trigger: <condition>

The definition card in Artefact 1, the renewal SOP in Artefact 3 and the reason taxonomy in Artefact 4 complete the set.

Neighbouring pages are compared in the neighbour table and coverage models in Artefact 2.

Weighted rules or a statistical model? Rules are explainable but carry opinion-based weights; models may rank better but need more closed renewals and maintenance. Both need the same backtest.

Is CustomerOps the same as customer success? No. Customer success is the customer-facing function; CustomerOps here is the operations layer behind it. In small teams one person does both.

Is “customer operations” just support operations? For some speakers it is centred on support: Kaizo defines it as the machinery behind customer support and treats support operations as its core slice.^[3] This Atlas covers that work on SupportOps.

How many CSMs do we need? No standard ratio exists. Derive it from each segment’s service model and the CSM time left after onboarding and renewals; vendor ratios are starting points.^[20]

Our health score has never been tested. Where do we start? Snapshot it this week, write its card, then backtest on the last four quarters if history can be reconstructed without leakage; otherwise wait one or two quarters of snapshots.

Should NPS be part of the health score? As one small input at most; responses are sparse. Survey design is taught on CXOps.

Can AI replace CSMs for small accounts? Automation can run standard journeys and draft outreach;^[36] measure it against a holdout and keep humans for complex risk and commercial decisions.

• Uplift modelling and experiments (established in research, rare in CS practice): estimate how much a play changes an account’s outcome, not its risk.^[29] Needs randomised plays and volume.
• Consumption pricing (practice still settling): renewal becomes continuous; see the usage-inclusive retention discussion on RevOps.
• AI agents in CS platforms (vendor and analyst direction, little public evidence): Forrester’s Q4 2025 platform evaluation names value, cross-team collaboration and AI as its themes;^[44] treat autonomous-retention claims as unproven until you have holdout results.

After this page you should be able to explain the three meanings of “customer operations” and the Atlas’s split; design a coverage model with triggers; write and evaluate a health score with a point-in-time backtest; operate a renewal process with completeness checks and coded losses; and decide whether a company needs CustomerOps now.

1. A colleague says “our CustomerOps team is drowning in tickets”. Which meaning are they using, and which page covers it?

2. A score has an AUC of 0.85 on last year’s renewals. What two questions do you ask before trusting it?

3. Your red band holds 45% of accounts. What do you change first?

4. A usage feed fails and the platform redistributes its weight. Why is that dangerous?

5. NRR is 115% but logo churn among small customers doubled. Is CustomerOps succeeding?

6. A company has 12 enterprise customers and one CSM. Should it hire an analyst to build a health score?

“CustomerOps” is a word in search of a definition; the work behind this page’s meaning is concrete: customers who bought need to reach the outcome they paid for, and a company that sells subscriptions needs to know, months ahead, which ones will not. The work is unglamorous: every contract with a renewal record, every customer with a first-value date, every loss with a reason. The health score is a prediction, and it can be tested. Build the records first, test the score second, test the plays third, and buy the platform when it serves that order.

Every source below was opened on 2026-10-23; dates are the source’s own. Claim-level support, caveats and the list of sources that could not be fetched are in the Atlas evidence ledger (research/customerops-ledger.md).

Further reading

• GitLab’s public Customer Health Assessment and Management page for red/yellow/green guidance and a “will churn” procedure (checked 2026-10-23).

Changelog

• 2026-10-23 — r0: first draft by the managing author (research, outline, ledger, draft, diagrams, labs executed); not yet independently reviewed.
• 2026-10-23 — r1: fixes from the independent fact check (reviews/customerops-r1.md): meaning 2 re-sourced, vendor naming, FTC status, Lab 2 caveat, judgement-call power, glossary, business reviews; repeated tables cut.
• 2026-10-23, post-score polish (reviews/customerops-polish.md): CustomerThink attribution; GitLab onboarding targets and playbook template; two capacity repeats cut; Figure 3 in two rows.