Make Customer Success Own Retention and Renewal

Task

Build customer success onboarding and renewal process.

Summary

Separate ongoing success from project delivery and give retention, renewal, and expansion explicit ownership.

Build Customer Onboarding and Renewals That Do Not Depend on the Founder

Task ID: S4-10

A customer success process should carry the reason a customer bought through onboarding, first value, ongoing use, renewal, and appropriate expansion. This article explains how to build that process, assign ownership, define health and retention measures, distinguish real evidence from completed activity, and decide when the company can rely on the system without constant founder intervention.

The renewal problem begins at the handoff

The sale closes on Friday. On Monday, the customer asks what happens next.

Sales has notes, but they describe the deal rather than the result the customer expects. The implementation team knows which features must be configured, but not which business change matters most. Support is waiting for tickets. The customer success manager has a start date, a contract value, and a list of contacts, but no agreed definition of success.

Everyone appears busy. Nobody can say what must happen before the customer has received enough value to justify renewal.

That is the problem a customer success playbook must solve. It is not merely a collection of welcome emails, meeting agendas, and renewal reminders. It is the operating process that carries the customer’s original reason for buying through product adoption, measurable results, renewal, and, where justified, expansion.

Recent open academic research defines customer success as more than satisfaction or activity. It describes success in terms of the degree of customer goal achievement, the agreement between supplier and customer about those goals, and the visibility of the achievement to the people who make decisions. The same research identifies joint goal framing—turning a desired result into an agreed and measurable goal—as an important precursor to success.

Earlier research on customer success management reached a compatible conclusion: the function is proactive rather than reactive. Its work includes preparing and educating customers, helping them create value through the product, demonstrating the value achieved, and representing customer needs inside the supplier’s organization.

The operating principle is therefore straightforward:

Renewal should be the commercial confirmation of value already achieved, not a last-minute attempt to persuade a customer to stay.

This work belongs after the company has a product, a defined customer, a reasonably clear purchase promise, and a subscription offer. The product does not need to be perfect, but the company must know enough to answer four questions:

When these answers are absent, customer success inherits uncertainty created earlier in the sale. It can compensate temporarily through personal effort, but the process will remain expensive, inconsistent, and dependent on experienced employees or the founder.

Build one customer success system

A useful playbook connects onboarding, health checks, renewals, and expansion triggers. These are not four separate administrative programs. They are successive views of one question: Is the customer progressing from the reason for purchase toward a result worth continuing to pay for?

flowchart LR
    A[Purchase goal and handoff] --> B[Onboarding plan]
    B --> C[First value confirmed]
    C --> D[Ongoing outcome and usage checks]
    D --> E{Customer health}
    E -->|Risk| F[Recovery plan]
    E -->|On track| G[Renewal readiness]
    E -->|Value achieved and need grows| H[Expansion review]
    F --> D
    G --> I[Renewal decision]
    H --> I
    I --> J[Updated success plan]

The diagram shows the intended sequence. The purchase goal becomes an onboarding plan. Onboarding ends only when the customer has reached a defined point of value and can continue operating. Health checks then monitor whether value is continuing. Risk produces a recovery plan; demonstrated value supports renewal; and expansion is considered only where additional use would serve a real customer need.

A public operating example is available in GitLab’s customer success handbook. Its onboarding process starts with an internal transition from pre-sales, confirms the customer’s purchase reason and business goals, identifies additional stakeholders, creates an initial success plan, establishes an ongoing meeting cadence, and records time-to-value measures. Its public targets include a kickoff within 14 days, first value within 30 days, and completion of the onboarding process within 45 days. Those are GitLab’s operating targets, not universal standards, but the structure is useful: each stage has an owner, a time expectation, required information, and an exit condition.

The completed playbook should contain at least the following artifacts:

The service model should reflect customer value and complexity. A low-price self-serve subscription cannot support the same meeting schedule as a complex enterprise implementation. Conversely, an enterprise customer with security reviews, integrations, migrations, and several decision makers is unlikely to succeed through automated email alone.

The aim is not to give every customer identical treatment. It is to ensure that every customer receives a defined treatment appropriate to the economics and difficulty of the relationship.

Design onboarding around first value

Onboarding should begin with the customer’s purchase goal, not with a tour of every available feature.

A strong handoff records what the customer was trying to change, how the problem was being handled before the purchase, what result justified the price, which assumptions were made during the sale, and which people must contribute. The customer success manager should reject an incomplete handoff rather than quietly rediscovering the deal after closing.

The first customer meeting should confirm, in plain language:

• the result the customer expects;
• the first useful outcome that can be achieved;
• who owns the work on each side;
• the customer’s important dates and dependencies;
• how progress and value will be measured;
• what is outside the purchased scope;
• how support, escalation, and commercial questions will be handled.

The output is a mutual success plan. “Mutual” matters because software rarely creates a business result by itself. The supplier may provide the product, configuration guidance, training, and advice, while the customer supplies data, access, decisions, process changes, internal communication, and employee participation. Research on customer success emphasizes this interorganizational character: the customer and supplier frame goals and integrate their resources together.

Define first value precisely

First value is the earliest meaningful evidence that the product is helping with the reason for purchase. It is not automatically:

• the contract start date;
• the completion of a kickoff call;
• the first login;
• installation;
• attendance at training;
• the number of features configured.

Those activities may be necessary, but they do not prove that the customer has received useful value.

A first-value definition should name the actor, action, result, and evidence. For example:

The finance operations manager imports one live reporting cycle, resolves the identified reconciliation differences, and confirms that the process can replace the prior spreadsheet workflow.

A weaker definition would be “customer completed setup.”

The appropriate event varies by product and customer. A collaboration product may reach first value when several employees complete a shared workflow. An analytics product may reach it when the customer answers a decision-relevant question with live data. A security product may reach it when a real exposure is detected, prioritized, and remediated. A workflow product may reach it when the customer completes a production process with less time, fewer errors, or stronger control.

GitLab’s public process illustrates both the value and limitation of operational proxies. It tracks time to first value using product adoption measures such as initial licence activation, while also carrying the customer’s original purchase intent into a living success plan. This is a useful combination: product data offers speed and consistency, while the success plan preserves the customer’s actual goal.

Use exit criteria, not calendar completion

Onboarding should finish when the customer can use the product successfully, knows how to obtain help, and has reached or is demonstrably progressing toward first value.

A practical onboarding exit record includes:

An account may leave formal onboarding with a non-critical action still open, but the exception should be explicit. Quietly closing overdue onboarding tasks to improve a dashboard converts a process measure into fiction.

Trial and self-serve customers require segmentation as well. Research using a digital television subscription service found that customers acquired through a free trial behaved differently from regular purchasers and, in that setting, had substantially lower average lifetime value. The authors also found that usage and communication affected the groups differently. That result should not be treated as a universal SaaS benchmark, but it demonstrates why trial customers should not automatically be judged by the same assumptions as customers who make a conventional purchase.

Use health checks to direct action

A customer health score is useful only when it changes what someone does.

A colour or number with no agreed response is decoration. A score assembled from whichever data happens to be available may be worse: it can create false confidence while hiding a lost sponsor, failed implementation, unaddressed product gap, or approaching contract deadline.

A practical health model separates five kinds of evidence:

GitLab’s public health framework combines product use, licence utilization, customer sentiment, stakeholder conditions, renewal progress, and explicit risk. It treats signals such as a customer going silent, losing an internal champion, declining active users, low utilization, stalled renewal activity, or poor use of the purchased capability as reasons for investigation. It also uses strong utilization and relevant feature use as possible expansion indicators.

Usage data can be valuable, but it should not be treated as a complete explanation. An open study of business-to-business subscription data from a scholarly publisher found that patterns of resource use could support churn prediction well before cancellation. The same study also showed why a simple usage measure can produce false positives and false negatives: some low-usage customers may still renew, while some high-usage customers may still leave.

A practical inference is that the company should combine behavioural data with customer goals, stakeholder evidence, service history, and commercial facts. It should also retain override conditions that cannot be averaged away. Examples include:

• the customer has stated an intention to cancel;
• the economic buyer has withdrawn support;
• a critical implementation dependency has no owner;
• the product cannot meet a required use case;
• a serious security or reliability issue remains unresolved;
• the customer has entered insolvency or announced a relevant closure;
• an invoice or payment method problem is preventing continuation.

Every signal needs a definition, source, update frequency, owner, and required response. “Usage is low” is not a definition. “Fewer than three of ten licensed operations users completed the primary workflow during the previous 30 days, excluding customers still in implementation” is.

Health should be reviewed at two levels. The customer success manager needs account-level actions. Leadership needs patterns: which segments, offers, onboarding paths, features, acquisition sources, or implementation types produce elevated risk.

Separate recovery triggers from expansion triggers

An expansion trigger is evidence of an additional customer need that the product can serve. It is not permission to sell merely because the renewal date is approaching.

Reasonable triggers may include:

• sustained use near a purchased capacity limit;
• successful adoption by one team followed by demand from another;
• achievement of the first agreed goal and identification of a related goal;
• repeated use of a workflow associated with a higher plan;
• requests for governance, security, administration, integration, or reporting capabilities available in another package;
• an organizational event that creates a legitimate new use case.

The guardrail is equally important: expansion should not obscure unresolved value or service problems. A customer with weak adoption, an absent sponsor, and unresolved support issues needs recovery work, not an optimistic expansion forecast.

Start renewal before the contract deadline

A renewal process that begins when the notice period is about to expire is a collections process, not customer success.

The company must first distinguish the contract deadline from the renewal decision. The signature may be due in December, but the customer may set its budget in September, evaluate vendors in August, or require a procurement request in July. The practical renewal date is therefore the earliest date at which inaction could prevent continuation.

GitLab’s public renewal process creates a customer success action four months before renewal. It calls for an internal review, confirmation of the person directly responsible for the renewal, customer discussion, and enough remaining time to address risk. The published process aims to identify risk while several months are still available to change the outcome.

A workable annual renewal calendar is:

The exact timing should reflect contract value and buying complexity. A monthly self-serve subscription may rely on in-product notices and automated billing events. A regulated enterprise customer may need six months or more.

The renewal record should separate facts from judgment.

Facts include contract dates, notice periods, product use, open incidents, invoice status, documented customer statements, procurement steps, and completed outcome milestones.

Judgments include the customer success manager’s assessment of risk, expected renewal amount, and confidence.

Hypotheses include suspected political problems, possible budget pressure, or assumed competitor activity that has not yet been confirmed.

This separation improves forecasting and prevents a confident employee opinion from being reported as customer evidence.

Treat payment failure as a distinct branch

Not all lost subscriptions represent rejection of the product. Some result from expired payment methods, authentication requirements, unsuccessful charges, or administrative delays. These cases should be labelled separately from voluntary churn so that product, customer success, and billing teams do not draw the wrong conclusion.

Stripe’s subscription documentation distinguishes active, past-due, unpaid, and cancelled states and recommends event-driven handling of invoice failures and upcoming renewals. Its recovery documentation supports automated retries and customer notifications that allow payment details to be corrected.

For larger invoiced accounts, the equivalent process may involve purchase-order validation, invoice delivery confirmation, accounts-payable contacts, tax documentation, and escalation rules. The underlying principle is the same: separate inability or failure to pay from a decision not to renew.

Measure proof, not activity

The primary measure for this work is gross retention, but that phrase is incomplete until the company defines the unit, cohort, time period, and treatment of contraction.

Common forms include:

Expansion is excluded from gross revenue retention. If a cohort begins with $1 million of recurring revenue, loses $50,000 through cancellations, and loses $30,000 through downgrades, gross revenue retention is 92%.

The company must publish its exact formula internally because public usage is not uniform. Procore, for example, reported gross retention of 95% as of September 30, 2025, while explicitly stating that its measure reflected customer losses but not expansion or contraction. Workiva reported gross retention of 97.3% as of March 31, 2026, using subscription and support revenue from a prior-period customer base. Backblaze reported a 91% gross customer retention rate as of March 31, 2026, using account counts rather than retained revenue. These figures illustrate different products and definitions; they are not interchangeable benchmarks.

A credible target should therefore be written in this form:

Target: Gross revenue retention of at least [x]% for [defined customer segment], measured over a [monthly, quarterly, or trailing-12-month] period, using [written formula], with expansion excluded and contraction [included or excluded explicitly].

The value of [x] should be based on the company’s customer type, contract length, price, maturity, implementation difficulty, historical performance, and economics. A low-price monthly consumer subscription, a small-business software product, and a mission-critical enterprise platform should not be expected to produce the same retention profile.

Gross retention is a result measure. It arrives too late to manage the current customer. The operating dashboard also needs leading and diagnostic measures:

Metrics should be segmented by customer size, plan, acquisition source, use case, geography where relevant, onboarding path, and customer age. A blended average can conceal a strong enterprise segment and a failing small-business segment, or vice versa.

Cohort analysis is especially important. Compare customers who began in the same period or followed the same onboarding path. That allows the company to test whether a change in handoff, training, product design, or first-value workflow improved later retention rather than merely coinciding with a different customer mix.

Know when the process is dependable

Customer success work often looks complete before it is useful.

A welcome sequence may exist, but nobody can define first value. A health dashboard may be colourful, but no action follows a red score. Renewal opportunities may be created automatically, but the customer’s budget decision has already passed. Expansion triggers may generate sales leads, but they reward raw usage rather than customer outcomes. A retention target may be documented, but its formula changes between finance and customer success.

These are paperwork successes and operating failures.

The process is not dependable until the company can show that:

• every new customer enters a defined service path;
• the handoff preserves the purchase goal, promise, scope, risks, and stakeholders;
• onboarding has a measurable first-value event and explicit exit conditions;
• delayed onboarding and unresolved dependencies trigger action;
• health signals have definitions, owners, thresholds, and response playbooks;
• material risks cannot be hidden by averaging several weak scores;
• renewal work begins before the customer’s practical decision deadline;
• voluntary churn, contraction, and payment failure are classified separately;
• expansion is pursued only when customer value and additional need are evident;
• retention is calculated consistently and segmented meaningfully;
• the cost of serving each customer segment is known;
• the process continues when the founder or most experienced employee is absent.

The final evidence should be a working customer success playbook, not a presentation about one. It should contain the live handoff form, onboarding plan, first-value definitions, success-plan template, health data dictionary, risk actions, renewal calendar, expansion rules, account records, dashboard, and review schedule.

At that point, management can answer the decision this work is meant to support: Can the company repeatedly onboard, support, retain, and renew subscription customers at a cost the business can support?

The answer does not come from a single retention percentage. It comes from a traceable connection between what the customer bought, the value the customer achieved, the actions the company took, the revenue retained, and the effort required to retain it.

Sources

Primary sources

• GitLab, “Customer Onboarding.”
• GitLab, “Customer Success Plan.”
• GitLab, “Customer Health Scoring.”
• GitLab, “Customer Renewal Tracking.”
• GitLab, “Renewals Managers — What We Do.”
• Stripe, “How Subscriptions Work,” “Automate Payment Retries,” “Automate Customer Emails,” and “Using Webhooks With Subscriptions.”
• Workiva, quarterly report for the period ended March 31, 2026.
• Procore Technologies, quarterly report for the period ended September 30, 2025.
• Backblaze, quarterly report for the period ended March 31, 2026.

Open research

• Gehring, Anna, Wolfgang Ulaga, Andreas Eggert, and Bryan Hochstein, “Customer Success: An Interorganizational Performance Concept in Business Markets,” Journal of the Academy of Marketing Science, published October 31, 2025.
• Hochstein, Bryan, Nawar N. Chaker, Deva Rangarajan, Duane Nagel, and Nathaniel N. Hartmann, “Proactive Value Co-Creation via Structural Ambidexterity: Customer Success Management and the Modularization of Frontline Roles,” Journal of Service Research, 2021.
• Roberts, Michael, J. Ignacio Deza, Hisham Ihshaish, and Yanhui Zhu, “Estimating Defection in Subscription-Type Markets: Empirical Analysis From the Scholarly Publishing Industry,” 2022.
• Datta, Hannes, Bram Foubert, and Harald J. Van Heerde, “The Challenge of Retaining Customers Acquired With Free Trials,” Journal of Marketing Research, 2015.