[drop_cap]A[/drop_cap] customer signed the contract, onboarded, and started using the product. In most businesses that would be the end of the story until renewal. In SaaS it is the start of a second one, because the number that decides whether this business compounds or merely survives is not new logo growth. It is net revenue retention — the existing customer base, one year later, measured against itself. NRR above 100% means the accounts you already have are worth more without a single new signup. NRR below 100% means growth has to outrun a leak that never closes. This stage is where NRR is earned or lost.
Most SaaS founders treat expansion as a sales motion — a number to hit in a quarter, a target handed to the account manager. That framing gets the causality backwards. Expansion is not something you push into a customer. It is a signal the customer is already sending, and your job is to notice it and respond before they solve the problem themselves in a way that doesn’t involve paying you more.
Four Paths, Four Different Signals
Expansion revenue comes from four places, and they do not share a trigger. Treating them as one motion — “upsell the account” — is why so many expansion plays feel like guessing.
More seats. The team using your product grew. A second department discovered it, or the original buyer’s team hired. The signal is observable and specific: a login from a new email domain-internal user, an invite sent from inside the product, an admin asking how to add users in a support ticket. This is the easiest expansion to sell because the customer is often the one who raises it — your job is to make the answer “yes, here’s how” arrive before they go looking for a workaround.
Higher tier. The customer is running into a wall the current plan puts up on purpose — an API rate limit, a missing integration, a feature gated behind the next plan up. The signal is a specific action against a specific ceiling: repeated 429s from your API, a support ticket asking for something your pricing page lists as a higher-tier feature, a workflow visibly built around the absence of something you sell. This one requires you to actually watch the ceiling get hit, not wait for the customer to ask.
More usage. The product is priced on a metered dimension — API calls, seats-times-activity, storage, compute — and consumption is climbing toward or past what the current plan assumes. The signal is a usage graph with a slope, read three months running, not a single spike. A customer who blows past their limit once might have run a one-time job. A customer trending up for a quarter is a different, growing account.
Adjacent product. The customer has fully adopted the core product and their workflow now visibly reaches past its edges — exporting data to stitch it into another tool, asking support if you do X when X is a product you also sell, building a manual process around a gap your adjacent offering fills. The signal here is behavioral evidence of an unmet need next door, not a feature request for the core product.
Four paths, four distinct observables. A team that runs one script for “check in about upsell” across all four is running the wrong play against at least three of them.
| Expansion path | The signal | Who you ask | What you say |
|---|---|---|---|
| More seats | New domain login, in-product invite sent, “how do I add a user” ticket | The admin or the original buyer | ”Looks like the team’s growing into this — want me to add seats now so nobody’s locked out?” |
| Higher tier | Rate limit hit, feature-gate ticket, workaround built around a missing capability | The technical user hitting the wall | ”You’re running into the ceiling on the current plan — here’s what the next tier removes.” |
| More usage | Usage trending up for 3 consecutive months against the plan’s assumed volume | The account owner or finance contact | ”Your usage has grown past what this plan is built for — let’s move you to one sized for where you are now.” |
| Adjacent product | Manual workaround, export-and-stitch behavior, direct “do you also do X” question | Whoever surfaced the gap | ”You’re already half-building this yourself — here’s the product that finishes it.” |
Timing: At Peak Value, Never at Renewal Panic
The signal tells you which ladder to climb. Timing tells you when to offer it, and getting this wrong turns a genuine expansion into a customer who feels squeezed.
The right moment is peak realised value — the point where the customer has just gotten more out of the product than they expected, and the ask reads as “let’s make sure you can keep doing this,” not “pay us more.” A team that just shipped something faster because of your tool, an admin who just onboarded a new hire without friction, a customer who just hit a milestone your product helped them reach — these are moments of goodwill, and an expansion offer made inside one lands as help.
The wrong moment is renewal panic — the weeks before a contract lapses, when the only reason anyone is talking about money is that a date is approaching. An expansion pitch here reads as exactly what it looks like: a company trying to extract more before the customer has a chance to leave. It is also the worst moment strategically, because a customer deciding whether to renew at all is in no mood to also decide whether to pay more.
The fix is structural, not a matter of trying harder to remember: instrument the signals above so they fire independently of the contract calendar. A usage graph crossing a threshold, a rate-limit alert, a new-domain login — none of these care what month the renewal falls in, and none of them should wait for it.
The Two Ways Expansion Pricing Goes Wrong
Get the mechanics of the ladder wrong and you don’t just lose the expansion — you actively suppress the growth that would have justified it.
Punishing growth. A pricing model where crossing a usage or seat threshold triggers a sudden, large price jump teaches customers to manage the number instead of using the product. A team that sees the next tier costs three times as much for one more seat will simply not add the seat — they’ll share a login, split a workflow across two smaller accounts, or quietly cap their own usage below the line. You have not protected revenue by pricing this way. You have taught your best customers to shrink.
Seats that ration access. A per-seat model prices the thing you most want to spread — more people touching the product, more workflows running through it — as a cost the champion has to justify internally every time. The champion who fought to bring your tool in becomes the person saying no to their own colleagues who want in, because each new login is a line item they have to defend. A model that makes your champion the gatekeeper against the product’s own spread is optimizing the wrong side of the ledger.
The shape that avoids both: price increases that scale smoothly with the value received, not in cliffs; and a model, where your product allows it, that lets usage or light seats grow without friction while the bigger commitment (the core contract, the paid tier) tracks real expansion. The goal is a ladder where saying yes to more is always the path of least resistance, never a wall to negotiate around.
Expansion vs. Extraction — and How Customers Tell
Every rung on this ladder can be climbed two ways, and customers can feel the difference even when the words on the page look identical.
Expansion answers a need the customer already has, timed to a moment where they feel the value, priced so the yes is easy. The customer walks away from it having solved a real problem, and the fact that they’re now paying you more is a side effect of that, not the point of the conversation.
Extraction reaches for the same words — seats, tier, usage — but starts from your target instead of their signal: a quota to hit, a renewal date to defend against, a plan structured to force an upgrade rather than earn one. The tell is what happens when you take away the deadline. An expansion offer still makes sense with no clock attached, because it’s solving something real. An extraction offer evaporates the moment there’s no pressure behind it, because pressure was the whole mechanism.
Build this stage on the four signals, not the calendar, and you end up on the right side of that line by construction — because a signal-driven offer can only fire when the need it answers is real.
AI Earns Its Place Here
Feed the tutor your product’s actual metered dimensions — seats, API limits, usage units, adjacent products you sell — and your current pricing tiers, and ask for a signal-detection checklist: the specific, observable events under each of the four expansion paths that your product and your support tooling could realistically surface. Ask it to phrase each one as something a support agent or account manager could notice this week, not a hypothetical.
Then ask for the scripted line for each path in the table above, rewritten for your product’s actual language and your actual next-tier features — not the generic phrasing here. Push back on anything that sounds like it’s selling on your behalf rather than handing the customer something they already wanted. The tutor can help you build the ladder and the language; only your own usage data and your own pricing sheet can tell you when a specific customer is standing on the rung that’s right for them.