Track a small set of customer success metrics that changes a real decision: leading signals such as adoption, unresolved friction, and feedback, alongside outcomes such as renewal, churn, and recurring revenue retention. For example, if weekly feature adoption falls for an eligible account, the CSM can investigate the change. If the account is not up for renewal, that signal is not itself a renewal result.
Define each measure before it reaches a dashboard. Specify the population, unit, period, formula, source, owner, and action. This prevents a login count, survey average, or health score from being mistaken for customer success on its own.
This guide focuses on the operating system behind the metrics: correct data grain, defensible formulas, useful health-score design, dashboard freshness, and controlled actions. The implementation examples are illustrative architectures, not claims that a particular HubSpot workspace card or public API endpoint supports every step.
Which customer success metrics should you track?
Start with the smallest useful set across four purposes: engagement or delivery progress, customer sentiment, service friction, and retention or revenue outcomes. The right measures depend on the operating model. A SaaS team may monitor activation, account adoption, eligible renewals, and expansion. A professional-services team may instead focus on milestone completion, realized outcomes, delivery issues, and repeat engagements.
- Leading signals: activation, qualifying product or service adoption, unresolved support issues, delivery progress, and customer feedback. These can prompt investigation, but do not prove that an account will churn.
- Lagging outcomes: customer churn, eligible renewal, gross revenue retention (GRR), and net revenue retention (NRR). These record what happened over a defined period.
Ticket volume, login counts, and composite health scores are signals, not success outcomes. A high ticket count might reflect friction, but it could also reflect a large, actively supported account. A login may be routine rather than evidence of meaningful adoption.
For every candidate metric, write down the decision it should change, the accountable owner, and the action triggered by meaningful movement. Remove measures that have no decision or owner.
A metric earns its place when it has a defined decision, an owner, and a next action.
Define each metric before putting it on a dashboard
Teams can report different answers under the same metric name because they count different populations, units, or time periods. A metric contract makes those choices explicit. Record the metric name and version, definition, numerator, denominator, population filter, data grain, period, timezone, currency where relevant, source system, calculation time, and data-quality status.
Also define the record grain: what one row represents. A login or support ticket is an event; a survey answer is a response; a weekly adoption rate is an account-period observation; a renewal is a contract-period outcome; and a dashboard value is an aggregate. An automation execution is a separate run record. These should not be collapsed into one row keyed only by company.
State the unit clearly: customer, company, contract, subscription, seat, or recurring-revenue dollar. They are not interchangeable. Logo retention counts customers. GRR and NRR measure recurring revenue retained from a starting customer base. Renewal rate counts eligible customers or contracts that renewed.
A percentage needs a defined denominator. If no customers were eligible to renew, renewal rate is undefined for that population and period, not zero. The same principle applies to survey response rates and adoption rates with no eligible users.
| Contract field | What to specify | Example |
|---|---|---|
| Population and unit | Who or what is counted | Active paid companies |
| Grain and period | Meaning of one record and its window | Company-week, Monday to Sunday |
| Formula and source | Numerator, denominator, and system | Qualifying users divided by eligible users |
| Owner and version | Who approves changes and which rule applies | CS operations, version 1 |
Have the metric owner and data owner approve the contract before building the report. For historical results, retain the source period and calculation version so a formula change does not silently redefine past performance.
The core customer success metrics and how to calculate them
Use the formula that matches the decision, and put the unit and denominator beside it. The examples below are illustrative calculations, not benchmarks.
| Metric | Calculation | What it measures |
|---|---|---|
| Customer churn rate | Customers lost in period divided by customers at period start, multiplied by 100 | Share of the starting customer population lost |
| Renewal rate | Eligible customers or contracts renewed divided by eligible customers or contracts up for renewal, multiplied by 100 | Renewal among those actually due |
| GRR | Starting recurring revenue minus churn and contraction, divided by starting recurring revenue, multiplied by 100 | Recurring revenue retained before expansion |
| NRR | Starting recurring revenue minus churn and contraction plus expansion, divided by starting recurring revenue, multiplied by 100 | Recurring revenue retained including expansion |
| NPS | Percentage of promoters minus percentage of detractors | Recommendation sentiment on a 0 to 10 question |
For churn, exclude customers acquired during the period from the starting-customer denominator. If 64 of 1,000 starting customers are lost, churn for that period is 6.4%. Under the simplifying assumption that the same monthly churn rate continues and applies consistently, the compounded 12-month loss would be approximately 54.8%, not 12 times the monthly rate.
For renewal rate, choose either customer count or contract count and retain that unit consistently. If 42 of 50 contracts eligible for renewal are renewed, the contract renewal rate is 84%. Do not divide by all active contracts or customers.
GRR and NRR begin with recurring revenue from the existing customer base at the start of the period. Exclude new-customer revenue from both. GRR subtracts churn and contraction; NRR also includes expansion. An NRR result does not, by itself, show which team caused the change.
MRR is the sum of recurring monthly revenue under a consistent currency, discount, and contract policy. Report new, expansion, contraction, and churned MRR separately. A net figure alone can conceal whether growth came from new accounts or existing customers.
NPS uses the 0 to 10 recommendation question: promoters score 9 or 10, passives 7 or 8, and detractors 0 to 6. If 60% of respondents are promoters and 20% are detractors, NPS is 40. It is not the percentage of respondents who selected a positive answer. See HubSpot’s explanation of survey response analysis for its documented NPS calculation.
CSAT and CES need their question, scale, qualifying responses, and calculation documented. A custom five-star CSAT measure might define positive responses as four or five stars. That formula does not describe HubSpot’s native CSAT response property, which uses unhappy, neutral, and happy values on a 0 to 2 scale. HubSpot documents a 1 to 7 scale for native CES. Keep the scales separate in reporting.
Product adoption is meaningful only after defining the qualifying event or feature, eligible users or accounts, observation window, and threshold. Distinguish active users from seats purchased and from accounts that meet an adoption criterion. CLV and retention-cost ratios depend on assumptions. For planning, use cohort-based, gross-profit-adjusted estimates rather than treating MRR divided by churn as a universal lifetime-value formula.
Build a customer health score that supports a decision
A health score prioritizes investigation and customer action. It does not replace churn, renewal, or revenue reporting. Choose signals with a plausible relationship to the outcome you want to understand: adoption, unresolved support friction, customer-reported sentiment, or progress toward agreed outcomes.
Set expectations by customer segment and lifecycle stage. A newly onboarded company may not yet have the usage pattern of a mature account. Limit the contribution of repeated, low-value events with an event window, frequency cap, association aggregation method, score limits, and decay rule where appropriate. Treat missing data as unknown unless the model explicitly defines its absence as meaningful.
HubSpot documents configurable health scores for contacts or companies, with selected segments and scoring based on properties and events. Its configuration includes event timeframes, frequency rules, score limits, decay, and association aggregation. Health-score and health-status properties are created after activation. These capabilities do not validate a particular model’s predictive value. Check the applicable subscription, seat, and permissions before configuring the workspace. See HubSpot’s health-score configuration guide.
A 40/30/30 weighting across usage, support, and business outcomes can be tested as a hypothetical starting point, but it is not a HubSpot default or a validated standard. Review the score distribution and test whether it predicts a defined outcome in your own historical cohorts before using it to forecast churn.
Use customer feedback without mixing survey scales or records
NPS asks about recommendation sentiment; CSAT asks about satisfaction with a defined interaction or experience; CES asks about the effort required to complete a particular task. They answer different questions. Preserve every response as its own record with survey ID and type, submission time, rating, response text where collected, source, and respondent or account association.
HubSpot’s survey-response properties are response-level records and can be used in segments, workflows, and custom reports. Its documented survey options and scales are described in the survey creation guide and response-property reference. Set a minimum response count before showing small-segment averages. When wording, scale, audience, or sampling changes, preserve the version and do not present the resulting values as an uninterrupted comparable trend.
A contact’s latest answer is not a historical feedback dataset. Preserve each survey response before calculating account or segment summaries. Overwriting earlier answers hides changes in sentiment and can distort trends.
Open-text comments can be grouped into suggested themes with AI, provided a person reviews themes that could change an account action. Keep the numeric rating sourced from the response, not inferred by a classifier. Deterministic rules are better for scale validation, NPS calculation, response counts, thresholds, and eligibility because those questions have explicit inputs and auditable answers.
Design dashboards around customer decisions, not metric volume
Build views for distinct jobs: a CSM account-risk queue, a manager’s renewal and revenue view, and a program owner’s segment or cohort view. Useful content includes health-score distribution, upcoming eligible renewals, account-level adoption trends, survey results with response counts, and churn or expansion outcomes. Label each chart’s population and period.
Keep customer-count outcomes distinct from revenue-weighted outcomes. When interpreting NRR, show expansion and contraction as well as churn. Revenue retention is affected by pricing, packaging, customer mix, sales, product changes, and account ownership, so do not attribute a change to Customer Success alone.
HubSpot’s Customer Success workspace is documented for Service Hub Professional and Enterprise, with Service Seat and permission requirements for relevant features. Workspace limits vary by edition. Dashboard and custom-report access, limits, permissions, and refresh behavior also depend on subscription and report type. HubSpot documents that new data can take about 10 to 15 minutes to appear in custom reports and that custom-report-builder reports refresh with newly available data approximately every two hours. Confirm current plan details and the specific report’s behavior. Do not describe every dashboard as real time. Dashboard access also does not necessarily grant access to the underlying reports or fields. See HubSpot’s Customer Success workspace documentation and custom report builder guidance.
Use source-specific freshness labels, such as product events through a stated date, report refreshed at a stated time, and health score calculated at a stated time. For configuration and reporting requirements, see HubSpot systems consulting.
A practical path from metric definition to customer action
Start with a metric owner and definition, verify source data and account identity, calculate at the correct grain, validate results, and only then publish an alert or CRM update. The system of record for historical observations should preserve the period and calculation version. A warehouse or reporting layer is often appropriate for those observations; a CRM summary write-back is a separate implementation decision.
For example, a scheduled product-analytics job could aggregate qualifying and eligible users by company-week. The following is an illustrative account-period observation, not a HubSpot field schema or a verified direct integration:
{
"source_system": "product_analytics",
"external_account_id": "acct_1042",
"metric_name": "weekly_feature_adoption_rate",
"metric_version": "v1",
"period_start": "2026-10-05",
"period_end": "2026-10-11",
"eligible_users": 20,
"qualifying_users": 12,
"value": 0.6,
"source_run_id": "run_8f31",
"validation_status": "pending_account_match"
}In this example, one row means one metric for one account over one week. The deterministic calculation is 12 divided by 20, or 60%. Resolve the external account ID to exactly one CRM company, verify period, timezone, units, and denominator, then save the observation with its source run ID and calculation timestamp. If a CRM summary is needed, verify the supported access path and target fields for that account and subscription first. HubSpot documents APIs and versioning, but research did not verify a public endpoint for every Customer Success workspace element.
Use a database-enforced unique constraint or transactional upsert for repeated observations. For a canonical account-period metric, a proposed key is source_system + company_id + metric_name + metric_version + period_start + period_end. If separate source snapshots must coexist, add a source snapshot identifier or make it part of the metric version. A read-then-create check is not safe when concurrent workers can process the same record. Retain source record IDs, source run IDs, calculation timestamps, and any replacement relationship between recalculations.
On API rate limits, follow documented retry guidance, including honoring the Retry-After header. For account matching, conflicting currency, stale periods, missing required values, or low-confidence AI themes, quarantine the record for the named data or account owner rather than silently writing it.
AI may suggest themes from open-text comments or summarize account notes. It should not decide a formula, renewal eligibility, duplicate status, or whether an external identifier maps to a CRM company when explicit rules can answer those questions. For identity, ownership, and system-of-record decisions, see CRM systems consulting.
- The source account maps to exactly one eligible CRM company.
- The period, timezone, numerator, denominator, and units are valid.
- The formula version, source observation, source run, and calculation time are retained.
- A database-enforced uniqueness rule or transactional upsert prevents duplicate observations.
- Multiple source snapshots cannot collide under the selected observation key.
- The destination fields and write path are confirmed for this implementation.
- An accountable person owns unmatched, stale, conflicting, or incomplete records.
- The action has an owner and a measurable outcome for review.
Evaluate benchmarks and improve the measurement system
Published benchmarks are directional comparisons, not universal targets. Compare only after matching business model, segment, contract or ARR size, geography, period, and calculation definition. Benchmark reports can disagree because their cohorts and measurement windows differ. For context, ChartMogul’s NRR discussion emphasizes variation by company type and price point, while its 2023 retention report is historical evidence for its own dataset, not a current universal standard.
Test whether a leading signal precedes a defined outcome in your own cohorts. Compare alternative windows and segments, and account for contract timing, pricing changes, account mix, and product or sales changes. Also evaluate whether an alert reached its owner, whether the owner acted, and whether the intervention changed the outcome. Review metric contracts when instrumentation, survey wording, contract policy, or calculation logic changes.
A practical launch is small: approve one metric contract, back-test it, review exceptions with CSMs, publish it with visible freshness and ownership, then measure whether the resulting action improves a specified customer outcome. Treat a target as an operational goal and an external comparison as context, not as proof of causation.