To improve customer retention, start by defining who counts as a customer, what “active” means, and the period you will measure. Then compare similar customer cohorts, identify why customers disengage, and assign one proportionate action to a named owner. A subscription business might investigate failed payments separately from cancellations, while a retailer might measure repeat purchases only among customers who have had time to reorder.
There is no single retention percentage that diagnoses every business. Subscription, repeat-purchase, and high-value service businesses need different measures and interventions. The practical sequence is consistent: define the customer and activity rule, choose the metric and period, compare cohorts, investigate losses, and test an owned response.
This guide focuses on measurement design and operating decisions rather than promising a universal result or a turnkey integration. Its examples show how to preserve data grain, distinguish deterministic rules from bounded AI use, and connect retention signals to human-owned actions.
A retention percentage is useful only when its population, time window, and next owner are explicit.
Choose the retention measure that fits your business
Use customer counts to understand whether relationships persist, recurring revenue to understand how much subscription revenue remains, and repeat-purchase rate to understand transactional behavior. Decide how pauses, downgrades, returns, and reactivated customers will be treated before calculating. Keep those definitions consistent across periods.
Customer retention and customer churn
For a fixed period, customer retention measures the share of opening customers who remain active at the end, excluding customers acquired during that period:
Customer retention rate = ((customers active at period end − customers acquired during the period) ÷ customers active at period start) × 100
Customer churn rate = (customers lost during the period ÷ customers active at period start) × 100
These formulas assume the same customer identity and activity rule at both ends. Define whether a paused subscription remains active, when a cancellation takes effect, and whether a returning customer counts as retained or reactivated. A new customer who replaces a lost one must not be counted as a retained opening customer.
Repeat purchase rate
For a transactional business, repeat purchase rate is the share of an eligible customer population that makes at least one additional purchase within a defined window:
Repeat purchase rate = eligible customers with two or more purchases in the window ÷ all eligible customers in the window × 100
Set eligibility to allow a reasonable opportunity to buy again. If a product is usually reordered every few months, customers who purchased too recently to reach that cycle should not be treated as failed repeat buyers. State whether returns or cancelled orders count, and track time to second purchase alongside the rate when it helps explain the result.
Gross and net revenue retention
Subscription businesses can also measure recurring revenue retention. Gross revenue retention (GRR) measures how much opening recurring revenue remains after cancellations and downgrades, excluding expansion revenue. Net revenue retention (NRR) includes expansion as well as the effects of cancellations and downgrades. Both use opening recurring revenue as the denominator and exclude revenue from new customers. Document how you handle pauses, credits, and plan changes before comparing periods.
Customer lifetime value and referral rate can help assess unit economics and acquisition sources, but neither replaces a retention measure. Lifetime value depends on the revenue or margin assumptions used; referral share depends on a consistent attribution rule. Treat them as supporting measures, not evidence that customer relationships persisted.
Set the data grain before calculating a rate
Retention errors often start when different kinds of records are mixed. A customer record represents an identity; an order or support ticket represents an event; a customer-period observation records that customer’s status for a defined period; and a cohort aggregate summarizes a population. Keep these grains separate. One customer with five orders is still one customer in a customer-retention denominator.
A practical customer-period snapshot has one row per customer, measurement-period end, and metric-definition version. The following fields are a hypothetical design, not a HubSpot schema or a ready-made integration:
{
"customer_id": "cust_1042",
"customer_type": "subscription_account",
"cohort_start_date": "2026-07-12",
"measurement_period_start": "2026-09-01",
"measurement_period_end": "2026-09-30",
"active_at_period_end": true,
"recurring_revenue_at_period_end": 89,
"churn_reason": null,
"source_system": "billing_platform",
"source_record_id": "sub_8821",
"calculation_version": "retention_v1"
}In this example, one row means one customer’s measured state at the end of one period. A proposed key is customer_id + measurement_period_end + calculation_version. If the same customer can have multiple metric definitions at the same period end, use a distinct metric-definition version rather than overwriting the earlier observation. Store individual order or billing events separately, using source_system + source_event_id as a proposed uniqueness key where repeated delivery is possible. Store cohort totals separately with their population definition, observation window, numerator, denominator, and calculation version.
At period close, an operations or finance owner can reconcile source customer and billing records, apply the written activity rule, reject missing or impossible dates, and calculate the rate. Investigate duplicate keys and unexplained differences before publishing. For concurrent event processing, enforce uniqueness in the integration’s own database and use a transactional upsert or insert-on-conflict operation. A lookup followed by a create can race when two workers process the same customer at once.
HubSpot documents record IDs and custom unique-value properties as CRM-side safeguards, and notes that companies created through the API are not automatically deduplicated by domain. Use a known record ID or supported unique property where appropriate, but do not treat CRM deduplication as a substitute for source-system idempotency. See HubSpot’s record deduplication guidance for the documented limits.
Compare cohorts and investigate why customers leave
A blended rate can change because the customer mix changed, not because the experience improved or worsened. Compare customers with similar start dates, products or plans, acquisition channels, and lifecycle windows. For a seasonal business, compare like seasons where possible rather than treating a predictable slow period as a sudden retention failure. Segment losses by tenure and recorded reason when the evidence supports it.
Do not fill a missing churn reason with a guess. A cancellation message, a failed payment, and an account with no recent activity are different observations. Record “unknown” when the cause is not established, then review a sample of those cases or ask a suitable follow-up question.
Benchmarks need the same care. Business model, purchase cycle, contract length, customer mix, metric definition, and observation period all affect the comparison. Benchmarkit’s 2025 SaaS benchmark materials report GRR by defined SaaS cohorts. The materials use specific ARR and ACV bands, so preserve the stated cohort definition rather than combining unlike groups into a new small-business target.
Turn retention signals into actions with an owner
Choose actions that match the business model and the observed reason for disengagement. A loyalty program may suit frequent purchases when its reward economics work; it is less likely to address an infrequent, high-value relationship that needs a clear service owner. The examples below are proposed operating designs, not promised outcomes or documented turnkey templates.
| Signal or trigger | Rule or bounded AI job | Validation and fallback | Action and owner |
|---|---|---|---|
| New account misses an activation milestone | Rule: start date plus incomplete milestone by a defined day | Check the correct account, milestone, consent status, and open-case status. Suppress if a human-owned case needs attention. | Create one owner task or send approved onboarding help; onboarding owner follows up. |
| Payment fails | Rule: verified failed-payment event, not a sentiment score | Match the billing event to the customer, check whether recovery already ran, and route disputes to billing. | Use the approved payment-update process; billing owner handles disputes. |
| Repeated setup questions | AI may group message text into an allowed theme such as onboarding | Keep the source ticket and review uncertain, sensitive, or contradictory classifications. | Support resolves the case; product or content owner reviews recurring verified themes. |
| No reorder by the expected date | Rule: purchase history and a documented reorder window | Exclude customers without enough time to reorder; check returns, opt-outs, and open complaints. | Send relevant reorder education or a reminder; ecommerce owner reviews results. |
Make the sequence operational: identify the source system and event, confirm the customer and eligibility, apply suppression rules, then send an approved message or create a task in the system where the owner works. Suppress routine outreach for opt-outs, cancellation requests, unresolved complaints, and open high-severity cases. A person should decide how to handle those exceptions rather than allowing a standard reminder to override the customer’s situation.
For HubSpot, workflows can enroll records using documented filter, event, schedule, or webhook triggers, subject to the account’s subscription, object, and permissions. Re-enrollment is not automatic: configure it only when repeated execution is intended. A practical onboarding rule might enroll an eligible account when its start date and incomplete milestone are present, create one owner task, and unenroll it when onboarding is complete or a qualifying support case requires personal handling. See the documentation for creating workflows and configuring re-enrollment.
Use rules for clear events and AI for unstructured feedback
Use deterministic rules for facts with a clear source: payment failed, subscription canceled, activation not completed, ticket overdue, or no purchase by a defined reorder date. Use AI only where interpretation is needed, such as grouping free-text complaints or summarizing a support history for an owner. Do not let a classifier decide whether a customer has churned, is eligible for a discount, or has had a complaint resolved.
For a feedback classifier, constrain the result to allowed themes and preserve its evidence. A hypothetical output could be:
{
"classification": "onboarding",
"confidence": 0.86,
"evidence_excerpt": "cannot find the setup instructions",
"source_record_id": "ticket_774",
"model_or_rule_version": "feedback_classifier_v1",
"processed_at": "2026-09-18T14:31:00Z",
"human_review_status": "pending"
}Validate the output against a schema and approved theme list before saving it to a feedback queue linked to the original ticket or survey. Route low-confidence, contradictory, sensitive, or high-impact cases to a named support or customer-experience reviewer. Do not overwrite a verified churn reason with an unreviewed classification. Record the action taken and, where appropriate, whether the customer was told about a resulting change.
A failed payment is a verifiable event to route. Negative sentiment or a low health score is a reason to investigate, not proof that a customer will churn. Check the underlying record and assign the next decision to a person when the signal is uncertain.
HubSpot’s Customer Success workspace supports configurable health scores based on selected properties and event activity, with score decay and limits on event contributions. The business still has to define thresholds, test the score against its own customer history, and connect a useful status to a review queue or separate workflow. The feature is documented for Service Hub Professional and Enterprise and requires an assigned Service Seat and relevant permissions. See HubSpot’s health-score configuration guidance.
If an AI support tool is considered, provide it with approved and current content, configure human handoff conditions, and test billing disputes, cancellation requests, legal issues, security events, and low-confidence answers before broader deployment. HubSpot documents Customer Agent content use and configurable handoff, but its definition of a resolved conversation is a usage classification, not a certification that an answer was accurate or appropriate. See Customer Agent documentation and handoff configuration guidance.
Pilot one intervention and measure its effect
Start with one segment, one intervention, and an outcome that matches the customer journey. For example, compare normal onboarding with onboarding plus a day-14 milestone check-in. Define eligible accounts, cohort dates, exclusions, denominator, primary measure, and calculation version before launch. Activation by day 30 could be an early measure; first renewal or period retention is a later outcome. Those dates are an illustrative test design, not a benchmark.
Where practical, assign eligible customers to a comparison group. If that is not feasible, use a clearly described comparable cohort and avoid claiming that the intervention caused a change. Report the sample size and observation window, and track unintended effects such as unsubscribes, complaints, discount cost, or extra support work. If the results are inconclusive, continue observing or revise the intervention rather than declaring success from a small fluctuation.
Choose tools after the operating process is clear
First identify where customer identity, orders or subscriptions, support cases, consent, and lifecycle status are recorded, and who owns each source. Then select the smallest set of systems that can preserve the definitions, show relevant history, route exceptions, and report cohort outcomes. Confirm required fields, permissions, and data access before building a workflow. A CRM is useful only if customer identity and lifecycle facts are reliable enough to support the action.
HubSpot is one product example, not a guarantee of a retention outcome or a turnkey connection to a billing, point-of-sale, or product-usage system. Check current plan, seat, and permission requirements before purchase or rollout because feature availability can differ by tier. If the process spans systems or needs careful identity and lifecycle design, CRM systems consulting can help clarify the data and ownership requirements. For HubSpot-specific implementation planning, see HubSpot systems consulting.
The operating test is straightforward: can the team explain who was measured, why a customer was flagged, what action followed, and whether the customer’s outcome changed over a suitable observation period? If not, improve the definitions and handoffs before adding more automation.