Here's a scenario that plays out at most B2B SaaS companies in the $15M–$60M ARR range. The Customer Success manager for one of your mid-market accounts notices something in their product dashboard: over the past six weeks, the account has expanded API call volume by 180%, promoted two new users from viewer to editor status, and started using a module they had never touched in the first year. Meanwhile, RevOps has this account on a list of renewals due in 150 days and hasn't flagged it as anything special.
The CS manager makes a note to "follow up about expansion" in their health score tool. The note sits there. The RevOps team runs their quarterly pipeline review and the account shows up as a standard renewal with a $42,000 ARR contract. Nobody connects the product data to a revenue opportunity. The renewal happens at $42,000. Expansion revenue that was sitting in plain sight goes unbooked for another cycle.
We've talked to enough CS and RevOps leaders to know this isn't a rare edge case. It's the modal outcome when CS and RevOps aren't operating from the same account intelligence at the same time.
The Structural Problem Behind the Missed Handoff
CS and RevOps teams fail to coordinate on expansion opportunities because they're optimized around different time horizons and different data sources. CS thinks in terms of health scores and quarterly business reviews — their attention is on the current state of the customer relationship. RevOps thinks in terms of renewal calendar and pipeline coverage — their attention is on what's closing in the current and next quarter.
The result is a systematic timing mismatch. When an account's product engagement starts climbing — which is typically when expansion potential is highest — that account is usually 90-180 days from renewal. CS sees the positive signal but it's not renewal season, so the conversation never escalates. By the time the account enters RevOps's active renewal window (60-90 days out), the most telling leading indicators have already played out, and the opportunity to proactively shape the expansion conversation has narrowed.
The second structural problem is data isolation. CS tools (health score platforms, CS success tooling) track product engagement signals and customer interaction logs but often don't have direct visibility into billing headroom — the gap between what the customer currently pays and what they'd pay if they fully utilized the contracted tier or added seats. RevOps has the billing and contract data but typically doesn't have a feed of product engagement metrics at the account level in the same view. The intelligence that would let you confidently say "this account is ready to expand, and they have $18,000 in headroom before they hit the next tier" requires both datasets simultaneously.
What Expansion Signals Actually Look Like Before the QBR
If you want to tighten the CS-RevOps handoff, you first need agreement on what constitutes a legitimate expansion signal — not just positive sentiment or a good health score, but product and billing evidence that correlates with actual expansion revenue.
From our analysis of expansion patterns across B2B SaaS cohorts, the signals with the strongest correlation to successful expansion within 90 days of identification are:
Feature adoption breadth increase. When an account that was using 2-3 features of your product starts regularly using 5-6, they've moved from tactical to embedded. The expansion conversation is natural because you have a use case hook — they're already using more, the upsell path is demonstrable.
Cross-team user proliferation. User counts growing from one functional team to multiple — say, from just the finance team to finance and operations — signals organizational adoption that typically precedes seat expansion. If you have visibility into which department users belong to, this is one of the cleaner indicators available.
API call volume growth at the integration layer. Accounts that start building integrations or automations around your product are investing in embedding it more deeply. That investment creates switching cost and often reveals use cases that warrant a higher-tier contract.
Support ticket profile shift. A shift from how-do-I-do-this tickets to can-you-add-this-feature tickets is a qualitative signal worth surfacing. The customer has moved from learning the product to hitting its current limits — which is the right moment to have an expansion conversation.
None of these signals alone constitutes a buy signal. It's the combination — and the trend direction over a 4-8 week window — that matters.
Building the Handoff Mechanism
The tactical fix that most teams attempt is a shared Slack channel or a weekly sync between CS and RevOps. We're not saying this doesn't help — any increase in communication improves coordination. But the people-process solution doesn't scale past a certain account volume, and it depends entirely on the CS manager remembering to mention the right accounts at the right time.
The more durable fix is a data-driven trigger system that routes expansion-ready accounts to the right queue without requiring human judgment to decide which accounts to surface. The mechanism works like this:
Define a set of expansion readiness criteria — something like "product engagement score has increased more than 40% over 45 days AND contract renewal is 60-180 days out AND billing headroom exists at the next tier." When an account meets all criteria, it triggers an alert into the RevOps pipeline view and assigns a follow-up task to the account's CS manager. The account enters the RevOps expansion calendar, not just the renewal calendar.
The critical detail is the billing headroom check. Expansion conversations fail when they happen too early in the contract cycle or when the customer is already at the ceiling of what their current use case requires. Billing headroom — the gap between current MRR and the contracted maximum or the next pricing tier — provides the revenue side of the equation. When product engagement is climbing and billing headroom exists, you have a defensible expansion case. When only one of those is true, you don't.
What RevOps Needs to Actually Act on the Signal
CS teams often complain that they flag expansion opportunities that RevOps never pursues. Part of this is prioritization — RevOps has more inbound signals than they can act on. But part of it is signal quality. A note in a health score tool that says "customer seems happy, might be ready to expand" doesn't give RevOps enough to work with.
For an expansion signal to be actionable from a RevOps perspective, it needs four things:
First, a quantified opportunity size. "Could expand" isn't useful. "Current contract is $3,200/month, next tier is $4,800/month, account has 14 users and the Growth tier allows 25" gives someone a number to put in a pipeline stage.
Second, the specific product evidence. "API call volume grew 180% over the last 6 weeks, they added 2 editor-level seats last month" gives the CS manager a factual anchor for the expansion conversation. They're not selling — they're responding to what the customer is already doing.
Third, a contact strategy. Who is the champion? Has there been an interaction in the last 30 days? If the last CS interaction was 60 days ago, a cold expansion ask is awkward. The signal should trigger the relationship maintenance touchpoint first.
Fourth, a timing recommendation. Accounts in the 60-90 day pre-renewal window are in a different urgency tier than accounts at 150 days. RevOps's bandwidth is limited — they need to know whether this is a next-week conversation or a next-quarter pipeline entry.
Without these four elements, expansion signals stay on CS's to-do list indefinitely. With them, RevOps can queue the account in the right revenue motion and give it appropriate attention.
The Measurement Problem: Attributing Expansion Revenue
One reason the CS-RevOps handoff breaks down at growing companies is attribution. CS teams whose compensation is tied to GRR (gross revenue retention) have limited incentive to hand off expansion opportunities to an AE or RevOps-led motion that gets the expansion credit. RevOps teams whose KPIs are tied to new ACV may underweight expansion because it doesn't count toward new logo pipeline.
We're not saying the attribution problem is easy to solve — it's genuinely difficult to design compensation structures that align CS and RevOps on expansion without creating perverse incentives. But teams that have successfully tightened their expansion motion almost always have some form of shared expansion ARR metric that both CS and RevOps contribute to. Even a simple arrangement — CS owns expansion accounts under a certain ARR threshold, RevOps/AE owns above it — reduces the ambiguity that causes signals to fall through the cracks.
The data infrastructure matters less than the coordination structure. The best signal routing in the world doesn't produce expansion revenue if the humans who receive the signal aren't clear on who's supposed to act on it and what a successful outcome looks like. Fix the accountability structure first, then build the signal delivery mechanism around it. Starting with tooling and hoping the coordination follows is the pattern that leaves money in accounts that were ready to expand.