--- title: "CustomerOps" slug: customerops category: business term_status: ambiguous evidence_status: partially_verified summary: "CustomerOps is an unstandardised label. This page uses it for customer success operations: the data, processes and systems that help existing customers reach value, so renewals and expansion become predictable and churn is seen early." audience: [Beginners, Customer success operations practitioners, Customer success and account management leaders, Analysts building health scores, RevOps and support partners] last_verified: 2026-10-23 key_takeaways: - "\"Customer operations\" has at least three competing meanings (everything behind customer-facing teams, the operations behind customer support, customer success operations); this page takes the third and labels that choice an editorial distinction." - "The job is post-sale value realisation run as a system: segmentation and coverage, onboarding to first value, success plans, health scoring, renewal and expansion processes, and the customer data behind them." - "A health score is a prediction and must be tested like one: score a past cohort before its renewals, then check ranking (AUC, top-decile lift), band churn rates and how much of the red band the team can actually work." - "Targeting the riskiest accounts is not the same as targeting the accounts an intervention will save; research on retention targeting found the difference can matter, so test plays with holdouts." - "Retention formulas (GRR, NRR) are defined once on the RevOps page; CustomerOps owns the drivers behind them: renewal-base completeness, risk calls, onboarding speed and adoption." - "Do not build a separate CustomerOps team before there is a repeatable renewal motion and enough accounts to learn from; one owner with a spreadsheet and a backtest beats a platform nobody trusts." related: [supportops, cxops, revops, salesops, analyticsops, knowledgeops, marketingops, bizops] --- ## What CustomerOps is ### In 30 seconds **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](#the-naming-problem-three-meanings-of-one-label)). 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. ### At a glance | Item | Summary | |---|---| | Goal | Customers reach value; renewals and expansion are forecastable; churn is seen early | | Users | CSMs, renewal and account managers, CS leaders, CS operations analysts | | In scope | Onboarding, segmentation and coverage, success plans, health scores, churn analytics, renewals and expansion, customer data | | Out of scope | Tickets and SLAs ([SupportOps](../supportops/)), survey design ([CXOps](../cxops/)), metric definitions ([RevOps](../revops/)) | | Prerequisites | Recurring or contracted revenue, a CRM with accounts and contracts, some usage signal | | Outputs | Coverage model, onboarding playbook, success plans, validated health score, renewal calendar, reason taxonomy | | Term status | **Ambiguous.** "Customer success operations" is an established role; "CustomerOps" is not a standard term | ### The naming problem: three meanings of one label 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.[^front] 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.[^workato] 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.[^kaizo] 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.[^customerthink] 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,[^fr-2019] and a 2023 role profile of the CS operations manager as the partner of the CS leader who implements processes at scale.[^fr-role] One US patent even uses "CustomerOps" as a software platform name.[^patent] No standards body defines the term. ::: decision Editorial distinction used across the Atlas This page takes meaning 3, because it has a recognisable role, analyst research and its own tool category. [SupportOps](../supportops/) covers reactive service (tickets, queues, SLAs) and [CXOps](../cxops/) covers measurement and governance of the experience across the journey. This split is an **editorial distinction** of the Atlas, not an industry standard; in a small company one person may do all three. ::: ### What CustomerOps is not - **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.[^fr-tower] - **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).[^fr-cscx] - **Not a health score.** A score is one artefact; a configured platform without plays and validation is a dashboard. ### The problem it solves 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](#metrics-and-kpis)), not in activity counts. ## Where CustomerOps comes from and where it sits ### Origins and evolution 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).[^murphy] - **Lifecycle models** gave the work a shape: TSIA's LAER model (Land, Adopt, Expand, Renew).[^tsia-laer] - **Operations roles followed**, visible in Forrester's 2019 report and 2023 role profile.[^fr-2019][^fr-role] - **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,[^gs-mq] and the market consolidated: Totango and Catalyst closed a merger in early 2024,[^cxdive] and as of October 2026 Totango's site reads "Totango is now Odie".[^totango] ### Glossary, core concepts and mental model | Term | Meaning on this page | Example | |---|---|---| | CSM | Customer success manager: owns adoption and outcomes for a book of accounts | 25 named accounts | | Coverage model | Which segments get a named CSM, a pooled team or automated ("tech-touch") programmes | Named CSM for complex, high-value accounts | | Time to first value (TTFV) | Days from contract start to the first customer-confirmed outcome | First production pipeline on day 21 | | Success plan | Objectives with success criteria, owners and dates, shared with the customer | "Release weekly instead of monthly by Q2" | | Health score | Rule or model that summarises signals into a band meant to predict renewal risk | 0–100; red, yellow, green | | ARR | Annual recurring revenue: the yearly value of active subscriptions | 24.0 m across 1,200 customers | | GRR / NRR | Gross and net revenue retention, defined on the [RevOps](../revops/#metrics-and-kpis) page | GRR 89%, NRR 104% | | Backtest | Scoring a past cohort as of a past date and comparing with what happened | Scores 120 days before each 2025 renewal | | Lift | How much more often an event occurs in a targeted group than overall | Riskiest tenth churns at 2.2 times the base rate | | AUC | Probability that a churner scores worse than a renewer; 0.5 is chance ([details](#validating-the-health-score)) | 0.69 | | Precision / recall | Share of red accounts that churned / share of churners that were red | 32% / 50% | | Right-censoring | An outcome not yet observed, e.g. a contract still open | Renewal due next year | **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. ### How CustomerOps relates to other Ops ::: figure Where CustomerOps sits among the customer-facing Ops pages ```mermaid %%{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 ``` Text equivalent: SalesOps hands won customers to CustomerOps. RevOps supplies the GRR and NRR formulas and the renewal base and receives the renewal call. SupportOps sends ticket signals; KnowledgeOps supplies self-service content (dotted). CustomerOps exchanges churn reasons and survey signals with CXOps and sends model requests to AnalyticsOps. Green: CustomerOps. Grey: neighbours. ::: | Neighbour | What CustomerOps owns | What the neighbour owns | |---|---|---| | [RevOps](../revops/) | Health score model, renewal process and call, coverage model | Metric formulas, the hand-off checklist as a stage gate, forecast governance, stack decision rights | | [SupportOps](../supportops/) | Ticket load as a health signal; account-level escalation plays | Queues, routing, SLAs, workforce management | | [CXOps](../cxops/) | Survey results as one input; coded churn reasons | NPS/CSAT/CES design, journey-wide governance | | [SalesOps](../salesops/) | Expansion signals; the success side of renewals | Territories, quotas, new-business pipeline | | [AnalyticsOps](../analyticsops/) | The question and decision a model serves | Metric layer, model engineering standards | ## Principles and operating model ### A proposed charter and principles 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. ### Roles, ownership and RACI 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. | Decision or task | CS ops | CS leader | CSM | Renewal/AM | RevOps | |---|---|---|---|---|---| | Segmentation and coverage model | R | A | C | C | C | | Onboarding playbook | R | A | C | I | I | | Success plan per account | C | I | A, R | C | I | | Health score model and validation | A, R | C | C | C | C | | Risk call on an account | I | I | A, R | C | I | | Commercial renewal | C | I | C | A, R | C | | Renewal call in the forecast | C | A | R | R | C | | Churn reason coding and review | R | A | R | R | C | The health-score row follows the boundary recorded on the [RevOps](../revops/) page. Who is accountable for the commercial renewal varies by company; what matters is exactly one accountable role per contract. ### The post-sale lifecycle ::: figure The post-sale lifecycle and what CustomerOps runs at each stage ```mermaid %%{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 ``` Text equivalent: After the sales hand-off, onboarding sets a kickoff, success plan and first-value date. Late first value triggers a risk play that loops back to onboarding; otherwise the customer adopts. Adoption feeds expansion signals and renewal preparation. A renewal returns to adoption; a loss triggers a coded loss review. Amber: decisions. Red: risk and loss paths. ::: The stages follow TSIA's Land–Adopt–Expand–Renew model,[^tsia-laer] 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;[^tsia-frost] the post shows no data, so test it in your own backtest. ### Operating model and governance | Cadence | Input | Decision | Owner | |---|---|---|---| | Weekly risk review | New red accounts, overdue onboardings, renewals inside 120 days without a call | Who acts, which play, by when | CS leader with CSMs | | Monthly renewal review | Renewal base for two quarters with risk calls | Renewal call per contract | Renewal owner, CS, RevOps | | Monthly play review | Play outcomes, against holdouts where available | Keep, change or stop plays | CS ops | | Quarterly health review | Backtest on the last closed cohort | Keep, reweight or retire signals | CS ops with analyst | | Quarterly churn review | Coded losses, cohorts | Fix requests to product, support, pricing | CS leader with product | Escalations run CSM → CS leader → executive sponsor; support escalations use the [SupportOps](../supportops/) process. ## Architecture and workflow ### Reference architecture: the customer data and action loop For a business function, the architecture is about where each fact lives and how it reaches the person who must act. ::: figure Reference architecture: from source systems to plays and back to validation ```mermaid %%{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 ``` Text equivalent: Billing, CRM, product usage and helpdesk data load into a warehouse with joined history and snapshots. It feeds the health model, then the CS platform, which triggers plays by CSMs or automation. Outcomes return to the warehouse, and a dotted quarterly backtest tests the model against them. Green: core. Grey: sources. Amber: actions and outcomes. ::: | Component | Typical owner | Failure to watch | |---|---|---| | Billing (contract dates, ARR) | Finance | Renewal dates retyped by hand into the CRM | | CRM (accounts, owners, renewal records) | RevOps decides, sales ops administers | Duplicates; merges that orphan CS data | | Product usage | Product or data engineering | Telemetry changes that silently zero a signal | | Warehouse | Data team or AnalyticsOps | No point-in-time snapshots, so backtests leak the future | | Health model and CS platform | CS ops | Untested weights; undocumented configuration | **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.[^gl-gainsight] ### End-to-end workflow: from signed contract to renewal call ::: figure End-to-end workflow with the happy path and the risk path ```mermaid %%{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 ``` Text equivalent: A signed contract creates a renewal record; kickoff, success plan and monitoring follow. A trigger starts a play; unresolved risk is escalated. At 120 days before the end date every account enters a renewal review and risk call. The outcome, with a coded reason, feeds the backtest and churn review. Amber: decisions. Red: the risk path. ::: 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.[^gl-renewals] Choose a lead time longer than your slowest mitigation. Exception paths to design in advance: a contract with no renewal record ([Lab 3](#lab-3-renewal-base-completeness-and-loss-reasons-in-sql)), a usage feed that stops ([worked runbook](#worked-runbook-the-health-score-that-went-quiet)), a non-renewal announced before any signal fired (missed-signal review), and an account merged or split mid-term. ## Practices, frameworks and tools ### Core practices and playbooks | Practice | Trigger | Owner | Output | Verification | |---|---|---|---|---| | Segmentation and coverage | Quarterly; account events | CS ops | Segment per account | Retention and cost to serve by segment | | Onboarding to first value | Signature or earlier | CSM; digital for small accounts | Kickoff, success plan, first-value date | TTFV; on-time rate | | Success planning | Kickoff; business reviews | CSM with customer | Objectives with criteria and dates | Customer-confirmed outcomes | | Health monitoring | Continuous | CS ops builds; CSM acts | Bands, alerts, risk register | Quarterly backtest | | Renewal management | Lead time before end date | Renewal owner | Renewal call and outcome | Completeness; call accuracy | | Loss review | Every loss | CSM; CS ops aggregates | Coded reason | Repeat-reason trend | **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.[^fr-sorted] They distinguish *scaled* customer success (human and digital, one-to-many) from *digital-led* (mainly automated, built on self-sufficiency).[^fr-scaled] Gainsight publishes starting heuristics, four tiers from high-touch to tech-touch with suggested ARR bands and CSM-to-account ratios;[^gs-techtouch] 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.[^gl-onboarding] See the [playbook template](#template-onboarding-playbook). The hand-off checklist itself is a [RevOps](../revops/) stage gate; Forrester's analysts recommend it hold what only sellers know.[^fr-handoff] **Success planning.** GitLab tracks "verifiable outcomes" from proposed to accepted, delivered and verified, the last meaning the customer has confirmed completion.[^gl-plans] 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.[^gl-csm] 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.[^gl-health] **Loss review.** Code one *primary* reason from a short list, agreed by CSM and renewal owner within a week ([Artefact 4](#artefact-4-churn-and-contraction-reason-taxonomy)). ### Methods, standards and frameworks No standard or regulation defines customer success operations. These optional frameworks each serve one job: | Framework or method | Use it for | Limits | |---|---|---| | LAER lifecycle (TSIA)[^tsia-laer] | Shared stage vocabulary | Describes stages, not measures | | Desired Outcome (Murphy)[^murphy] | Defining value in success plans | Needs measurable criteria | | Scaled vs digital-led CS (Forrester)[^fr-scaled] | Designing coverage tiers | Opinion, no thresholds | | ROC/AUC, lift, Brier score[^fawcett][^sk-brier] | Testing ranking and calibration | Needs point-in-time data | | Survival analysis[^lifelines] | Time to churn with open contracts | Harder to explain | | Holdout tests of plays[^ama-2019] | Knowing whether a play works | Needs volume and patience | ### Tooling landscape Categories first; product names are examples verified on 2026-10-23, not recommendations. | Category | Job | Examples | Watch-outs | |---|---|---|---| | CRM | Accounts, owners, renewal records | Salesforce (GitLab syncs its CS platform with it),[^gl-gainsight] HubSpot[^hs-health] | CS fields nobody owns | | CS platform | Scores, playbooks, success plans | Gainsight,[^gs-home] Totango and Catalyst (company now named Odie),[^totango] ChurnZero,[^churnzero] Planhat (now billed as a CRM),[^planhat] HubSpot's customer success workspace[^hs-health] | Black-box scores; admin load; playbook lock-in | | Product analytics | Usage per account | Telemetry or an analytics tool | Event renames breaking signals | | Warehouse and BI | History, snapshots, validation | Any warehouse | Models nobody maintains | | Helpdesk, surveys | Ticket and survey signals | Owned by [SupportOps](../supportops/) and [CXOps](../cxops/) | Counting tickets without severity | **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.[^gs-overview][^gs-weights] 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).[^hs-health] 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.[^gl-health] ### Automation and AI 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.[^fr-agentic] 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](#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.[^gl-health] ## CustomerOps in practice ### Reference implementation: operating artefacts **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. #### Artefact 1: health score definition card 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)._ ```yaml 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[^gl-health] but shows "incomplete" instead of redistributing a missing signal's weight; the retirement threshold is illustrative. #### Artefact 2: coverage model | Segment (illustrative) | Entry rule | Service model | Human triggers | |---|---|---|---| | Strategic | Top ARR, or multi-product with complex deployment | Named CSM, quarterly reviews, executive sponsor | Any red; renewal inside 180 days | | Growth | Mid ARR, adopting, expansion potential | Named CSM, half-yearly review | Red for 2 weeks; objective overdue | | Scale | Lower ARR, standard deployment, past onboarding | Pooled team, one-to-many programmes | Red for 2 weeks; 14 days inactive | | Digital | Smallest, self-serve product | Automated journeys, community, help centre | Expansion signal; severe tickets | The "red for 2 weeks" and "14 days inactive" triggers adapt Gainsight's suggested escalation triggers.[^gs-techtouch] Accounts per CSM come from capacity maths ([Cost, capacity and coverage economics](#cost-capacity-and-coverage-economics)). #### Artefact 3: renewal SOP (one page) 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.[^gl-csm] 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. #### Artefact 4: churn and contraction reason taxonomy | Code | Primary reason | Usual fix owner | |---|---|---| | L1 | Never adopted | CustomerOps (onboarding) | | L2 | Champion or sponsor left | CSM (multi-threading) | | L3 | Budget cut or business change | None or commercial | | L4 | Product gap (specific, documented) | Product | | L5 | Service failure | Support, engineering | | L6 | Moved to competitor | Product, pricing | | L7 | Price or packaging | Pricing | | L8 | Company closed or acquired | None | The taxonomy is useful only if two people would code the same loss the same way. ### Hands-on labs Labs 2 and 3 generate synthetic data; no customer data is needed or wanted. #### Lab 1: write a health-score definition card and a backtest plan - **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. #### Lab 2: backtest two health-score designs in Python - **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._ ```python """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: ```text 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.[^fawcett] - **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).[^gl-health] - **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`. #### Lab 3: renewal-base completeness and loss reasons in SQL - **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._ ```python """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: ```text 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](../revops/#metrics-and-kpis) 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`. ### Use cases and scenarios **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.[^gl-health] **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.[^ama-2019][^ama-2023] 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).** ::: example Eight CSMs and 1,200 accounts Each CSM carries 150 accounts and only the largest get regular contact. CS ops re-segments on complexity and adoption stage as well as ARR, moves 880 stable, simple accounts to automated journeys with a pooled triage rota and human triggers (red for two weeks, 14 days inactive, severe tickets), and leaves about 40 accounts per named CSM. Trade-off: digital accounts lose a named contact. Success: GRR in the digital segment holds while named segments improve, and cost to serve per retained ARR falls. Pitfall: moving accounts before the content and triggers exist. ::: **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.[^dataact] 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](../privacyops/) and [ComplianceOps](../complianceops/). ## Measure, govern, pay ### Metrics and KPIs GRR and NRR are defined once for the Atlas on the [RevOps](../revops/#metrics-and-kpis) 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. | KPI | Definition / formula | Pitfall | Cadence | |---|---|---|---| | Logo churn rate | Customers lost ÷ customers at start | Hides size differences | Quarterly | | Lost ARR by reason | Churn + contraction ARR by primary reason code | "Other" swallows the signal | Quarterly | | Time to first value | Days to the first customer-confirmed objective; median and 80th percentile | Using product activation instead | Monthly | | Renewal-call accuracy | Share of contracts per call category whose outcome matched; by caller | Scoring only the total | Quarterly | | Score ranking (AUC) | P(churned account scored lower than renewed one), at a fixed lead time | Leakage from today's data | Quarterly | | Red-band precision, recall | Churned among red ÷ red; red among churned ÷ churned | A huge red band "catches" everything | Quarterly | | Red-band load | Red accounts ÷ accounts the team can work | Alerts nobody can work | Monthly | | Play effect | Churn rate treated − churn rate in a random holdout | No randomisation | Per play | 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. #### A worked calculation ::: example Fiscal year to 2026-09-30, 1,200 customers (illustrative numbers) **Retention.** Start ARR 24.0 m; churn 1.8 m (90 customers), contraction 0.9 m, expansion 3.0 m. GRR = (24.0 − 0.9 − 1.8) ÷ 24.0 = **88.75%**. NRR = (24.0 + 3.0 − 0.9 − 1.8) ÷ 24.0 = **101.25%**. Logo churn = 90 ÷ 1,200 = **7.5%**. **Drivers.** Of 2.7 m lost, 1.1 m is coded "never adopted" (40.7%), 0.6 m "champion left" (22.2%), 0.5 m "budget cut" (18.5%): onboarding is the largest lever CustomerOps controls. **Score check.** Snapshots 120 days before each renewal put 140 customers in red; 45 of the 90 churners had been red. Recall = 45 ÷ 90 = **50%**; precision = 45 ÷ 140 = **32.1%**, about **4.3 times** the 7.5% base rate. The green band held 700 customers, 12 of whom churned (**1.7%**). Useful, but half the churners were never red: review those 45. **Renewal calls.** Of 220 contracts called "commit", 214 renewed in full (**97.3%**); of 50 called "at risk", 28 churned or contracted (**56%**). ::: #### Validating the health score Validate a health score like any prediction; the loop below is this page's recommended procedure. ::: figure Health-score validation loop ```mermaid %%{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 ``` Text equivalent: Weekly snapshots let a closed cohort be scored at a fixed lead time and measured on AUC, lift, band churn rates and red-band load. If the pre-set criteria are met, the score is kept and the record published; otherwise misses are inspected, signals and bands revised, and the backtest repeated. Amber: decision. Red: repair path. ::: - **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."[^fawcett] 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.[^lessmann] - **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.[^sk-brier] - **Survival curves** handle contracts still open (right-censored, in the lifelines documentation's terms).[^lifelines] 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).[^gupta-2006] ### Quality, privacy and compliance Not legal advice; it signals when to involve [PrivacyOps](../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).[^ico] 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;[^gtlaw] the FTC issued an advance notice of proposed rulemaking on 11 March 2026;[^ftc-anprm] 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. ### Cost, capacity and coverage economics The main cost is people time, so the central calculation is capacity. ::: example Capacity check for the red band (illustrative) Eight CSMs can each give about 40 hours a quarter to risk plays: 320 hours. A play takes about six hours per account, so capacity is about 320 ÷ 6 ≈ **53 red accounts a quarter**. The score flags 140. Redefine red (for example the riskiest 50 by expected lost ARR), lighten the play, or add capacity. Showing 140 red accounts to a team that can work 53 teaches CSMs to ignore red. ::: 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. ### Assurance of the operating model | Check | Frequency | Red flag | |---|---|---| | Renewal-base completeness | Weekly | Any contract inside 90 days without a record | | Score validation record | Quarterly | Validation overdue; bands changed without a record | | Signal freshness | Daily | A source stale beyond its rule | | Play log | Monthly | Red accounts with no play opened | | Missed-signal reviews | Per loss | Unreviewed surprise churn | | Configuration change log | Per change | Untracked edits in the CS platform | ## When things go wrong ### Common failures and troubleshooting | Symptom | Likely cause | Diagnosis | Remediation and prevention | |---|---|---|---| | A green account does not renew | Missing signal (sponsor change, budget) or stale data | Snapshot history and timeline 180 days back | Add the signal or play; missed-signal review for every loss | | Scores jump overnight | Telemetry change, account merge, plan rename | Signal distributions before and after | Freeze alerts, fix, backfill; freshness monitors | | CSMs ignore the score | Unexplainable, no plays, red too common | Interviews; play log | Publish the card; attach plays; shrink red | | Renewal forecast missed | Late or optimistic calls; missing contracts | Call accuracy by caller | Fixed SOP dates; completeness check | | Churn reasons all "other" | Taxonomy too long or one-sided coding | Two people re-code 20 losses | Shorter list; joint coding | ### Worked runbook: the health score that went quiet ::: example Illustrative incident, health score v3 **Trigger.** Monday's risk review shows 31 red accounts instead of the usual 120 to 150. **1. Contain (day 0).** CS ops tells CSMs to use last week's list, pauses automated play R1 so about a hundred accounts do not silently lose outreach, and marks the score "incomplete". **2. Diagnose (day 0–1).** Compare signal distributions with the last snapshot: `use_case_breadth` has been null for 60% of accounts since Thursday, when a product release renamed two usage events. An admin had also set that signal's weight to 0 "to avoid red scores", so the other weights were renormalised and many accounts drifted to yellow or green. **3. Fix (day 1–3).** The data team maps the renamed events and backfills; CS ops reverts the unrecorded weight change and re-runs the score for the affected days. **4. Verify (day 3).** Red returns to 138; 20 hand-checked accounts match; no stale sources. R1 resumes with accounts that should have turned red since Thursday. **5. Learn (within two weeks).** Blameless review. Actions: event renames announced before release; the "incomplete" rule enforced; weight changes need a change record; an alert when the red count moves more than 30% in a week. ::: ### Anti-patterns and myths - **"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](#use-cases-and-scenarios)); test plays. - **NPS as the health score.** Sparse responses from few contacts; one input at most ([CXOps](../cxops/) owns survey design). ## Deciding and adopting ### When to use and when not to use **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](../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. ### Decision framework ::: figure Decision tree: what CustomerOps capability to build next ```mermaid %%{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 ``` Text equivalent: No renewal or usage revenue: do not build CustomerOps. No renewal records and owners: start with the SOP, completeness check and reason codes. CSMs still know every account: keep it light. Fewer than about 50 closed renewals or no usage data: segment and snapshot. Otherwise build and backtest a score and test plays with holdouts. Amber: questions. Green: next steps. Red: do not build. ::: 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: | Option | Fits when | Main risk | |---|---|---| | CS leader, part-time | Few CSMs, one product | Ops loses to escalations | | CS ops role inside CS | Tooling and reporting fill a role | Isolated from RevOps | | CS ops inside RevOps | Strong RevOps, one revenue leader | CS work deprioritised | | Shared centre plus ops per function | Several go-to-market teams | Coordination overhead | ### Maturity model This is **this Atlas's proposed model**, not an industry standard. | Level | Observable behaviour | Exit criterion | |---|---|---| | 1. Reactive | Renewals handled when the invoice is due; churn learned from finance | Renewal record for every contract ending in 180 days | | 2. Recorded | Renewal calendar, coded losses, success plans for top accounts | Segments with defined service models | | 3. Managed | Coverage model; first-value dates; score with a published card | First backtest meets pre-set criteria | | 4. Validated | Quarterly backtests; band churn rates known; renewal calls scored | Plays tested against holdouts | | 5. Experimental | Plays and coverage chosen on measured effect | Keep running the loop | ### Adoption roadmap: 30/60/90 days | Window | Actions | Milestone | |---|---|---| | Days 1–30 | Inventory contracts; completeness check; agree reason codes and code last year's losses; write the score's card (Lab 1) | No contract inside 90 days without a record | | Days 31–60 | Define segments, service models and first value per product; start weekly snapshots; start the weekly risk review | Segment on every account; TTFV baseline | | Days 61–90 | First backtest (Lab 2); size bands to capacity; attach plays; first churn review with product | Published validation record; a play per band | 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. ## Toolkit ### Checklists **Quick start:** see the first 30 days of the [roadmap](#adoption-roadmap-306090-days). **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 ### Templates #### Template: success plan (one page) _Example status: plain-text template; not executable._ ```text SUCCESS PLAN - - version - Customer sponsor: Vendor owner: Why they bought (from hand-off): Objective 1: Baseline: Target: By: Success criteria: Initiatives: Owners: Status: proposed | accepted | delivered | verified by customer Risks and dependencies: Next review: Renewal date: ``` #### Template: onboarding playbook _Example status: plain-text template (this Atlas's proposal); not executable._ ```text ONBOARDING PLAYBOOK - segment - version - owner First value (customer's words): Evidence: Confirmed by: Stage Due (from start) Owner Done when 1 Hand-off before kickoff hand-off checklist complete 2 Kickoff day <14> goals, contacts, value date agreed 3 Success plan day <30> sponsor accepts objective 1 4 First value day customer confirms the outcome 5 To adoption after stage 4 TTFV recorded; cadence set Late-value trigger: stage 4 not done by day -> risk play , 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 ``` #### Template: risk register entry ```text RISK - - opened by Signal: Cause (hypothesis): ARR at risk: Renewal date: Play: Owner: Due: Escalation: Outcome: , closed ``` #### Template: health-score validation record ```text VALIDATION RECORD VR--Q - score version Cohort: renewals closed to ; n = , churned = Lead time: score as of before each renewal (snapshots) Results: AUC ; top-decile lift ; red precision ; red recall Band churn rates: red %, yellow %, green % Red-band size vs capacity: vs Pass criteria (set on ): Result: pass | fail Misses reviewed: churned greens, renewed reds; findings: <...> Decision: keep | reweight | retire Approved by: ``` #### Template: coverage change decision record ```text DECISION - - Coverage change for segment Context: Options considered: Decision: Expected effect: ; how measured: Customer communication: Review date: ; reversal trigger: ``` The definition card in [Artefact 1](#artefact-1-health-score-definition-card), the renewal SOP in [Artefact 3](#artefact-3-renewal-sop-one-page) and the reason taxonomy in [Artefact 4](#artefact-4-churn-and-contraction-reason-taxonomy) complete the set. ### Deep comparisons Neighbouring pages are compared in [the neighbour table](#how-customerops-relates-to-other-ops) and coverage models in [Artefact 2](#artefact-2-coverage-model). **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. ### FAQ **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.[^kaizo] This Atlas covers that work on [SupportOps](../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.[^gs-techtouch] **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](../cxops/). **Can AI replace CSMs for small accounts?** Automation can run standard journeys and draft outreach;[^fr-agentic] measure it against a holdout and keep humans for complex risk and commercial decisions. ## Going further ### Advanced topics and emerging direction - **Uplift modelling and experiments** (established in research, rare in CS practice): estimate how much a play changes an account's outcome, not its risk.[^ama-2019] Needs randomised plays and volume. - **Consumption pricing** (practice still settling): renewal becomes continuous; see the usage-inclusive retention discussion on [RevOps](../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;[^fr-wave] treat autonomous-retention claims as unproven until you have holdout results. ### Learning path | Stage | Activities | |---|---| | Prerequisites | ARR, GRR, NRR on the [RevOps](../revops/) page | | 1-day primer | This page's first three parts; Lab 1 on your own score | | 1-week practice | Labs 2 and 3; a backtest on your own snapshots | | 30 days | The 30-day roadmap; one renewal review and one churn review | | Specialisation | Survival analysis and experiment design, or coverage design and CS leadership | | Portfolio | A published validation record; a segmentation redesign with before/after cost to serve | ## Wrap-up ### Executive recap and cheat sheet | Area | Remember | |---|---| | Name | Ambiguous; here it means customer success operations (editorial distinction) | | Purpose | Customers reach value; renewals and expansion are predictable; risk is seen early | | Artefacts | Coverage model, onboarding playbook, success plans, score card and validation record, renewal SOP, reason codes | | Metrics | GRR and NRR (from RevOps); TTFV; renewal-base completeness; call accuracy; AUC, lift, band churn rates | | Watch-outs | Untested scores, red bands beyond capacity, silent weight redistribution, leakage, targeting by risk alone | | Next actions | Completeness check; code losses; snapshot the score; backtest; size red to capacity | ### A judgement call: work the reddest accounts, or test first? ::: decision The dilemma **Situation (illustrative).** The validated score flags 140 red accounts; the team can run the risk play on about 50 this quarter. The CS leader wants the 50 reddest. The CS ops lead wants 50 drawn at random from the 140, compared afterwards with the other 90. **Assumptions.** The play costs about six CSM hours per account; these renewals fall in the next two quarters; the play's effect has never been measured. **Option A, the reddest 50,** looks responsible and concentrates effort on risk. But the reddest accounts may be past saving, and with no comparison group the team never learns whether the play works. **Option B, a random 50,** produces evidence but leaves some very high-risk accounts unworked; only a large effect will stand out from chance. **Middle path.** Work the 20 accounts with the largest ARR at risk by judgement and randomise the other 30 plays among the remaining 120. Its weakness is power: 30 treated against 90 untreated shows only a large effect, so pool quarters or state the smallest effect worth detecting in advance; and the result applies to the randomised lower-ARR accounts, not the top 20. The untreated accounts get normal service (cadence calls, support, the renewal SOP), only not the extra play. **Why the attractive choice can be wrong.** In the consumer research of use case 2, targeting by expected response beat targeting by risk.[^ama-2019] No comparable B2B study is cited here; that uncertainty is the argument for measuring. **Decision.** The middle path, with the comparison written down before the quarter and reviewed after renewals close. ::: ### Learning objectives and mastery check 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? ::: answer Question 1 The support-centred meaning; queues, routing and SLAs are covered on SupportOps. Clarify the meaning before proposing fixes. ::: 2. A score has an AUC of 0.85 on last year's renewals. What two questions do you ask before trusting it? ::: answer Question 2 Were scores taken from snapshots before the renewal decisions (no leakage)? And how large is the red band against capacity, with what churn rate per band? ::: 3. Your red band holds 45% of accounts. What do you change first? ::: answer Question 3 Size the band from capacity and lift (for example the riskiest 10–15%), then revisit weights with a backtest (Lab 2). ::: 4. A usage feed fails and the platform redistributes its weight. Why is that dangerous? ::: answer Question 4 The score keeps showing a colour built from the remaining signals, hiding risk. Use an explicit "incomplete" state and a freshness alert. ::: 5. NRR is 115% but logo churn among small customers doubled. Is CustomerOps succeeding? ::: answer Question 5 Not necessarily: a few large expansions can mask many small losses. Read GRR and logo churn by segment and code the small-customer losses. ::: 6. A company has 12 enterprise customers and one CSM. Should it hire an analyst to build a health score? ::: answer Question 6 No. Twelve accounts give too few outcomes to learn from; start with renewal records, success plans and a renewal review. ::: ### Conclusion "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. ## Sources and further reading 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`). [^front]: [Customer Operations Ultimate Guide [2026]](https://front.com/guides/customer-operations-guide) — Front (FrontApp, Inc.), undated (2026 edition). Checked 2026-10-23. [^workato]: [What Customer Ops Looks Like At Four Real-World Companies](https://www.workato.com/the-connector/customer-ops-four-companies) — Hannah Herman, Workato, 2018-03-16. Checked 2026-10-23. [^customerthink]: [Customer operations: the secret to top-notch customer service](https://customerthink.com/customer-operations-the-secret-to-top-notch-customer-service/) — Paul Selby, CustomerThink (contributor post), 2021-05-19. Checked 2026-10-23. [^kaizo]: [Customer operations: support your support for happy customers](https://kaizo.com/blog/customer-operations/) — Kaizo, published 2023-02-14, updated October 2026. Checked 2026-10-23. [^fr-2019]: [The Customer Success Operations Role: Definitions And Responsibilities (summary page)](https://www.forrester.com/report/the-customer-success-operations-role-definitions-and-responsibilities/RES171930) — Lisa Nakano, Forrester, 2019-08-29. Checked 2026-10-23 (report itself paywalled). [^fr-role]: [Role Profile: Customer Success Operations Manager (summary page)](https://www.forrester.com/report/role-profile-customer-success-operations-manager/RES180258) — Shari Srebnick et al., Forrester, 2023-12-15. Checked 2026-10-23 (report itself paywalled). [^patent]: [US9824363B1: Method and system for electronically engaging customers](https://patents.google.com/patent/US9824363) — Lu Wang, Jinsheng Wang; Google Patents, granted 2017-11-21. Checked 2026-10-23. [^fr-tower]: [CS Operations: The Air Traffic Control Tower Your CS Team Needs](https://www.forrester.com/blogs/cs-operations-the-air-traffic-control-tower-your-cs-team-needs/) — Shari Srebnick, Brett Kahnke, Forrester, 2026-03-24. Checked 2026-10-23. [^fr-cscx]: [Customer Success And Customer Experience: The Difference Is More Than Semantic](https://www.forrester.com/blogs/customer-success-and-customer-experience-the-difference-is-more-than-semantic/) — Shari Srebnick, Su Doyle, Forrester, 2026-06-10. Checked 2026-10-23. [^murphy]: [Customer Success: Defined (2024)](https://sixteenventures.com/customer-success-definition) — Lincoln Murphy, Sixteen Ventures, 2023-01-04. Checked 2026-10-23. [^tsia-laer]: [Four Phases of LAER](https://tsia.com/blog/four-phases-of-laer) — TSIA, updated 2024-08-20. Checked 2026-10-23. [^tsia-frost]: [Re-Thinking Your Customer Engagement Model with LAER](https://tsia.com/blog/re-thinking-your-customer-engagement-model-with-laer) — Steve Frost, TSIA, updated 2020-10-15. Checked 2026-10-23. [^gs-mq]: [Gainsight Named a Leader in 2024 Gartner Magic Quadrant for Customer Success Management Platforms](https://www.gainsight.com/press/gainsight-named-a-leader-in-2024-gartner-magic-quadrant-for-customer-success-management-platforms/) — Gainsight press release, November 2024 (vendor's report of a Gartner document dated 2024-10-28). Checked 2026-10-23. [^cxdive]: [Catalyst, Totango merge to boost customer success platform](https://www.customerexperiencedive.com/news/catalyst-totango-merger-customer-success-teams/709373/) — Kristen Doerer, CX Dive, 2024-03-05. Checked 2026-10-23. [^totango]: [Totango is now Odie](https://www.totango.com/) — Totango home page (lists Totango, Catalyst and Odie products), undated. Checked 2026-10-23. [^fr-agentic]: [Customer Success Enters The Agentic Era](https://www.forrester.com/blogs/customer-success-enters-the-agentic-era/) — Shari Srebnick, Forrester, 2026-04-10. Checked 2026-10-23. [^fr-sorted]: [It's Time To Get Your Customers Sorted — No Wizardry Required](https://www.forrester.com/blogs/its-time-to-get-your-customers-sorted-no-wizardry-required/) — Shari Srebnick, Forrester, 2026-03-24. Checked 2026-10-23. [^fr-scaled]: [Are Scaled And Digital-Led Customer Success The Same Thing? Inconceivable!](https://www.forrester.com/blogs/are-scaled-and-digital-led-customer-success-the-same-thing-inconceivable/) — Shari Srebnick, Forrester, 2023-11-30. Checked 2026-10-23. [^fr-handoff]: [From Sprint To Marathon: Passing The Baton From Sales To CS For Seamless Account Transitions](https://www.forrester.com/blogs/from-sprint-to-marathon-passing-the-baton-from-sales-to-cs-for-seamless-account-transitions/) — Shari Srebnick, Forrester, 2025-01-23. Checked 2026-10-23. [^fr-wave]: [From Scattered Tools To Strategic Systems — Three Themes From The Forrester Wave: Customer Success Platforms, Q4 2025](https://www.forrester.com/blogs/from-scattered-tools-to-strategic-systems-three-themes-from-the-forrester-wave-customer-success-platforms-q4-2025/) — Shari Srebnick, Forrester, 2025-10-09. Checked 2026-10-23. [^gs-techtouch]: [Tech Touch Customer Success: The Playbook and Metrics](https://www.gainsight.com/blog/tech-touch-customer-success/) — Gainsight, 2026-06-26 (vendor guidance). Checked 2026-10-23. [^gs-home]: [Gainsight: The Customer Retention Platform](https://www.gainsight.com/) — Gainsight home page, undated. Checked 2026-10-23. [^gs-overview]: [Scorecards Overview](https://support.gainsight.com/gainsight_nxt/05Scorecards/01About/Scorecards_Overview) — Gainsight NXT documentation, undated. Checked 2026-10-23. [^gs-weights]: [Measure Weights in Scorecards](https://support.gainsight.com/gainsight_nxt/05Scorecards/02Admin_Guides/Measure_Weights_in_Scorecards) — Gainsight NXT documentation, undated. Checked 2026-10-23. [^hs-health]: [Customize a health score in the customer success workspace](https://knowledge.hubspot.com/help-desk/customize-a-health-score-in-the-customer-success-workspace) — HubSpot Knowledge Base, updated 2026-06-15. Checked 2026-10-23. [^churnzero]: [ChurnZero home page](https://churnzero.com/) — ChurnZero, undated. Checked 2026-10-23. [^planhat]: [Planhat home page](https://www.planhat.com/) — Planhat, undated. Checked 2026-10-23. [^gl-health]: [Customer Health Scoring](https://handbook.gitlab.com/handbook/customer-experience/customer-health-scoring/) — GitLab Handbook, last modified 2026-09-24. Checked 2026-10-23. [^gl-csm]: [Customer Success Management Handbook](https://handbook.gitlab.com/handbook/customer-experience/csm/) — GitLab Handbook, last modified 2026-10-20. Checked 2026-10-23. [^gl-renewals]: [Customer Renewal Tracking](https://handbook.gitlab.com/handbook/customer-experience/csm/renewals/) — GitLab Handbook, last modified 2026-09-24. Checked 2026-10-23. [^gl-onboarding]: [Customer Onboarding](https://handbook.gitlab.com/handbook/customer-experience/csm/onboarding/) — GitLab Handbook, last modified 2026-09-24. Checked 2026-10-23. [^gl-plans]: [Success Plans](https://handbook.gitlab.com/handbook/customer-experience/csm/success-plans/) — GitLab Handbook, live page. Checked 2026-10-23. [^gl-gainsight]: [Using Gainsight at GitLab](https://handbook.gitlab.com/handbook/sales/gainsight/) — GitLab Handbook, last modified 2026-09-24. Checked 2026-10-23. [^fawcett]: [An introduction to ROC analysis](https://www2.cs.uh.edu/~acl/cs6397/Doc/2006-PRL-An%20Intro%20to%20ROC%20analysis.pdf) — Tom Fawcett, Pattern Recognition Letters 27(8):861–874, 2006 (university-hosted copy). Checked 2026-10-23. [^sk-brier]: [Metrics and scoring: quantifying the quality of predictions](https://scikit-learn.org/stable/modules/model_evaluation.html) — scikit-learn 1.9.1 documentation. Checked 2026-10-23. [^lifelines]: [Introduction to survival analysis](https://lifelines.readthedocs.io/en/latest/Survival%20analysis%20with%20lifelines.html) — lifelines documentation. Checked 2026-10-23. [^lessmann]: [Maximize What Matters: Predicting Customer Churn With Decision-Centric Ensemble Selection](https://www.ieseg.fr/wp-content/uploads/2013-MARK-06_Coussement.pdf) — Stefan Lessmann, Kristof Coussement, Koen W. De Bock, IESEG Working Paper 2013-MARK-06, October 2013. Checked 2026-10-23. [^gupta-2006]: [Defection detection: Measuring and understanding the predictive accuracy of customer churn models (index record)](https://iaorifors.com/paper/53214) — Sunil Gupta, Scott A. Neslin, Charlotte H. Mason, Wagner Kamakura, Junxiang Lu, Journal of Marketing Research 43(2):204–211, 2006; abstract via IAOR (journal page returned HTTP 403). Checked 2026-10-23. [^ama-2019]: [Ascarza's "Retention Futility: Targeting High-Risk Customers Might Be Ineffective" Wins 2018 Award](https://www.ama.org/2019/04/24/escarzas-retention-futility-targeting-high-risk-customers-might-be-ineffective-wins-2018-award/) — Rajdeep Grewal, American Marketing Association, 2019-04-24 (summary of Ascarza, Journal of Marketing Research 55(1), 2018). Checked 2026-10-23. [^ama-2023]: [Eva Ascarza Receives 2023 Weitz-Winer-O'Dell Award for "Retention Futility"](https://www.ama.org/press-releases/eva-ascarza-receives-2023-weitz-winer-odell-award-for-retention-futility/) — American Marketing Association, April 2023. Checked 2026-10-23. [^ico]: [What is automated individual decision-making and profiling?](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/automated-decision-making-and-profiling/what-is-automated-individual-decision-making-and-profiling/) — Information Commissioner's Office (UK), updated 2026-03-31 (draft guidance). Checked 2026-10-23. [^dataact]: [Data Act explained](https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained) — European Commission, updated 2025-12-15. Checked 2026-10-23. [^gtlaw]: [Eighth Circuit Vacates FTC's 'Click to Cancel' Rule](https://www.gtlaw.com/en/insights/2025/7/eighth-circuit-vacates-ftcs-click-to-cancel-rule) — Greenberg Traurig, 2025-07-11. Checked 2026-10-23. [^ftc-anprm]: [FTC Seeks Public Comment in Response to Advance Notice of Proposed Rulemaking Regarding Negative Option Marketing Practices](https://www.ftc.gov/news-events/news/press-releases/2026/03/ftc-seeks-public-comment-response-advance-notice-proposed-rulemaking-regarding-negative-option) — US Federal Trade Commission, press release, 2026-03-11. Checked 2026-10-23. **Further reading** - GitLab's public [Customer Health Assessment and Management](https://handbook.gitlab.com/handbook/customer-experience/csm/health-score-triage/) 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.