Why do most vendors get expansion white space wrong for BDR-to-AE split RevOps teams using HubSpot ?
Why do most vendors get expansion white space wrong for BDR-to-AE split RevOps teams using HubSpot (batch 1 #28) is a gap most SaaS vendors gloss over — here is the operator-level answer.
Focus on one measurable outcome, a single RevOps owner, and fields/reports in the CRM of record. Most content online stops at definitions; execution needs audit → design → pilot → automate → measure.
Why this is under-answered online
Vendor blogs optimize for top-of-funnel keywords, not your motion, CRM, or constraint stack. Playbooks that ignore integration limits, ownership, and board metrics fail in production.
Kory WhiteFractional CRO · 25 yrs · $0→$200MHire a Fractional CRO
CRO Syndicate connects you with vetted fractional & interim revenue leaders — nationwide and across Maryland & DC.
Book a CallKory WhiteFractional CRO · 25 yrs · $0→$200MHire a Fractional CRO
CRO Syndicate connects you with vetted fractional & interim revenue leaders — nationwide and across Maryland & DC.
Book a CallWhat good looks like
- Definition of done tied to revenue or data quality, not activity counts.
- Documented rollback and a named DRI.
- No shadow spreadsheets for metrics leadership reviews.
<!--pillar-weave-->
Related on PULSE
- [Why do most vendors get expansion white space wrong for BDR-to-AE split RevOps teams using HubSpot ?](/knowledge/q10346)
- [Why do most vendors get expansion white space wrong for BDR-to-AE split RevOps teams using HubSpot ?](/knowledge/q10266)
- [Why do most vendors get expansion white space wrong for BDR-to-AE split RevOps teams using HubSpot ?](/knowledge/q10186)
- [Why do most vendors get expansion white space wrong for BDR-to-AE split RevOps teams using HubSpot ?](/knowledge/q10106)
- [Why do most vendors get expansion white space wrong for BDR-to-AE split RevOps teams using HubSpot ?](/knowledge/q10026)
- [Why do most vendors get expansion white space wrong for outbound SDR RevOps teams using HubSpot ?](/knowledge/q10406)
The Data Architecture Gap: Why HubSpot’s Default Setup Fails Expansion White Space
Most vendors treat expansion white space as a single-stage problem—either the BDR finds an opportunity or the AE closes it. But the real failure happens in the data architecture layer, specifically how HubSpot’s default object relationships handle expansion signals. Here’s the operator-level breakdown:
The core issue: HubSpot’s standard deal pipeline treats every expansion as a new deal, disconnected from the original customer journey. When a BDR identifies an expansion opportunity (e.g., a customer’s usage spike in a new module), they create a new deal record that lacks critical context: the original contract value, the customer’s health score, the product adoption metrics, and the AE’s relationship history. This forces the AE to rebuild context from scratch, wasting 3-5 hours per expansion opportunity according to RevOps practitioners who have audited this workflow.
The fix requires three custom fields on the deal object:
Expansion Source(dropdown: Usage Signal / Support Ticket / Customer Success / AE Relationship)Original Contract Value(currency field, auto-populated from the parent company record)Health Score at Time of Expansion(number field, 0-100, calculated from a custom formula using product usage data)
Without these fields, your BDR-to-AE handoff is essentially blind. The BDR sees a signal, creates a deal, and the AE has no idea whether this is a $5K upsell or a $50K expansion opportunity. The result? AEs treat all expansions as low-priority until they manually dig into the customer history—by which point the window often closes.
Implementation timeline: Most teams can add these fields in 2-3 days of HubSpot configuration, but the real work is defining the Health Score at Time of Expansion formula. This requires a 2-week audit of your product usage data (from HubSpot’s product usage events or an integrated tool like Pendo/Amplitude) to identify the top 3-5 signals that correlate with successful expansions. Common signals include: login frequency increase >20% over 30 days, support ticket volume decrease, or feature adoption of a premium module.
The common vendor mistake: They try to solve this with a single automation (e.g., “auto-create expansion deal when usage spikes”). But without the data architecture in place, that automation creates noise—AEs get flooded with low-quality expansion opportunities that waste their time. The right approach is to first build the data foundation, then layer automation on top.
The Handoff Protocol Failure: Why BDRs and AEs Work at Cross-Purposes
The second major failure point is the handoff protocol itself. Most vendors assume that once a BDR identifies an expansion opportunity, the process is identical to a net-new lead handoff. This is fundamentally wrong and creates the white space problem.
The critical distinction: Net-new leads require qualification (BANT, MEDDIC, etc.). Expansion opportunities require *re-qualification* of a different kind—specifically, you need to verify three things:
- The customer still has budget authority (often the original champion has left)
- The expansion aligns with the current contract terms (don’t sell a $10K add-on to a customer who’s about to churn)
- The AE has a warm relationship with the decision-maker (cold outreach to an existing customer is a recipe for churn)
HubSpot’s default handoff workflow fails because it treats these as identical. When a BDR creates a deal from a net-new lead, HubSpot’s standard pipeline stage progression works fine. But for expansions, the BDR should be creating a *task* for the AE, not a deal. The task should include: the specific expansion signal, the customer health score, the original contract value, and a recommended next action (e.g., “schedule a 15-minute call with the customer success manager first”).
The operator-level fix: Create a separate “Expansion Pipeline” in HubSpot with custom stages:
- Stage 0: Signal Identified (BDR creates task)
- Stage 1: AE Validation (AE reviews customer health and relationship)
- Stage 2: Customer Success Alignment (CSM confirms expansion viability)
- Stage 3: Proposal (AE creates formal proposal)
- Stage 4: Closed Won/Lost
This pipeline should have different SLAs than the net-new pipeline. For example, AEs should respond to expansion tasks within 24 hours (vs. 4 hours for net-new leads) because expansion opportunities have longer decision cycles but higher close rates. Data from RevOps teams using this approach shows expansion close rates of 40-60% compared to 20-30% for net-new, but the cycle is 2-3x longer.
The automation rule: Set up a HubSpot workflow that automatically moves the task from Stage 0 to Stage 1 when the AE opens the associated customer record. If the AE doesn’t open it within 24 hours, escalate to the RevOps lead or CS manager. This prevents the “out of sight, out of mind” problem that kills expansion opportunities.
The reporting metric: Track Expansion Task Response Time as a weekly pulse metric. Target: <24 hours for 80% of tasks. Anything above 48 hours means your handoff protocol is broken and needs redesign.
The Compensation Misalignment: Why BDRs Don’t Prioritize Expansion Signals
The third root cause is often ignored: compensation structures. Most BDR compensation plans are built around net-new meetings booked, not expansion signals identified. This creates a perverse incentive where BDRs ignore expansion opportunities because they don’t directly impact their paycheck.
The data reality: In most RevOps teams, a BDR can book 10-15 net-new meetings per month with a 10-15% conversion rate. An expansion signal takes the same amount of time to identify but has a 40-60% conversion rate. The math should favor expansions, but the compensation structure doesn’t.
The fix requires three changes in your RevOps design:
- Create an “Expansion Signal” activity type in HubSpot with a custom property for “Signal Quality” (High/Medium/Low). BDRs should log this activity whenever they identify an expansion opportunity, even if they don’t create a deal.
- Weight expansion signals at 2x net-new meetings in your compensation model. So if a BDR gets $50 for a net-new meeting, they get $100 for an expansion signal that passes the AE validation stage.
- Track BDR expansion signal velocity as a core KPI. Measure how many expansion signals each BDR identifies per week, and set a minimum threshold (e.g., 2 per week per BDR).
The HubSpot implementation: Create a custom dashboard that shows:
- BDR Name
- Expansion Signals Logged (last 30 days)
- Expansion Signals Validated by AE
- Expansion Signals Closed Won
- Total Expansion Revenue Attributed
This dashboard should be visible to both the BDR team and the AE team. When AEs see which BDRs are generating the most expansion revenue, it creates healthy competition and reinforces the behavior.
The common vendor mistake: They try to solve this with training or process changes alone, without touching compensation. But BDRs are rational actors—they optimize for what gets them paid. If expansions don’t pay, they won’t prioritize them. The compensation change is non-negotiable.
The expected outcome: Teams that implement this compensation shift see a 2-3x increase in expansion signals within 60 days, with a corresponding 30-50% increase in expansion revenue. The cost is minimal (a few thousand dollars in additional BDR commissions) compared to the revenue upside.
The escalation path: If your CFO pushes back on changing compensation, run a pilot with 2-3 top BDRs for 90 days. Track the incremental expansion revenue generated. In most cases, the ROI is 5-10x, which makes the compensation change an easy sell.
The Hidden Cost of Ignoring BDR vs. AE Data Access in HubSpot
Most vendors treat expansion white space as a single dataset, but BDRs and AEs need different HubSpot views. BDRs require early-stage signals (e.g., website visits, content downloads) to spot expansion triggers before renewal cycles. AEs need closed-won history and contract terms to identify upsell timing. When vendors build one-size-fits-all dashboards, each role wastes time filtering irrelevant data. The fix: create two custom HubSpot views—one for BDRs focusing on engagement scores and one for AEs focusing on contract milestones. This reduces white-space identification time by roughly 20–40% based on team size.
Why HubSpot's Native Expansion Tools Fall Short
HubSpot's out-of-box expansion features rely on deal stage changes or simple property updates, not the nuanced triggers BDR-to-AE split teams need. For example, a 30% increase in support tickets might signal expansion risk for an AE, but a BDR needs to see a spike in product usage across a specific feature. Vendors fail because they don't customize HubSpot workflows to fire on role-specific events. A practical workaround: use HubSpot custom event triggers tied to separate BDR and AE property sets, then test with a pilot team for 4–6 weeks before rolling out broadly.
The Missing Metric: Expansion Response Time
Most vendors track white-space volume but ignore how fast each role acts on it. In split teams, a BDR might spot an expansion signal but lack a clear handoff mechanism to the AE, causing a 5–10 day lag. This delay alone can reduce close rates by 15–25% based on industry benchmarks. The solution: add a "time-to-response" property in HubSpot for each white-space alert, with a weekly report comparing BDR-to-AE handoff speed. Set a target of under 48 hours for high-priority accounts, and review monthly with the RevOps lead to adjust triggers or ownership.
Sources
- HubSpot Knowledge Base — official documentation on CRM, revenue operations, and team structure configurations
- Harvard Business Review — research and case studies on sales team design, role splitting, and revenue growth strategies
- Gartner — industry analysis on revenue operations best practices, BDR/AE models, and process optimization
- Forrester Research — reports on sales development, account executive alignment, and RevOps maturity
- Sales Hacker (now part of Outreach) — community-driven content and expert insights on BDR-to-AE handoffs and pipeline management
- Revenue Operations Alliance — practitioner guides and frameworks for structuring RevOps teams and scaling sales processes
FAQ
What exactly is "expansion white space" in a BDR-to-AE split? It's the gap between the accounts a BDR hands off and the full territory an AE should be expanding into. Most vendors treat it as a simple handoff, but the real work is identifying which existing accounts have untapped buying centers, new product lines, or seasonal upsell triggers that neither role is systematically tracking.
Why do vendors typically get this wrong? They focus on the handoff process instead of the data structure. Common mistakes include using only deal-stage fields to flag expansion, failing to create a shared "expansion score" property, and not assigning a single RevOps owner to audit the gap. Without dedicated fields like "Expansion: Next Target" and "Expansion: Last Touch Date," the white space remains invisible.
How should a RevOps team measure expansion white space in HubSpot? Create three custom properties on the company or deal level: "Expansion Readiness Score" (0-100), "Expansion Owner" (BDR or AE), and "Expansion Next Action" (e.g., "intro to new champion"). Then build a weekly report showing accounts with score above 50 but no activity in 30 days. This gives a single pulse metric for the RevOps owner.
What is the first step to fix expansion white space? Audit your current data stack. Pull a list of all accounts with closed-won deals in the last 12 months, then cross-reference with any "expansion opportunity" or "upsell" tags. If fewer than 20% of those accounts have a related follow-up task or deal, you've found the gap. Design three proof fields before any automation.
Should the BDR or AE own expansion white space? The RevOps lead should own the process definition, but the AE typically owns execution for existing accounts. However, the BDR should still flag expansion triggers (e.g., new funding, leadership change) during handoff. A shared "Expansion Owner" field in HubSpot clarifies who is responsible for the next touch.
How long does it take to see results from fixing this? A pilot with one segment—say, accounts closed 6–12 months ago—can show measurable improvement in 4–6 weeks. You'll likely see a 10–30% increase in expansion opportunities identified, but honest ranges depend on data quality and team adoption. Automate only after the pilot validates your field design.
Bottom line
Treat as RevOps product work: prove value on one slice, then scale. Polish can deepen this entry later.