The Expansion Playbook Your CRO Doesn’t Want You to Run
The "revenue era of CS" is destroying the one thing that actually drives revenue.
The “revenue era of CS” movement has a pitch you’ve probably heard by now: CSMs should carry quotas. Expansion is everyone’s job. Customer Success is a revenue function.
It sounds progressive. It sounds like alignment. And it’s quietly destroying the one thing that makes CS effective.
Trust.
The moment a customer perceives their CSM as a salesperson, the relationship changes fundamentally. Technical buyers are especially attuned to this. Engineers have been burned by vendor relationships that prioritized extraction over value. They can smell a pitch from three slides away, and once they do, you’ve lost something you can’t get back.
But here’s the part nobody says out loud: the best CS orgs drive more expansion revenue than sales-led models, not less. They just do it differently.
The Problem With Sales-Led Expansion
The standard playbook goes like this: CSM has a good relationship with the customer, so CSM should leverage that relationship to drive upsells. QBR becomes the venue for the pitch. Renewal becomes the forcing function for the expansion conversation.
This logic is backwards.
You’re converting a trust asset into a transaction, and you can only do that once. The champion, who used to be candid about what was broken, now hedges because they know the CSM has a number to hit. The engineering lead who used to pull you into architecture discussions stops inviting you because the last three conversations ended with a pricing conversation.
The revenue shows up short-term. The trust doesn’t come back.
I’ve watched this scenario play out at dozens of companies. The teams that grafted sales motions onto CS relationships saw an initial bump in expansion revenue followed by a slow, steady decline in NRR. Teams that took a different approach, one rooted in technical depth, consistently outperformed.
The Framework: Architecture-Led Expansion (ALE)
Expansion in technical products follows a predictable pattern: deeper integration leads to more use cases, more use cases lead to more users, more users create more value, and more value creates natural commercial expansion.
Your job is to accelerate that progression. Not to pitch upgrades.
ALE has four components:
1. Map the Whitespace Architecturally
Most expansion conversations start with "What else can we sell them?” ALE starts with "What does their full technical environment look like, and where else could our product add value they haven’t considered?”
This is a fundamentally different lens. You’re not looking at your product catalog and matching features to a customer. You’re looking at their architecture and identifying gaps where your product is the natural solution. The difference is subtle but critical: one feels like selling, the other feels like consulting.
At GitHub, the CSMs who drove the most expansion revenue were the ones who could diagram a customer’s entire development workflow and identify the friction points our platform could eliminate. They never pitched. They solved problems that happened to require additional capabilities.
2. Plant Seeds Through Problem-Solving
When a customer raises a challenge in a TVR or a support interaction, solve it. And if the solution naturally involves capabilities beyond their current plan, demonstrate rather than sell.
“We actually have a way to handle that” is the most powerful expansion sentence in CS. It positions the capability as a solution to their problem, not a product you’re pushing. The customer experiences it as help, not a pitch.
The key word is “naturally”. If you’re contorting every support interaction into an upsell opportunity, you’re doing sales-led expansion with extra steps. ALE only works when the connection between their problem and the additional capability is genuine.
3. Enable the Champion to Sell Internally
Your technical champion already believes in the product. They don’t need to be convinced. They need ammunition.
The Champion Enablement Package is the most underused tool in CS. Instead of you selling to their leadership, you equip your champion to make the case internally. This works for three reasons:
Credibility: An internal advocate is more trusted than an external vendor.
Context: They know the political landscape, the budget cycles, and the objections.
Ownership: When they champion the expansion, they own the outcome, which means they’re invested in making it successful.
You have to build the package around their narrative, not yours. Architecture diagrams should show the current vs. proposed state. Three talking points framed around their business priorities. They fill in a simple ROI framework with their own numbers. Anticipate objections with suggested responses. Map a timeline to their budget cycle.
Every component should be something they can present as their analysis, not something that looks like it came from your marketing team.
4. Trigger-Based Expansion Conversations
Certain technical milestones naturally create expansion opportunities. Hitting usage thresholds. Completing initial integration. Adding a new team. Architectural reviews. Production deployments that change the scope of the implementation.
Consider incorporating these triggers into your operating model rather than depending on CSM intuition or renewal timelines.
The distinction between vanity signals and real expansion signals is critical. A green health score tells you the customer is happy. Expansion signals tell you they’re ready. Most CS teams only instrument the first metric. ALE requires you to instrument both.
The Two Failure Modes
Failure Mode 1: Stealth Sales
This scenario is where a CS team adopts ALE language but keeps running a sales-led motion underneath. The CSM “maps the whitespace,” but the whitespace map is really just a territory plan. They “enable the champion,” but the enablement package is a sales deck with the logo removed.
Technical buyers see through the charade immediately. If your champion enablement package has your product name in the header and your competitive positioning in the talking points, it’s not enablement. It’s a brochure.
The test: Could your champion present this material without mentioning your company name and have it still be valuable? If not, it’s not enablement.
Failure Mode 2: Passive Waiting
The opposite failure. The CS team is so afraid of being perceived as sales that they never proactively surface expansion opportunities. They wait for the customer to ask. They wait for renewal. They wait for the champion to figure out on their own that more capabilities exist.
ALE isn’t passive. It’s proactive problem-solving that creates natural pull. You’re solving problems, demonstrating capabilities, and equipping champions. The expansion conversation is a consequence of excellent technical partnership, not an agenda item you’re avoiding.
The One Metric That Matters
If you adopt ALE, the metric you track changes.
Sales-led expansion tracks expansion revenue per CSM, which is a number that incentivizes CSMs to push. ALE tracks champion-initiated expansion rate, the percentage of expansion deals where the customer reached out first or the champion drove the internal business case.
A healthy ALE motion should produce a champion-initiated rate above 60%. If most of your expansion is still CSM-initiated, you haven’t shifted the model, you’ve just relabeled it.
The Prompt Library
Two prompts and one agent workflow to operationalize ALE in your CS org.
Prompt 1: Whitespace Analyzer
Analyze this customer's current product usage and technical environment to identify expansion opportunities that are architecturally natural — not forced upsells.
Current state:
- Products/modules currently using: {list}
- Current usage volume and trends: {data}
- Known technical environment: {stack}
- Teams currently using the product: {teams}
- Integrations in place: {integrations}
- Problems they've raised in the last 6 months: {support themes}
Identify:
1. Adjacent use cases where the product could solve problems they're currently handling with other tools or manual processes
2. Teams or departments that would benefit but aren't currently using the product
3. Technical milestones they're approaching that naturally create expansion conversations
4. The single highest-probability expansion opportunity and a recommended approach that feels helpful, not salesy
Prompt 2: Champion Enablement Package Builder
My technical champion at {customer_name} wants to expand our product to {new use case/team/capability}. They need to make an internal business case to their leadership.
Context:
- Champion's role: {title}
- Current deployment: {what they're using today}
- Proposed expansion: {what they want to add}
- Their leadership's likely concerns: {concerns}
- Budget cycle timing: {when}
Create a champion enablement package:
1. A one-page architecture diagram description showing current state vs. proposed state
2. Three talking points framed around their business priorities (not our product features)
3. A simple ROI framework they can fill in with their own numbers
4. Anticipated objections and suggested responses
5. A recommended timeline that aligns with their budget cycle
Agent Workflow: Expansion Signal Monitor
You are monitoring a portfolio of accounts for natural expansion signals. Review the following data weekly and flag accounts showing expansion readiness.
Portfolio data:
{structured account data including usage, support, engagement}
Expansion signals to detect:
- Usage approaching tier thresholds (>80% of current plan)
- New teams or users being added organically
- Support questions about capabilities not in their current plan
- Integration with new tools that suggest evolving use cases
- Champion promotions or role changes that increase their influence
- Positive references to the product in external channels
For each flagged account, specify:
1. Which signal(s) triggered the flag
2. Recommended expansion conversation approach
3. Timing recommendation (act now vs. nurture)
4. Whether to engage directly or equip the champion
This is Post 4 of a 5-part series: Rebuilding Customer Success. Next up: the scaling problem nobody wants to talk about and why the answer isn’t more headcount.
If these frameworks and prompts are useful, subscribe for the final post and the complete prompt library that comes with it.