When pipeline data is messy, /sales-ops-analyst designs dashboards, lead routing, and commission models, so you can trust the numbers your team sees. — Claude Skill
A Claude Skill for Claude Code by Nick Jensen — run /sales-ops-analyst in Claude·Updated
Design CRM workflows, dashboards, lead routing, and commission plans.
- CRM workflow and automation rule design
- Pipeline analytics dashboard specifications
- Lead routing and territory assignment logic
- Commission and quota model calculation
- Salesforce and HubSpot field mapping
Who this is for
What it does
Run /sales-ops-analyst with your team structure and segments to get round-robin or weighted routing logic ready to implement in Salesforce or HubSpot.
Use /sales-ops-analyst to generate a dashboard spec with stage conversion rates, velocity metrics, and forecast accuracy — includes chart types and data sources.
Feed /sales-ops-analyst your comp structure and quota targets — it returns a commission calculator with accelerators, clawbacks, and split-deal logic.
Paste /sales-ops-analyst your field list and it flags missing required fields, stale records criteria, and deduplication rules for 90%+ data accuracy.
How it works
Describe your sales ops challenge: CRM platform, team size, current pain (routing, reporting, commissions, etc.).
The skill analyzes the scenario and designs a solution spec with rules, formulas, or dashboard layouts.
It outputs implementation-ready specs including field mappings, automation triggers, and calculation logic.
Apply the spec in your CRM or share with your admin for implementation.
Example
We have 8 AEs across 3 territories (West, Central, East). Leads currently go to a shared queue and reps cherry-pick. Need automated routing in HubSpot based on company size and region.
Rule 1: Match company state to territory (West: CA/WA/OR/AZ, Central: TX/IL/CO/MN, East: NY/MA/FL/GA). Rule 2: Within territory, round-robin by last-assigned timestamp. Rule 3: Enterprise (500+ employees) routes to senior AE in territory. Rule 4: Unmatched region defaults to Central.
Create workflow: Trigger = new contact with Lifecycle Stage = Lead. Branch 1: Company State in [West list] → assign to West rotation. Use HubSpot owner rotation action. Set SLA: 4-hour first touch.
Track: lead-to-first-touch time by territory, lead acceptance rate, territory win rate delta. Alert if any territory response time exceeds 4 hours for 3 consecutive days.
Metrics this improves
Works with
Sales Ops Analyst
Strategic sales operations expertise for revenue teams — from CRM architecture and pipeline analytics to territory design and commission automation.
Philosophy
Great sales ops isn't about more data. It's about actionable insights that accelerate revenue.
The best sales operations teams:
- Enable, don't police — Make it easier for reps to do the right thing
- Measure what matters — Vanity metrics create vanity pipeline
- Automate the mundane — Free reps to sell, not update fields
- Build for scale — Today's workaround is tomorrow's technical debt
How This Skill Works
When invoked, apply the guidelines in rules/ organized by:
crm-*— CRM architecture, data models, hygiene practicespipeline-*— Pipeline analytics, stage definitions, velocity metricsdashboard-*— Sales reporting, metrics, visualizationsprocess-*— Automation, workflows, approval chainsrouting-*— Lead routing, assignment rules, territory designcommission-*— Comp plans, calculation logic, trackingdata-*— Data quality, deduplication, enrichmentforecast-*— Forecasting methodologies, models, accuracy
Core Frameworks
The RevOps Data Hierarchy
| Level | What It Measures | Used By | Update Frequency |
|---|---|---|---|
| Activity | Calls, emails, meetings | Reps, managers | Real-time |
| Opportunity | Deal progress, value | Reps, managers | Daily |
| Pipeline | Forecast, velocity | Directors, execs | Weekly |
| Revenue | Bookings, ARR, churn | C-suite, board | Monthly/Quarterly |
Pipeline Velocity Formula
Pipeline Velocity = (# Opportunities × Win Rate × Avg Deal Size) / Sales Cycle Length
Example:
(100 opps × 25% × $50K) / 90 days = $13,889/day potential revenue
The Sales Tech Stack
┌─────────────────────────────────────────────────────────────┐
│ ANALYTICS LAYER │
│ (BI Tools: Tableau, Looker, Power BI, Salesforce Reports) │
├─────────────────────────────────────────────────────────────┤
│ CRM LAYER │
│ (Salesforce, HubSpot, Dynamics 365) │
├──────────────────┬──────────────────┬───────────────────────┤
│ ENGAGEMENT │ INTELLIGENCE │ ENRICHMENT │
│ Outreach, Salesloft│ Gong, Chorus │ ZoomInfo, Clearbit │
├──────────────────┴──────────────────┴───────────────────────┤
│ DATA LAYER │
│ (Integrations, ETL, Data Warehouse, CDP) │
└─────────────────────────────────────────────────────────────┘
Lead Scoring Matrix
| Signal Type | Examples | Weight |
|---|---|---|
| Fit (firmographic) | Industry, company size, tech stack | 40% |
| Engagement (behavioral) | Website visits, content downloads, email opens | 35% |
| Intent (buying signals) | Pricing page views, demo requests, competitor research | 25% |
Territory Design Principles
┌─────────────────┐
│ BALANCED │
│ OPPORTUNITY │
└────────┬────────┘
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Account │ │ Revenue │ │ Travel │
│ Volume │ │Potential│ │ Load │
└─────────┘ └─────────┘ └─────────┘
Key Metrics Overview
| Category | Metric | Target Range | Red Flag |
|---|---|---|---|
| Activity | Meetings/week/rep | 10-15 | <5 |
| Pipeline | Coverage ratio | 3-4x | <2x |
| Velocity | Avg sales cycle | Industry dependent | Growing |
| Quality | Win rate | 20-30% | <15% or >50% |
| Forecast | Accuracy | ±10% | >25% variance |
| Data | Duplicate rate | <5% | >10% |
Anti-Patterns
- Field proliferation — Adding fields without removing unused ones
- Report graveyard — Dashboards no one looks at
- Process theater — Mandatory updates that don't drive action
- Excel dependency — Critical processes outside the CRM
- Garbage in, garbage out — No data quality governance
- Over-automation — Automating bad processes faster
- Single point of failure — Tribal knowledge in one person's head
- Metric gaming — Optimizing for the number, not the outcome
Reference documents
title: Section Organization
1. CRM Management (crm)
Impact: CRITICAL Description: CRM architecture, object relationships, data models, and hygiene practices. The foundation everything else depends on.
2. Pipeline Analytics (pipeline)
Impact: CRITICAL Description: Stage definitions, velocity metrics, conversion tracking, and pipeline health monitoring. Your window into revenue predictability.
3. Sales Dashboards (dashboard)
Impact: HIGH Description: Metric design, visualization best practices, report hierarchies, and actionable insights that drive behavior.
4. Process Automation (process)
Impact: HIGH Description: Workflow automation, approval chains, notification systems, and eliminating manual data entry.
5. Lead Routing (routing)
Impact: HIGH Description: Assignment rules, round-robin logic, territory-based routing, and SLA monitoring for speed-to-lead.
6. Territory Design (territory)
Impact: MEDIUM-HIGH Description: Territory carving, balanced coverage, account assignment, and quota alignment.
7. Commission Tracking (commission)
Impact: MEDIUM-HIGH Description: Comp plan modeling, commission calculation, dispute resolution, and payout automation.
8. Data Quality (data)
Impact: HIGH Description: Deduplication, enrichment, validation rules, and ongoing data governance programs.
9. Sales Forecasting (forecast)
Impact: CRITICAL Description: Forecasting methodologies, AI/ML models, commit accuracy, and board-level reporting.
title: Commission Calculation & Tracking impact: MEDIUM-HIGH tags: commission, compensation, tracking, spiffs, accelerators
Commission Calculation & Tracking
Impact: MEDIUM-HIGH
Reps trust you with their paycheck. Commission accuracy builds trust; errors destroy it. Clear rules drive behavior; ambiguous rules create disputes.
Commission Plan Components
┌─────────────────────────────────────────────────────────────┐
│ TOTAL COMPENSATION │
├─────────────────────────────────────────────────────────────┤
│ │
│ BASE SALARY VARIABLE (OTE) BONUSES │
│ 60% 40% (Additional) │
│ │
│ Fixed pay Commission on SPIFFs, MBOs, │
│ quota attainment team bonuses │
│ │
└─────────────────────────────────────────────────────────────┘
Standard Commission Structures
| Structure | How It Works | Best For |
|---|---|---|
| Linear | Fixed % on all revenue | Simple, predictable |
| Tiered | % increases at thresholds | Reward overperformance |
| Accelerators | Higher % above quota | Drive quota attainment |
| Decelerators | Lower % below threshold | Prevent sandbagging |
| Uncapped | No maximum commission | Motivate top performers |
| Capped | Maximum payout limit | Budget predictability |
Commission Calculation Example
Plan Structure:
Base Salary: $75,000
OTE: $150,000 (50/50 split)
Variable Target: $75,000
Quota: $1,000,000
Rate Structure:
- 0-80% quota: 5% commission rate
- 80-100% quota: 7.5% commission rate
- 100-120% quota: 10% commission rate (1.33x accelerator)
- >120% quota: 12% commission rate (1.6x accelerator)
Calculation at $1,200,000 (120% attainment):
Tier 1: $0 - $800K (80%) = $800,000 × 5% = $40,000
Tier 2: $800K - $1M (80-100%) = $200,000 × 7.5% = $15,000
Tier 3: $1M - $1.2M (100-120%) = $200,000 × 10% = $20,000
─────────────────────────
Total Commission: = $75,000
At 120% attainment, rep earns $75K (100% of variable target)
Total Comp: $75K base + $75K commission = $150K (exactly OTE)
Commission Tracking Dashboard
┌────────────────────────────────────────────────────────────┐
│ COMMISSION TRACKING - Q1 2025 │
├────────────────────────────────────────────────────────────┤
│ Rep: Sarah Johnson │
│ Quota: $250,000 Closed: $287,500 (115%) │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Deal Amount Rate Commission Status │ │
│ ├────────────────────────────────────────────────────────┤ │
│ │ Acme Corp $85,000 7.5% $6,375 Paid │ │
│ │ TechStart Inc $62,500 7.5% $4,688 Paid │ │
│ │ BigCo LLC $95,000 10% $9,500 Pending │ │
│ │ Startup XYZ $45,000 10% $4,500 Pending │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ Total Earned: $25,063 │
│ Paid to Date: $11,063 │
│ Pending: $14,000 (pays Feb 15) │
└────────────────────────────────────────────────────────────┘
Commission Rules Matrix
| Scenario | Rule | Example |
|---|---|---|
| Multi-year deal | Commission on Year 1 only OR amortized | 3-year $300K = $100K commissionable |
| Discount >20% | Manager approval required | Standard rate still applies |
| Churned within 90 days | Clawback provision | Full commission returned |
| Split deal | Defined % by role | AE 60% / SDR 40% |
| Renewal | Lower rate (50% of new) | $50K renewal = $25K effective |
| Expansion | Full rate or discounted | Upsell treated as new business |
| Professional services | Excluded or reduced | Services revenue at 25% rate |
Deal Split Scenarios
Standard Split Configuration:
New Business Deal:
├── AE (Closer): 100% OR split with SDR
├── SDR (Sourced): 20-30% of AE rate if sourced
└── SE (Supported): SPIFFs only, not commission
Expansion Deal:
├── AE (Closer): 60%
├── CSM (Owned account): 40%
└── SDR: 0% (no sourcing needed)
Partner Deal:
├── AE (Closed): 80%
├── Partner Manager: 20%
└── SDR: 0%
Commission Calculation Code
# Commission calculation engine
class CommissionCalculator:
def __init__(self, plan):
self.tiers = plan['tiers'] # [(threshold_pct, rate), ...]
self.quota = plan['quota']
def calculate(self, revenue):
attainment = revenue / self.quota
commission = 0
remaining_revenue = revenue
for i, (threshold, rate) in enumerate(self.tiers):
tier_ceiling = self.quota * threshold
if i == 0:
tier_floor = 0
else:
tier_floor = self.quota * self.tiers[i-1][0]
tier_revenue = min(remaining_revenue, tier_ceiling - tier_floor)
tier_revenue = max(0, tier_revenue)
commission += tier_revenue * rate
remaining_revenue -= tier_revenue
if remaining_revenue <= 0:
break
# Handle any revenue above last tier
if remaining_revenue > 0:
commission += remaining_revenue * self.tiers[-1][1]
return commission
# Example usage
plan = {
'quota': 1000000,
'tiers': [
(0.80, 0.05), # 0-80%: 5%
(1.00, 0.075), # 80-100%: 7.5%
(1.20, 0.10), # 100-120%: 10%
(float('inf'), 0.12) # >120%: 12%
]
}
calc = CommissionCalculator(plan)
print(calc.calculate(1200000)) # $75,000
SPIFF Program Design
| SPIFF Type | Trigger | Payout | Duration |
|---|---|---|---|
| Product Launch | Close new product deal | $500-$2,000 | 90 days |
| Competitive Win | Displace named competitor | $1,000 | Ongoing |
| Multi-Year | Close 2+ year deal | 10% bonus | Ongoing |
| Fast Close | Close within 30 days | $250 | Quarterly |
| New Logo | First deal with company | $500 | Ongoing |
Commission Dispute Resolution
Dispute Process:
1. Rep submits dispute via form
├── Deal ID
├── Expected commission
├── Actual commission
└── Reason for dispute
2. Sales Ops review (48 hours)
├── Verify deal data
├── Check commission rules
└── Calculate correct amount
3. Resolution
├── If error found → Adjust + apologize
├── If rules unclear → Escalate to VP
└── If correct → Explain with documentation
4. Communication
└── Document decision in writing
Commission Technology Stack
| Tool | Best For | Complexity |
|---|---|---|
| CaptivateIQ | Mid-market, complex plans | Medium |
| Xactly | Enterprise, full suite | High |
| Spiff | SMB, simple plans | Low |
| Performio | Mid-market | Medium |
| Excel | Startups, <20 reps | Low |
| Custom build | Unique requirements | High |
Anti-Patterns
- Unclear rules — "Manager discretion" on important items
- Retroactive changes — Changing rules mid-quarter
- Delayed payment — Commission paid >30 days after close
- Manual calculation — Spreadsheet errors erode trust
- No visibility — Reps can't see their own calculations
- Clawback abuse — Excessive or unclear clawback policies
- Cap on overperformance — Kills motivation for top reps
- Impossible quotas — Setting reps up to fail
title: CRM Architecture & Data Model impact: CRITICAL tags: crm, architecture, data-model, salesforce, hubspot
CRM Architecture & Data Model
Impact: CRITICAL
Your CRM data model determines what questions you can answer. Get the architecture right, and everything else becomes possible.
Core Object Relationships
┌─────────────────────────────────────────────────────────────────┐
│ ACCOUNT │
│ (Company record - single source of truth for org data) │
└───────────────────────────────┬─────────────────────────────────┘
│
┌──────────────────────┼──────────────────────┐
│ │ │
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ CONTACT │ │ LEAD │ │ OPP │
│(Converted│◄─────────│(Pre- │ │(Deal in │
│ leads) │ Convert │qualified)│ │progress)│
└─────────┘ └─────────┘ └─────────┘
│ │
│ │
└──────────────► ACTIVITIES ◄────────────────┘
(Calls, emails, meetings)
Object Design Principles
| Principle | Good Practice | Bad Practice |
|---|---|---|
| Single source of truth | Account holds company data | Duplicating company name on every contact |
| Minimal custom objects | Use standard objects when possible | Custom object for every process |
| Clear ownership | One owner per record | Multiple ownership fields |
| Audit trail | Created/Modified fields preserved | Overwriting historical data |
Field Design Guidelines
Do This:
Field: Annual_Revenue__c
Type: Currency
Required: No
Help Text: "Company annual revenue in USD. Source: ZoomInfo or company disclosure."
Validation: Must be >= 0
Not This:
Field: Revenue
Type: Text (arbitrary format)
Required: Yes (blocks record creation)
Help Text: None
Validation: None (accepts "~5M" or "$5,000,000" or "5000000")
Standard vs Custom Fields
| Use Standard Fields For | Use Custom Fields For |
|---|---|
| Name, email, phone | Industry-specific attributes |
| Address, website | Calculated/derived values |
| Owner, created date | Integration mappings |
| Stage, amount, close date | Business-specific processes |
Record Type Strategy
When to use Record Types:
- Different sales processes (New Business vs Expansion)
- Different page layouts needed
- Different picklist values by type
- Reporting segmentation requirements
When NOT to use Record Types:
- Just for filtering (use fields instead)
- Fewer than 100 records of a type
- No process differences
Good Example: Clean Data Model
Account
├── Name (Standard)
├── Industry (Standard)
├── Annual_Revenue__c (Currency)
├── Employee_Count__c (Number)
├── ICP_Score__c (Formula: calculated)
├── Owner (Lookup to User)
└── Account_Tier__c (Picklist: Enterprise/Mid-Market/SMB)
Opportunity
├── Name (Standard)
├── Account (Lookup - required)
├── Stage (Standard picklist)
├── Amount (Standard currency)
├── Close_Date (Standard date)
├── Primary_Contact__c (Lookup to Contact)
├── Loss_Reason__c (Picklist - required if Closed Lost)
└── Competition__c (Multi-select picklist)
Bad Example: Messy Data Model
Opportunity (Problematic)
├── Account_Name__c (Text - duplicates Account.Name)
├── Account_Industry__c (Text - duplicates Account.Industry)
├── Contact_Email__c (Text - should be lookup)
├── Stage__c (Text - should be picklist)
├── deal_size (Text - should be Currency)
├── Expected_Close (Text - should be Date)
├── won_lost (Checkbox - conflicts with Stage)
└── notes_misc_other_info (Long text - catch-all field)
Data Model Audit Checklist
| Check | Pass Criteria |
|---|---|
| No duplicate data across objects | Company data lives on Account only |
| Lookups instead of text references | Related records use relationship fields |
| Consistent naming conventions | All custom fields use Field_Name__c format |
| Required fields are truly required | Won't block legitimate record creation |
| Formula fields for derived values | No manual calculation required |
| Picklists have valid values only | No "Other" that's used 50% of the time |
Integration Field Strategy
Always create dedicated fields for integration data:
Integration Fields (read-only to users):
├── ZoomInfo_ID__c
├── ZoomInfo_Last_Updated__c
├── Outreach_Sequence_Status__c
├── Gong_Last_Call_Date__c
└── Marketing_Attribution_Source__c
Anti-Patterns
- Field sprawl — Creating new fields without auditing existing ones
- Text field abuse — Using text for dates, currencies, lookups
- Required field overload — Making everything required blocks adoption
- Lookup vs Master-Detail confusion — Wrong relationship type causes data issues
- No naming convention —
revenue,Revenue__c,Annual_Rev,ACVall meaning the same thing - Catch-all fields — "Notes" or "Other Info" fields become data graveyards
title: Sales Dashboards & Metrics impact: HIGH tags: dashboard, metrics, reporting, analytics, visualization
Sales Dashboards & Metrics
Impact: HIGH
A great dashboard answers questions before they're asked. It drives behavior, not just measurement.
Dashboard Design Hierarchy
┌─────────────────────────────────────────────────────────────┐
│ EXECUTIVE DASHBOARD │
│ Monthly/Quarterly • Revenue, ARR, Pipeline, Forecast │
│ Audience: C-suite, Board │
├─────────────────────────────────────────────────────────────┤
│ MANAGEMENT DASHBOARD │
│ Weekly • Team performance, Pipeline health, Forecast │
│ Audience: VPs, Directors │
├─────────────────────────────────────────────────────────────┤
│ TEAM DASHBOARD │
│ Daily • Activity metrics, Open opps, Tasks due │
│ Audience: Managers, Team leads │
├─────────────────────────────────────────────────────────────┤
│ REP DASHBOARD │
│ Real-time • My pipeline, My quota, My activities │
│ Audience: Individual reps │
└─────────────────────────────────────────────────────────────┘
Key Metrics by Role
| Role | Primary Metrics | Secondary Metrics |
|---|---|---|
| SDR/BDR | Meetings booked, Qualified opps | Activities, Response rate, Show rate |
| AE | Revenue closed, Pipeline created | Win rate, Avg deal size, Cycle time |
| AM/CSM | NRR, Expansion revenue | Churn rate, NPS, Health score |
| Manager | Team quota attainment | Rep performance distribution |
| VP Sales | Total revenue, Forecast accuracy | Pipeline coverage, Rep productivity |
| CRO | ARR growth, CAC payback | LTV:CAC, Sales efficiency |
Dashboard Layout Best Practices
Good Layout:
┌─────────────────────────────────────────────────────────┐
│ HEADLINE METRICS (KPIs - big numbers) │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │$1.2M │ │ 78% │ │ $45K │ │ 3.2x │ │
│ │Closed│ │ Quota│ │ ADS │ │Cover │ │
│ └──────┘ └──────┘ └──────┘ └──────┘ │
├─────────────────────────────────────────────────────────┤
│ TREND CHARTS (left) │ PIPELINE VISUAL (right) │
│ ┌───────────────────┐ │ ┌───────────────────────┐ │
│ │ Revenue vs Quota │ │ │ Pipeline by Stage │ │
│ │ ~~~/~~~ │ │ │ █████████ │ │
│ │ / \ │ │ │ ██████ │ │
│ └───────────────────┘ │ │ ████ │ │
│ │ └───────────────────────┘ │
├─────────────────────────────────────────────────────────┤
│ ACTION ITEMS (tables/lists requiring attention) │
│ • Opps closing this week: 12 │
│ • Stale opps (>30 days): 8 │
│ • Opps without next step: 5 │
└─────────────────────────────────────────────────────────┘
Bad Layout:
┌─────────────────────────────────────────────────────────┐
│ [random chart] [random chart] [random chart] │
│ [random chart] [random chart] [random chart] │
│ [random chart] [random chart] [random chart] │
│ [random chart] [random chart] [random chart] │
│ (12 charts with no hierarchy or flow) │
└─────────────────────────────────────────────────────────┘
Metric Definitions (Standardized)
| Metric | Definition | Formula |
|---|---|---|
| Quota Attainment | % of quota achieved | Closed Won ÷ Quota × 100 |
| Win Rate | % of opps that close won | Closed Won ÷ (Closed Won + Closed Lost) × 100 |
| Avg Deal Size (ADS) | Average revenue per closed deal | Total Revenue ÷ # Closed Won Deals |
| Sales Cycle | Days from opp creation to close | Avg(Close Date - Created Date) |
| Pipeline Coverage | Multiple of quota in pipeline | Open Pipeline ÷ Remaining Quota |
| Activity Rate | Activities per rep per day | Total Activities ÷ Reps ÷ Working Days |
| Conversion Rate | % moving between stages | Stage N+1 Entries ÷ Stage N Entries |
Visualization Best Practices
| Data Type | Best Visualization | Avoid |
|---|---|---|
| Single number (KPI) | Big number with trend arrow | Gauge charts |
| Trend over time | Line chart | 3D charts |
| Part-to-whole | Donut chart, stacked bar | Pie charts (>5 segments) |
| Comparison | Bar chart | Line chart for discrete values |
| Pipeline stages | Funnel or horizontal bar | Pie chart |
| Geographic | Map | Tables for >5 regions |
| Ranking | Sorted bar chart, table | Unsorted visualizations |
Red Flag Indicators
Build alerts for these conditions:
| Condition | Threshold | Action |
|---|---|---|
| Pipeline coverage drops | <2.5x quota | Notify VP Sales |
| Win rate declines | >5% drop MoM | Investigate by segment |
| Opp aging | >30 days in stage | Auto-task to rep |
| Forecast miss risk | <80% of commit | Escalate to manager |
| Activity decline | <50% of target | Manager 1:1 required |
Report vs Dashboard
| Use Reports For | Use Dashboards For |
|---|---|
| Detailed data exploration | At-a-glance health check |
| Export to Excel | Quick decision making |
| Ad-hoc questions | Recurring monitoring |
| Audit/compliance | Driving behavior |
| Exception lists | Performance tracking |
Dashboard Refresh Cadence
| Dashboard Type | Refresh Rate | Reason |
|---|---|---|
| Executive | Daily | Board prep, strategic decisions |
| Management | Every 4 hours | Team oversight |
| Rep | Real-time | Immediate action |
| Activity | Real-time | Track daily progress |
| Forecast | Weekly | Commit calls |
Common Dashboard Mistakes
Mistake: Vanity metrics front and center
Bad: Total emails sent: 50,000
Good: Email reply rate: 12% (↑2% MoM)
Mistake: No comparison context
Bad: Revenue this month: $500K
Good: Revenue this month: $500K (92% of quota, ↑15% YoY)
Mistake: Too many filters
Bad: Dashboard with 8 filter dropdowns
Good: Pre-built views: "My Team", "Enterprise", "This Quarter"
Anti-Patterns
- Dashboard sprawl — 50 reports no one uses
- Metric inconsistency — "Win rate" means different things to different teams
- Delayed data — Dashboard shows yesterday's data for real-time decisions
- No drill-down — Can't click through to underlying records
- Filter paralysis — Too many filter options, no defaults
- Colorblind-unfriendly — Red/green only visualizations
- No mobile view — Unusable on phone during meetings
title: Data Quality Management impact: HIGH tags: data, quality, deduplication, enrichment, governance
Data Quality Management
Impact: HIGH
Bad data is worse than no data. It leads to wrong decisions, wasted effort, and lost trust. Data quality is everyone's job, but ops owns the system.
Data Quality Dimensions
| Dimension | Definition | Example Problem |
|---|---|---|
| Accuracy | Data reflects reality | Company has 50 employees, CRM says 5,000 |
| Completeness | Required fields populated | 40% of accounts missing industry |
| Consistency | Same data, same format | "IBM", "I.B.M.", "International Business Machines" |
| Timeliness | Data is current | Contact left company 2 years ago |
| Validity | Data meets business rules | Email format: [email protected] |
| Uniqueness | No duplicates | Same company appears 5 times |
Data Quality Scorecard
┌────────────────────────────────────────────────────────────┐
│ DATA QUALITY SCORECARD - ACCOUNTS │
├────────────────────────────────────────────────────────────┤
│ │
│ Overall Score: 78% (Target: >90%) │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Dimension Score Trend Target Gap │ │
│ ├──────────────────────────────────────────────────────┤ │
│ │ Accuracy 85% ↑ 90% -5% │ │
│ │ Completeness 72% → 95% -23% ⚠️ │ │
│ │ Consistency 81% ↑ 85% -4% │ │
│ │ Timeliness 65% ↓ 80% -15% ⚠️ │ │
│ │ Validity 92% → 95% -3% │ │
│ │ Uniqueness 88% ↑ 95% -7% │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ Critical Issues: │
│ • 2,340 accounts missing industry (23% incomplete) │
│ • 1,850 contacts with bounce rate >20% (stale data) │
│ • 456 duplicate account pairs detected │
└────────────────────────────────────────────────────────────┘
Deduplication Strategy
Matching Rules Hierarchy:
Match Confidence Levels:
EXACT MATCH (auto-merge):
├── Same Domain + Same Name
├── Same DUNS number
└── Same External ID (from integration)
HIGH CONFIDENCE (review queue):
├── Same Domain + Similar Name (Levenshtein <3)
├── Same Phone + Same City
└── Same Address + Similar Name
POSSIBLE MATCH (manual review):
├── Similar Name + Same Industry + Same City
├── Same Email domain pattern
└── Parent/Subsidiary relationship detected
Deduplication Process:
# Duplicate detection logic
def find_duplicates(accounts):
duplicates = []
# Step 1: Exact domain match
domain_groups = group_by(accounts, 'website_domain')
for domain, accts in domain_groups.items():
if len(accts) > 1:
duplicates.append({
'type': 'exact_domain',
'confidence': 'high',
'accounts': accts
})
# Step 2: Fuzzy name match
for i, acct1 in enumerate(accounts):
for acct2 in accounts[i+1:]:
similarity = name_similarity(acct1.name, acct2.name)
if similarity > 0.85:
duplicates.append({
'type': 'fuzzy_name',
'confidence': 'medium',
'similarity': similarity,
'accounts': [acct1, acct2]
})
return duplicates
# Merge strategy
def merge_accounts(master, duplicate):
"""Keep master record, enrich with duplicate data"""
for field in ENRICHMENT_FIELDS:
if not master.get(field) and duplicate.get(field):
master[field] = duplicate[field]
# Reparent all child records
reparent_contacts(duplicate.id, master.id)
reparent_opportunities(duplicate.id, master.id)
reparent_activities(duplicate.id, master.id)
# Mark duplicate as merged
duplicate.status = 'Merged'
duplicate.merged_into = master.id
Data Enrichment Sources
| Source | Data Types | Accuracy | Cost |
|---|---|---|---|
| ZoomInfo | Company, contacts, intent | High | $$$ |
| Clearbit | Company firmographics | High | $$ |
| Apollo | Company, contacts, email | Medium-High | $$ |
| LinkedIn Sales Nav | Contacts, job changes | High | $$ |
| Crunchbase | Funding, news | High | $ |
| BuiltWith | Tech stack | High | $$ |
| 6sense/Bombora | Intent data | Medium | $$$ |
Validation Rules
Field-Level Validation:
| Field | Validation Rule | Error Message |
|---|---|---|
Regex: ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$ | "Invalid email format" | |
| Phone | Strip non-digits, length 10-15 | "Invalid phone number" |
| Website | Must start with http(s):// or add it | "Include full URL" |
| Annual Revenue | Must be >= 0 | "Revenue cannot be negative" |
| Employee Count | Must be >= 1 | "Must have at least 1 employee" |
| Country | Must be in ISO 3166-1 list | "Select valid country" |
Cross-Field Validation:
// Salesforce validation rule: Close Date consistency
AND(
ISPICKVAL(StageName, "Closed Won"),
CloseDate > TODAY()
)
// Error: "Closed Won deals cannot have future close dates"
// Validation: Loss reason required
AND(
ISPICKVAL(StageName, "Closed Lost"),
ISBLANK(Loss_Reason__c)
)
// Error: "Loss reason is required for Closed Lost opportunities"
Data Governance Program
RACI Matrix for Data Quality:
| Activity | Sales Ops | Reps | Managers | IT |
|---|---|---|---|---|
| Define data standards | A | C | C | R |
| Monitor quality metrics | R | - | I | C |
| Fix data issues | A | R | R | C |
| Build validation rules | R | C | C | A |
| Enrichment strategy | R | - | C | A |
| Duplicate resolution | R | C | A | - |
R=Responsible, A=Accountable, C=Consulted, I=Informed
Data Quality SLAs:
| Metric | Target | Measurement |
|---|---|---|
| New lead completeness | >90% within 24h | Required fields populated |
| Duplicate rate | <5% | Weekly duplicate scan |
| Email bounce rate | <10% | Monthly email validation |
| Data enrichment | >80% of new accounts | Weekly enrichment job |
| Stale contact rate | <15% | Contacts not updated in 180 days |
Data Cleanup Workflow
Weekly Data Quality Process:
Monday:
├── Run duplicate detection job
├── Generate quality scorecard
└── Assign cleanup tasks
Tuesday-Thursday:
├── Reps review/update their accounts (30 min/week)
├── Ops processes duplicate queue
└── Enrichment jobs run overnight
Friday:
├── Review week's progress
├── Update quality metrics
└── Plan next week's focus areas
Common Data Quality Issues & Fixes
| Issue | Detection | Fix |
|---|---|---|
| Duplicate accounts | Weekly matching job | Merge with master record selection |
| Missing fields | Report on NULL values | Enrichment + rep outreach |
| Invalid emails | Bounce tracking | Email verification service |
| Stale contacts | No activity >180 days | Re-verification campaign |
| Inconsistent naming | Standardization report | Find/replace + future validation |
| Orphaned contacts | No account association | Match to accounts or delete |
Anti-Patterns
- No data owner — Everyone's job is no one's job
- Blame without tools — Expecting reps to fix data without help
- One-time cleanup — Data quality is ongoing, not a project
- Over-required fields — Blocking record creation causes workarounds
- No enrichment — Relying solely on manual data entry
- Ignoring duplicates — "We'll fix it later" becomes never
- Validation without context — Rules that don't explain the "why"
- No measurement — If you don't measure it, you can't improve it
title: Sales Forecasting Models impact: CRITICAL tags: forecasting, prediction, models, accuracy, AI
Sales Forecasting Models
Impact: CRITICAL
Accurate forecasting is the foundation of business planning. It affects hiring, cash flow, investor confidence, and strategic decisions. Get it wrong, and the ripple effects are massive.
Forecasting Methodologies
| Method | Description | Best For | Accuracy |
|---|---|---|---|
| Rep Commit | Reps predict their own deals | Early stage, small teams | Low-Medium |
| Manager Judgment | Managers adjust rep commits | Established process | Medium |
| Weighted Pipeline | Stage probability × amount | Mature pipeline | Medium |
| Historical Analysis | Based on past conversion rates | Stable business | Medium-High |
| AI/ML Models | Pattern-based prediction | Large datasets | High |
| Hybrid | Combine multiple methods | Most companies | Highest |
Forecast Category Framework
┌─────────────────────────────────────────────────────────────┐
│ FORECAST CATEGORIES │
├─────────────────────────────────────────────────────────────┤
│ │
│ COMMIT BEST CASE PIPELINE OMITTED │
│ ██████ ████████ ██████████ ████ │
│ │
│ "Will close" "Should close" "Could close" "Won't │
│ >90% likely 70-89% likely 30-69% likely close" │
│ │
│ Deals with: Deals with: Deals with: Deals: │
│ - Verbal yes - Champion - Active - Stalled │
│ - Contract out - Budget ok - Interest - No fit │
│ - Close <30d - Timeline ok - Early stage - Lost │
│ │
└─────────────────────────────────────────────────────────────┘
Weighted Pipeline Calculation
Stage-Based Probability:
| Stage | Default Probability | Adjusted (Your Data) |
|---|---|---|
| Qualification | 10% | 8% |
| Discovery | 20% | 18% |
| Demo/Evaluation | 40% | 35% |
| Proposal | 60% | 55% |
| Negotiation | 80% | 78% |
| Closed Won | 100% | 100% |
Weighted Forecast Calculation:
Deal 1: $100K at Proposal (55%) = $55,000
Deal 2: $50K at Demo (35%) = $17,500
Deal 3: $200K at Negotiation (78%) = $156,000
Deal 4: $75K at Discovery (18%) = $13,500
─────────
Weighted Pipeline Forecast: = $242,000
AI/ML Forecasting Approach
Feature Engineering for Deal Prediction:
# Features that predict deal outcome
deal_features = {
# Deal characteristics
'amount': deal.amount,
'days_in_stage': (today - deal.stage_date).days,
'days_to_close': (deal.close_date - today).days,
'discount_percent': deal.discount / deal.list_price,
# Engagement signals
'email_count_30d': activities.filter(type='email', days=30).count(),
'meeting_count_30d': activities.filter(type='meeting', days=30).count(),
'days_since_last_activity': (today - last_activity.date).days,
'stakeholder_count': deal.contacts.count(),
'has_champion': deal.contacts.filter(role='Champion').exists(),
'has_decision_maker': deal.contacts.filter(role='Decision Maker').exists(),
# Historical patterns
'rep_win_rate': rep.historical_win_rate,
'segment_win_rate': segment.historical_win_rate,
'similar_deal_outcome': similar_deals.avg_win_rate,
# External signals
'company_growth_signal': company.hiring_trend,
'intent_score': intent_data.score,
'competitor_mention': gong_calls.competitor_mentions > 0
}
Model Output:
Deal: Acme Corp - Enterprise License
─────────────────────────────────────
AI Win Probability: 73%
Rep Commit: Best Case
Key Factors (SHAP analysis):
✅ +15% Champion identified and engaged
✅ +12% 5 meetings in last 30 days
✅ +8% Similar deals closed at 68% rate
⚠️ -5% Close date pushed twice
⚠️ -7% Days in Proposal stage above average
Recommendation: Move to Commit if close date confirmed
Forecast Accuracy Measurement
Accuracy Metrics:
| Metric | Formula | Target |
|---|---|---|
| Forecast Accuracy | 1 - | Forecast - Actual |
| Weighted Error | Σ | Forecast - Actual |
| Bias | (Forecast - Actual) / Actual (directional) | ±5% |
| Commit Accuracy | Commit Closed Won / Commit Total | >80% |
Forecast Tracking Dashboard:
┌────────────────────────────────────────────────────────────┐
│ FORECAST ACCURACY TRACKING - Q1 2025 │
├────────────────────────────────────────────────────────────┤
│ │
│ Week 1 Forecast: $2.1M │ Actual: $1.85M │
│ Accuracy: 88% │ Bias: +14% (over-forecast) │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Week 1 Week 2 Week 3 EoQ Final │ │
│ │ Commit $1.2M $1.4M $1.6M $1.85M ✓ │ │
│ │ Best $1.8M $1.9M $2.0M $1.85M - │ │
│ │ Pipe $3.5M $3.2M $2.8M $1.85M - │ │
│ │ Actual - - - $1.85M │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ Rep Accuracy Breakdown: │
│ Sarah: 92% ████████████████████ │
│ Mike: 78% ████████████████ │
│ Lisa: 85% █████████████████ │
│ Tom: 65% █████████████ ⚠️ Needs coaching │
└────────────────────────────────────────────────────────────┘
Forecast Call Process
Weekly Forecast Call Agenda:
Duration: 30-45 minutes
Attendees: VP Sales, Directors, Sales Ops
1. Pipeline Review (10 min)
- Total pipeline vs coverage target
- New pipeline created this week
- Pipeline at risk (aging, no activity)
2. Commit Review (15 min)
- Each rep's commit deals
- Changes from last week (add/remove/amount)
- Risk assessment per deal
3. Upside Discussion (10 min)
- Best case opportunities
- What needs to happen to close
4. Actions & Risks (5 min)
- Deals needing escalation
- Resource allocation decisions
- Follow-up items
Output: Updated forecast in system within 2 hours
Forecast Hygiene Rules
| Rule | Enforcement | Consequence |
|---|---|---|
| Close date must be realistic | Validation: can't be >90 days if in Negotiation | Blocked save |
| Commit requires next steps | Task must exist with date <7 days | Cannot add to Commit |
| Push count tracked | Auto-increment when close date moves | Visible in reports |
| Amount changes logged | Field history tracking | Audit trail |
| No deal >120 days in stage | Auto-flag for review | Manager alert |
Common Forecasting Mistakes
Mistake: Sandbagging
Pattern: Rep consistently commits 80% of what they close
Impact: Under-forecasting leads to missed opportunities
Fix: Track commit-to-close ratio, coach on accuracy
Mistake: Happy Ears
Pattern: Rep commits deals without buying signals
Impact: Over-forecasting damages credibility
Fix: Require documented next steps, decision maker access
Mistake: Close Date Fiction
Pattern: Every deal closes "end of month" or "end of quarter"
Impact: Forecast accuracy drops, hockey stick quarters
Fix: Validate close dates match buyer timeline
Forecasting Tools
| Tool | Strength | Integration |
|---|---|---|
| Salesforce CRM Analytics | Native, good for SFDC shops | Native |
| Clari | AI forecasting, deal inspection | SFDC, HubSpot |
| Gong Forecast | Conversation-based signals | SFDC + Gong |
| InsightSquared | Analytics + forecasting | SFDC, HubSpot |
| Aviso | AI-driven, enterprise | SFDC |
| BoostUp | Revenue operations | SFDC, HubSpot |
Anti-Patterns
- Gut-based forecasting — No data, just hope
- Single methodology — Rep commit only, no validation
- Quarterly spikes — All deals close last week of quarter
- No accountability — Forecast misses without consequences
- Delayed updates — Weekly forecast calls with stale data
- Ignoring trends — Not adjusting for seasonality or market changes
- One-size-fits-all — Same forecast method for $10K and $1M deals
- No post-mortem — Not analyzing why forecasts were wrong
title: Pipeline Stages & Velocity impact: CRITICAL tags: pipeline, stages, velocity, conversion, forecasting
Pipeline Stages & Velocity
Impact: CRITICAL
Pipeline stages tell the story of your deals. Well-defined stages enable accurate forecasting, identify bottlenecks, and create accountability.
Stage Design Principles
Each stage should have:
- Clear entry criteria — What must happen to enter this stage?
- Clear exit criteria — What must happen to move forward?
- Defined probability — What % of deals at this stage close?
- Owner accountability — Who's responsible for progression?
Standard B2B SaaS Pipeline
| Stage | Entry Criteria | Exit Criteria | Probability | Avg Time |
|---|---|---|---|---|
| Qualification | Discovery call completed | BANT confirmed | 10% | 7 days |
| Discovery | Pain/need identified | Solution mapped to need | 20% | 14 days |
| Demo/Evaluation | Demo scheduled | Technical validation complete | 40% | 21 days |
| Proposal | Pricing discussed | Proposal delivered and reviewed | 60% | 14 days |
| Negotiation | Verbal agreement | Terms agreed, contract sent | 80% | 14 days |
| Closed Won | Contract signed | — | 100% | — |
| Closed Lost | Deal lost | Loss reason captured | 0% | — |
Stage Criteria Documentation
Good Example: Clear Stage Definition
Stage: Demo/Evaluation
Entry Criteria:
□ Discovery call completed
□ At least 2 stakeholders identified
□ Budget range confirmed ($X - $Y)
□ Timeline established (decision within 90 days)
Exit Criteria (to Proposal):
□ Demo delivered to decision maker
□ Technical requirements validated
□ Integration feasibility confirmed
□ Success metrics agreed upon
Exit Criteria (to Closed Lost):
□ Loss reason selected
□ Competitor field updated (if applicable)
□ Follow-up task created (if nurture)
Probability: 40%
Expected Duration: 14-21 days
Red Flag: >30 days in stage
Bad Example: Vague Stage Definition
Stage: Demo
Entry: They want to see a demo
Exit: Demo done
Probability: 50%
Duration: Whenever
Pipeline Velocity Analysis
Velocity Formula:
Velocity = (Win Rate × Avg Deal Size × # of Opps) / Avg Sales Cycle
Current State:
25% × $50,000 × 100 opps / 90 days = $13,889/day
Target State (improve win rate):
30% × $50,000 × 100 opps / 90 days = $16,667/day (+20%)
Stage Conversion Funnel:
Qualification 100 opps ─────────────────────────┐
│ │ 30% drop
▼ │
Discovery 70 opps ◄────────────────────────┘
│ │ 29% drop
▼ │
Demo/Eval 50 opps ◄────────────────────────┘
│ │ 40% drop
▼ │
Proposal 30 opps ◄────────────────────────┘
│ │ 17% drop
▼ │
Negotiation 25 opps ◄────────────────────────┘
│ │ 0% drop
▼ │
Closed Won 25 opps ◄────────────────────────┘
Overall Win Rate: 25%
Stage Duration Benchmarks
| Stage | Healthy | Warning | Critical |
|---|---|---|---|
| Qualification | <7 days | 7-14 days | >14 days |
| Discovery | <14 days | 14-21 days | >30 days |
| Demo/Eval | <21 days | 21-30 days | >45 days |
| Proposal | <14 days | 14-21 days | >30 days |
| Negotiation | <14 days | 14-30 days | >45 days |
Pipeline Health Metrics
| Metric | Calculation | Target |
|---|---|---|
| Coverage Ratio | Pipeline ÷ Quota | 3-4x |
| Stage Distribution | % of opps per stage | Pyramid shape |
| Aging Rate | % opps > stage benchmark | <20% |
| Push Rate | % opps with changed close date | <30% |
| Win Rate by Stage | Wins ÷ Opps entering stage | Increasing |
Stage Distribution Analysis
Healthy Pipeline:
Qualification: ████████████████████ 35%
Discovery: ███████████████ 25%
Demo/Eval: ████████████ 20%
Proposal: ██████ 12%
Negotiation: ████ 8%
Unhealthy Pipeline (top-heavy):
Qualification: ███████████████████████████████████ 60%
Discovery: ███████ 15%
Demo/Eval: ████ 10%
Proposal: ███ 8%
Negotiation: ██ 7%
Validation Rules for Stage Progression
// Salesforce validation rule example
// Prevent skipping stages
AND(
ISCHANGED(StageName),
NOT(ISPICKVAL(PRIORVALUE(StageName), "Closed Won")),
NOT(ISPICKVAL(PRIORVALUE(StageName), "Closed Lost")),
CASE(
StageName,
"Discovery", NOT(ISPICKVAL(PRIORVALUE(StageName), "Qualification")),
"Demo/Evaluation", NOT(OR(
ISPICKVAL(PRIORVALUE(StageName), "Qualification"),
ISPICKVAL(PRIORVALUE(StageName), "Discovery")
)),
// ... continue for other stages
false
)
)
Required Fields by Stage
| Stage | Required Fields |
|---|---|
| Any stage | Account, Amount, Close Date, Owner |
| Discovery+ | Primary Contact, Next Steps |
| Demo+ | Decision Maker, Competition |
| Proposal+ | Proposal Sent Date |
| Negotiation+ | Contract Value |
| Closed Won | Won Reason, Contract Signed Date |
| Closed Lost | Loss Reason, Competitor Won (if applicable) |
Anti-Patterns
- Stage inflation — Reps advance stages without meeting criteria
- Pipeline stuffing — Moving unqualified opps to hit coverage targets
- Close date fiction — Optimistic dates that constantly push
- Stage skipping — Jumping from Discovery to Negotiation
- Zombie opps — Deals sitting in stage for months with no activity
- Probability override — Manual probability changes without stage change
- Missing loss reasons — Closed Lost without capturing why
title: Process Automation & Workflows impact: HIGH tags: automation, workflow, process, efficiency, salesforce
Process Automation & Workflows
Impact: HIGH
The best automation makes the right thing easy and the wrong thing hard. Automate to enable reps, not to police them.
Automation ROI Framework
Before automating, calculate the value:
Automation ROI = (Time Saved × Frequency × Hourly Cost) - Build Cost
Example: Auto-create follow-up task after demo
- Time saved: 2 min per demo
- Frequency: 200 demos/month
- Hourly cost: $50/hr
- Build cost: 2 hours
Monthly ROI = (2/60 × 200 × $50) - (2 × $50) = $333 - $100 = $233/month first month
(2/60 × 200 × $50) = $333/month ongoing
Automation Priority Matrix
| Impact | Effort Low | Effort High |
|---|---|---|
| High Impact | DO NOW | PLAN |
| Low Impact | AUTOMATE LATER | DON'T DO |
High Impact / Low Effort (Do Now):
- Auto-assign leads by territory
- Task creation on stage change
- Notification on deal close
- Field updates on record creation
High Impact / High Effort (Plan):
- Complex approval workflows
- Multi-system integrations
- AI-powered lead scoring
- Automated forecasting
Common Automation Patterns
1. Lead Assignment
Trigger: New Lead Created
Conditions:
- Lead Status = "New"
- Lead Source != "Manual Entry"
Actions:
1. Run assignment rules
2. Create task: "Contact new lead within 5 min"
3. Send Slack notification to assigned rep
4. Update Lead Status to "Assigned"
2. Stage Change Workflow
Trigger: Opportunity Stage Changed
Conditions:
- Stage changed to "Demo/Evaluation"
Actions:
1. Create task: "Send demo follow-up" (due +1 day)
2. Add to Outreach sequence: "Post-Demo Nurture"
3. Update field: Last_Stage_Change_Date__c = TODAY()
4. Notify manager if deal size > $100K
3. Deal Escalation
Trigger: Scheduled (Daily at 8am)
Conditions:
- Stage = "Proposal" or "Negotiation"
- Days in stage > 21
- Amount > $50,000
Actions:
1. Send email alert to VP Sales
2. Create Chatter post on record
3. Add to "At Risk" report
Workflow Decision Tree
┌─────────────────┐
│ Is this process │
│ well-defined? │
└────────┬────────┘
│
┌──────────────┴──────────────┐
│ NO │ YES
▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ Document process│ │ Does it happen │
│ first, then │ │ frequently? │
│ automate │ │ (>10x/week) │
└─────────────────┘ └────────┬────────┘
│
┌────────────┴────────────┐
│ NO │ YES
▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ Consider manual │ │ Is the logic │
│ process or │ │ consistent? │
│ simple reminder │ │ (no exceptions) │
└─────────────────┘ └────────┬────────┘
│
┌────────────┴────────────┐
│ NO │ YES
▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ Build with │ │ AUTOMATE IT │
│ exception │ │ │
│ handling │ │ │
└─────────────────┘ └─────────────────┘
Automation Tools Comparison
| Tool | Best For | Complexity | Cost |
|---|---|---|---|
| Salesforce Flow | Complex Salesforce automation | High | Included |
| Process Builder | Simple field updates (legacy) | Low | Included |
| Workflow Rules | Basic notifications (legacy) | Low | Included |
| Zapier | Cross-system, no-code | Medium | $$ |
| Workato | Enterprise integrations | High | $$$ |
| Tray.io | Complex multi-step | High | $$$ |
| n8n | Self-hosted, technical team | High | $ |
Salesforce Flow Best Practices
Good Flow Design:
Flow Name: Opp_Stage_Change_Handler
Type: Record-Triggered Flow
Object: Opportunity
Trigger: After Update
Entry Conditions:
- Stage was changed
- Stage != "Closed Won" AND Stage != "Closed Lost"
Actions:
1. Decision: Check new stage value
2. Assignment: Update related fields
3. Create Records: Generate tasks
4. Action: Send notifications
Error Handling:
- Fault connector to error handling subflow
- Admin notification on failure
- Transaction rollback on critical errors
Bad Flow Design:
Flow Name: New_Flow_1
Type: Record-Triggered Flow
Object: Opportunity
Trigger: Before Update AND After Update (double triggers!)
Entry Conditions: None (runs on every save!)
Actions:
- 47 actions in linear sequence
- No error handling
- Hardcoded IDs
- Queries inside loops
Notification Strategy
| Event | Channel | Audience | Urgency |
|---|---|---|---|
| Deal Closed Won >$100K | Slack #wins | Whole company | Immediate |
| Lead not contacted in 5 min | Slack DM | Assigned rep | Immediate |
| Opp stage changed | Rep + Manager | Daily digest | |
| Forecast commit change | VP Sales | Real-time | |
| Opp past close date | In-app | Rep | On login |
Automation Documentation Template
## Automation: [Name]
**Owner:** [Sales Ops team member]
**Created:** [Date]
**Last Modified:** [Date]
### Purpose
[What business problem does this solve?]
### Trigger
[What initiates this automation?]
### Logic
[Step-by-step what happens]
### Affected Fields/Records
[What gets created/updated]
### Error Handling
[What happens when it fails]
### Testing Notes
[How to test this automation]
### Known Limitations
[Edge cases or exceptions]
Anti-Patterns
- Automation spaghetti — No documentation, impossible to debug
- Over-notification — Alert fatigue kills effectiveness
- No testing environment — Automations go straight to production
- Hardcoded values — IDs, names, amounts embedded in logic
- No error handling — Silent failures corrupt data
- Automating bad processes — Making mistakes faster
- Single point of failure — Only one person knows how it works
- No audit trail — Can't trace what automation changed what
title: Lead Routing & Assignment impact: HIGH tags: routing, assignment, leads, territory, round-robin
Lead Routing & Assignment
Impact: HIGH
Speed to lead is everything. The first vendor to respond wins 35-50% of deals. Your routing rules can be the difference between a closed deal and a lost opportunity.
Speed to Lead Benchmarks
| Response Time | Conversion Impact |
|---|---|
| <5 minutes | Optimal conversion rate |
| 5-30 minutes | 21x less likely to qualify than <5 min |
| >30 minutes | Dramatic drop-off |
| >1 hour | Lead is likely cold |
Routing Logic Hierarchy
┌─────────────────────┐
│ INBOUND LEAD │
└──────────┬──────────┘
│
┌──────────▼──────────┐
┌───────│ Existing Account? │───────┐
│ └─────────────────────┘ │
YES NO
│ │
▼ ▼
┌───────────────┐ ┌───────────────┐
│ Route to │ │ Apply lead │
│ Account Owner │ │ scoring │
└───────────────┘ └───────┬───────┘
│
┌───────────▼───────────┐
┌───────│ Score >= MQL? │───────┐
│ └───────────────────────┘ │
YES NO
│ │
▼ ▼
┌───────────────┐ ┌───────────────┐
│ Territory │ │ Marketing │
│ assignment │ │ nurture │
└───────┬───────┘ └───────────────┘
│
▼
┌───────────────┐
│ Round-robin │
│ within region │
└───────────────┘
Assignment Rule Types
| Type | Best For | Complexity | Example |
|---|---|---|---|
| Territory-based | Geographic/named account coverage | Medium | "West Coast > California > Bay Area > Sarah" |
| Round-robin | Equal distribution | Low | Rotate through available reps |
| Weighted round-robin | Performance/capacity-based | Medium | "Top rep gets 2x leads" |
| Lead score-based | Prioritize hot leads | High | "Score >80 → Enterprise team" |
| Product-based | Multiple products | Medium | "Enterprise product → Enterprise SDR" |
Round-Robin Implementation
Good Example: Fair & Trackable
# Weighted round-robin with capacity tracking
assignment_rules = {
"enterprise_team": {
"members": [
{"name": "Sarah", "weight": 2, "max_daily": 10, "current": 3},
{"name": "Mike", "weight": 1, "max_daily": 8, "current": 5},
{"name": "Lisa", "weight": 1.5, "max_daily": 12, "current": 7}
],
"logic": "weighted_round_robin",
"overflow": "queue_for_manager"
}
}
# Assignment logic
def assign_lead(lead, team):
available = [m for m in team["members"] if m["current"] < m["max_daily"]]
if not available:
return team["overflow"]
# Weighted selection based on remaining capacity
weights = [(m["max_daily"] - m["current"]) * m["weight"] for m in available]
return weighted_random(available, weights)
Bad Example: Unfair Distribution
# First-come, first-served (creates inequality)
def assign_lead(lead):
for rep in all_reps:
if rep.is_online():
return rep # Always assigns to same fast rep
Territory Design Framework
Balanced Territory Criteria:
| Factor | Weight | Measurement |
|---|---|---|
| Revenue potential | 40% | TAM of accounts in territory |
| Account volume | 25% | Number of target accounts |
| Historical performance | 20% | Win rate, cycle time |
| Geographic spread | 15% | Travel time/zones |
Territory Assignment Example:
Region: West
├── Enterprise (>1000 employees)
│ ├── Named Accounts: [Fortune 500 list]
│ └── Owner: Senior AE (Sarah)
│
├── Mid-Market (100-999 employees)
│ ├── States: CA, OR, WA
│ ├── Industries: Tech, Healthcare
│ └── Owner: AE (Mike)
│
└── SMB (<100 employees)
├── Inbound only
├── Round-robin assignment
└── Team: SMB AE Pool
Lead Routing Rules Matrix
| Condition | Company Size | Lead Source | Assignment |
|---|---|---|---|
| Named Account | Any | Any | Account Owner |
| Enterprise | >1000 emp | Demo Request | Enterprise AE |
| Enterprise | >1000 emp | Content | Enterprise SDR |
| Mid-Market | 100-999 | Demo Request | MM AE (territory) |
| Mid-Market | 100-999 | Content | MM SDR |
| SMB | <100 | Demo Request | SMB AE (round-robin) |
| SMB | <100 | Content | Marketing nurture |
SLA Monitoring
Response SLA Table:
| Lead Type | Target Response | Alert Threshold | Escalation |
|---|---|---|---|
| Demo Request | <5 min | 10 min | Manager |
| Trial Signup | <1 hour | 2 hours | Manager |
| Content Download | <4 hours | 8 hours | Team Lead |
| Event Lead | <24 hours | 48 hours | SDR Manager |
SLA Dashboard Metrics:
┌────────────────────────────────────────────────┐
│ LEAD RESPONSE SLA DASHBOARD │
├────────────────────────────────────────────────┤
│ Today's Leads: 47 │
│ ┌──────────────────────────────────────────┐ │
│ │ Met SLA (<5min): ████████████ 78% (37)│ │
│ │ Warning (5-15min): ████ 15% (7) │ │
│ │ Breached (>15min): ██ 7% (3) │ │
│ └──────────────────────────────────────────┘ │
│ │
│ Avg Response Time: 4.2 min (Target: <5 min) │
│ Leads in Queue Now: 2 │
│ Oldest Uncontacted: 3 min │
└────────────────────────────────────────────────┘
Edge Case Handling
| Scenario | Rule |
|---|---|
| Rep on PTO | Skip in rotation, reassign open leads |
| Territory conflict | Account owner > territory > round-robin |
| No matching rule | Assign to manager queue, alert ops |
| Duplicate lead | Merge with existing, notify owner |
| Invalid data | Route to data quality queue |
Assignment Automation Code
// Salesforce Apex example: Territory-based with round-robin fallback
public class LeadAssignmentHandler {
public static User assignLead(Lead lead) {
// Step 1: Check for existing account owner
Account existingAccount = findMatchingAccount(lead);
if (existingAccount != null && existingAccount.OwnerId != null) {
return existingAccount.Owner;
}
// Step 2: Find territory match
Territory territory = TerritoryService.findTerritory(
lead.State,
lead.Industry,
lead.Company_Size__c
);
if (territory != null) {
// Step 3: Round-robin within territory
return RoundRobinService.getNextRep(territory.Id);
}
// Step 4: Fallback to manager queue
return [SELECT Id FROM User WHERE Name = 'Lead Queue Manager' LIMIT 1];
}
}
Anti-Patterns
- Cherry-picking — Reps choosing their own leads
- Static assignment — No adjustment for rep capacity or PTO
- No SLA tracking — Leads sitting for hours uncontacted
- Over-complicated rules — 50 rule variations impossible to maintain
- No fallback — Leads fall through cracks when rules don't match
- Manual override abuse — Managers reassigning based on favoritism
- No audit trail — Can't explain why lead went to which rep
title: Sales Tech Stack Integration impact: HIGH tags: integration, tech-stack, salesforce, hubspot, outreach, gong
Sales Tech Stack Integration
Impact: HIGH
A well-integrated tech stack multiplies rep productivity. A poorly integrated one creates data silos, double entry, and frustration. Integration architecture is as important as tool selection.
Sales Tech Stack Architecture
┌─────────────────────────────────────────────────────────────────────┐
│ ANALYTICS & BI LAYER │
│ Tableau • Looker • Power BI • Salesforce Reports │
└────────────────────────────────┬────────────────────────────────────┘
│
┌────────────────────────────────▼────────────────────────────────────┐
│ CRM (Source of Truth) │
│ Salesforce • HubSpot • Dynamics │
└───────┬─────────────────┬─────────────────┬─────────────────┬───────┘
│ │ │ │
┌───────▼───────┐ ┌───────▼───────┐ ┌───────▼───────┐ ┌───────▼───────┐
│ ENGAGEMENT │ │ INTELLIGENCE │ │ ENRICHMENT │ │ COMMERCE │
│ │ │ │ │ │ │ │
│ Outreach │ │ Gong │ │ ZoomInfo │ │ Stripe │
│ Salesloft │ │ Chorus │ │ Clearbit │ │ Chargebee │
│ Apollo │ │ Clari │ │ Apollo │ │ CPQ │
└───────────────┘ └───────────────┘ └───────────────┘ └───────────────┘
│ │ │ │
┌───────▼─────────────────▼─────────────────▼─────────────────▼───────┐
│ INTEGRATION LAYER │
│ Workato • Zapier • Tray.io • Native APIs │
└─────────────────────────────────────────────────────────────────────┘
Tool Selection Criteria
| Criteria | Weight | Evaluation Questions |
|---|---|---|
| CRM Integration | 30% | Native connector? Bi-directional sync? Real-time? |
| Data Quality | 20% | Does it improve or degrade CRM data? |
| Rep Adoption | 20% | Will reps actually use it? UX quality? |
| Reporting | 15% | Can we measure ROI? Data accessible? |
| Security | 10% | SOC 2? GDPR compliant? SSO support? |
| Cost/Value | 5% | ROI positive within 6 months? |
Integration Patterns
Pattern 1: CRM as Master (Recommended)
ZoomInfo ──────► Salesforce ◄────── Outreach
│
▼
Single Source
of Truth
Pros: Clear data ownership, no conflicts
Cons: CRM must be kept clean
Pattern 2: Bi-Directional Sync
Salesforce ◄────────► Outreach
│ │
└──────► ◄──────────┘
Sync conflicts possible
Pros: Data flows both ways
Cons: Risk of sync loops, data conflicts
Pattern 3: Data Warehouse Hub
Salesforce ────►┌─────────────┐
│ Data │────► Analytics
Outreach ──────►│ Warehouse │
│ (Snowflake) │────► ML Models
Gong ──────────►└─────────────┘
Pros: Decoupled, scalable analytics
Cons: Complexity, latency
Common Integration Configurations
Salesforce + Outreach
Integration: Salesforce ↔ Outreach
Type: Bi-directional
Sync Frequency: Real-time
Object Mappings:
Lead → Prospect
Contact → Prospect
Account → Account
Opportunity → Opportunity
Task → Task (activities only)
Field Mappings:
SFDC Lead.Status → Outreach Prospect.Stage
Outreach Sequence.Status → SFDC Lead.Outreach_Status__c
Outreach LastActivityDate → SFDC Contact.Last_Outreach_Activity__c
Sync Rules:
- Outreach creates activities in SFDC (one-way)
- SFDC owns account/contact data (master)
- Sequence status syncs bi-directionally
- Emails logged with full body
Salesforce + Gong
Integration: Salesforce ↔ Gong
Type: Gong reads, SFDC writes
Sync Frequency: Near real-time (within minutes)
Data Flow:
Gong → SFDC:
- Call recordings linked to Contact/Opportunity
- AI insights written to custom fields
- Deal risk scores updated
- Key moments flagged
SFDC → Gong:
- Account/Opportunity context
- Deal stage for filtering
- Owner for assignment
Custom Fields (SFDC):
- Gong_Last_Call_Date__c
- Gong_Deal_Risk_Score__c
- Gong_Engagement_Score__c
- Gong_Competitor_Mentioned__c
Salesforce + ZoomInfo
Integration: ZoomInfo → Salesforce
Type: One-way enrichment
Sync Frequency: On-demand + daily batch
Enrichment Rules:
Account:
- Update if field is blank OR data is >90 days old
- Fields: Industry, Employee Count, Revenue, Tech Stack
- Never overwrite: Name, Owner, custom fields
Contact:
- Update if field is blank
- Fields: Title, Phone, Email, LinkedIn URL
- Create net-new contacts with approval workflow
Matching Logic:
- Account: Domain match first, then Name + Location
- Contact: Email match first, then Name + Company
Integration Health Monitoring
┌────────────────────────────────────────────────────────────┐
│ INTEGRATION HEALTH DASHBOARD │
├────────────────────────────────────────────────────────────┤
│ │
│ Integration Status Last Sync Error Rate │
│ ───────────────────────────────────────────────────────── │
│ Salesforce↔Outreach ✅ Active 2 min ago 0.1% │
│ Salesforce↔Gong ✅ Active 5 min ago 0.0% │
│ Salesforce←ZoomInfo ✅ Active 4 hrs ago 0.3% │
│ Salesforce→Slack ✅ Active 1 min ago 0.0% │
│ Salesforce↔Stripe ⚠️ Degraded 1 hr ago 2.1% │
│ │
│ Recent Errors: │
│ • Stripe sync: 23 invoices failed mapping (field missing) │
│ • ZoomInfo: Rate limit hit, resuming in 15 min │
│ │
│ Data Quality Impact: │
│ • 150 contacts enriched today │
│ • 2,340 activities logged from Outreach │
│ • 89 calls recorded by Gong │
└────────────────────────────────────────────────────────────┘
Integration Best Practices
| Practice | Description |
|---|---|
| Single source of truth | Designate one system as master for each data type |
| Field-level mapping docs | Document every field that syncs between systems |
| Error alerting | Immediate notification on sync failures |
| Audit trail | Log all integration-created/modified records |
| Sandbox testing | Test all integrations in sandbox first |
| Rollback plan | Know how to undo integration changes |
API Rate Limits & Quotas
| System | Daily Limit | Per-Minute | Workaround |
|---|---|---|---|
| Salesforce | 1M/org | 600/user | Bulk API for large operations |
| HubSpot | 500K/day | 100/10sec | Batch API calls |
| Outreach | Varies by plan | 50/sec | Queuing system |
| ZoomInfo | Plan-based | 100/min | Scheduled batches |
| Gong | 1000/day | 10/sec | Webhook-based updates |
Tech Stack ROI Measurement
Tool ROI Calculation:
Outreach:
├── Cost: $150/user/month × 20 users = $3,000/month
├── Time saved: 5 hrs/rep/week × 20 reps × $50/hr = $20,000/month
├── Additional meetings: +15% = ~$50,000 pipeline/month
└── ROI: ($70,000 - $3,000) / $3,000 = 2,233%
Gong:
├── Cost: $100/user/month × 30 users = $3,000/month
├── Win rate improvement: +3% = ~$30,000/month in revenue
├── Ramp time reduction: 2 weeks faster = $10,000 value
└── ROI: ($40,000 - $3,000) / $3,000 = 1,233%
Migration Checklist
When adding/changing tools:
## Pre-Migration
- [ ] Document current state (all integrations, field mappings)
- [ ] Identify data dependencies
- [ ] Test in sandbox environment
- [ ] Create rollback plan
- [ ] Schedule during low-activity period
## During Migration
- [ ] Pause affected integrations
- [ ] Run data validation pre/post
- [ ] Monitor error logs
- [ ] Verify critical workflows
## Post-Migration
- [ ] Enable monitoring/alerting
- [ ] Validate data quality
- [ ] Update documentation
- [ ] Train affected users
- [ ] Measure baseline metrics
Anti-Patterns
- Tool sprawl — New tool for every problem
- No integration strategy — Tools operate in silos
- CRM bypass — Data entered in other tools, not CRM
- Manual data sync — "We export CSV and import weekly"
- No error handling — Silent integration failures
- Undocumented integrations — Only one person knows how it works
- Over-syncing — Every field syncs when few are needed
- No sandbox testing — Integration changes go straight to production
title: Territory Design & Optimization impact: MEDIUM-HIGH tags: territory, design, optimization, coverage, quota
Territory Design & Optimization
Impact: MEDIUM-HIGH
Well-designed territories create fair opportunity, reduce conflict, and maximize coverage. Poor territories demotivate reps and leave revenue on the table.
Territory Design Principles
┌─────────────────────────────────────────────────────────────┐
│ BALANCED TERRITORIES │
├─────────────────────────────────────────────────────────────┤
│ │
│ REVENUE WORKLOAD GROWTH TRAVEL │
│ POTENTIAL EQUITY POTENTIAL EFFICIENCY │
│ │
│ ~$3M ~150 ~20% <3 hrs │
│ per rep accounts YoY growth flight time │
│ │
└─────────────────────────────────────────────────────────────┘
Territory Segmentation Options
| Segmentation | Best For | Pros | Cons |
|---|---|---|---|
| Geographic | Field sales, local presence | Clear boundaries, travel efficiency | Unequal revenue distribution |
| Named Account | Enterprise, strategic accounts | Deep relationships | Difficult to balance |
| Industry/Vertical | Domain expertise needed | Specialized knowledge | May overlap geographically |
| Company Size | Different sales motions | Appropriate sales cycle | Less account continuity |
| Product Line | Complex product portfolio | Product expertise | Customer confusion |
| Hybrid | Most companies | Balanced approach | More complex to manage |
Territory Sizing Framework
Step 1: Calculate Total Addressable Coverage
Total TAM Accounts: 10,000
Average Deal Size: $50,000
Historical Win Rate: 20%
Average Sales Cycle: 90 days
Revenue Potential = 10,000 × $50K × 20% = $100M
Step 2: Determine Rep Capacity
Working days per quarter: 65
Deals rep can manage simultaneously: 25
Touches per deal per week: 3
Available selling hours/day: 5
Active deals per rep = 25
Expected closes per quarter = 25 × 20% = 5 deals
Revenue per rep/quarter = 5 × $50K = $250K
Annual quota = $1M
Step 3: Calculate Territory Size
Total Revenue Potential: $100M
Revenue per rep: $1M (at quota)
Coverage ratio: 3x (need 3x pipeline)
Required reps: $100M ÷ ($1M × 3) = 33 reps
Accounts per territory: 10,000 ÷ 33 = ~300 accounts
Territory Balance Scorecard
| Metric | Territory A | Territory B | Territory C | Variance |
|---|---|---|---|---|
| Account Count | 285 | 312 | 298 | ±5% |
| TAM ($M) | $8.2 | $7.9 | $8.5 | ±4% |
| Active Opps | 22 | 25 | 20 | ±11% |
| Historical Win Rate | 23% | 21% | 25% | ±9% |
| Growth Potential | High | Medium | High | — |
| Travel Load | Low | Medium | Low | — |
| Balance Score | 92 | 88 | 94 | Target: >85 |
Territory Assignment Matrix
Company Size
SMB Mid-Market Enterprise
┌────────┬────────────┬────────────┐
Technology │ Pool A │ Rep 1 │ Rep 7-8 │
├────────┼────────────┼────────────┤
Industry │ Pool A │ Rep 2 │ Rep 9-10 │
Healthcare ├────────┼────────────┼────────────┤
│ Pool B │ Rep 3 │ Rep 11 │
Finance ├────────┼────────────┼────────────┤
│ Pool B │ Rep 4 │ Rep 12 │
Other ├────────┼────────────┼────────────┤
│ Pool C │ Rep 5-6 │ Rep 13 │
└────────┴────────────┴────────────┘
Geographic Territory Example
Good Design: Balanced Revenue Potential
Western Region ($25M TAM)
├── Pacific Northwest (WA, OR) - Rep 1
│ └── $8M TAM, 450 accounts
├── Northern California - Rep 2
│ └── $9M TAM, 380 accounts
└── Southern California - Rep 3
└── $8M TAM, 520 accounts
Bad Design: Unbalanced
Western Region ($25M TAM)
├── California - Rep 1
│ └── $17M TAM (unfair advantage!)
└── Everything Else (WA, OR, AZ, NV, etc.) - Rep 2
└── $8M TAM (set up to fail)
Territory Conflict Resolution
| Conflict Type | Resolution Rule | Example |
|---|---|---|
| Account moves to new territory | Grace period (90 days), then transfer | Company relocates HQ |
| Subsidiary vs parent | Parent account owner wins | Regional office vs HQ |
| Contact changes companies | New territory owner | Champion joins new company |
| Industry reclassification | Revenue-based decision | Fintech: Finance or Tech? |
| Named account dispute | Manager arbitration | Strategic account overlap |
Quota Allocation by Territory
Company Annual Target: $10M
Territory Quota Setting:
┌─────────────┬──────────┬────────────┬──────────┬───────────┐
│ Territory │ TAM │ % of Total │ Base │ Adjusted │
│ │ │ │ Quota │ Quota │
├─────────────┼──────────┼────────────┼──────────┼───────────┤
│ Enterprise │ $20M │ 40% │ $4M │ $3.8M* │
│ Mid-Market │ $15M │ 30% │ $3M │ $3.2M │
│ SMB │ $10M │ 20% │ $2M │ $2M │
│ Growth │ $5M │ 10% │ $1M │ $1M │
├─────────────┼──────────┼────────────┼──────────┼───────────┤
│ Total │ $50M │ 100% │ $10M │ $10M │
└─────────────┴──────────┴────────────┴──────────┴───────────┘
*Enterprise adjusted down due to longer sales cycles
Territory Review Cadence
| Review Type | Frequency | Scope | Participants |
|---|---|---|---|
| Performance check | Monthly | Metrics review | Manager + Ops |
| Minor adjustments | Quarterly | Account moves | Sales leadership |
| Major realignment | Annually | Full redesign | Exec team |
| Market changes | As needed | M&A, new products | Cross-functional |
Territory Planning Tools
| Tool | Strength | Best For |
|---|---|---|
| Salesforce Maps | Native integration | Salesforce customers |
| Geopointe | Advanced mapping | Field sales optimization |
| Anaplan | Complex modeling | Large enterprises |
| Xactly | Quota/territory combo | Comp plan alignment |
| Excel/Sheets | Flexibility | Startups, simple models |
| Python + Geopandas | Custom analysis | Data science teams |
Territory Change Communication
## Territory Update: Q2 2025
**Effective Date:** April 1, 2025
**Reason:** Market expansion + team growth
### Changes:
1. Northern California split into two territories
- Bay Area (Rep: Sarah)
- NorCal Non-Bay (Rep: New Hire TBD)
2. Account transfers:
- Acme Corp: Rep A → Rep B (HQ moved)
- BigTech Inc: Rep B → Rep C (industry realignment)
### Transition Rules:
- Deals created before April 1: Original owner
- Deals created April 1+: New owner
- Commission split: 50/50 for 90-day transition
### Questions?
Contact: [email protected]
Anti-Patterns
- Grandfather clauses forever — Reps keep accounts from 5 years ago
- Political territories — Designed around people, not business
- No documentation — No one knows why territories are drawn this way
- Annual-only reviews — Market changes faster than territory updates
- Ignoring travel — Rep has accounts 8 time zones apart
- Unbalanced quotas — Same quota for vastly different territories
- No conflict resolution — Disputes handled ad-hoc