What is the RevOps playbook for forecast sandbagging during usage-based pricing on Salesforce when sales on Outreach ?
What is the RevOps playbook for forecast sandbagging during usage-based pricing on Salesforce when sales on Outreach (batch 1 #481) 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
- [What is the RevOps playbook for forecast sandbagging during usage-based pricing on Salesforce when sales on Outreach ?](/knowledge/q10159)
- [What is the RevOps playbook for forecast sandbagging during usage-based pricing on Salesforce when sales on Outreach ?](/knowledge/q9919)
- [What is the RevOps playbook for forecast sandbagging during usage-based pricing on Salesforce when no dedicated RevOps hire yet ?](/knowledge/q10319)
- [What is the RevOps playbook for forecast sandbagging during usage-based pricing on Salesforce when parent-company rollup reporting ?](/knowledge/q10239)
- [What is the RevOps playbook for forecast sandbagging during usage-based pricing on Salesforce when no dedicated RevOps hire yet ?](/knowledge/q10079)
- [What is the RevOps playbook for forecast sandbagging during usage-based pricing on Salesforce when parent-company rollup reporting ?](/knowledge/q9999)
The Technical Audit: Uncovering Sandbagging Signals in Usage-Based Data
Before any playbook can be executed, you must surface the specific data points where sandbagging hides in usage-based pricing (UBP) environments. Unlike traditional subscription models where sandbagging manifests as understated pipeline value, UBP sandbagging hides in consumption patterns, deployment timelines, and expansion triggers. The audit must focus on three distinct data layers within your Salesforce-Outreach stack.
Layer 1: Consumption Velocity Discrepancies. Create a custom Salesforce report comparing Monthly Active Usage (MAU) against Forecasted Consumption at the account level. Pull Outreach call logs and email engagement data to correlate sales activity spikes with usage dips. A typical pattern: an account shows 40% below-forecast usage but has 3x normal Outreach cadence activity from the assigned rep. This signals the rep is delaying expansion conversations to push consumption into the next quarter. Set up a field on the Opportunity object — Usage:Forecast Ratio — calculated as (Actual Usage / Forecasted Usage) * 100. Flag any ratio below 60% with a warning icon in your Salesforce dashboard.
Layer 2: Deployment Timeline Manipulation. In UBP, sandbaggers often delay go-live dates or understate deployment milestones to keep consumption low. Audit your Salesforce Contract and Opportunity objects for a field called Go-Live Date vs. First Usage Date. Pull Outreach sequence data to see if reps are sending “implementation delay” emails or scheduling “check-in” calls that have no substantive content. Create a custom report titled “Deployment Gap Analysis” that shows accounts where the gap between Go-Live Date and First Usage exceeds 30 days. For these accounts, review the Outreach call recordings — if a rep is actively discouraging rapid deployment (e.g., “Let’s take it slow to make sure everything works”), that’s a sandbagging red flag.
Layer 3: Expansion Trigger Suppression. Sandbaggers in UBP often suppress expansion triggers by underreporting usage spikes. In Salesforce, create a Usage Spike Alert field that triggers when an account’s weekly usage exceeds 120% of the trailing 4-week average. Cross-reference this with Outreach activity: if a rep receives a spike alert but has zero follow-up activity (email, call, or task) within 48 hours, it’s a strong indicator of intentional suppression. Set up a Salesforce automation that creates a Sandbagging Review Task for the RevOps team whenever this pattern occurs.
The audit output should be a single Salesforce dashboard with three tiles: “Accounts with Consumption Velocity Gaps,” “Deployment Timeline Anomalies,” and “Suppressed Expansion Triggers.” Each tile should link directly to the underlying Opportunity records. This gives you a measurable baseline — aim to reduce the number of flagged accounts by 30% within the first 90 days of the playbook.
The Pulse Metric: Designing a Weekly Sandbagging Scorecard
Most RevOps teams drown in data but starve for actionable signals. The answer is a single weekly pulse metric — the Sandbagging Risk Score (SRS) — that lives in a Salesforce dashboard and is automatically updated via a scheduled Apex job or Flow. The SRS combines three weighted factors, each pulled from your audit findings:
Factor 1: Consumption Gap Index (CGI) — 40% weight. Calculate as (Forecasted Consumption - Actual Consumption) / Forecasted Consumption. A score of 0.0 means consumption matches forecast; 1.0 means zero consumption against forecast. Set a threshold: any account with CGI > 0.4 gets 10 risk points. Pull data from your Usage:Forecast Ratio field.
Factor 2: Deployment Delay Factor (DDF) — 30% weight. Measure days between Go-Live Date and First Usage Date. For accounts with a gap > 30 days, assign 5 risk points plus 1 additional point for every 10 days beyond 30. Cap at 20 points. This prevents extreme outliers from skewing the score.
Factor 3: Expansion Suppression Signal (ESS) — 30% weight. Count the number of Usage Spike Alerts in the trailing 30 days that had zero Outreach follow-up within 48 hours. Each suppressed alert adds 3 risk points. If a rep has 3 or more suppressed alerts across any accounts in a single week, add an additional 10 points to all their accounts (this catches pattern sandbaggers).
The total SRS is the sum of these weighted factors, normalized to a 0-100 scale. A score of 0-20 is green (low risk), 21-50 is yellow (medium risk — review), and 51+ is red (high risk — immediate intervention required). Build this in Salesforce using a formula field on the Account object or a custom object that stores weekly snapshots.
Automation in Salesforce: Schedule a weekly Apex job (or use Flow with scheduled paths) that runs every Monday at 6 AM. The job recalculates SRS for all active accounts with UBP contracts and updates a Sandbagging Risk Score field. Simultaneously, create a Weekly Pulse Report that emails the RevOps team with a summary: total accounts in red, yellow, and green, plus the top 5 accounts with the highest SRS. Include a direct link to each account’s Opportunity record.
Outreach integration: Use Outreach’s API to pull call and email activity logs into a custom Salesforce object called Outreach Activity Summary. The weekly Apex job queries this object for the ESS calculation. If you lack API access, create a manual process: every Monday, the RevOps analyst exports Outreach activity for the prior week and uploads it to Salesforce via Data Loader. This manual step is temporary — automate within 30 days.
The measurable outcome: reduce the number of accounts in “red” SRS status by 50% within 6 months. Track this as a line chart in your Salesforce dashboard, with a target line overlaid. If red accounts increase, escalate to the CRO with a root-cause analysis.
The Pilot-to-Automate Sequence: Testing the Playbook on One Segment
You cannot roll out a sandbagging playbook across your entire book of business on day one. The risk of false positives damaging rep morale is too high. Instead, select a single pilot segment — ideally a territory or product line with at least 20 accounts, clear UBP metrics, and a cooperative sales leader. The pilot runs for 60 days and follows a strict sequence: detect, validate, intervene, measure.
Week 1-2: Baseline and Detection. Configure the SRS dashboard for your pilot segment only. Run the weekly pulse report for two weeks without taking any action. This establishes a baseline — you need to know the natural rate of “false positives” (accounts flagged that are not actually sandbagging). In my experience, 20-30% of flagged accounts will be false positives due to genuine deployment delays or seasonal usage dips. Document these patterns.
Week 3-4: Validation Calls. For every account flagged as “yellow” or “red” in the pilot, schedule a 15-minute validation call between the RevOps analyst and the assigned sales rep. The call follows a strict script: “I see your account [Account Name] has a usage-to-forecast gap of X%. Can you walk me through the customer’s deployment status and any blockers?” Do not accuse — gather facts. Record the rep’s explanation in a Salesforce field called Sandbagging Rep Explanation. If the explanation is credible (e.g., “Customer is in a regulatory freeze until next month”), mark the account as “Validated — Not Sandbagging” and adjust the SRS algorithm to exclude that pattern in the future. If the explanation is weak or evasive, escalate to the sales manager.
Week 5-6: Intervention and Measurement. For accounts confirmed as sandbagging, implement a structured intervention. The RevOps owner sends a Salesforce task to the rep: “Within 48 hours, schedule a consumption acceleration call with the customer. Use the approved UBP expansion script (link here).” The task must be completed before the next weekly pulse report. Simultaneously, the sales manager reviews the rep’s Outreach sequence for that account — are they sending the right expansion emails? If not, the manager updates the sequence.
After the intervention, measure the SRS change within 14 days. A successful intervention shows the SRS dropping by at least 30 points (e.g., from red to yellow). If the SRS does not drop, escalate to the CRO for a formal performance improvement plan.
Week 7-8: Automation Handoff. Document every manual step from the pilot and identify what can be automated. Common automation candidates: the SRS calculation (already automated), the validation call scheduling (use Salesforce Flow to auto-create tasks), and the intervention task assignment (triggered when SRS remains red after two weeks). Build these automations in a sandbox first, then deploy to production. By week 8, the pilot should run with 80% automation, requiring only the RevOps analyst’s weekly review of the pulse report.
Scaling the Playbook: After the pilot, present a “Scale Readiness Report” to the CRO. Include: baseline SRS vs. pilot-end SRS (target: 40% reduction in red accounts), false positive rate (target: below 15%), and rep feedback (critical — if reps feel targeted unfairly, adjust the algorithm). If the pilot succeeds, roll out to the next segment (e.g., another territory) with a 30-day ramp. Do not attempt a full org-wide rollout until you have validated the playbook across at least three segments with consistent results.
The final measurable outcome: a 60% reduction in forecast variance due to sandbagging within 12 months, tracked via a custom Salesforce report comparing Forecasted Consumption vs. Actual Consumption at the quarter level. This is the single number your board will care about.
Sources
- Salesforce Official Documentation — Salesforce’s own guides on Revenue Operations, forecasting, and usage-based pricing models.
- Outreach Knowledge Base — Outreach’s official resources on sales engagement workflows and CRM integration best practices.
- Gartner — Industry research on revenue operations strategies, forecasting accuracy, and sales compensation risks.
- Forrester — Analyst reports on usage-based pricing adoption and operational playbooks for B2B SaaS.
- Harvard Business Review — Articles on sales forecasting biases, sandbagging behavior, and organizational incentives.
- RevOps Co-op — Community-driven resources and frameworks for revenue operations, including forecasting and CRM configuration.
FAQ
What exactly is forecast sandbagging in a usage-based pricing model? Forecast sandbagging is when reps intentionally underreport expected usage consumption to make hitting quota easier later. In usage-based pricing, this often means hiding expansion signals like rising API calls or storage consumption until the next quarter.
How do I detect sandbagging in Salesforce when sales uses Outreach? You can audit the gap between Outreach activity data (email opens, meeting requests) and Salesforce opportunity stage movement. A rep with high Outreach engagement but no stage progression or usage data updates is a red flag. Set up a weekly report comparing Outreach sequence completion rates to Salesforce field changes.
What Salesforce fields should I add to prevent sandbagging? Add three proof fields: "Current Month Usage (units)", "Usage Trend (↑/↓/→)", and "Next Quarter Forecast Confidence (Low/Medium/High)". Require these on all usage-based opportunities before they can move past Stage 2. No field update = no stage progression.
Who should own the sandbagging prevention process? A single RevOps analyst should own the audit, field design, and weekly pulse report. This person reports directly to the CRO, not sales leadership, to maintain objectivity. They run the weekly "Pulse" metric comparing forecasted usage to actual consumption.
How do I pilot this without disrupting current sales cycles? Start with one segment—like your top 20 enterprise accounts—and enforce the three proof fields only for that group. Run the pilot for 60 days, measuring forecast accuracy improvement. If you see a 15-20% reduction in end-of-quarter surprises, expand to the next segment.
What’s the simplest automation to sustain this long-term? Build a Salesforce Flow that triggers when an opportunity stage changes: it checks if the three usage fields are populated. If not, it sends a Slack alert to the rep and their manager. Then schedule a weekly report that compares current usage data to the forecasted values from 30 days prior.
Bottom line
Treat as RevOps product work: prove value on one slice, then scale. Polish can deepen this entry later.