Your Customer Success team can be busy, responsive, and well liked while NRR remains flat. That usually means the team is managing activity rather than managing the customer behaviors that precede retention and expansion. Renewals still arrive as surprises, adoption is discussed in anecdotes, and expansion depends on an alert CSM noticing an opportunity.

You can replace that uncertainty with an operating system. The work is to define how customers reach value, instrument the behaviors that show progress or risk, and connect each signal to a specific product or human intervention. When that system works, expansion stops being an end-of-quarter sales hunt. It becomes the commercial consequence of demonstrated customer value.

Give Customer Success an economic job, not an activity target

I treat NRR as the economic score for the installed base, not as a departmental Customer Success report. The standard calculation is:

NRR = (starting recurring revenue + expansion – downgrades – churn) / starting recurring revenue.

New-logo revenue does not belong in the calculation. You are asking what happened to the recurring revenue already under management: how much was retained, how much contracted, and how much grew. At 100% or more, the installed base sustains its starting revenue before new sales are added. Materially higher performance means existing customers are contributing to growth rather than merely surviving renewal.

That makes NRR important, but it does not make NRR diagnostic. It is a lagging result. It can tell you that the installed base expanded or contracted, but it cannot tell you which onboarding failure, adoption pattern, product limitation, or commercial decision caused the movement. Managing only the final number is like managing product quality from refund totals.

Give the team two connected views instead:

• The economic view: NRR separated into expansion, downgrades, and churn for a consistent customer cohort and period.
• The behavioral view: activation, time-to-first-value, time-to-second-value, adoption depth, usage direction, risk signals, and evidence of expansion readiness.

The economic view shows where revenue landed. The behavioral view shows what you can still change.

Key takeaways

• NRR is the result. Customer progress, product adoption, and expansion readiness are the controllable inputs.
• Customer Success should own movement toward customer outcomes, not a calendar of calls and QBRs.
• Usage should trigger investigation and a relevant playbook; it should not automatically trigger an upsell.
• Product, Customer Success, Sales, Solutions Engineering, and operations need the same definitions and dashboard.
• Review NRR drivers every week, while there is still time to change the outcome.

Build an NRR driver tree from customer behavior

A useful NRR driver tree starts with the customer’s job, not your feature list. Customers do not renew because they clicked enough buttons. They renew because a workflow repeatedly produced an outcome worth paying for. Product usage matters when it provides evidence that this value-producing behavior is becoming established.

Start with one segment. Customers with different use cases or levels of maturity can reach value through different workflows, so a universal activation event will usually blur more than it reveals. For that segment, define the progression in five steps:

1. Name the outcome the customer hired the product to achieve.
2. Identify the critical event that represents first value, not merely setup completion.
3. Define second value: the customer successfully repeats the meaningful workflow.
4. Identify the deeper or broader behaviors associated with durable use.
5. Specify the risk and expansion signals that should activate a playbook.

The distinction between first and second value matters. First value proves that the product can help. Second value begins to prove that the customer can incorporate it into normal work. A customer who completes a workflow once and never returns should not be classified alongside one who repeats it reliably.

Translate that progression into a table your product and CS teams can actually use:

Journey stage	Evidence to capture	What failure looks like	Next response
First value	The customer completes the critical outcome-producing workflow	Setup activity occurs, but the meaningful result does not	Remove the specific dependency or friction blocking completion
Second value	The customer repeats the workflow in a relevant context	Initial success remains a one-time event	Reinforce the use case with a contextual prompt or CSM follow-up
Habitual value	Use becomes deeper, broader, or more consistent	Adoption stays shallow or trends downward	Coach the customer toward the next value-producing behavior
Expansion readiness	Proven value meets a real capacity, seat, capability, or plan constraint	A commercial signal exists without a clear customer outcome	Validate the unmet need before recommending an offer
Renewal readiness	Outcome evidence, adoption, and stakeholder alignment remain healthy	Risk is discovered only when the renewal conversation begins	Launch a recovery plan while behavior can still change

Instrument each critical event precisely. Record who performed it, which account the user belongs to, what object or workflow was completed, when it occurred, and what completion condition distinguishes success from a partial attempt. If the event definition is loose, every downstream health score and expansion alert will inherit the ambiguity.

Then examine adoption by use case and maturity rather than averaging unlike customers together. Behavioral analytics and retention analysis can reveal which workflows are associated with durable customers. Treat that association as a shortlist for investigation, not automatic proof of causation. A feature can appear correlated with retention because healthy customers adopt it, because it creates value, or because both are driven by a third factor such as implementation maturity.

Your shared customer view should answer practical questions without forcing a CSM to assemble evidence from several tools: What outcome is this account pursuing? Which value milestones has it reached? What was its last meaningful event? Is use becoming deeper, broader, or weaker? Which risk or readiness signal fired? Who owns the response? Those fields are more actionable than a single unexplained health-score color.

Design the journey from first value to habitual value

Onboarding is not finished when users complete a checklist. It is finished when the intended customer has reached the defined value milestones and has a credible path to repeat them. This is why compressing time-to-first-value and time-to-second-value matters more than increasing tour completion.

Split the journey between product-led and human help based on the nature of the work.

• Let the product handle repeatable education: contextual in-app guidance, focused product tours, reminders, and reinforcement around the next meaningful action.
• Use people for ambiguity: clarifying the customer’s outcome, mapping a complex workflow, resolving implementation constraints, aligning stakeholders, and coaching organizational adoption.

Do not assign the touch model from contract value alone. A high-value account with a straightforward use case may need less intervention than a smaller account facing integration, process, or change-management complexity. Touch should follow complexity, risk, and maturity as well as commercial importance.

Every onboarding playbook needs explicit exit criteria. At minimum, the account record should show:

• The intended business outcome and primary use case.
• The customer roles involved in producing and receiving that outcome.
• Completion of the first-value event.
• Completion of the second-value event.
• Adoption of the next workflow associated with durable use for that segment.
• The next outcome the customer is trying to reach.
• An owner and action for any unresolved blocker.

This also changes how you evaluate in-app education. A product tour is an intervention, not a success metric. Measure whether the targeted customer subsequently completes the intended workflow and repeats it. A guide that attracts clicks but does not change the relevant behavior is not improving adoption.

Create recovery playbooks for recognizable failure states rather than one generic risk sequence:

• If setup is active but first value is missing, identify and remove the blocked dependency.
• If first value occurred but second value did not, reconnect the customer to the recurring use case and its next natural trigger.
• If use is broad but shallow, coach the account toward the workflow that creates a meaningful result.
• If a small group has deep adoption, verify whether the same outcome applies to adjacent users before treating the pattern as expansion readiness.
• If meaningful usage is declining, inspect the outcome, workflow, stakeholder, and product experience before assuming that more reminders will help.

The mechanism matters. A customer blocked by configuration needs a different intervention from one whose original use case disappeared. Lumping both into a red health score makes the dashboard cleaner and the response weaker.

Make expansion a consequence of demonstrated value

Expansion should begin when the customer’s success creates a legitimate next need. Common paths include additional seats, premium capabilities, or a higher plan, but the commercial offer must follow the use case. The plan limit is evidence of a constraint; it is not the customer outcome by itself.

A product-qualified expansion signal becomes useful when it combines four kinds of evidence:

• Value evidence: the customer has completed and repeated the important workflow.
• Demand evidence: use is approaching a real capacity, access, seat, or capability boundary.
• Fit evidence: the additional product or plan resolves a need related to the customer’s next outcome.
• Relationship evidence: the team understands the champion, decision path, timing, and any unresolved risk.

A limit event without value evidence may indicate confusion, poor packaging, or temporary activity. Deep usage without an additional need may indicate a healthy renewal rather than an expansion. A premium capability without use-case fit is simply an upsell idea. Require the signals to tell a coherent customer story before placing the opportunity in a pipeline.

For each qualified lead, give the CSM or commercial owner a compact evidence packet:

• The outcome the account has already achieved.
• The users and workflows producing that outcome.
• The usage pattern or constraint that triggered the signal.
• The next customer need the additional capacity or capability could address.
• The most relevant proof from the account’s own behavior.
• Known risks, missing information, the owner, and the next action.

This changes the expansion conversation from “Would you like to upgrade?” to a decision grounded in the customer’s operating reality. The CSM can show what is working, name the constraint, and ask whether removing it advances the customer’s next priority. When customers repeatedly encounter plan limits, usage can create a product-qualified expansion lead, but a person still needs to validate the value narrative and buying context.

Do not conceal risk behind an expansion signal. If core adoption is deteriorating or the customer has not achieved the promised outcome, pressing for a larger commitment can turn a recoverable problem into a trust problem. Resolve the health question first or make the uncertainty explicit.

Downgrades deserve the same rigor as wins. Separate customers who bought excess capacity, customers who never reached value, customers whose needs changed, and customers who found a product limitation. Those are different product, packaging, onboarding, and commercial problems. Treating all contraction as “churn risk” prevents the right team from learning from it.

Run a weekly NRR review that changes customer outcomes

In my work at HighLevel, the durable lesson has been that NRR improves when incentives, dashboards, and operating rituals point at the same customer outcomes. A weekly review provides the connective tissue. It is frequent enough to catch changes while product guidance, CSM coaching, technical help, or commercial action can still affect the result.

Use a four-level dashboard:

1. Outcome: NRR, with expansion, downgrade, and churn shown separately.
2. Leading behavior: activation, time-to-first-value, time-to-second-value, meaningful adoption, and usage direction by segment.
3. Account movement: customers entering or leaving defined risk and expansion-readiness states.
4. Execution: the intervention, owner, next action, and subsequent behavior for each material signal.

Keep the meeting focused on changes and decisions. A practical agenda is:

1. Inspect cohort movement in expansion, downgrades, and churn.
2. Identify which leading behaviors changed and in which customer segment.
3. Review accounts that crossed a defined risk or readiness threshold.
4. Assign the next action, owner, and expected customer behavior.
5. Feed recurring friction into product discovery, onboarding, packaging, or enablement work.

Thresholds must be defined for your own product and segments. Avoid inventing one universal usage score and pretending that it represents every use case. The important test is operational: does crossing the threshold reliably prompt an action that can improve a customer outcome?

Assign clear responsibilities around the shared result:

• Product defines and instruments critical workflows, removes recurring friction, and builds scalable guidance.
• Customer Success clarifies outcomes, coaches adoption, validates risk, and develops the expansion story.
• Solutions Engineering resolves technical complexity that blocks value.
• Sales or the designated commercial owner manages pricing, negotiation, and the formal expansion decision.
• Data or operations maintains cohort logic, event definitions, account mapping, and dashboard integrity.

One person should still own the next action for each account. Shared accountability for NRR should not become ambiguous accountability for execution.

Connect quarterly planning to the same driver tree. QBRs should identify which NRR constraint deserves investment. OKRs should express the customer or business behavior that needs to change, not merely the feature a team plans to ship. If an initiative cannot be connected to activation, value realization, durable adoption, risk reduction, or qualified expansion, its NRR rationale is incomplete.

Watch for four common forms of dashboard theater:

• Blended NRR hides a weak segment behind expansion from a stronger one.
• Large-account expansion masks broad logo churn or shallow adoption elsewhere.
• A health score changes color without revealing the behavior, cause, or required response.
• Alerts accumulate without an owner, playbook, or record of what happened next.

Your first move does not require a complete health-scoring program. Choose one important customer segment. Define its first-value event, second-value event, durable-use behavior, primary risk signal, and clearest expansion constraint. Put those five signals beside the economic result, attach an owner and playbook to each, and review the movement next week. If the team cannot agree on the definitions, that disagreement is the first operating problem to solve.

References

• Shivam.Consulting Blog – Mastering NRR: How Great Customer Success Teams Drive Expansion, Crush Churn, and Scale PLG

---