New-logo growth gets the attention, but in most vertical SaaS businesses I've looked at, expansion revenue from the existing customer base is what separates a company growing 20% a year from one growing 60%. The math is unforgiving: if you're churning 10% of revenue annually and only replacing it with new logos, you're on a treadmill. Expansion — getting existing customers to pay more over time — is the only lever that compounds without a proportional increase in sales and marketing spend.
What net revenue retention actually measures
Net revenue retention (NRR) tracks the revenue from a cohort of customers over time, including upgrades, downgrades, and churn, but excluding any new customers acquired in the period. An NRR of 110% means that cohort of customers, left alone, grew their spend by 10% over a year even after accounting for anyone who churned or downgraded. Vertical SaaS companies with strong expansion motion routinely post NRR in the 115-130% range, because the product naturally grows with the customer's business — more locations, more transaction volume, more seats — in a way that horizontal tools like a generic CRM don't.
The three expansion levers, and which one to build first
Seat-based expansion is the easiest to build and the easiest for customers to understand: more users, more cost, linear and predictable. Usage-based expansion (more transactions, more API calls, more storage) scales better with genuine value delivered but is harder to price transparently and can create bill-shock if customers don't see it coming. Module or tier-based expansion — unlocking a new feature set for an incremental fee — has the highest margin but requires the product to actually be modular, which most codebases aren't unless it was designed in from early on. Most vertical SaaS companies end up combining all three, but the order you build them in matters: seat-based expansion is nearly free to implement if you already gate by user count, so it's usually the first lever, not the best one.
You can't manage NRR directly — it's the output of specific product and pricing decisions made months earlier. Track it monthly for visibility, but spend your actual attention on the leading indicators: percentage of accounts using a feature that's gated behind an upsell, and how often customer success has a genuine "you've outgrown your plan" conversation.
Building usage thresholds that nudge without annoying
The cleanest expansion trigger I've seen implemented is a soft usage cap: the customer can exceed their plan's included volume, but crosses into an overage rate or a prompt to upgrade once they've done it consistently for a full billing cycle, not the moment they touch the ceiling once. A one-time spike shouldn't trigger a sales conversation; a sustained pattern should. This requires storing rolling usage data per tenant and running the threshold check against a trailing window, not a point-in-time snapshot.
SELECT
tenant_id,
plan_tier,
AVG(monthly_usage) OVER (
PARTITION BY tenant_id
ORDER BY billing_month
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
) AS trailing_3mo_avg_usage,
plan_included_usage
FROM tenant_usage_monthly
QUALIFY trailing_3mo_avg_usage > plan_included_usage * 1.15;
Who owns the expansion conversation
In self-serve vertical SaaS, in-app prompts and automated billing changes can carry most of the load — a usage bar that turns amber, an email when a customer crosses 80% of their plan. In higher-touch vertical SaaS, where deals are closed by a sales rep and the customer has a named account manager, expansion needs a human, because the decision to spend more often needs internal budget approval on the customer's side that no in-app nudge can produce alone. Getting this ownership wrong — automating a conversation that needed a human, or routing every account through an account manager who's already overloaded — is a common reason expansion pipeline exists in the CRM but never closes.
Wrapping up
Expansion revenue isn't a pricing trick, it's a product and org design problem: does the product have natural growth surfaces (seats, usage, modules), does the data exist to detect when a customer has outgrown their plan, and is there a clear owner — human or automated — for the conversation that follows. Get those three right and NRR becomes a byproduct rather than a target you have to chase.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.