Build Expansion into the Customer Journey

Task

Build expansion playbook.

Summary

Define signals and offers for upsell, cross-sell, renewal, and broader adoption.

Build an Expansion Playbook for Renewals, Upsells, and Cross-Sells

Task ID: S5-07

An expansion playbook turns customer evidence into repeatable renewal, upsell, and cross-sell decisions. It defines which signals deserve action, who owns each step, what offer fits the customer’s next goal, and how expansion annual recurring revenue is measured without hiding contraction, churn, delivery cost, or weak adoption.

The expansion problem is not a shortage of sales activity

A customer is six weeks from renewal. Product use is up, one team has reached a plan limit, another department has asked about access, and the customer’s procurement team prefers to buy through a cloud marketplace. Customer Success sees the usage. Sales sees a possible larger contract. Product sees a capacity issue. A partner sees an opportunity. Nobody has agreed who should act, what evidence is sufficient, or which offer should be made.

That is the problem an expansion playbook solves. It is not a collection of persuasive messages. It is an operating agreement for turning customer progress into the next sensible commercial decision.

The central principle is simple: expand after value is visible, toward a customer goal that the current agreement cannot fully support. Recent research defines customer success in business markets through the degree, alignment, and visibility of the customer’s goal achievement. It also identifies “goal framing”—the joint work of defining goals and translating them into measurable indicators—as a critical precursor to success.

That matters because an account can look healthy without being ready to expand. Frequent logins may reflect habit rather than meaningful value. High usage may indicate poor configuration rather than demand. A positive relationship with a champion may not survive a budget review. An expansion playbook therefore combines product evidence, business outcomes, commercial facts, and human judgment.

This work belongs after the company can onboard, support, renew, and measure customers consistently. There may be no formal dependency in a project tracker, but the practical prerequisites are real: clear plans and add-ons, dependable delivery, usable product data, renewal dates, account ownership, and a way to quote and fulfill the expansion. Without them, the company will create custom promises that operations cannot reliably deliver.

Customer Success should lead the evidence and value conversation, but it should not own every commercial or technical decision. Research on customer-success management describes the function as proactive work to educate and engage customers, demonstrate delivered value, and advocate for the customer inside the supplier. The playbook should preserve that role while making Sales, Product, Finance, Operations, partners, and marketplace teams accountable for their parts.

A completed playbook should make four questions answerable for every expansion opportunity:

  • What has the customer already achieved?
  • What new need or constraint has appeared?
  • Which standard offer addresses that need?
  • Can the company deliver the added value profitably and reliably?

An opportunity that cannot answer those questions is a sales hypothesis, not yet a qualified expansion.

Build around evidence of the customer’s next need

A useful expansion trigger is not “the account feels ready.” It is an observable event that suggests three things at once:

  1. The customer has received enough value to justify continuing.
  2. A new constraint, use case, team, volume, or goal has appeared.
  3. A defined offer can address that need without creating disproportionate cost or risk.

The strongest triggers usually combine several kinds of evidence.

Evidence classExamples of signalsWhat must be verified before action
Value achievedAgreed outcome reached; milestone completed; executive sponsor confirms impactThe outcome matters to the customer and can be explained in the customer’s terms
Capacity reachedSeat, transaction, storage, project, location, or usage threshold approachedThe limit reflects healthy demand rather than waste, error, or poor setup
Breadth opportunityA second team, workflow, geography, or business unit begins using or requesting the productThe new group has a real problem, owner, budget path, and onboarding plan
Adjacent product needUse of one capability creates demand for a complementary product or integrationThe products work together and the second product has its own value case
Commercial eventRenewal, budget cycle, marketplace commitment, acquisition, policy change, or contract consolidationTiming, buyer, procurement route, and decision process are known
Customer request or feedbackRepeated request for a feature, service level, reporting package, or support tierThe request represents a valuable segment rather than a one-off exception
Risk or service eventLow adoption, unresolved support issue, sponsor loss, or value gapExpansion is paused until the risk is understood and a recovery plan exists

Usage evidence is especially important in software, but it must be connected to customer value. Datadog states that its land-and-expand model depends on products that are easy to adopt and have a short time to value. As of March 31, 2026, about 85% of its customers used at least two products, and its trailing twelve-month dollar-based net retention rate was in the low-120% range. The company attributed the increase in that rate to higher usage by existing customers.

Snowflake reported a 126% net revenue retention rate as of April 30, 2026 and said its product-revenue growth was driven primarily by increased consumption from existing customers.

These examples teach two different expansion patterns. Datadog can observe product breadth as customers add related products. Snowflake can observe workload consumption as customers move more work onto the platform. A seat-based collaboration product, a professional subscription, and a usage-priced data platform should not share the same trigger thresholds. The playbook must reflect how the product creates value and how the customer buys.

A trigger record should contain:

Trigger fieldPurpose
SignalDescribes the observable event
Data sourceShows where the evidence comes from
ThresholdStates when the signal deserves attention
Customer goalConnects the event to a result the customer values
DisqualifiersPrevents inappropriate or premature selling
Lead ownerNames the person responsible for investigating
Response timePrevents opportunities from remaining unattended
Recommended offerConnects the need to a standard commercial response
Transaction routeIdentifies direct, partner, or marketplace execution
OutcomeRecords whether the signal led to recovery, renewal, expansion, or no action

The playbook should distinguish deterministic triggers from exploratory signals. “Active users have exceeded 90% of licensed seats for 30 days” can be a relatively strong trigger. “A second department attended a webinar” is only a hypothesis until someone confirms a problem, an owner, a budget path, and a reason to act.

The playbook also needs a risk gate. Do not attach a cross-sell to every support or success conversation. A field experiment on proactive post-sale service found that cross-selling can cause customers to question the seller’s motives, while intrusive contact can reduce the effectiveness of the service intervention. The researchers concluded that the message should be clear and the contact should not feel invasive. A customer trying to resolve a serious incident should hear a recovery plan, not an upgrade pitch.

flowchart LR
    A[Product, outcome, commercial, or partner signal] --> B[Verify customer goal and evidence]
    B --> C{Unresolved risk or weak value?}
    C -->|Yes| D[Recovery or adoption plan]
    C -->|No| E[Choose expansion offer]
    E --> F{Buying route}
    F -->|Direct| G[Direct quote and close]
    F -->|Partner| H[Partner-led or co-sell process]
    F -->|Marketplace| I[Private offer or amendment]
    G --> J[Onboard the expansion]
    H --> J
    I --> J
    J --> K[Measure value, ARR, cost, and retention]

The sequence contains an important control: a signal does not become an offer until value, need, risk, ownership, and buying route have been checked.

Turn signals into controlled expansion plays

A play is a repeatable response to a specific trigger. Each play should say who acts, what that person inspects, what is discussed with the customer, what can be offered, what stops the play, and what result is recorded.

A compact play card can use this structure:

FieldExample
Play nameSeat-capacity expansion
TriggerActive paid seats exceed 85% of contracted seats for 30 days
EvidenceActive-seat trend, team growth, customer goal, administrator confirmation
DisqualifiersDuplicate users, seasonal spike, unresolved adoption issue, planned downsizing
Lead ownerCustomer Success Manager
Commercial ownerAccount Executive or authorized partner
First actionConfirm hiring or rollout plan and expected timing
OfferAdditional seat block, higher tier, or enterprise agreement
Value caseAvoid access delays and support the next rollout
Transaction routeDirect order, partner quote, or marketplace amendment
Success measureNew users activated and using the agreed workflow within 45 days
Financial measureExpansion ARR, discount, margin, and implementation cost

The playbook will normally need separate plays for capacity expansion, tier upgrades, add-on purchases, new-product cross-sells, new-department rollouts, service-level upgrades, renewal with expansion, and partner- or marketplace-led expansion. Combining them into one generic “upsell” motion makes ownership, qualification, delivery, and measurement ambiguous.

Renewal plays. Renewal is not merely a contract date. It is the point where the customer decides whether past value, the future plan, price, risk, and the cost of change justify another commitment. The first renewal conversation should happen early enough to change the outcome.

GitLab’s public operating handbook provides one practical example: its renewal play begins four months before the renewal date, aligns the account team, asks an early renewal question, and leaves roughly three months to address risk. That timing is not a universal rule. A monthly self-serve subscription may require automated prompts measured in days, while a regulated enterprise agreement may require six to twelve months. The principle is to begin before procurement deadlines and before risks become irreversible.

A plain renewal script can be:

“Your renewal is scheduled for [date]. Before we discuss terms, I want to confirm whether the product is delivering the result we agreed: [customer outcome]. What has changed in your priorities, usage, budget, or team that we should plan for?”

When the answer reveals risk:

“The main gap I heard is [gap]. Let us agree on the recovery result, owner, and date before we discuss a larger commitment. Would [specific action] by [date] give you enough evidence to make the renewal decision?”

When the answer reveals an expansion need:

“You have achieved [result], and [new team, use case, or volume] is now creating a new requirement. The current plan does not cover [constraint]. We can compare [two suitable options], including the implementation work and expected result, before [decision date].”

These scripts keep renewal, recovery, and expansion connected but distinct. They do not assume that every renewal should increase. An account with unresolved value or delivery problems may need recovery, a smaller scope, or a deliberate exit rather than an upsell.

Quarterly business review plays. A quarterly business review, or QBR, should make customer value and future decisions visible. It should not be a slide deck of login counts, support statistics, and product announcements. GitLab describes its executive business review as a strategic meeting focused on measurable business outcomes, return on investment, future priorities, and joint action plans.

A practical QBR template is:

SectionQuestions the meeting must answer
Customer prioritiesWhat business goals matter now, and what changed since the last review?
Outcomes deliveredWhich agreed results were achieved, missed, or remain uncertain?
Adoption and useWhich teams and workflows create value? Where is adoption shallow or inefficient?
EconomicsWhat effect on time, cost, risk, revenue, or capacity can be supported by evidence?
RisksWhat could prevent renewal or expansion? Who owns each mitigation?
Expansion hypothesesWhich new use cases, teams, volumes, or products fit the customer’s goals?
DecisionsWhat is approved, rejected, deferred, or requires more evidence?
Action planWhat are the owner, date, measure, and next review for each commitment?

The QBR should end with decisions and a written action log. An expansion opportunity that emerges should enter a defined play rather than remain a hopeful note in a presentation.

The internal QBR preparation sheet should also distinguish among three levels of evidence:

  • Verified fact: supported by product, financial, operational, or customer-approved data.
  • Customer statement: reported by a named customer stakeholder but not independently measured.
  • Working hypothesis: a reasonable interpretation that still requires validation.

This distinction reduces the risk of building an expansion proposal around an attractive but unsupported return-on-investment claim.

Expansion offers. An expansion offer should be a small business case, not a list of extra features. It should contain:

Offer componentRequired content
Customer changeThe new goal, constraint, volume, team, or risk
EvidenceObserved usage, outcome data, stakeholder request, or approved future plan
OfferThe plan, add-on, product, service level, or usage commitment that addresses the change
Expected resultWhat the customer should achieve, by when, and how it will be measured
Commercial termsPrice metric, quantity, term, discount, renewal treatment, and any ramp or pilot
Delivery planOnboarding, integration, training, support, capacity, and accountable owner
Decision processEconomic buyer, users, procurement, legal or security work, route, and decision date

A marketplace is a transaction route, not proof of demand. Google Cloud’s current documentation permits private offers with customized pricing, billing frequency, contract duration, and optional automatic renewal; existing offers can also be modified or replaced. That flexibility makes ownership rules more important, not less.

The playbook should state who:

  • Identifies the opportunity.
  • Validates the use case and customer result.
  • Is authorized to quote and approve discounts.
  • Creates the partner or marketplace offer.
  • Receives sourcing, assistance, and closing credit.
  • Provisions the added entitlement.
  • Owns onboarding and post-sale adoption.
  • Records the revenue and delivery cost.

Without those rules, multiple channels may claim the same opportunity, present inconsistent terms, or leave the customer waiting after the order is signed.

Create evidence that the playbook is real

A document is not a working playbook until people can use it on live accounts and produce consistent records. Completion should leave four visible sets of evidence.

The trigger library should contain a limited set of approved triggers with definitions, thresholds, data sources, disqualifiers, owners, and response times. It should show which triggers are automated, which require human review, and how false positives are handled.

The renewal package should contain scripts for healthy, uncertain, and at-risk accounts; timing by customer segment; internal review steps; procurement milestones; and clear responsibility for renewal, expansion, technical validation, and executive escalation.

The QBR package should contain a customer-facing template, an internal preparation sheet, a source list for every claimed outcome, and an action log. It should distinguish verified results from estimates and customer statements from supplier assumptions.

The offer catalogue should contain the expansion offers that operations can actually deliver. Each offer needs eligibility rules, standard scope, price metric, approval limits, implementation effort, expected time to value, margin assumptions, and direct, partner, or marketplace paths.

A minimum evidence record for each live opportunity should look like this:

Account:
Current ARR and products:
Renewal date:
Customer goal:
Verified value already achieved:
Expansion trigger and date:
Evidence source:
Risk gate result:
Recommended offer:
Alternative considered:
Commercial owner:
Delivery owner:
Partner or marketplace role:
Expected expansion ARR:
Expected customer result:
Decision date:
Outcome and reason:
Post-sale activation result:

This record prevents the company from counting vague interest as pipeline or signed annual recurring revenue as completed customer success. The expansion is operationally complete only when the customer can use what was purchased and the expected value has a named measure.

Evidence that the playbook works should come from live trials, not an internal workshop alone. A useful pilot would apply the plays to a defined account cohort and examine:

Pilot questionEvidence to collect
Are triggers accurate?True opportunities, false positives, missed opportunities, and data gaps
Are owners clear?Response time, handoff failures, duplicated outreach, and unresolved decisions
Do offers fit the need?Acceptance, rejection reasons, requests for exceptions, and time to quote
Can delivery support the sale?Onboarding time, implementation effort, support demand, and time to value
Does the customer use the expansion?Activated seats, workloads, products, locations, or workflows
Does the expansion endure?Contraction, renewal, product use, and outcome attainment after the sale
Are channels working together?Sourced, assisted, transacted, and fulfilled roles by opportunity

The pilot should include both wins and non-wins. A rejected expansion offer can reveal an incorrect trigger, poor timing, missing value, unsuitable packaging, procurement friction, or a customer segment that should not be pursued.

Measure expansion without hiding contraction or weak delivery

The primary measure is expansion annual recurring revenue, or expansion ARR: the annualized recurring value added by customers who were already paying at the beginning of the measurement period. It can come from more seats, higher usage commitments, tier upgrades, add-ons, new products, or additional business units.

The company should define whether variable usage, currency movement, acquisitions, short-term services, one-time implementation charges, and automatic price increases are included. It should then apply that definition consistently.

A useful revenue bridge is:

Ending ARR
= Starting ARR
+ Expansion ARR
- Contraction ARR
- Churned ARR
+ New-customer ARR

For the existing-customer cohort:

Expansion rate
= Expansion ARR / Starting ARR
Gross revenue retention
= (Starting ARR - Contraction ARR - Churned ARR)
  / Starting ARR
Net revenue retention
= (Starting ARR + Expansion ARR - Contraction ARR - Churned ARR)
  / Starting ARR

Expansion ARR should be reported beside gross retention, contraction, and churn. A company can produce strong net retention because a small group expands rapidly while many smaller customers shrink or leave. It should also separate price increases from quantity, tier, product, and usage expansion because those changes have different implications for customer value and future growth.

ARR and net retention are operating measures, not standardized accounting measures. Datadog defines ARR using monthly run-rate subscription amounts, says ARR should be viewed independently from revenue, and uses a same-customer comparison for dollar-based net retention. Snowflake explicitly warns that its key-business-metric calculations may differ from similarly named metrics used by other companies or analysts.

A target should therefore be derived from the company’s own customer base and operating model rather than copied from a public-company percentage.

A defensible expansion target can be built from the bottom up:

Expected expansion ARR
= Eligible installed-base ARR
× trigger incidence
× qualification rate
× offer rate
× win rate
× average ARR uplift

Each input should refer to a named cohort and period.

For example, “eligible installed-base ARR” might include only customers that have completed onboarding, achieved a minimum value milestone, have no critical unresolved risk, and offer at least one standard expansion path. Including every customer would inflate the opportunity base and weaken the target.

A company with limited history can use ranges:

Low case:
Conservative incidence, win rate, and average uplift

Working case:
Best current estimate from observed customer behavior

High case:
Plausible upside, not a sales commitment

After several cycles, assumed inputs should be replaced with observed conversion, timing, discount, activation, contraction, and delivery-cost data.

The target also needs guardrails.

MeasureWhy it belongs beside expansion ARR
Gross revenue retentionShows whether expansion is masking contraction and churn
Expansion activation rateShows whether purchased seats, products, or capacity are actually used
Time to value after expansionTests whether delivery can support the larger promise
Expansion gross marginPrevents custom work and support cost from making growth uneconomic
Discount and concession rateDistinguishes value-led expansion from price-led closing
Customer outcome attainmentTests whether the expansion solved the stated problem
Partner or marketplace contributionShows sourced, assisted, transacted, and fulfilled roles separately
Expansion cycle timeReveals procurement and operational friction
Post-expansion support loadDetects offers that create avoidable service demand

The working target is “defined” only when it names:

  • The formula and measurement period.
  • The starting customer cohort.
  • Included products and revenue types.
  • Currency and usage treatment.
  • The point at which an expansion is counted.
  • The responsible owner.
  • The data source and reconciliation method.
  • The retention, margin, activation, and customer-outcome guardrails.

A single percentage or currency amount in a tracker is not enough.

Avoid the plays that look complete but are not

Several failure modes create the appearance of an expansion system while leaving the business dependent on individual judgment.

Calendar-based selling. The team contacts every account 90 days before renewal with the same upgrade message. Timing matters, but readiness comes from value, need, and buying conditions.

Health-score theater. A composite score turns green, but nobody can explain the underlying events, data quality, or intervention. Scores should route attention. They should not replace account evidence.

Selling through unresolved risk. The account has poor adoption or a serious support issue, but the team presents more products. This damages trust and confuses recovery with growth.

Feature-led QBRs. The meeting reports releases, tickets, and usage without connecting them to customer goals. It produces activity but no decision.

Discount-led expansion. A time-limited concession creates a larger booking but weak adoption, future price resistance, or avoidable churn. A real customer or procurement deadline can support a decision. Artificial urgency cannot create customer value.

Custom offers disguised as packages. Every expansion requires new scope, special integrations, senior attention, or exceptions. Expansion ARR rises while margin, delivery time, and operational reliability deteriorate.

Channel conflict. The Customer Success Manager, direct seller, partner, and marketplace team pursue the same account without rules for ownership, communication, quoting, or credit. The customer receives conflicting proposals, and the internal forecast may count the same opportunity more than once.

Counting the contract instead of the result. The company records expansion when the order is signed but never checks activation, delivery cost, or customer outcome. This is a booking process, not a customer-expansion system.

Treating public retention figures as universal benchmarks. Datadog’s multi-product model and Snowflake’s consumption model illustrate why expansion mechanics differ. Their reported rates describe their businesses, metric definitions, customer mixes, and reporting periods; they do not set a universal target.

Automating judgment too early. Product data can identify thresholds, create tasks, and prepare account information. It cannot always determine whether a usage spike is healthy, whether the political sponsor has changed, or whether the new use case fits the product. Automation should reduce repetitive work while leaving consequential interpretation to an accountable person.

Ignoring customers that should not expand. Some customers have weak fit, excessive support demands, poor payment behavior, or requirements that would pull the product away from its intended market. A disciplined playbook permits “renew without expansion,” “reduce scope,” and “do not renew” as valid outcomes.

Before the company depends on the playbook, live-account evidence should show that:

  • Triggers are detected reliably.
  • Customer value can be demonstrated.
  • Risks stop inappropriate offers.
  • Direct, partner, and marketplace ownership is unambiguous.
  • Standard offers fit most qualified opportunities.
  • Delivery can support expansion without repeated exceptions.
  • Renewal conversations begin early enough to affect the outcome.
  • Signed expansions activate and produce the intended customer result.
  • Expansion records reconcile with Finance.
  • The target remains credible after contraction, churn, discounts, and delivery cost are considered.

The final decision is not whether the team has written scripts or built a dashboard. It is whether the company can explain, account by account, why the next sale helps the customer, who will deliver it, and what result will prove that the expansion was sound.

Sources

Primary sources

  • Datadog, Form 10-Q for the quarter ended March 31, 2026.
  • Snowflake, Form 10-Q for the quarter ended April 30, 2026.
  • GitLab, “Executive Business Reviews.”
  • GitLab, “Customer Renewal Tracking.”
  • Google Cloud Marketplace documentation on private-offer pricing and management.

Open research

  • Gehring, Ulaga, Eggert, and Hochstein, “Customer Success: An Interorganizational Performance Concept in Business Markets,” Journal of the Academy of Marketing Science, published October 31, 2025.
  • Hochstein, Chaker, Rangarajan, Nagel, and Hartmann, “Proactive Value Co-Creation via Structural Ambidexterity,” Journal of Service Research, 2021.
  • Becker, Spann, and Barrot, “Impact of Proactive Postsales Service and Cross-Selling Activities on Customer Churn and Service Calls,” Journal of Service Research, 2020.