{ "version": "1.13.0", "releasedAt": "2026-06-25", "domain": "sales", "kpis": [ { "rogueId": "sales.arr", "slug": "arr", "domain": "sales", "defaultLabel": "ARR", "description": "Annual Recurring Revenue — the value of all recurring subscription revenue normalized to a one-year run-rate as of the period close. The headline operating metric for a subscription business; every growth and efficiency ratio (NRR, GRR, magic number, CAC payback, Rule of 40) is calibrated against it. Excludes one-time fees, professional services, and non-contractual usage. Common pitfall: confusing ARR (contracted recurring) with revenue (recognized) or with CARR (contracted incl. not-yet-live) — the SMSB standard draws sharp lines between them, and boards expect the same discipline. The KpiVarianceTable widget surfaces forecast / actual / variance / status / future-forecast columns against the same field.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "Sales" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/annual-recurring-revenue", "sectionRef": "ARR", "publicationDate": "2023-01-01", "attributionNotice": "Metric definitions reference standards published by the SaaS Metrics Standards Board (saasmetricsboard.com). imboard is not affiliated with, endorsed by, or a member of SMSB.", "authorityLevel": "self-declared-coalition" }, "formula": "ARR = Sum of annualized value of all active recurring subscription contracts at period close. Per SMSB: includes only the recurring portion of contracts that are live (delivered / in production). Excludes one-time fees, professional services, and usage that is not contractually committed. For multi-year contracts, ARR is the contract value divided by the term in years.", "whyItMatters": "Headline operating number that every other SaaS metric calibrates against — growth rate, efficiency ratios (CAC ratio, magic number, Rule of 40), retention math (NRR, GRR), and valuation multiples all read off ARR. Boards use the period-over-period ARR delta as the first-pass health check for the business.", "interpretationGuidance": "Per KBCM/Sapphire SaaS Survey 2024 §Growth Rate, public-SaaS-comparable private companies in the $5–25M ARR band typically grow ARR 40–60% YoY, falling toward 20–30% by $100M+ ARR; well-below-band growth at any ARR scale is the first thing a board interrogates. Always read ARR alongside Net New ARR (sales.new_business + sales.expansion − sales.churn_arr − sales.downgrades) — flat ARR can mask churn offset by upsell.", "relatedKpiIds": [ "sales.carr", "sales.new_business", "sales.expansion", "sales.churn_arr", "sales.downgrades", "sales.growth_rate_yoy", "sales.starting_arr", "customers.net_revenue_retention", "operations.rule_of_40" ], "calculationPolicy": { "inclusionRules": [ "Recurring revenue from contracts that are live / delivered / in production at the period close.", "Annualized value of multi-year contracts is the contract value divided by the term in years (not first-year ARR, not back-loaded).", "Contractually committed usage minimums count as recurring (the floor, not the expected overage)." ], "exclusionRules": [ "One-time fees: setup, implementation, onboarding, professional services, training — even when invoiced on a recurring cadence.", "Non-committed usage / overage revenue (only contractual minimums count).", "Signed contracts not yet live (those belong in CARR; promote to ARR on go-live).", "Recognized revenue, invoiced revenue, or bookings — ARR is contracted-recurring run-rate, not any of those." ], "requiredInputs": [ "Contract status (live / signed-not-live / churned).", "Contract value (annualized, multi-year divided by term).", "Contract start date and term length (months or years).", "Recurring-vs-one-time flag per line item (or per contract if line items are not modeled)." ], "dataSourcePriority": [ "CRM contract / subscription system with explicit go-live status (Salesforce, HubSpot Subscription Module, Zuora, Chargebee).", "Billing system as a fallback when contract status is not modeled — but verify against the contract data, since billing can run ahead of go-live.", "Spreadsheet exports: only when nothing else exists; flag uncertainty in the output." ], "edgeCases": [ "Partial-month or mid-period starts: prorate or use end-of-period contract value, but be consistent across the time series.", "Contract amendments (price changes, term extensions): re-annualize from the amendment date; do not back-fill prior periods.", "Pauses / suspensions: treat as churn unless contract is held open with go-live SLA — flag the ambiguity in any output.", "Multi-currency: normalize to a single reporting currency at a stable FX rate (period-end or a documented fixed rate); never mix.", "Ramp contracts (escalating annual fees): use the contractually committed annual value for the period, not the average over the ramp." ], "validationChecks": [ "Ending ARR ≈ Starting ARR + New Business + Expansion − Downgrades − Churn ARR — if the waterfall does not reconcile to within 1%, the underlying components are misclassified.", "ARR ≤ total contracted value across all live contracts.", "Year-over-year growth rate sits within the KBCM/Sapphire band for the ARR scale; out-of-band growth in either direction is a calculation red flag, not a story." ], "commonMiscomputations": [ "ARR-vs-CARR confusion: including signed-but-not-yet-live contracts inflates ARR and contradicts the SMSB definition. If unsure, report both ARR and CARR separately and let the reader pick.", "Recognized revenue × 12 or × 4: this is run-rate revenue, not ARR. The two diverge when service revenue is recognized at a different cadence than subscription value.", "MRR × 12 only matches ARR when MRR itself is calculated from contracted recurring (not from invoiced or recognized revenue) — verify upstream.", "Counting expansion or renewal ARR in the \"new business\" line — inflates the acquisition motion and hides a stalled new-logo engine.", "Mixing fiscal-year-end ARR and period-end ARR in the same chart: always pin to one snapshot definition per series." ], "inclusionRulesStructured": [ { "rule": "Include rows whose normalized status is \"live\" (delivered / in production at period close).", "mutability": "invariant", "provenance": "imboard-authored" }, { "rule": "Monthly intervals annualize × 12; annual taken as stated; multi-year = contract value ÷ term in years.", "mutability": "invariant", "provenance": "anchor-derived", "sourceId": "smsb-v1" } ], "exclusionRulesStructured": [ { "rule": "Exclude rows with current_period_start in the future (signed-not-yet-live belongs in CARR).", "mutability": "invariant", "provenance": "imboard-authored" }, { "rule": "Exclude one-time fees and non-committed usage / overage (only contractual minimums count).", "mutability": "invariant", "provenance": "anchor-derived", "sourceId": "smsb-v1" }, { "rule": "Treatment of \"paused\" / suspended subscriptions.", "mutability": "company-defined", "provenance": "imboard-authored", "default": "excluded" } ], "validationAssertions": [ { "assert": "result >= 0", "severity": "error", "message": "ARR cannot be negative — recurring contracted revenue is a non-negative quantity." } ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "contracted_arr", "dateBasis": "go_live", "production": "computed" }, "inputContract": { "fields": [ { "name": "contract_status", "type": "enum", "required": true, "description": "Canonical contract lifecycle the metric reasons about.", "values": [ "live", "signed_not_live", "churned" ] }, { "name": "subscription_status", "type": "enum", "required": false, "description": "Raw billing-system status (Stripe-style), normalized onto the inclusion concept.", "values": [ "active", "past_due", "trialing", "canceled", "paused" ], "normalizationMap": { "active": "live", "past_due": "at_risk", "trialing": "excluded", "canceled": "excluded", "paused": "policy" } }, { "name": "billing_interval", "type": "enum", "required": true, "description": "Monthly intervals annualize × 12; annual taken as stated.", "values": [ "month", "year" ] }, { "name": "amount", "type": "currency", "required": true, "description": "Recurring contract amount in the billing interval." }, { "name": "contract_term_months", "type": "number", "required": false, "description": "For multi-year contracts: ARR = contract value ÷ term in years." }, { "name": "current_period_start", "type": "date", "required": true, "description": "Rows with a start date in the future are excluded." } ] }, "dependencies": [ { "kpi": "sales.starting_arr", "edge": "computesFrom" }, { "kpi": "sales.new_business", "edge": "computesFrom" }, { "kpi": "sales.expansion", "edge": "computesFrom" }, { "kpi": "sales.churn_arr", "edge": "computesFrom" }, { "kpi": "sales.carr", "edge": "validatesAgainst" } ] }, { "rogueId": "sales.average_deal_size", "slug": "average_deal_size", "domain": "sales", "defaultLabel": "Average Deal Size", "description": "Mean dollar value across active pipeline opportunities (Pipeline Value / Pipeline Deal Count). Distinct from sales.avg_contract_value (ACV) which measures closed-won deals — average_deal_size is forward-looking pipeline-shape, ACV is realized output. Common pitfall: a few oversized deals materially skew the average — always inspect median_deal_size alongside; a large gap between average and median signals a few mega-deals that drive most of the projected number, which concentrates pipeline risk.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Average Deal Size = Pipeline Value / Pipeline Deal Count. Same value convention (TCV or ACV) as the upstream metrics. Always report alongside Median Deal Size for skew detection.", "whyItMatters": "Forward-looking signal for ACV mix-shift before it appears in closed-won numbers — pipeline-size trending up usually shows up in closed-won-size 1–2 cycles later. Boards use the lead-time to ask \"is this an intentional up-market move or a mix drift to correct?\"", "interpretationGuidance": "Track the spread (average − median) over time: stable, narrow spread = healthy uniform pipeline; widening spread = increasing concentration risk in a few oversized deals (those deals slipping then becomes catastrophic to the period). Average rising faster than median = up-market mix-shift in pipeline.", "relatedKpiIds": [ "sales.median_deal_size", "sales.pipeline_value", "sales.pipeline_deal_count", "sales.avg_contract_value", "sales.closed_won_value" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "sales.avg_contract_value", "slug": "avg_contract_value", "domain": "sales", "defaultLabel": "Average Contract Value", "description": "Average annualized contract value across new-customer deals signed during the period (ACV). Defines where the company plays on the SaaS deal-size spectrum and dictates the operating model — high-ACV businesses tolerate longer sales cycles and direct sales motions; low-ACV businesses must run product-led or inside-sales motions to keep CAC payback short. Common pitfall: blending new and expansion ACV obscures the new-logo deal-size trend that boards actually want to see. Anchored to KBCM/Sapphire SaaS Survey 2024 §Average Contract Value for cross-company benchmarking.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceUrl": "https://www.cfodesk.co.il/wp-content/uploads/2024/10/2024_kbcm_sapphire_saas_survey.pdf", "sectionRef": "Average Contract Value", "publicationDate": "2024-09-01", "attributionNotice": null, "authorityLevel": "industry-benchmark" }, "benchmark": { "p25": 25000, "median": 62000, "p75": 100000, "unit": "$", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceYear": "2024", "higherIsBetter": true }, "formula": "Average Contract Value = New Business ARR / New Customers Added (for the same period). For multi-year contracts, use the annualized ACV (TCV / contract term in years), not Total Contract Value (TCV). Restrict to new-logo deals to keep the trend interpretable; track Expansion ACV separately if material.", "whyItMatters": "Sets the cost ceiling for the sales motion — at $5k ACV the company cannot afford a field sales team; at $250k ACV inside sales alone usually leaves money on the table. The board uses ACV trend to validate up-market or down-market strategy bets.", "interpretationGuidance": "Per KBCM/Sapphire SaaS Survey 2024 §Average Contract Value, segmentation bands: SMB ≤ $5k, Mid-Market $5k–$50k, Enterprise > $50k (often $100k+ for true enterprise). ACV doubling over four quarters is a clear up-market motion — make sure CAC and sales-cycle changes are reflected in plan. Flat ACV with rising volume = scaling the existing motion; rising ACV with flat volume = a deliberate up-market bet that needs explicit board buy-in.", "relatedKpiIds": [ "sales.new_business", "sales.new_customers_added", "sales.median_deal_size", "sales.average_deal_size", "sales.avg_sales_cycle_days", "sales.cac" ], "calculationPolicy": { "inclusionRules": [ "Numerator: `sales.new_business` (annualized new-logo ARR for the period).", "Denominator: `sales.new_customers_added` (count of new logos in the same period, using the same logo unit).", "Result is annualized — for multi-year contracts use annualized contract value, not TCV." ], "exclusionRules": [ "Expansion ARR in the numerator — that produces Expansion ACV, a different metric. Track separately if material.", "Existing customers in the denominator — same reason.", "Pilots / unpaid trials." ], "requiredInputs": [ "New Business ARR for the period.", "New Customers Added for the period (matching logo unit and same period)." ], "dataSourcePriority": [ "Same CRM source as `sales.new_business` and `sales.new_customers_added` — they must come from the same record set." ], "edgeCases": [ "Single very large enterprise deal: pulls ACV up dramatically. Surface alongside median deal size to spot when one mega-deal is masking the underlying distribution.", "Mid-period logo-unit change: ACV becomes meaningless across the boundary. Keep methodology pinned and back-cast on change.", "Multi-year contracts with ramp pricing: use Year 1 annualized value for the numerator (matches the New Business ARR convention)." ], "validationChecks": [ "ACV = New Business ARR / New Customers Added — recompute and verify against any pre-computed value.", "ACV should sit within the segmentation band consistent with the company's ICP (SMB ≤ $5k, Mid-market $5k-50k, Enterprise > $50k). Out-of-band ACV signals up- or down-market drift worth a narrative line." ], "commonMiscomputations": [ "Including expansion ARR in the numerator — produces a \"blended ACV\" that boards mis-read as new-logo ACV.", "Counting customers (denominator) using a different logo unit than ARR (numerator) — e.g. counting billing entities for revenue but parent accounts for logos — produces nonsense.", "Using TCV instead of annualized ACV — overstates by the contract term (e.g. a 3-year deal looks 3x as large).", "Reporting a single-deal-pulled ACV without flagging the outlier — leadership reads it as motion improvement when it's one good deal.", "Computing ACV from median deal size when ACV should use the arithmetic mean — these are different metrics (`sales.median_deal_size` exists for the median)." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "contracted_arr", "production": "computed" } }, { "rogueId": "sales.avg_sales_cycle_days", "slug": "avg_sales_cycle_days", "domain": "sales", "defaultLabel": "Average Sales Cycle (Days)", "description": "Average number of days from opportunity creation to closed-won status — measured only on won deals (lost deals are tracked separately). The motion-velocity metric — directly determines how much pipeline coverage is needed, how quickly investment in new reps pays back, and how feedback loops on packaging or pricing experiments compound. Common pitfall: blending segment cycles (SMB and Enterprise often differ 5–10×) into a single average hides material trend signals — segment-cut the metric where deal-volume permits.", "fieldType": "number", "unit": "days", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "benchmark": { "p25": 40, "median": 84, "p75": 150, "unit": "days", "sourceName": "imboard Editorial", "sourceYear": "2026", "higherIsBetter": false }, "formula": "Average Sales Cycle (Days) = Σ (close_date − created_date) across closed-won opportunities in period / Count of those opportunities. Restrict to won deals; for cycle-time analysis on lost deals, compute separately.", "whyItMatters": "Determines required pipeline coverage (a 90-day cycle needs ~1 quarter of forward pipeline; a 270-day cycle needs ~3 quarters), and is the leading indicator of ICP fit — strong fit shortens cycles; mismatched fit lengthens them.", "interpretationGuidance": "Typical ranges by ACV band (industry folk-wisdom, not citation-grade): SMB < $5k ACV → 14–45 days; Mid-Market $5k–50k → 45–90 days; Enterprise $50k+ → 90–270 days; Strategic > $250k → 180–365+ days. Cycle lengthening trend over 2+ quarters at constant ACV mix is the canonical \"deals stuck in evaluation\" signal — usually buyer-side decision-process changes (procurement, security review) or competitive friction.", "relatedKpiIds": [ "sales.avg_contract_value", "sales.pipeline_stage_metrics", "sales.pipeline_sales_cycle", "sales.win_rate", "sales.pipeline_value" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "sales.base_currency", "slug": "base_currency", "domain": "sales", "defaultLabel": "Sales Base Currency", "description": "The ISO-4217 currency code (e.g. `USD`) the sales/pipeline feed displays its money metrics in. The bespoke sales and pipeline feed cards read this to choose the currency symbol/format; absent it, they fall back to USD. This is a board-level reporting-currency constant rather than a measured metric. Common pitfall: leaving it unset on a non-USD board — the feed then silently renders USD symbols over non-USD figures.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "Sales" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "A single ISO-4217 currency code. Not a calculation — it is the display/reporting currency the feed formats sales money figures in.", "whyItMatters": "Ensures the sales/pipeline feed renders money in the board's actual reporting currency instead of a silent USD default.", "interpretationGuidance": "Should match the board's reporting currency. If FX conversion is applied upstream, this is the post-conversion display currency, not each deal's original currency.", "relatedKpiIds": [ "sales.arr", "sales.pipeline_value" ] }, { "rogueId": "sales.blended_cac_ratio", "slug": "blended_cac_ratio", "domain": "sales", "defaultLabel": "Blended CAC Ratio", "description": "Total fully-loaded S&M spend in the period divided by the dollars of new CARR generated in the period (new-customer + expansion CARR combined). Per the SMSB standard, the headline efficiency ratio for the full sales-and-marketing motion — answers \"how many cents do we spend on S&M to add one dollar of contracted ARR.\" Common pitfall: blending without separately reporting New CAC Ratio and Expansion CAC Ratio hides which side of the motion is driving efficiency — for a healthy SaaS company expansion CAC is usually 3–5× cheaper per dollar than new-logo CAC.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales", "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/blended-cac-ratio", "sectionRef": "Blended CAC Ratio", "publicationDate": "2023-01-01", "attributionNotice": "Metric definitions reference standards published by the SaaS Metrics Standards Board (saasmetricsboard.com). imboard is not affiliated with, endorsed by, or a member of SMSB.", "authorityLevel": "self-declared-coalition" }, "formula": "Blended CAC Ratio = Total S&M Spend (period) / (New CARR + Expansion CARR generated in period). Per SMSB §Blended CAC Ratio: spend uses the same fully-loaded definition as CAC; CARR-based denominator (not ARR) reflects committed contract value at the point of sign.", "whyItMatters": "The portfolio-level efficiency number — one ratio that summarizes the full S&M engine. Boards use it to track quarter-over-quarter efficiency improvement as the motion matures.", "interpretationGuidance": "Per SMSB convention, a Blended CAC Ratio < 1.0 means the company is acquiring more contracted ARR than it spends on S&M — capital-efficient growth. 1.0–1.5 is acceptable while the motion is scaling; > 2.0 sustained signals either a motion or pricing problem. Always pair with the New and Expansion CAC Ratio split to localize the issue.", "relatedKpiIds": [ "sales.new_cac_ratio", "sales.expansion_cac_ratio", "sales.cac", "sales.cac_payback_period", "sales.new_business", "sales.expansion", "sales.carr" ], "calculationPolicy": { "inclusionRules": [ "Numerator: total fully-loaded S&M spend for the period (same definition as `sales.cac`).", "Denominator: total new CARR generated in the period — new-customer CARR + expansion CARR combined.", "Use CARR (contracted, including signed-not-yet-live) for the denominator, per SMSB convention — it reflects committed value at the point of sign." ], "exclusionRules": [ "R&D / G&A / COGS from the numerator.", "Renewal CARR from the denominator — renewals are not new selling activity.", "Churn / downgrades — this is a gross-efficiency ratio, not a net one." ], "requiredInputs": [ "Fully-loaded S&M spend for the period.", "New-customer CARR for the period.", "Expansion CARR for the period." ], "dataSourcePriority": [ "Financials for S&M spend; CRM for new + expansion CARR, same period boundary." ], "edgeCases": [ "Sales-cycle lag: same consideration as `sales.cac` — for long cycles, consider lagging S&M and disclose.", "A quarter with near-zero new CARR (e.g. seasonal trough) produces an enormous ratio — annualize or use a trailing window for stability, and disclose." ], "validationChecks": [ "Blended CAC Ratio should sit between New CAC Ratio and Expansion CAC Ratio — it is a weighted blend. If it falls outside that range, the spend allocation or the CARR split is wrong.", "A ratio < 1.0 means more contracted ARR added than S&M spent — capital-efficient. Sustained > 2.0 is a motion/pricing problem." ], "commonMiscomputations": [ "Using ARR instead of CARR in the denominator — understates the denominator by the implementation backlog and overstates the ratio.", "Reporting only the blended number without the New / Expansion split — hides which motion is driving (or dragging) efficiency.", "Including renewal CARR in the denominator — renewals cost almost nothing and artificially deflate the ratio.", "Mixing a CARR denominator with an ARR-based New/Expansion split — the three ratios then fail to reconcile." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "sales.bookings_backlog", "slug": "bookings_backlog", "domain": "sales", "defaultLabel": "Bookings Backlog", "description": "Total value of signed contracts that have not yet been recognized as revenue — future revenue locked into the books. Equivalent to \"remaining performance obligation\" (RPO) in public-SaaS disclosures, though private companies often track only the in-period portion. Board reads this as the visibility horizon: a healthy backlog means recognized revenue is largely already-sold and not dependent on Q-end heroics. Common pitfall: confusing backlog with pipeline — backlog is contractually committed, pipeline is unsigned opportunity. Surface the two on the same dashboard but never sum them.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales", "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Bookings Backlog = TCV of all signed customer contracts − Revenue already recognized against those contracts. For a SaaS business, the dominant component is unrecognized subscription value on multi-month / multi-year contracts. Most-comparable public-disclosure equivalent: ASC 606 Remaining Performance Obligation (RPO).", "whyItMatters": "The single best read on next-period revenue predictability — high backlog means the revenue line for the coming quarter is largely contractual, not pipeline-dependent. Boards use it to gauge whether the team is selling for in-quarter close or building durable forward visibility.", "interpretationGuidance": "Backlog at year-end ≥ 1.0× the next year's ARR plan is the \"visible year\" threshold most boards expect at Series B+ subscription companies (industry folk-wisdom — no single published standard; the underlying conventions derive from ASC 606 RPO disclosure norms in public-SaaS filings). Backlog declining as a share of forward plan = visibility eroding; usually demands a sales-cycle or pipeline-coverage drill-down.", "relatedKpiIds": [ "sales.bookings_backlog_total", "sales.total_revenue", "sales.arr", "sales.carr", "sales.pipeline_value", "sales.weighted_forecast" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "bookings", "production": "computed" } }, { "rogueId": "sales.bookings_backlog_changes", "slug": "bookings_backlog_changes", "domain": "sales", "defaultLabel": "Bookings Backlog Changes", "description": "Structured bridge that reconciles opening bookings backlog to closing backlog through the period's new bookings, conversions to revenue, post-contract losses, and value adjustments (starting + new − converted − lost + increases − decreases = ending). The bespoke sales card reads this typed object to show the backlog motion. Distinct from the editor's `sales.bookings_backlog_total` FlowSubform container — this is the typed `IBookingsBacklog` the feed card consumes. Common pitfall: an ending value that does not reconcile because conversions to recognized revenue were not netted out.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales", "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — { startingBackLogValue, newBookingValue, bookingsConvertedToRevenue, lostBookingsPostContract, backlogValueIncreases, backlogValueDecreases, endingBackLogValue, netChange, netChangePercent }. Identity: starting + new − converted − lost + increases − decreases = ending.", "whyItMatters": "Makes signed-but-not-yet-recognized revenue auditable — a growing backlog is forward revenue visibility; a shrinking one (conversions outpacing new bookings) is an early top-of-funnel warning.", "interpretationGuidance": "When conversions consistently exceed new bookings, the backlog erodes and future recognized revenue will soften. Disproportionate post-contract losses signal delivery or scoping problems.", "relatedKpiIds": [ "sales.bookings_backlog_total", "sales.bookings_backlog", "sales.arr" ] }, { "rogueId": "sales.bookings_backlog_total", "slug": "bookings_backlog_total", "domain": "sales", "defaultLabel": "Bookings Backlog Total", "description": "Total dollar value of all signed contracts that have not yet been recognized as revenue — the visibility window into future revenue at a point in time. Closely related to sales.bookings_backlog; this entry serves as the FlowSubform `start` slot for the per-period bookings-backlog flow (open + new bookings − recognized − cancellations = close). Common pitfall: omitting cancellations from the flow leaves a phantom backlog that overstates future revenue visibility — every backlog flow needs an explicit cancellation line even when zero.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Bookings Backlog Total at period close = Σ TCV of all signed contracts − Σ revenue recognized to date against those contracts. Equivalent to ASC 606 RPO. The per-period flow: opening backlog + new bookings (TCV signed in period) − revenue recognized in period − cancellations = closing backlog.", "whyItMatters": "Quantifies how much of forward revenue is already contracted — high ratios of backlog to forward plan = high revenue predictability. Boards use it to assess whether the business has visibility or is running quarter-to-quarter on pipeline conversion.", "interpretationGuidance": "Backlog at year-end ≥ 1.0× next-year ARR plan is the conventional \"visible year\" benchmark for Series B+ subscription companies (industry folk-wisdom — anchored to public-SaaS RPO disclosure norms but not a published cross-company threshold). Track the cancellation share of the flow — rising cancellations as a % of opening backlog signal contract instability.", "relatedKpiIds": [ "sales.bookings_backlog", "sales.total_revenue", "sales.arr", "sales.carr", "sales.new_business" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "bookings", "production": "computed" } }, { "rogueId": "sales.cac", "slug": "cac", "domain": "sales", "defaultLabel": "Customer Acquisition Cost", "description": "Fully-loaded sales-and-marketing (S&M) expense incurred to acquire one new customer during the period. Per the SMSB standard, the CAC numerator includes salaries + commissions + benefits + travel + marketing programs + tooling — i.e. all S&M costs, not just direct-attribution paid acquisition. The denominator is new logos, not deals. Common pitfall: omitting fully-loaded comp (especially BDR/SDR base salary and CS-team cost-of-sale where they participate in expansion) understates CAC and inflates every downstream efficiency metric. The board cares about CAC alongside CAC Payback and the CAC Ratio family — single-number CAC is a building block, not a verdict.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales", "Finance" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/customer-acquisition-cost", "sectionRef": "CAC", "publicationDate": "2023-01-01", "attributionNotice": "Metric definitions reference standards published by the SaaS Metrics Standards Board (saasmetricsboard.com). imboard is not affiliated with, endorsed by, or a member of SMSB.", "authorityLevel": "self-declared-coalition" }, "formula": "CAC = Total fully-loaded S&M expense for the period / New Customers Added in the period. Per SMSB §CAC: numerator includes all S&M spend (compensation, benefits, programs, tooling, allocated overhead); denominator counts net-new logos only (not expansion deals).", "whyItMatters": "The cost side of the customer-unit economics ledger — paired with ACV and gross margin, determines whether each customer is a profitable transaction over a reasonable horizon. Boards read CAC alongside payback period before debating S&M investment levels.", "interpretationGuidance": "Absolute CAC values vary by ACV band — what matters is the ratio CAC / first-year-ARR (= New CAC Ratio) and CAC Payback. Per public SaaS comps, healthy CAC payback is < 24 months gross-margin-adjusted; > 36 months usually means the acquisition motion is either too expensive or the contract terms too short.", "relatedKpiIds": [ "sales.cac_payback_period", "sales.new_cac_ratio", "sales.blended_cac_ratio", "sales.expansion_cac_ratio", "sales.new_business", "sales.new_customers_added" ], "calculationPolicy": { "inclusionRules": [ "Numerator: total fully-loaded S&M expense for the period — all sales + marketing compensation (base, commission, benefits), marketing programs, sales/marketing tooling, travel, allocated S&M overhead.", "Denominator: count of net-new logos acquired in the same period (`sales.new_customers_added`).", "Result is a per-customer dollar figure." ], "exclusionRules": [ "R&D, G&A, and COGS — CAC is S&M-only.", "Expansion-attributed S&M / CS cost — that belongs in `sales.expansion_cac_ratio`. If AEs do both, allocate by a documented rule.", "Expansion deals in the denominator — count new logos only.", "Stock-based compensation if the company reports cash CAC (disclose which basis is used)." ], "requiredInputs": [ "Fully-loaded S&M expense for the period.", "New logos acquired in the same period.", "If AEs split new vs expansion: the documented allocation rule (e.g. fraction of OTE tied to new-business quota)." ], "dataSourcePriority": [ "Audited or reviewed financials for S&M expense.", "CRM for new-logo count, matched to the same period boundary." ], "edgeCases": [ "CAC-lag: S&M spent this quarter often acquires customers next quarter. For long sales cycles, consider a trailing-spend window (e.g. lag S&M by the average sales-cycle length) and disclose the method.", "Founder-led sales with no formal S&M line: impute a market-rate cost or flag CAC as not-yet-meaningful — never report a near-zero CAC.", "Marketing brand spend that benefits future periods: include it in the period spent; do not capitalize it." ], "validationChecks": [ "CAC is positive.", "CAC ÷ first-year ACV ≈ New CAC Ratio — cross-check the two.", "CAC at a > $5M ARR company that comes out implausibly low (e.g. < $1k for a $30k-ACV product) almost always means S&M is not fully loaded." ], "commonMiscomputations": [ "Omitting fully-loaded comp — especially SDR/BDR base salary, sales-ops, and sales-engineering — understates CAC and inflates every downstream efficiency metric.", "Counting expansion deals in the denominator — makes the new-logo motion look cheaper than it is.", "Using only paid-media spend (\"ad CAC\") and calling it CAC — ignores the much larger people cost.", "Period mismatch: S&M from one period, new logos from another. For long cycles this is defensible only if explicitly lag-adjusted and disclosed.", "Dividing by deal count instead of distinct new logos — multi-deal customers inflate the denominator and understate CAC." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "cash", "production": "computed" } }, { "rogueId": "sales.cac_payback_period", "slug": "cac_payback_period", "domain": "sales", "defaultLabel": "CAC Payback Period", "description": "Number of months required for the gross profit generated from a new customer's ARR to recover the fully-loaded S&M spend used to acquire them. The single most decision-useful efficiency metric at the board level — it directly connects acquisition cost, ACV, and gross margin into one \"how long until we break even on this customer\" answer. Per the SMSB standard, the calculation must use gross-margin-adjusted ARR in the denominator (not raw ARR) to be cross-company comparable. Common pitfall: using raw ARR understates payback by ~25–30 percentage points and breaks comparability with peer benchmarks.", "fieldType": "number", "unit": "months", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales", "Finance" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/cac-payback-period", "sectionRef": "CAC Payback Period", "publicationDate": "2023-01-01", "attributionNotice": "Metric definitions reference standards published by the SaaS Metrics Standards Board (saasmetricsboard.com). imboard is not affiliated with, endorsed by, or a member of SMSB.", "authorityLevel": "self-declared-coalition" }, "formula": "CAC Payback (months) = Total fully-loaded S&M spend (period) / (Monthly New ARR × Gross Margin %). Both numerator and denominator are period aggregates — the numerator is total S&M spend for the period, NOT per-customer CAC (pairing per-customer cost with aggregate new ARR is a dimensional error that yields months-per-customer). The denominator is gross-margin-adjusted total monthly new ARR. Per SMSB §CAC Payback Period: the gross-margin adjustment makes the metric comparable across companies with different cost structures.", "whyItMatters": "The decision-relevant single number for \"is the acquisition motion working\" — sub-24 months signals capital-efficient growth; > 36 months means each dollar of S&M is locking up cash for too long to justify scaling spend.", "interpretationGuidance": "Per the SaaS-investor convention reflected in KBCM/Sapphire SaaS Survey 2024 benchmarking: < 24 months gross-margin-adjusted payback is healthy; 24–36 months is acceptable for early-stage / up-market motions; > 36 months requires either an explicit path to compress (motion change) or a strategic rationale (e.g. multi-year deferred-revenue contracts with strong retention).", "relatedKpiIds": [ "sales.cac", "sales.new_cac_ratio", "sales.blended_cac_ratio", "sales.gross_margin", "sales.new_business", "sales.arr" ], "calculationPolicy": { "inclusionRules": [ "Numerator: total fully-loaded S&M spend for the period — all S&M compensation (base, commissions, benefits), marketing programs, tooling, allocated overhead. This is the period aggregate, NOT per-customer CAC.", "Denominator: new-customer ARR only (from `sales.new_business`), gross-margin-adjusted, normalized to a monthly figure — also a period aggregate, so it pairs dimensionally with the aggregate numerator.", "Gross margin uses the company-reported gross margin % for the same period." ], "exclusionRules": [ "Expansion ARR in the denominator (use `sales.expansion_cac_ratio` for that motion separately).", "Renewal ARR in the denominator (renewals are not acquisition).", "Non-S&M costs in the numerator (do not include R&D, G&A, or COGS — those belong in unit economics, not in CAC).", "Revenue (recognized) in place of ARR — payback is a contracted-recurring metric." ], "requiredInputs": [ "Fully-loaded S&M spend for the period (CAC numerator).", "New-customer ARR signed in the same period.", "Gross margin % for the same period.", "Period length so monthly conversion is explicit (annual → ÷12, quarterly → ÷3)." ], "dataSourcePriority": [ "Audited or reviewed financials for S&M spend and gross margin.", "CRM-derived new-business ARR for the same period (matched to the same start/end dates as the S&M figure)." ], "edgeCases": [ "Period mismatch (S&M from Q1, new ARR from Q2): pick a single period and recompute both; otherwise the ratio is meaningless.", "Founder-led sales (no formal S&M line): impute a market-rate AE/marketing cost or flag the metric as not-yet-meaningful — do not report a zero-CAC payback.", "Customer-success cost participating in expansion: include the share attributable to acquisition (typically zero); do NOT pull CS into new-customer CAC.", "Negative gross margin (early-stage with heavy hosting cost): the formula breaks; report payback as N/A and flag the underlying GM problem.", "Multi-year contracts: use first-year ARR only in the denominator — payback is a year-one cash-recovery metric." ], "validationChecks": [ "Result is in months and positive; payback < 6 months at >$5M ARR usually means the numerator is missing fully-loaded comp.", "Sanity-check against `sales.new_cac_ratio`: payback ≈ (CAC ratio × 12) / gross margin %.", "Compare to KBCM/Sapphire band for the ARR scale; an out-of-band result is more likely a calculation error than a true outlier." ], "commonMiscomputations": [ "Pairing per-customer CAC (the `sales.cac` value) with aggregate Monthly New ARR — a dimensional mismatch that yields months-per-customer, not months. The numerator and denominator must both be period aggregates: total S&M spend over total monthly new ARR.", "Dropping the gross-margin adjustment (total S&M / Monthly New ARR, without × Gross Margin %) — overstates efficiency by ~25–30 percentage points and breaks comparability with peer benchmarks.", "Using total net new ARR (including expansion) in the denominator — makes acquisition look artificially efficient and obscures whether new-logo motion is working.", "Using annual new ARR directly without monthly normalization — produces a payback ~12× off (number reads as years instead of months, or vice versa).", "Omitting fully-loaded S&M (esp. SDR base pay, sales ops, tooling, marketing programs) — common in early-stage models; understates CAC and breaks peer comparability.", "Using bookings or invoiced revenue in place of new ARR — they recognize at different cadences and produce different payback numbers.", "Period mismatch between numerator and denominator (S&M and ARR from different periods) — most common when carrying numbers across a fiscal-year boundary." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "sales.carr", "slug": "carr", "domain": "sales", "defaultLabel": "CARR", "description": "Contracted Annual Recurring Revenue — recognized MRR × 12 plus the annualized value of contracts that are signed but not yet live (i.e. implementation, ramp, deferred-start). Per the SMSB standard, CARR sits between ARR (live only) and pipeline (unsigned) on the revenue-certainty spectrum: contractually committed but not yet delivered. Boards reading CARR > ARR gap can quantify the in-flight implementation backlog and the leading indicator of next-period ARR. Common pitfall: counting verbal commitments or LOIs as CARR — only signed contracts qualify under the SMSB definition.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "Sales" ], "stageRelevance": { "preSeed": "recommended", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/contracted-annual-recurring-revenue", "sectionRef": "CARR", "publicationDate": "2023-01-01", "attributionNotice": "Metric definitions reference standards published by the SaaS Metrics Standards Board (saasmetricsboard.com). imboard is not affiliated with, endorsed by, or a member of SMSB.", "authorityLevel": "self-declared-coalition" }, "formula": "CARR = ARR (live, recognized contracts annualized) + Annualized value of signed contracts not yet in production. Per SMSB §CARR: requires a signed contract; excludes verbal commitments, letters of intent, and pipeline. The (CARR − ARR) gap = in-flight ARR awaiting go-live.", "whyItMatters": "A leading indicator that ARR alone misses — if CARR is growing faster than ARR, an implementation backlog is building and ARR will accelerate as those contracts go live. Boards use the CARR-to-ARR ratio to interrogate the implementation engine.", "interpretationGuidance": "A CARR / ARR ratio of 1.00 means everything signed is already live (no implementation backlog); 1.10–1.20 is typical for enterprise SaaS with multi-month implementation timelines; > 1.30 may signal either an implementation bottleneck (operational risk) or a deliberate backlog-build before a known activation event (intentional). Always cross-reference with the implementation team's capacity plan.", "relatedKpiIds": [ "sales.arr", "sales.new_business", "sales.blended_cac_ratio", "sales.new_cac_ratio", "sales.bookings_backlog_total" ], "calculationPolicy": { "inclusionRules": [ "ARR (live, recognized contracts annualized) plus the annualized value of signed contracts not yet in production.", "Requires a signed contract — same recurring-contract definition as ARR; CARR uses the same multi-year handling (contract value divided by term in years)." ], "exclusionRules": [ "Verbal commitments, letters of intent, qualified pipeline — these are pipeline, not CARR.", "One-time fees and non-committed usage (same exclusions as ARR).", "Cancelled contracts even if recently signed." ], "requiredInputs": [ "Live ARR figure for the same period close.", "List of signed contracts with `not yet live` status and their annualized contract value.", "Signed-date and expected go-live-date per pending contract (used in edge-case handling)." ], "dataSourcePriority": [ "CRM contract module with explicit `signed but not live` status (Salesforce opportunity stage + go-live field).", "Manual signed-contract log when CRM does not model the implementation backlog." ], "edgeCases": [ "Contracts signed but with conditional or rolling go-live dates: include in CARR only if the contract is unconditional.", "Long implementation cycles (> 6 months): include but flag separately; boards may want to see ARR + near-term CARR + far-term CARR.", "Contracts with deferred-start clauses: include from signature date, not from intended start." ], "validationChecks": [ "CARR ≥ ARR always; if not, the underlying classifications are wrong.", "(CARR − ARR) should equal the sum of `signed-not-live` contract annualized values." ], "commonMiscomputations": [ "Reporting CARR as if it were ARR — this is the single most common source of board-deck inflation; always show the (CARR − ARR) gap explicitly.", "Including pipeline / LOIs / verbal commitments — those are not contracted and do not qualify.", "Failing to migrate a CARR contract to ARR on go-live — leaves it double-counted or stranded; reconcile each period." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "contracted_arr", "dateBasis": "signed", "production": "computed" }, "dependencies": [ { "kpi": "sales.arr", "edge": "computesFrom" }, { "kpi": "sales.bookings_backlog_total", "edge": "computesFrom" } ] }, { "rogueId": "sales.churn_arr", "slug": "churn_arr", "domain": "sales", "defaultLabel": "Churned ARR", "description": "Annualized recurring revenue lost during the period from customers who fully cancelled — terminating their contract or letting it lapse without renewal. The \"leak\" line of the ARR waterfall and the denominator of Gross Revenue Retention. Distinct from Downgrade ARR (sales.downgrades) which captures contractions where the customer stays. Common pitfall: lumping mid-term cancellations with non-renewals masks two very different retention failures — surface them separately when material. The KpiVarianceTable widget tracks period forecast vs actual; a widening miss against forecast is the earliest signal of a retention problem.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "preSeed": "recommended", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Churned ARR = Sum of ARR from contracts that terminated during the period (cancelled mid-term or not renewed at the end of term) attributable to customers whose ARR with the company drops to zero. Excludes contractions where the customer remains (those land in Downgrade ARR).", "whyItMatters": "Direct read on Gross Revenue Retention (GRR) — the floor of the retention math, since downgrades and churn cannot be offset by upsell in GRR. A board can tolerate slow new-logo growth if churn is low, but cannot tolerate high churn at any growth rate — it compounds against valuation.", "interpretationGuidance": "Per KBCM/Sapphire SaaS Survey 2024 §Gross Revenue Retention, top-quartile SaaS companies hold GRR ≥ 90% (enterprise-segment) or ≥ 85% (SMB-segment); GRR below 80% in either segment usually means the product or onboarding has a structural problem, not a sales-execution one. Pair this line with the Customers domain to identify whether churn concentrates in a particular segment or cohort.", "relatedKpiIds": [ "sales.arr", "sales.downgrades", "sales.expansion", "customers.gross_revenue_retention", "customers.net_revenue_retention", "customers.logo_retention_rate", "customers.logo_churn_rate" ], "calculationPolicy": { "inclusionRules": [ "Annualized ARR of contracts that terminated during the period such that the customer's total ARR with the company drops to zero.", "Both mid-term cancellations and non-renewals count.", "Use the customer's ARR at the most recent live period close as the churned amount (don't pro-rate the partial period of service)." ], "exclusionRules": [ "Contractions where the customer remains (seat reductions, tier downgrades) — those are `sales.downgrades`.", "New-logo failures (customer signed but never went live and was refunded) — these were never ARR and don't belong in churn.", "Pause / suspension if the contract is still open with a defined return SLA — flag separately as \"paused ARR\" rather than churned." ], "requiredInputs": [ "Customer-level ARR snapshot at period start.", "Customer-level termination dates and cancellation reason codes if available.", "Distinction between mid-term cancellation and non-renewal (these are often surfaced separately on board packs)." ], "dataSourcePriority": [ "Customer-level ARR ledger with churn events.", "CRM opportunity / renewal stages as a fallback." ], "edgeCases": [ "Customer terminates one product but keeps another: the per-customer ARR delta is negative but non-zero — that goes in `sales.downgrades`, NOT churn.", "Customer is acquired by another company and the contract is novated to the acquirer: typically count as retention, not churn (account identity transfers).", "Bankruptcy / non-payment write-offs: count as churn from the date the contract is voided.", "Mid-term cancellation with a non-cancellable balance still due: still count as churn from the cancellation effective date; the unpaid balance is an AR issue, not an ARR one." ], "validationChecks": [ "Churned ARR ≥ 0 always.", "GRR = (Starting ARR − Churned − Downgrades) / Starting ARR. Bounded at 100% — recompute if violated.", "Per-customer churned amount ≤ that customer's period-start ARR." ], "commonMiscomputations": [ "Lumping downgrades and churn into a single \"churn\" number — masks the contraction-vs-cancellation signal that the waterfall exists to reveal.", "Counting customers who never went live (refunded new logos) as churn — they were never ARR.", "Using cancellation-request date instead of contract-end date for the period attribution — produces phantom churn in the request quarter and missing churn in the actual cancellation quarter.", "Treating \"paused\" customers as churned (or vice versa) — pick a convention and apply it; mid-stream policy changes corrupt the trend.", "Forgetting to remove the customer from the starting-cohort base for the next period — produces double-counting in the next quarter's retention math." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "contracted_arr", "dateBasis": "period_close", "production": "primary" }, "dependencies": [ { "kpi": "customers.churn_risks", "edge": "narrates" }, { "kpi": "customers.percent_arr_at_risk", "edge": "contextualizes" } ] }, { "rogueId": "sales.closed_lost_count", "slug": "closed_lost_count", "domain": "sales", "defaultLabel": "Deals Lost", "description": "Count of opportunities that transitioned to closed-lost during the period — the volume side of pipeline disqualification. The other half of the win rate denominator; without tracking it explicitly you cannot compute or benchmark win rate. Common pitfall: stale \"open\" deals that should be marked lost are left open, inflating pipeline value while suppressing the lost count — a hygiene problem that compounds because next-period coverage looks fine while win rates silently degrade. Every CRM hygiene policy should specify a max-age before deals auto-flag for lost-or-update review.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Closed-Lost Count = Count of distinct opportunities whose stage transitioned to closed-lost during the period. Excludes \"no decision\" / paused opportunities (which should have a separate stage); excludes disqualified-pre-pipeline opportunities.", "whyItMatters": "Denominator input for win rate and direct read on pipeline hygiene. Cluster analysis of loss reasons feeds product / pricing / positioning decisions that boards expect to see referenced in strategic_context.", "interpretationGuidance": "Track loss-reason distribution quarter-over-quarter — concentration in \"price\" usually points to packaging; concentration in \"feature gap\" feeds product roadmap; concentration in \"no decision\" usually means lead-qualification is too loose. Pair count with value to spot mix-shift (e.g. losing more small deals while winning the large ones is a different motion problem than the inverse).", "relatedKpiIds": [ "sales.closed_lost_value", "sales.closed_won_count", "sales.win_rate", "sales.competitive_alerts", "sales.pipeline_risk_factors" ], "calculationPolicy": { "inclusionRules": [ "Count of distinct opportunities whose stage transitioned to closed-lost during the period." ], "exclusionRules": [ "\"No decision\" / paused opportunities — those belong in a separate stage, not in lost.", "Disqualified-pre-pipeline opportunities (never bona-fide pipeline).", "Closed-won opportunities (see `sales.closed_won_count`)." ], "requiredInputs": [ "Opportunities with close date, final stage, and loss-reason code if available.", "A stage convention that separates lost from no-decision / paused." ], "dataSourcePriority": [ "CRM closed-lost report with loss-reason codes.", "Rev-ops export as a fallback." ], "edgeCases": [ "Stale \"open\" deals that should be lost are left open — this suppresses the lost count while inflating pipeline value; enforce a max-age lost-or-update review.", "\"No decision\" lumped into lost — artificially depresses win rate; bucket it separately." ], "validationChecks": [ "Count is a non-negative integer.", "Denominator input for win rate alongside `sales.closed_won_count`.", "Pair the count with `sales.closed_lost_value` to detect mix-shift (losing many small deals vs a few large ones)." ], "commonMiscomputations": [ "Counting no-decision / paused outcomes as lost — distorts win rate.", "Leaving stale deals open instead of marking them lost — silent win-rate degradation that compounds across periods." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "sales.closed_lost_value", "slug": "closed_lost_value", "domain": "sales", "defaultLabel": "Deals Lost Value", "description": "Total dollar value of opportunities closed-lost during the period — the opportunity-cost view on the pipeline motion. Useful for sizing the \"what we missed\" gap and prioritizing post-mortem efforts on the highest-value losses. Common pitfall: post-mortems on small lost deals waste time relative to insight; tier the post-mortem cadence by value (e.g. every loss above the 80th-percentile deal size gets a written debrief). Boards expect the largest 2–3 losses to be explained explicitly in commentary.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Closed-Lost Value = Σ (deal_value) across opportunities that transitioned to closed-lost in the period. Use the same value convention (TCV vs ACV) as Closed-Won Value for consistency.", "whyItMatters": "Quantifies the realized opportunity cost — useful for justifying packaging changes, ICP refinement, or product investment that would have closed specific tier-1 losses. Drives loss-reason prioritization.", "interpretationGuidance": "Loss-Value / Won-Value (= loss share of total close events) — at steady state usually 30–60% depending on motion type (inbound-heavy motions have higher win rates and lower loss values; outbound motions have lower win rates and higher loss values). Spiking loss-value with stable won-value usually indicates competitive friction or pricing pressure on enterprise deals specifically.", "relatedKpiIds": [ "sales.closed_lost_count", "sales.closed_won_value", "sales.win_rate", "sales.average_deal_size", "sales.competitive_alerts" ], "calculationPolicy": { "inclusionRules": [ "Σ deal_value across opportunities that transitioned to closed-lost in the period — the opportunity-cost view on the pipeline motion.", "Use the same value convention (TCV vs ACV) as `sales.closed_won_value`." ], "exclusionRules": [ "\"No decision\" / paused opportunities (separate stage).", "Closed-won value (see `sales.closed_won_value`).", "Disqualified-pre-pipeline opportunities." ], "requiredInputs": [ "Closed-lost opportunities with deal_value and close date.", "A value convention consistent with `sales.closed_won_value`." ], "dataSourcePriority": [ "CRM closed-lost report for the period.", "Rev-ops export as a fallback." ], "edgeCases": [ "Same value convention as won — a mismatched TCV / ACV choice breaks the loss-share ratio.", "Tier post-mortems by value; the largest 2–3 losses should be explained explicitly in commentary." ], "validationChecks": [ "closed_lost_value ≥ 0.", "Loss share = closed_lost_value / `sales.closed_won_value` — at steady state usually 30–60% depending on motion type; spiking loss value with stable won value signals competitive or pricing pressure on enterprise deals." ], "commonMiscomputations": [ "Using a different value convention than `sales.closed_won_value` — the loss-vs-won comparison becomes meaningless.", "Including no-decision / paused deal value in the lost total." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "sales.closed_won_count", "slug": "closed_won_count", "domain": "sales", "defaultLabel": "Deals Won", "description": "Count of opportunities that reached closed-won status during the period — the volume side of the period's sales output. Paired with closed_won_value gives the period's average won-deal size, a critical mix-shift indicator. Common pitfall: counting opportunity stage transitions rather than discrete deal closes (re-opened deals inflate the count). Boards read the trend over 4+ quarters to detect motion-volume stability — sharp drops while pipeline holds usually mean late-stage conversion has broken.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Closed-Won Count = Count of distinct opportunities whose stage transitioned to closed-won during the period. Each opportunity counted at most once even if multiple stage transitions occur.", "whyItMatters": "The most direct sales-execution volume signal — separates \"we sold lots of small things\" from \"we sold a few big things\" when paired with deal-size lines. Inputs win rate and ASP analysis.", "interpretationGuidance": "Read alongside closed_won_value: rising count + rising value = healthy scale; rising count + falling value = down-market mix shift (often unintentional); falling count + rising value = up-market success or a coverage problem; both falling = execution issue requiring intervention.", "relatedKpiIds": [ "sales.closed_won_value", "sales.closed_lost_count", "sales.win_rate", "sales.average_deal_size", "sales.new_customers_added" ], "calculationPolicy": { "inclusionRules": [ "Count of distinct opportunities whose stage transitioned to closed-won during the period.", "Each opportunity counted at most once even if it had multiple stage transitions (e.g. re-opened then re-won)." ], "exclusionRules": [ "Stage transitions that are not genuine closes (a re-opened deal counted a second time).", "Closed-lost opportunities (see `sales.closed_lost_count`).", "Expansion / renewal bookings not tracked as discrete won opportunities — be consistent with how `sales.closed_won_value` is built." ], "requiredInputs": [ "Opportunities with close date and final stage.", "Period boundaries." ], "dataSourcePriority": [ "CRM closed-won report for the period.", "Rev-ops export as a fallback." ], "edgeCases": [ "Re-opened-then-re-won deals: count once.", "Multi-product single opportunity vs split opportunities: hold the counting unit constant with `sales.pipeline_deal_count`." ], "validationChecks": [ "Count is a non-negative integer.", "Win rate = closed_won_count / (closed_won_count + `sales.closed_lost_count`) × 100 — this is the count-basis numerator and denominator input.", "`sales.closed_won_value` / closed_won_count = realized average won-deal size; cross-check against `sales.avg_contract_value`." ], "commonMiscomputations": [ "Counting opportunity stage transitions rather than discrete deal closes — re-opened deals inflate the count.", "Omitting `sales.closed_lost_count` (or mixing won and lost) so win rate cannot be computed." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "sales.closed_won_value", "slug": "closed_won_value", "domain": "sales", "defaultLabel": "Deals Won Value", "description": "Total dollar value of all opportunities closed-won during the period — the period's realized bookings from the pipeline motion. Reconciles to (sales.new_business + sales.expansion) when split by deal type. Common pitfall: reporting TCV (total contract value) here when the rest of the dashboard uses ACV — pick one and apply it consistently across closed_won_value, weighted_forecast, and pipeline_value, or the dashboard math stops reconciling.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Closed-Won Value = Σ (deal_value) across opportunities that transitioned to closed-won in the period. The \"deal_value\" convention (TCV vs ACV) must match the pipeline-tracking convention for the math to reconcile.", "whyItMatters": "Realized bookings — the period's actual sales output. Sum across periods should reconcile to total new-customer + expansion CARR additions; gaps indicate either revenue-recognition policy or stage-data-quality issues.", "interpretationGuidance": "Closed-Won Value / Quota gives the period's attainment percentage — > 100% is over-plan, 80–100% is the typical \"acceptable\" band, < 80% triggers the post-mortem cycle. Read alongside Win Rate to identify whether misses are pipeline-driven (low value but normal win rate) or execution-driven (normal value, depressed win rate).", "relatedKpiIds": [ "sales.closed_won_count", "sales.weighted_forecast", "sales.quarterly_forecast", "sales.win_rate", "sales.new_business" ], "calculationPolicy": { "inclusionRules": [ "Σ deal_value across opportunities that transitioned to closed-won in the period — the realized bookings from the pipeline motion.", "Use ONE value convention (TCV or ACV) and apply it consistently with `sales.pipeline_value` and `sales.weighted_forecast`." ], "exclusionRules": [ "Closed-lost value (see `sales.closed_lost_value`).", "Recognized or invoiced revenue — closed-won value is bookings (signed), NOT earned revenue (`sales.total_revenue`) and NOT an annualized run-rate (`sales.arr`).", "Re-opened-then-re-won double counts." ], "requiredInputs": [ "Closed-won opportunities with deal_value and close date.", "The value convention (TCV vs ACV) in force." ], "dataSourcePriority": [ "CRM closed-won report for the period.", "Finance bookings ledger as a cross-check." ], "edgeCases": [ "TCV-vs-ACV: pick one — reporting TCV here while the rest of the dashboard is ACV breaks reconciliation.", "Multi-year deals: the convention decides whether the full TCV or the annualized value lands on this line.", "When split by deal type, closed-won value reconciles to `sales.new_business` + `sales.expansion` (the live-ARR subset). Cross-reference those already-hardened ARR-movement lines; do NOT restate their waterfall here." ], "validationChecks": [ "closed_won_value ≥ 0.", "Sum across periods reconciles to total new-customer + expansion CARR additions; persistent gaps indicate revenue-recognition policy or stage-data-quality issues.", "closed_won_value / quota = the period attainment percentage." ], "commonMiscomputations": [ "Reporting TCV here while using ACV elsewhere — breaks the dashboard math.", "Conflating closed-won bookings with recognized revenue (`sales.total_revenue`) or with the ARR run-rate (`sales.arr`).", "Double-counting re-opened / re-won deals.", "Duplicating the ARR-movement waterfall (`sales.new_business` / `sales.expansion`) on this line instead of cross-referencing it." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "bookings", "production": "primary" } }, { "rogueId": "sales.competitive_alerts", "slug": "competitive_alerts", "domain": "sales", "defaultLabel": "Competitive Alerts", "description": "Narrative read on competitive dynamics affecting the sales motion — material wins / losses to specific competitors, observed pricing or packaging moves in the market, new entrants, M&A in the competitive set. Boards use this surface to bring outside intelligence (their other portfolio companies, advisors) to bear on the competitive picture. Common pitfall: listing competitor names without quantifying how often they show up in deal cycles — a \"Competitor X is being aggressive\" entry without \"we saw them in 8 of 20 active deals last quarter, up from 3 of 18\" is too vague to act on.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Free-text narrative — no calculation. Convention: per-competitor sub-sections covering deal-frequency observed, win/loss split when statistically meaningful, and any observed pricing / packaging moves.", "whyItMatters": "Competitive intelligence is the most under-shared information in board packs and the most useful for cross-portfolio learning — boards can validate or refute observations from other companies they sit on.", "interpretationGuidance": "Track entries quarter-over-quarter: a competitor whose mention frequency rises consistently is a leading indicator of market positioning erosion. Pair with sales.win_rate trend cut by competitor when possible.", "relatedKpiIds": [ "sales.win_rate", "sales.closed_lost_count", "sales.closed_lost_value", "sales.key_concerns", "sales.strategic_context" ] }, { "rogueId": "sales.deals_summary", "slug": "deals_summary", "domain": "sales", "defaultLabel": "Deals Summary (Won / Lost)", "description": "Container handle for the period's notable deals split into WON and LOST arrays — each deal carries name, account, amount, owner, deal type, source, and competitor, plus a win reason + close date (won) or a loss reason (lost). The bespoke sales feed card renders this as the \"Notable Deals\" won/lost breakdown the demo design shows. This is RICHER than the flat `sales.pipeline_key_deals` editor gallery (which has no won/lost split, reason, or close date). Common pitfall: carrying the same list forward each quarter — refresh to the actual period's closes.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — { wonDeals: IWonDeal[], lostDeals: ILostDeal[] }. Won deals carry winReason + closeDate; lost deals carry lossReason. No aggregate calculation; the surface makes specific outcomes visible at the board level.", "whyItMatters": "Turns the quarter's win/loss outcomes into board-readable narrative — why deals were won (superior product / service) and lost (features / price / competitor) is the qualitative signal raw pipeline numbers miss.", "interpretationGuidance": "Cluster the loss reasons: repeated `features` losses signal a product gap; repeated `price` losses signal a packaging/positioning gap. Pair with `sales.pipeline_key_deals` for the still-open top deals.", "relatedKpiIds": [ "sales.pipeline_key_deals", "sales.closed_won_value", "sales.closed_lost_value" ] }, { "rogueId": "sales.downgrades", "slug": "downgrades", "domain": "sales", "defaultLabel": "Downgrade ARR", "description": "Annualized recurring revenue lost from existing customers who reduced spend mid-term or at renewal (seat reductions, tier downgrades, removed modules) — without leaving entirely. The \"contraction\" line of the ARR waterfall, distinct from full churn. Often a more sensitive leading indicator than churn because customers tend to contract before they cancel. Common pitfall: lumping downgrades into churn obscures the early-warning signal — boards looking only at logo churn miss the slow-bleed pattern. Surfaces in the KpiVarianceTable widget alongside expansion and churn so the net-retention math is auditable.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Downgrade ARR = Sum across existing customers of (ARR at period start − ARR at period close) for the subset where the delta is positive AND the customer's ARR did not drop to zero. Customers whose ARR drops to zero count in Churned ARR instead.", "whyItMatters": "Earliest leading indicator of retention risk — customers usually contract before they cancel, so a rising downgrade line predicts churn 1–2 quarters out. Inputs NRR (subtracts from expansion) and CCO/CS comp models that gate on Net Retention.", "interpretationGuidance": "Downgrade ARR rising as a share of expansion ARR over 2+ quarters is the canonical leading signal of a renewal-cycle problem. There is no widely-published cross-company benchmark for downgrade rates as a standalone — read it in context of NRR (industry folk-wisdom: a healthy SaaS company with NRR ≥ 110% typically has downgrade ARR ≤ 3% of starting ARR per period).", "relatedKpiIds": [ "sales.expansion", "sales.churn_arr", "sales.arr", "customers.net_revenue_retention", "customers.gross_revenue_retention" ], "calculationPolicy": { "inclusionRules": [ "Sum across existing customers of (period-start ARR − period-end ARR) where the delta is positive AND the customer's ARR did not drop to zero.", "Includes seat reductions, tier downgrades, removed modules/products, and renewal-time contractions." ], "exclusionRules": [ "Customers whose ARR dropped to zero — those are full churn (`sales.churn_arr`), not downgrades.", "New-logo deals and expansions — positive-delta customers do not appear here.", "Contractual price decreases that were pre-agreed in the original contract (rare, but disclose if present)." ], "requiredInputs": [ "Customer-level ARR snapshot at period start.", "Customer-level ARR snapshot at period end.", "Per-customer churn flag (to separate full churn from contraction)." ], "dataSourcePriority": [ "Customer-level ARR ledger (same source as expansion / churn / NRR).", "CRM contract changelog as a fallback." ], "edgeCases": [ "Customer downgrades one product and expands another in the same period: net the per-customer delta; if negative, it counts here; if positive, it counts in expansion.", "Renewal at a lower price after a discount expires: count the reduction as a downgrade.", "Customer contracts to zero: that is churn, not a downgrade — even though it \"feels\" like the extreme downgrade." ], "validationChecks": [ "Downgrade ARR ≥ 0 always.", "NRR = (Starting ARR + Expansion − Downgrades − Churn) / Starting ARR — downgrades and churn together must reconcile the waterfall.", "Per-customer downgrade ≤ that customer's period-start ARR." ], "commonMiscomputations": [ "Lumping downgrades into churn — destroys the leading-indicator signal; customers usually contract 1-2 quarters before they cancel.", "Counting a contract-to-zero as a downgrade — it is churn; mixing the two corrupts both GRR and the churn line.", "Netting downgrades against same-customer expansion and reporting only the net — both gross lines are needed for the waterfall.", "Missing renewal-time downgrades because the system only captures mid-term amendments — renewal contractions are the larger share for most SaaS." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "contracted_arr", "dateBasis": "period_close", "production": "primary" } }, { "rogueId": "sales.expansion", "slug": "expansion", "domain": "sales", "defaultLabel": "Expansion ARR", "description": "Annualized recurring revenue added during the period from existing customers — through upsell (more seats / higher tier), cross-sell (additional products), or price increases. The \"farm\" line of the ARR waterfall. Boards read this as the leading indicator that product-market fit has translated into product-account fit and that the post-sale motion is creating compound growth. Common pitfall: classifying contractual price-step-ups (CPI escalators baked into the original contract) as expansion overstates new selling motion. Expansion CAC Ratio and Net Revenue Retention are derived from this number.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Expansion ARR = (ARR from existing customers at period close) − (ARR from those same customers at period start) for the subset where the delta is positive. Excludes downgrades (tracked separately) and excludes new-logo bookings. Pre-contracted CPI escalators may or may not be treated as expansion — pick one convention per the company and apply it consistently.", "whyItMatters": "A high expansion line is the single best predictor of capital-efficient compounding growth — the SaaS playbook depends on existing customers expanding faster than new ones churn. Drives NRR, which is the metric public-market investors weight most heavily on the retention side of the model.", "interpretationGuidance": "Expansion ARR ≥ Churned + Downgrade ARR means NRR ≥ 100% (the \"leaky bucket gets refilled by upsell\" condition). Per KBCM/Sapphire SaaS Survey 2024 §Net Revenue Retention, median NRR is roughly 105–110% for $5M+ ARR SaaS — below 100% is a yellow flag at any stage; above 120% signals a category-leading account-expansion motion.", "relatedKpiIds": [ "sales.arr", "sales.new_business", "sales.churn_arr", "sales.downgrades", "sales.expansion_cac_ratio", "customers.net_revenue_retention", "customers.gross_revenue_retention" ], "calculationPolicy": { "inclusionRules": [ "Sum of (end-of-period ARR − start-of-period ARR) per customer, restricted to existing customers and to the subset where the delta is positive.", "Includes upsell (more seats, more capacity), cross-sell (additional products/modules), tier upgrades, and discretionary price increases negotiated mid-term.", "Disclose handling of contractual CPI escalators baked into the original contract — pick a convention (count or don't) and apply consistently." ], "exclusionRules": [ "New-logo ARR — those are in `sales.new_business`.", "Customers who started the period with zero ARR (they're new logos, not expansions, even if they upgraded the same period).", "Negative deltas (downgrades) — those go in `sales.downgrades`.", "Renewals at the same price — those are retention, not expansion." ], "requiredInputs": [ "Customer-level ARR snapshot at period start.", "Customer-level ARR snapshot at period end.", "Convention flag: are contractual CPI escalators counted as expansion?" ], "dataSourcePriority": [ "Customer-level ARR ledger keyed by stable account ID (same source as NRR/GRR).", "CRM contract changelog as a fallback when the ledger isn't available." ], "edgeCases": [ "Customer who upgraded AND downgraded different products in the same period: net the per-customer delta; if positive, count in expansion (only).", "Mid-period contract amendment: take the period-end ARR vs period-start ARR for the customer; don't double-book intermediate changes.", "Account mergers (parent acquires sub-customer): treat the consolidated entity as the new cohort; don't count the consolidation as expansion.", "Price-pack upgrade (Pro→Enterprise) at renewal: count the delta as expansion, not as renewal." ], "validationChecks": [ "Expansion ARR ≥ 0 always.", "Per-customer expansion ≤ their period-end ARR (you can't expand by more than the customer pays).", "Sum of all expansion line items reconciles to the aggregate expansion number within 1%." ], "commonMiscomputations": [ "Counting price-step-ups that were pre-contracted (CPI escalators) as expansion — inflates the selling-motion narrative without any actual sales activity.", "Including new-logo upsells (customer signed Tier 1 then upgraded to Tier 2 in the same period) as expansion — they're part of the new-logo motion.", "Netting downgrades against expansion at the customer level and reporting the net as \"expansion\" — they're different lines for a reason.", "Cohort drift: counting expansion from customers who weren't in the starting-period cohort. The cohort must be closed at period start.", "Counting renewal value as expansion — renewal at the same price is retention, not expansion." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "contracted_arr", "dateBasis": "go_live", "production": "primary" } }, { "rogueId": "sales.expansion_cac_ratio", "slug": "expansion_cac_ratio", "domain": "sales", "defaultLabel": "Expansion CAC Ratio", "description": "Fully-loaded S&M plus Customer Success expense attributable to expansion divided by expansion CARR generated in the period. Per SMSB, the efficiency read on the upsell / cross-sell / land-and-expand motion. Distinct from the new-logo CAC ratio because the cost base often includes CSMs whose primary metric is retention but whose secondary metric is expansion — boards expect to see that allocation called out. Common pitfall: excluding CS comp entirely understates the true cost of expansion; including all of CS overstates it. The SMSB standard prescribes a documented allocation rule (typically tied to expansion-quota OTE share).", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales", "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/expansion-cac-ratio", "sectionRef": "Expansion CAC Ratio", "publicationDate": "2023-01-01", "attributionNotice": "Metric definitions reference standards published by the SaaS Metrics Standards Board (saasmetricsboard.com). imboard is not affiliated with, endorsed by, or a member of SMSB.", "authorityLevel": "self-declared-coalition" }, "formula": "Expansion CAC Ratio = (S&M + CS spend allocated to expansion in period) / (Expansion CARR generated in period). Per SMSB §Expansion CAC Ratio: allocation rule for cross-functional comp (typically split by quota share of OTE) must be documented and consistent.", "whyItMatters": "Validates the financial logic of \"expansion is cheaper than acquisition\" — when this is healthy, the company should bias growth investment toward post-sale; when it inverts (Expansion CAC ≥ New CAC), the expansion motion is broken and acquisition is the only available lever.", "interpretationGuidance": "Per SMSB convention, healthy Expansion CAC Ratio is typically 3–5× cheaper than New CAC Ratio — i.e. 0.2–0.5 when New CAC Ratio is ~1.5. Expansion CAC Ratio > 1.0 is a yellow flag (expansion costs as much as it earns); inversion vs New CAC Ratio is a red flag warranting a CS / sales-team org review.", "relatedKpiIds": [ "sales.blended_cac_ratio", "sales.new_cac_ratio", "sales.expansion", "customers.net_revenue_retention", "sales.carr" ], "calculationPolicy": { "inclusionRules": [ "Numerator: S&M + Customer Success spend allocated to the expansion motion (upsell / cross-sell / land-and-expand).", "Denominator: expansion CARR generated in the period.", "CS comp is partly in scope: include the share of CSM cost attributable to expansion (typically the fraction of OTE tied to an expansion quota), per a documented rule." ], "exclusionRules": [ "New-logo S&M spend from the numerator (goes in `sales.new_cac_ratio`).", "The retention-only share of CS comp — CSMs whose comp is purely tied to renewal/retention, not expansion.", "New-customer CARR and renewal CARR from the denominator." ], "requiredInputs": [ "S&M + CS spend allocated to expansion.", "Expansion CARR for the period.", "The documented allocation rule for cross-functional (CS) comp." ], "dataSourcePriority": [ "Financials + documented CS/S&M allocation model.", "CRM for expansion CARR." ], "edgeCases": [ "CS team with no expansion quota at all: expansion is AE-driven; CS comp share is ~0 and the numerator is AE-expansion-comp only.", "Product-led expansion (self-serve upgrades, no human touch): the numerator may be near-zero — Expansion CAC Ratio approaches zero, which is correct and worth calling out as a strength.", "Allocation-rule change: re-state prior periods." ], "validationChecks": [ "Expansion CAC Ratio should be materially lower than New CAC Ratio — healthy SaaS expansion is typically 3–5× cheaper per dollar (≈ 0.2–0.5 when New CAC Ratio ≈ 1.5).", "Expansion CAC Ratio ≥ New CAC Ratio is a red flag — the expansion motion is broken; investigate before reporting it as a number without commentary.", "Blended CAC Ratio must sit between New and Expansion CAC Ratio." ], "commonMiscomputations": [ "Excluding CS comp entirely — understates the true cost of expansion, makes the motion look free.", "Including ALL of CS comp — overstates it; most CS comp is retention, not expansion. Use the documented allocation.", "Using ARR instead of CARR in the denominator.", "Reporting Expansion CAC Ratio in isolation — it is only meaningful next to New CAC Ratio (the comparison IS the insight)." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "sales.focus_areas", "slug": "focus_areas", "domain": "sales", "defaultLabel": "Sales Focus Areas", "description": "Forward-looking narrative naming the next-period (typically next-quarter) sales priorities — segment bets, pipeline-coverage actions, hiring focuses, enablement themes, ICP refinements. The \"what we're changing or doubling-down on\" surface, complementing strategic_context (which is past-tense) and key_concerns (which is present-tense). Common pitfall: listing too many focus areas (3 is the practical maximum a team can actually execute against; 7+ means everything is a priority, i.e. nothing is). Boards use this to track promise-vs-delivery quarter over quarter.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Free-text narrative — no calculation. Convention: 3 numbered priorities, each with a one-line statement and a measurable next-period success criterion.", "whyItMatters": "Creates accountability across periods — the board can ask \"you said X was the focus last quarter, what happened?\" Without an explicit list, every quarter looks like a fresh strategy reset.", "interpretationGuidance": "Focus areas should reappear (with progress) for 2–3 quarters before retiring — single-quarter focus shifts are usually a thrash signal. Track which focuses produce measurable KPI delta vs which produce only activity reports.", "relatedKpiIds": [ "sales.strategic_context", "sales.key_concerns", "sales.pipeline_assumptions", "sales.win_rate", "sales.cac_payback_period" ] }, { "rogueId": "sales.gross_margin", "slug": "gross_margin", "domain": "sales", "defaultLabel": "Gross Margin", "description": "Recognized revenue minus cost of goods sold (COGS), divided by recognized revenue, expressed as a percentage. The single best read on whether the business model can ever generate operating leverage — a low gross margin caps every downstream efficiency metric (CAC payback, LTV/CAC, Rule of 40). For SaaS, COGS includes hosting, third-party software, customer support, and customer-success cost-of-service. Common pitfall: omitting customer success from COGS inflates the margin and breaks comparability with peer benchmarks. Anchored to KBCM/Sapphire SaaS Survey 2024 §Gross Margin.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceUrl": "https://www.cfodesk.co.il/wp-content/uploads/2024/10/2024_kbcm_sapphire_saas_survey.pdf", "sectionRef": "Gross Margin", "publicationDate": "2024-09-01", "attributionNotice": null, "authorityLevel": "industry-benchmark" }, "benchmark": { "p25": 65, "median": 72, "p75": 81, "unit": "%", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceYear": "2024", "higherIsBetter": true }, "formula": "Gross Margin = ((Recognized Revenue − COGS) / Recognized Revenue) × 100. COGS for a SaaS business: cloud / hosting infrastructure, third-party data and APIs called for delivery, customer support, customer success cost-of-service, and any directly-attributable delivery personnel. Excludes R&D, S&M, and G&A.", "whyItMatters": "Caps every long-term efficiency metric — Rule of 40, LTV/CAC, CAC payback all run off contribution margin which derives from gross margin. Board uses it to verify the unit economics are real before debating S&M investment levels.", "interpretationGuidance": "Per KBCM/Sapphire SaaS Survey 2024 §Gross Margin, healthy SaaS gross margin is 70–80%; > 80% is best-in-class infrastructure leverage; < 65% usually signals heavy services revenue or inefficient COGS (often customer-success scaling linearly with customer count). Sub-70% companies must show a credible path to 70%+ by next funding milestone or face valuation pressure.", "relatedKpiIds": [ "sales.total_revenue", "sales.arr", "sales.cac_payback_period", "operations.rule_of_40", "sales.growth_rate_yoy" ], "calculationPolicy": { "inclusionRules": [ "Numerator: Recognized Revenue (period) − COGS (period).", "COGS for SaaS includes: cloud/hosting/infrastructure, third-party APIs/data called for product delivery, payment-processing fees, customer support, customer-success cost-of-service, directly-attributable delivery personnel, software included with the product.", "Denominator: Recognized Revenue for the same period.", "Result is a percentage; format consistently (rounded to one decimal, or as the company's investor-letter standard)." ], "exclusionRules": [ "R&D, S&M, G&A — those are below the gross-margin line and belong in operating expenses.", "Stock-based compensation expense — exclude from COGS (separately disclose adjusted GM if non-GAAP).", "One-off implementation services revenue if reported in a separate revenue line with its own services-COGS." ], "requiredInputs": [ "Period Recognized Revenue (`sales.total_revenue` or income-statement total revenue).", "Period COGS, broken out by component (hosting, support, CS cost-of-service, payment-processing, third-party delivery costs).", "Methodology disclosure: cash vs accrual basis; GAAP vs adjusted (SBC-excluded)." ], "dataSourcePriority": [ "Audited or reviewed income statement.", "Internal management P&L with documented adjustments." ], "edgeCases": [ "High services-revenue mix (professional services > 15% of total revenue): break out product GM vs services GM. Blended GM hides whether the product GM is healthy.", "Customer-success cost-of-service: include in COGS for SaaS comparability. The single most common omission that inflates GM by 5–10 percentage points.", "Pure usage-based metering with variable infra cost: include the variable infra cost in COGS for each unit delivered.", "Hosting credits from cloud providers: net against hosting COGS, but disclose the credit period (it ends and COGS spikes)." ], "validationChecks": [ "Gross Margin should sit in 60–85% range for healthy SaaS. Below 60% requires either a services-heavy explanation or a credible path to 70%+.", "GM × Revenue = Gross Profit — recompute and cross-check.", "Trend should be smooth at steady state; > 5-percentage-point swings quarter-over-quarter usually indicate either a one-off COGS event or a revenue-mix shift worth narrative." ], "commonMiscomputations": [ "Omitting customer success from COGS — inflates GM by ~5–10 points and breaks peer comparability with KBCM/Sapphire benchmarks.", "Computing GM from ARR (not Recognized Revenue) while still using period-COGS — produces a number that is neither GM nor anything else meaningful.", "Including S&M or R&D in COGS — drops GM far below true unit economics.", "Counting SBC as a cash COGS — overstates COGS by 5–15% depending on equity comp intensity. Disclose adjusted GM if SBC-excluded is the headline.", "Mixing GAAP and non-GAAP GM across periods of the same trend chart — distorts comparability.", "Hiding cloud credits as a permanent COGS reduction — when the credit period ends, GM \"drops\" without any business change." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "sales.growth_rate_yoy", "slug": "growth_rate_yoy", "domain": "sales", "defaultLabel": "Growth Rate (YoY)", "description": "Year-over-year percentage growth in ARR (or recognized revenue, if explicitly anchored) — comparing the current period to the equivalent period 12 months prior. The single most-watched investor metric and the largest single driver of SaaS valuation multiples. Common pitfall: comparing to the prior quarter (QoQ) and reporting it as \"growth rate\" — boards and investors mean YoY unless explicitly noted otherwise. Anchored to KBCM/Sapphire SaaS Survey 2024 §YoY ARR Growth for cross-company benchmarking.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceUrl": "https://www.cfodesk.co.il/wp-content/uploads/2024/10/2024_kbcm_sapphire_saas_survey.pdf", "sectionRef": "YoY ARR Growth", "publicationDate": "2024-09-01", "attributionNotice": null, "authorityLevel": "industry-benchmark" }, "benchmark": { "p25": 12, "median": 19, "p75": 27, "unit": "%", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceYear": "2024", "higherIsBetter": true }, "formula": "YoY Growth Rate = ((ARR at period close − ARR 12 months prior) / ARR 12 months prior) × 100. State the underlying metric explicitly (ARR vs Recognized Revenue) — they diverge meaningfully for sub-scale businesses. For quarters, use end-of-quarter ARR vs end-of-same-quarter-prior-year.", "whyItMatters": "Direct input to public-comparable valuation multiples (EV / NTM ARR multiples are sliced by growth band). Boards use it to triangulate stage-appropriate pace and to flag deceleration early.", "interpretationGuidance": "Per KBCM/Sapphire SaaS Survey 2024 §YoY ARR Growth, median private-SaaS growth bands by ARR scale: $5–10M ARR median ~55–70%, $10–25M ARR ~40–55%, $25–50M ARR ~35–45%, $50M+ ARR ~25–35%. Growth decelerating > 30 percentage points YoY at any ARR scale is the most actionable board warning signal — usually requires either pipeline-coverage diagnosis or product-investment reallocation.", "relatedKpiIds": [ "sales.arr", "sales.new_business", "sales.expansion", "sales.churn_arr", "operations.rule_of_40", "sales.gross_margin" ], "calculationPolicy": { "inclusionRules": [ "Numerator: ARR at period close (or Recognized Revenue at period close if explicitly anchored on revenue) minus the same metric exactly 12 months prior.", "Denominator: the same metric 12 months prior.", "For quarterly reporting, use end-of-quarter ARR vs end-of-same-quarter-prior-year (not start-of-period).", "State the underlying metric explicitly in any output (\"ARR YoY growth\" or \"Revenue YoY growth\") — they diverge for sub-scale businesses." ], "exclusionRules": [ "Quarter-over-quarter (QoQ) growth — that's a different metric. \"Growth rate\" without qualifier means YoY by convention.", "Monthly growth annualized via compounding — that's \"run-rate growth\", not YoY.", "Inorganic ARR additions (acquisitions) — disclose separately as \"ARR growth excluding M&A\" alongside the headline." ], "requiredInputs": [ "Period-close ARR (or Recognized Revenue) for the current period.", "Period-close ARR (or Recognized Revenue) exactly 12 months prior.", "Acquisition / divestiture log within the trailing 12 months." ], "dataSourcePriority": [ "Audited or reviewed period-close balances.", "Internal closed-period ARR snapshots maintained for board reporting." ], "edgeCases": [ "Acquisition mid-year: show two numbers — headline YoY (including acquired ARR from the acquisition date) and organic YoY (excluding). Boards read both.", "Currency moves on multi-currency revenue: hold FX flat at one rate across both endpoints when revenue is multi-currency. Constant-currency growth is the comparable number.", "Very small base 12 months prior (< $1M ARR): growth rate becomes mathematically unstable; report carefully or use absolute deltas alongside.", "Calendar-shift (53-week years, fiscal-year change): pin the comparable period or disclose the adjustment." ], "validationChecks": [ "Result is a percentage; can be negative (decline) but rarely > 200% for sub-scale companies in a single year.", "Sit within stage-typical KBCM/Sapphire band for ARR scale — out-of-band growth (especially declines) requires investigation, not narration.", "Cross-check ARR and Revenue growth rates: if they diverge by > 30 percentage points, ask why — usually a contract-mix shift or billing-policy change." ], "commonMiscomputations": [ "Computing QoQ growth and labeling it \"growth rate\" — investors interpret unqualified growth rate as YoY.", "Mixing ARR for numerator and Recognized Revenue for denominator (or vice versa) — produces a meaningless ratio.", "Including acquired ARR in the headline growth rate without flagging the inorganic contribution — investors see \"rocket growth\" that is mostly M&A.", "Using start-of-period vs end-of-period inconsistently (period-start one year vs period-end the other) — produces a 1-period offset that distorts the rate.", "Annualizing a monthly delta and reporting it as YoY — overstates dramatically for any company with seasonality.", "Computing growth on a metric that itself changed definition mid-trend (e.g. swapped MRR×12 to true contracted ARR) — usually inflates the growth rate by the methodology change." ] }, "metricBasis": { "timeBasis": "trailing_window", "production": "computed" } }, { "rogueId": "sales.key_concerns", "slug": "key_concerns", "domain": "sales", "defaultLabel": "Sales Key Concerns", "description": "Free-text narrative of the critical issues, pipeline risks, or blockers in the sales motion that require board attention this period. Distinct from sales.pipeline_risk_factors (which is forecast-specific) — this is the full-stack sales-org concerns list including hiring, comp, churn-cluster patterns, large-deal slippage, and competitive losses. Common pitfall: under-reporting concerns because the team wants to show progress — boards explicitly invite this surface so they can help, and a board pack with no concerns surfaces is itself a yellow flag (either the team is hiding something or not introspecting deeply enough).", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Free-text narrative — no calculation. Convention: 3–7 bulleted concerns, each one sentence framing the issue + one sentence on what is being done.", "whyItMatters": "Lets the board pre-load the discussion topics that need their judgment or network — the most leveraged use of board time. Absent this surface, the conversation drifts to whatever board members notice in the numbers, which is rarely the highest-leverage issue.", "interpretationGuidance": "A healthy entry names specific deals or accounts, quantifies the at-risk amount where possible, and links to follow-up KPIs. Vague concerns (\"market is choppy\") consume board time without producing action; ask the team to either quantify or remove.", "relatedKpiIds": [ "sales.strategic_context", "sales.pipeline_risk_factors", "sales.competitive_alerts", "sales.focus_areas", "sales.churn_arr", "sales.downgrades" ] }, { "rogueId": "sales.median_deal_size", "slug": "median_deal_size", "domain": "sales", "defaultLabel": "Median Deal Size", "description": "Median dollar value across active pipeline opportunities — the typical deal in the pipeline, robust against the few-big-deals skew that distorts the average. The honest read on the \"core motion\" deal-size; if the team is winning a few oversized deals but the median is shrinking, the underlying motion is degrading even though the topline numbers look fine. Common pitfall: omitting median in dashboards in favor of just the average lets concentration risk hide. A best-practice board pack always shows both.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Median Deal Size = 50th-percentile deal_value across active pipeline opportunities. Same value convention (TCV vs ACV) as upstream metrics; same active-pipeline stage filter as average_deal_size.", "whyItMatters": "The most honest read on the typical motion — distinguishes \"we have a real scalable motion\" (high median) from \"we have a few oversized deals carrying everything else\" (low median, high average).", "interpretationGuidance": "When median deal size is stable while average deal size rises, the pipeline is becoming more skewed (a few mega-deals) — concentration risk. When median rises with average, the entire motion is shifting up-market. When median shrinks while average stays flat, deal-size compression is happening in the core motion (usually competitive pricing pressure).", "relatedKpiIds": [ "sales.average_deal_size", "sales.pipeline_value", "sales.pipeline_deal_count", "sales.avg_contract_value" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "sales.new_business", "slug": "new_business", "domain": "sales", "defaultLabel": "New Business ARR", "description": "Annualized recurring revenue booked from net-new logos (first-time customers) during the period. This is the \"hunt\" line of the ARR waterfall — the output of the new-customer acquisition motion, distinct from expansion (existing-customer upsell) and from churn / downgrades. Common pitfall: counting renewals or expansion deals as new business inflates the new-logo conversion engine and hides a stalled acquisition motion. The KpiVarianceTable widget shows period forecast vs actual; downstream views compare it to S&M spend to derive new-business CAC and CAC payback.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "New Business ARR = Sum of ARR contracts signed during the period by customers who had zero prior ARR with the company. Excludes expansion, renewals, and reactivations. Aligns with the SMSB definition of new-logo ARR and pairs 1:1 with sales.new_customers_added for ASP analysis.", "whyItMatters": "Direct read on the health of the new-customer acquisition engine — separates \"are we winning new logos\" from \"are existing customers expanding.\" Inputs the New CAC Ratio and CAC Payback calculations the board uses to judge sales efficiency.", "interpretationGuidance": "New Business ARR running below plan for two consecutive quarters is the classic early-stage growth-stall signal — usually upstream pipeline coverage or win-rate problems. New Business as a share of total Net New ARR should be 60–80% pre-Series B and trends down to 40–60% post-Series B as expansion picks up (industry folk-wisdom, not citation-grade — verify against KBCM/Sapphire 2024 segmentation tables for the company stage band).", "relatedKpiIds": [ "sales.arr", "sales.new_customers_added", "sales.avg_contract_value", "sales.expansion", "sales.cac", "sales.new_cac_ratio", "sales.cac_payback_period" ], "calculationPolicy": { "inclusionRules": [ "Annualized contract value of net-new logos signed during the period (customers with zero prior ARR with the company).", "Multi-year contracts: use annualized value (TCV / term in years), not first-year billing.", "Same recurring-revenue definition as ARR: live / delivered subscription value only." ], "exclusionRules": [ "Expansion deals from existing customers — those belong in `sales.expansion`.", "Renewals of existing customers — those are retention, not new business.", "Reactivated customers who previously churned: classify per company policy, but be consistent and disclose. Some firms count reactivations as new business, others as recovery.", "Bookings (signed but not yet live) — those are CARR. New Business is the live-ARR subset." ], "requiredInputs": [ "CRM customer table with first-active-contract-date per account.", "Contract value annualized per account.", "Period boundaries (start/end dates)." ], "dataSourcePriority": [ "CRM with explicit \"first-time customer\" flag or stable customer-since field.", "Manual classification from CFO/Rev-Ops when CRM customer-since isn't reliable." ], "edgeCases": [ "Account splits / parent-child relationships: count by the same logo-unit used elsewhere in the waterfall (typically parent organization).", "Customers who signed late in the period but went live in the next: defer to the period when ARR turns live (matches ARR semantics) — unless the company explicitly uses booking-date.", "Pilots that convert to paid: count from the first paid contract, not the pilot start." ], "validationChecks": [ "New Business ARR + Expansion − Churned − Downgrades = Net New ARR. The waterfall must reconcile to the ARR delta within 1%.", "New Business should pair 1:1 with `sales.new_customers_added` — count and dollars track together; a large divergence indicates a logo-counting or classification error." ], "commonMiscomputations": [ "Counting renewals as new business — most common error; inflates the new-logo motion narrative and breaks every downstream CAC ratio.", "Counting expansion deals from existing customers — same effect; also doubles up against the expansion line.", "Using bookings instead of live ARR — overstates by the implementation backlog (often 10-25% of new bookings).", "Logo-unit drift: parent-org-counted one quarter, sub-account-counted the next — produces phantom new-logo growth.", "Late-period signing counted in the wrong period when the live-vs-signing convention isn't pinned." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "contracted_arr", "dateBasis": "go_live", "production": "primary" } }, { "rogueId": "sales.new_cac_ratio", "slug": "new_cac_ratio", "domain": "sales", "defaultLabel": "New CAC Ratio", "description": "S&M expense attributable to new-customer acquisition divided by the new-customer CARR generated in the period. Per SMSB, the cleanest read on the new-logo acquisition engine's efficiency — strips out the expansion motion which has materially different unit economics. Common pitfall: failing to split AE comp time correctly between new and expansion activities — when the same AE owns both motions, an allocation rule (often the % of OTE tied to new-vs-expansion quota) is required and must be applied consistently quarter-over-quarter.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales", "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/new-cac-ratio", "sectionRef": "New CAC Ratio", "publicationDate": "2023-01-01", "attributionNotice": "Metric definitions reference standards published by the SaaS Metrics Standards Board (saasmetricsboard.com). imboard is not affiliated with, endorsed by, or a member of SMSB.", "authorityLevel": "self-declared-coalition" }, "formula": "New CAC Ratio = (S&M spend allocated to new-customer acquisition in period) / (New-customer CARR generated in period). Per SMSB §New CAC Ratio: spend allocation must follow a documented rule (e.g. fraction of S&M headcount tied to new-business quota) applied consistently.", "whyItMatters": "Isolates the new-logo engine — when blended CAC Ratio is moving, this is the first line of split-out diagnosis. Boards use it to evaluate whether to invest more in acquisition or shift weight toward expansion.", "interpretationGuidance": "Per SMSB convention, New CAC Ratio of 1.0–2.0 is the typical mid-stage SaaS band; > 2.5 sustained signals the new-logo motion is structurally expensive (often a fit problem with target segment). Should be ≥ Blended CAC Ratio (new-logo is always more expensive than expansion); if New CAC Ratio < Blended, the spend allocation between new and expansion is mis-tagged.", "relatedKpiIds": [ "sales.blended_cac_ratio", "sales.expansion_cac_ratio", "sales.cac", "sales.cac_payback_period", "sales.new_business", "sales.carr" ], "calculationPolicy": { "inclusionRules": [ "Numerator: S&M spend allocated specifically to new-customer acquisition.", "Denominator: new-customer CARR generated in the period.", "When AEs run both new and expansion motions, allocate their comp by a documented rule — typically the fraction of OTE tied to new-business quota." ], "exclusionRules": [ "Expansion-attributed S&M / CS spend from the numerator (goes in `sales.expansion_cac_ratio`).", "Expansion CARR from the denominator.", "Renewal CARR from the denominator." ], "requiredInputs": [ "S&M spend allocated to new acquisition.", "New-customer CARR for the period.", "The documented new-vs-expansion allocation rule, applied consistently across periods." ], "dataSourcePriority": [ "Financials + a documented allocation model for split-role comp.", "CRM for new-customer CARR." ], "edgeCases": [ "Pure new-logo sales team (no split roles): allocation is trivial — all of that team's comp is in the numerator.", "Marketing spend that supports both new and expansion: allocate by the same documented rule; do not dump all of marketing into new-logo.", "Allocation-rule change between periods: re-state prior periods on the new rule, or the trend is broken." ], "validationChecks": [ "New CAC Ratio should be ≥ Blended CAC Ratio — new-logo acquisition is always more expensive per dollar than expansion. If New < Blended, the spend allocation between new and expansion is mis-tagged.", "New CAC Ratio of 1.0–2.0 is the typical mid-stage band; sustained > 2.5 signals a structurally expensive new-logo motion." ], "commonMiscomputations": [ "No allocation rule for split-role AEs — all AE comp lands in new-logo, overstating New CAC Ratio and understating Expansion CAC Ratio.", "Allocation rule that drifts quarter to quarter — produces a trend that reflects bookkeeping, not the motion.", "Using ARR instead of CARR — same understatement as the blended ratio.", "New CAC Ratio computed < Blended CAC Ratio and shipped without catching it — a guaranteed sign of an allocation error." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "sales.new_customers_added", "slug": "new_customers_added", "domain": "sales", "defaultLabel": "New Customers Added", "description": "Count of net-new logo customers signed during the period (a customer is a discrete buying entity — typically an account, not a seat). Paired with sales.new_business gives Average Selling Price (ASP) — a primary input to ICP / segment-fit conversations. Early-stage boards read the logo count as a sanity check on top-of-funnel and PMF before ARR-density grows enough to matter. Common pitfall: counting expansion deals or new contracts from existing customers as \"new\" inflates the acquisition signal — the count must match the same \"first-time customer\" criterion as New Business ARR.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "New Customers Added = Count of distinct customer entities whose first-ever active contract started during the period. Must apply the same logo-counting unit (account / parent-org / billing entity) consistently across periods so the trend is comparable.", "whyItMatters": "Logo count is the most direct read on acquisition-motion volume before contract-value mix dominates the ARR view. Early-stage boards read it before ARR; growth-stage boards pair it with ASP to spot segment drift (e.g. up-market mix-shift where logo count falls while ARR rises).", "interpretationGuidance": "Read alongside New Business ARR to derive ASP (= New Business ARR / New Customers Added). A rising ASP with falling logo count signals up-market drift (often intentional). Stable ASP with falling logo count signals a top-of-funnel problem. Falling ASP with stable logo count usually means discounting pressure — investigate competitive dynamics.", "relatedKpiIds": [ "sales.new_business", "sales.avg_contract_value", "sales.cac", "sales.pipeline_deal_count", "sales.closed_won_count", "sales.win_rate" ], "calculationPolicy": { "inclusionRules": [ "Count of distinct customer entities whose first-ever active contract started during the period.", "Use a consistent logo unit (typically parent account / billing entity) across periods." ], "exclusionRules": [ "Expansion deals to existing customers — even if a new product or new line of business is added.", "Renewals or reactivations of previously-churned customers — those are separately tracked.", "Pilots / free trials — until the first paid contract starts.", "Sub-accounts under an existing parent (when parent-level is the unit) — should not double-count." ], "requiredInputs": [ "CRM customer table with stable customer-since field.", "Definition of \"logo unit\" (parent account vs sub-account vs billing entity) — pin one and apply consistently." ], "dataSourcePriority": [ "CRM with explicit customer-since field per logo unit.", "Billing system with first-billed-date as a fallback." ], "edgeCases": [ "Customer signs in period N but goes live in period N+1: pick a convention (signing-date vs go-live-date) and apply consistently with `sales.new_business`. Mismatched conventions break ASP calculations.", "Reactivated former customers: pin a policy (\"count as new\" or \"count as recovery\") and apply consistently. Most boards prefer separate reporting.", "Parent-child shifts: if the logo unit changes mid-year (e.g. multi-subsidiary deal becomes a single parent contract), don't treat the consolidation as a logo gain or loss." ], "validationChecks": [ "Count is a positive integer.", "New Customers Added × ACV ≈ New Business ARR within ~1% rounding — material divergence means the two metrics use different logo definitions.", "Trend should be smooth at steady state; large step-functions usually indicate a CRM data-cleanup or logo-unit change, not a real-world event." ], "commonMiscomputations": [ "Counting expansion deals or sub-account adds as \"new customers\" — inflates the acquisition signal.", "Logo-unit inconsistency across periods (parent in Q1, billing-entity in Q2) — produces phantom growth or shrinkage.", "Using signing-date here but go-live-date for New Business ARR — ASP becomes nonsense.", "Counting trial conversions twice (once when trial started, once when paid contract began).", "Including customers in the count whose contract never went live (lost-to-implementation churn happens before live-ARR but after counting)." ] }, "metricBasis": { "timeBasis": "period_flow", "dateBasis": "go_live", "production": "primary" } }, { "rogueId": "sales.new_opps_added_value", "slug": "new_opps_added_value", "domain": "sales", "defaultLabel": "New Opportunities Added", "description": "Total dollar value of new opportunities entering the pipeline during the period — the top-of-funnel inflow line in the pipeline flow. The single best read on the marketing-and-SDR engine's output. Common pitfall: counting inflated, un-qualified opportunities (e.g. every demo request) overstates the engine's output; restrict to opportunities that pass a defined qualification stage (typically SQL or higher) before counting. Boards expect this number to track forward quota — a quarter's top-of-funnel should be ~1× the same quarter's quota for a normal sales-cycle business.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "New Opportunities Added (Value) = Σ deal_value across opportunities that entered the pipeline during the period (using the same qualification-stage floor and value convention as upstream metrics). Excludes deals re-opened from closed-lost (those should be tracked separately to avoid double-counting top-of-funnel).", "whyItMatters": "Marketing/SDR output measured in dollars — directly determines whether future periods will have sufficient pipeline coverage. Trending down with stable conversion = future-period miss baked in 1–2 cycles out.", "interpretationGuidance": "New opportunities added should run ~1× of the comparable-period quota at steady state (i.e. the period's top-of-funnel feeds roughly the same period's closes via the sales cycle). Sustained sub-quota top-of-funnel for 2+ quarters is the canonical signal to invest in marketing or SDR capacity.", "relatedKpiIds": [ "sales.pipeline_value", "sales.opening_pipeline_value", "sales.pipeline_deal_count", "sales.pipeline_flow", "sales.win_rate" ], "calculationPolicy": { "inclusionRules": [ "Σ deal_value across opportunities that ENTERED the pipeline during the period — the top-of-funnel inflow line in the pipeline flow.", "Use the same qualification-stage floor (typically SQL or higher) and the same value convention as the upstream pipeline metrics." ], "exclusionRules": [ "Deals re-opened from closed-lost — track those separately to avoid double-counting top-of-funnel.", "Opportunities below the qualification floor (raw demo requests, unqualified inbound).", "Value already counted in the opening pipeline — only net-new entrants this period count." ], "requiredInputs": [ "Opportunity entry / creation dates and deal_value.", "The qualification-stage floor and value convention.", "Comparable-period quota for the benchmark read." ], "dataSourcePriority": [ "CRM opportunity-created report for the period.", "Marketing / SDR attribution system as a cross-check on engine output." ], "edgeCases": [ "Re-opened closed-lost deals: exclude or track separately so the engine output is not double-counted.", "A mega-deal entering pipeline skews the inflow — inspect alongside the count of new opportunities.", "Deals created late in the period: attribute by entry date, consistently." ], "validationChecks": [ "This is the inflow term of the pipeline-flow identity: opening + new_opps_added − `sales.closed_won_value` − `sales.closed_lost_value` − scrubs = closing pipeline (see `sales.opening_pipeline_value`). The flow must reconcile to the penny.", "New opportunities added ≈ 1× comparable-period quota at steady state; sustained sub-quota top-of-funnel for 2+ quarters is the canonical future-miss signal." ], "commonMiscomputations": [ "Counting un-qualified opportunities (every demo request) — overstates the marketing / SDR engine output.", "Counting re-opened closed-lost deals as new top-of-funnel — double-counts pipeline generation.", "Using a different value or stage-floor convention than the rest of the pipeline flow so the reconciliation breaks." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "sales.opening_pipeline_value", "slug": "opening_pipeline_value", "domain": "sales", "defaultLabel": "Opening Pipeline Value", "description": "Total pipeline value at the start of the period — the baseline against which the period's pipeline flow (+ new opportunities − won − lost = closing) reconciles. Equal to the prior period's closing pipeline by construction. Surfaces in sales.pipeline_flow as the `start` slot. Common pitfall: restating opening pipeline to retroactively \"clean up\" stale deals masks the hygiene problem rather than addressing it; cleanup should happen via explicit \"old-deal scrub\" lines in the flow, not by editing the opening baseline.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Opening Pipeline Value = Total pipeline value snapshot at period open = prior period's closing pipeline. Identity: opening + new_opps_added − closed_won_value − closed_lost_value − scrubs = closing pipeline.", "whyItMatters": "Without an explicit opening line, the pipeline flow has no anchor and the additions / removals cannot be audited. Boards expect the flow to reconcile to the penny period-over-period.", "interpretationGuidance": "Compare opening pipeline to the period's quota — opening pipeline coverage (opening / quota) is a stronger leading indicator than current pipeline (which has had time for in-period additions). Coverage < 1.5× quota at period open is usually a warning that the period requires above-average in-period generation to land.", "relatedKpiIds": [ "sales.pipeline_value", "sales.new_opps_added_value", "sales.closed_won_value", "sales.closed_lost_value", "sales.pipeline_flow" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "sales.pipeline_assumptions", "slug": "pipeline_assumptions", "domain": "sales", "defaultLabel": "Pipeline Assumptions", "description": "Narrative documenting the key assumptions underlying the pipeline forecast — conversion rates by stage, expected sales-cycle length, segment-mix expectations, and any deal-specific dependencies (e.g. \"we assume Acme renews their POC by end of month and signs the upgrade in Q3\"). Common pitfall: leaving assumptions implicit makes the forecast non-falsifiable — if you don't list the assumptions, you can't identify which one broke when the forecast misses. Renders side-by-side with sales.pipeline_risk_factors in the TwoColumnTextarea widget (sales.pipeline_context_notes container).", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Free-text narrative — no calculation. Convention: 3–6 bullet assumptions, each one stating the assumed value/rate and the implication if it diverges (e.g. \"Assumed Q3 win-rate of 28%; each 5pp miss = $X off forecast\").", "whyItMatters": "Makes the forecast falsifiable and post-mortem-able — without an assumptions list, missed quarters get attributed to vague \"execution\" rather than specific assumption failures the next plan should correct.", "interpretationGuidance": "After-the-fact review: which assumptions held and which broke? An assumption that consistently breaks (e.g. \"Q4 always slips\") is a planning-process problem, not an execution problem. Strong commentary names 1–2 assumptions explicitly and provides the sensitivity (\"if conversion holds at 32%, forecast holds; below 28% we are $X short\").", "relatedKpiIds": [ "sales.pipeline_risk_factors", "sales.pipeline_context_notes", "sales.weighted_forecast", "sales.quarterly_forecast", "sales.win_rate" ] }, { "rogueId": "sales.pipeline_composition", "slug": "pipeline_composition", "domain": "sales", "defaultLabel": "Pipeline Composition", "description": "Container handle for the manual pipeline-composition summary the bespoke Composition subform edits — four user-entered scalars (total open deals, average deal size, median deal size, largest deal) plus optional `dealsByType` / `dealsByStage` count+value breakdown maps. The median vs. average gap reveals pipeline skew: a median well below the average means a few mega-deals dominate. Common pitfall: carrying the summary forward each quarter instead of re-deriving it from the current open pipeline — roll-forward resets these to zero precisely so a human re-enters the period’s real numbers.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — { totalDeals, averageDealSize, medianDealSize, largestDeal, dealsByType?, dealsByStage? }. The four scalars are manual summary stats (not computed); the optional dealsByType/dealsByStage maps carry per-category { count, totalValue }. medianDealSize < averageDealSize signals right-skewed deal-size concentration.", "whyItMatters": "Summarizes the shape of the open pipeline in one place — deal count and size distribution — so a board can read concentration risk (a handful of large deals carrying the forecast) at a glance, alongside the reconciling pipeline flow.", "interpretationGuidance": "Read medianDealSize against averageDealSize: a large gap (e.g. median $82k vs. average $95k) means the pipeline leans on a few large deals — pair with `sales.pipeline_flow` and the notable-opportunities list to see whether those large deals are progressing. A largestDeal that dwarfs the median is single-deal risk worth naming in the narrative.", "relatedKpiIds": [ "sales.pipeline_deal_count", "sales.average_deal_size", "sales.median_deal_size", "sales.pipeline_flow", "sales.pipeline_key_deals" ] }, { "rogueId": "sales.pipeline_context_notes", "slug": "pipeline_context_notes", "domain": "sales", "defaultLabel": "Pipeline Context Notes", "description": "Container handle for the side-by-side contextual notes — pairs sales.pipeline_assumptions (left slot) with sales.pipeline_risk_factors (right slot) in the TwoColumnTextarea widget. Visually positions the \"what we're assuming\" narrative directly next to the \"what could break those assumptions\" narrative, forcing the team to write them in concert (rather than as two independent surfaces that drift apart over quarters). Common pitfall: writing assumptions without their corresponding risks (or vice versa) means the forecast is incomplete — every assumption should pair to a risk factor that captures the failure mode.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — two-slot composite. Left slot = sales.pipeline_assumptions, right slot = sales.pipeline_risk_factors. No additional content; the value of the container is purely the side-by-side rendering, which structurally encourages assumptions and risks to be written together.", "whyItMatters": "Forces a discipline that significantly improves forecast quality — assumption / risk pairs are more useful than either alone because each risk has a sensitivity (how much the forecast moves if the corresponding assumption breaks).", "interpretationGuidance": "Well-constructed pairs read like \"Assume win rate of 28% in Q3 → Risk: Win rate has dropped below 25% in months with competitive entry.\" A board reading the surface should be able to identify every risk's sensitivity by cross-referencing to the assumption.", "relatedKpiIds": [ "sales.pipeline_assumptions", "sales.pipeline_risk_factors", "sales.weighted_forecast", "sales.quarterly_forecast", "sales.key_concerns" ] }, { "rogueId": "sales.pipeline_deal_count", "slug": "pipeline_deal_count", "domain": "sales", "defaultLabel": "Pipeline Deal Count", "description": "Total number of active opportunities in the pipeline (open stages only — excludes closed-won and closed-lost). The volume side of pipeline coverage; paired with pipeline_value gives the average deal size and the deal-count vs deal-size ratio that characterizes the motion shape. Common pitfall: counting non-bona-fide opportunities (orphaned trials, demo requests that never converted to a real evaluation) inflates the number — apply a stage-floor cutoff (e.g. SQL or higher) so the count reflects committed evaluation activity.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Pipeline Deal Count = Count of opportunities currently in any open stage (qualification through proposal / negotiation). Applies the same stage-floor convention quarter-over-quarter so trend is comparable.", "whyItMatters": "Volume-side health of the funnel — when value rises with falling count, deal sizes are growing (often deliberate up-market motion); when count falls without value compensation, top-of-funnel is the problem.", "interpretationGuidance": "Read alongside average_deal_size and median_deal_size to characterize the motion shape: many small deals (high count / low size) implies a velocity / inside-sales motion; few large deals (low count / high size) implies an enterprise motion; mismatch between intended motion and observed shape is a strategic signal.", "relatedKpiIds": [ "sales.pipeline_value", "sales.average_deal_size", "sales.median_deal_size", "sales.win_rate", "sales.pipeline_stage_metrics" ], "calculationPolicy": { "inclusionRules": [ "Count of distinct opportunities currently in any open stage (qualification through proposal / negotiation) — a point-in-time count.", "Apply a stage-floor (typically SQL or higher) so the count reflects committed evaluation activity, held constant across periods." ], "exclusionRules": [ "Closed-won and closed-lost opportunities.", "Non-bona-fide opportunities below the stage floor (orphaned trials, unconverted demo requests).", "Splitting one multi-product opportunity into several deals — count the opportunity once (hold the counting unit constant)." ], "requiredInputs": [ "Open opportunities with stage at the snapshot date.", "The stage-floor convention." ], "dataSourcePriority": [ "CRM pipeline report at the snapshot date.", "Rev-ops export as a fallback — verify stage hygiene." ], "edgeCases": [ "Stale open deals inflate the count just as they inflate pipeline value — apply the same max-age hygiene rule.", "Parent / child or multi-product opportunities: pick a counting unit (opportunity vs account) and hold it constant with `sales.pipeline_value`." ], "validationChecks": [ "Count is a non-negative integer.", "Identity: `sales.pipeline_value` / pipeline_deal_count = `sales.average_deal_size` — sanity-check the three together.", "Trend should be smooth at steady state; step-changes usually mean a CRM cleanup or stage-floor change, not real-world motion." ], "commonMiscomputations": [ "Counting sub-floor opportunities (every demo request) — inflates the funnel.", "Stage-floor drift across periods — produces phantom count growth / shrinkage.", "Counting closed-won or closed-lost deals in the open-pipeline count." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "sales.pipeline_flow", "slug": "pipeline_flow", "domain": "sales", "defaultLabel": "Pipeline Flow", "description": "Container handle for the additive / subtractive pipeline-flow bridge — reconciles opening pipeline to closing pipeline through the period's adds, wins, and losses (opening + new_opps − closed_won − closed_lost = closing) with dual count + value columns. Renders via the FlowSubform widget. The audit trail of the pipeline motion — without this, period-over-period pipeline changes are unexplained. Common pitfall: a \"scrub\" line (deals reclassified from open to lost mid-period) is needed to keep the math reconciling when CRM hygiene happens; without it the flow appears not to balance and trust in the underlying numbers erodes.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — start/end slots with dual (count + value) columns. Identity that must hold: opening_pipeline_value + new_opps_added_value − closed_won_value − closed_lost_value − scrubs = closing pipeline_value. Same identity holds on the count side using deal counts. Any gap surfaces a data-quality issue worth root-causing before next period.", "whyItMatters": "Makes the period's pipeline changes auditable line-by-line — boards can immediately see whether closing pipeline shrank because deals closed (good) or because deals were lost / scrubbed (bad). Without the flow, only the net change is visible and the underlying motion is opaque.", "interpretationGuidance": "A healthy flow shows new_opps_added ≈ (closed_won + closed_lost) at steady state (top-of-funnel replacing what closes). When new_opps_added consistently lags closes, the closing pipeline shrinks period-over-period — future quarters will run into coverage stress. Disproportionate scrubs (large negative reclassifications) signal a CRM hygiene problem that's been suppressed.", "relatedKpiIds": [ "sales.opening_pipeline_value", "sales.new_opps_added_value", "sales.closed_won_value", "sales.closed_lost_value", "sales.pipeline_value", "sales.pipeline_deal_count" ] }, { "rogueId": "sales.pipeline_key_deals", "slug": "pipeline_key_deals", "domain": "sales", "defaultLabel": "Pipeline Key Deals", "description": "Container handle for the field-array of key in-flight deals — each entry tracks deal name, current stage, dollar value, and confidence/commit status. Renders via the CollapsibleFormItemCardGallery widget (a reused gallery pattern shared with HR keyHires / keyOpenings). The \"named deals the board should know about\" surface — typically the top 5–10 deals by value or strategic importance. Common pitfall: a static list that doesn't reflect the current quarter — these should be refreshed each period to reflect actual top-of-mind deals, not carried forward from prior packs.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — field-array of items (name, stage, value, confidence). No aggregate calculation; the surface's purpose is to make individual deals visible at the board level. Sum of values across the items typically represents a meaningful share (≥ 25%) of the period's quarterly forecast.", "whyItMatters": "Concentrates board attention on the specific deals whose outcomes will determine the quarter — sales leaders often have valuable context (executive relationships, partnership levers) that only the board can deploy. Without named-deal visibility, board help on big deals happens reactively.", "interpretationGuidance": "If the top 5 deals represent > 60% of the weighted forecast, the quarter is concentration-risky — any single slip is catastrophic. A healthy distribution has the top 5 below 50% of forecast. Track deal-mention persistence across quarters: deals that have appeared 2–3 quarters in a row at \"high commit\" without closing usually have a structural issue that's been missed.", "relatedKpiIds": [ "sales.pipeline_value", "sales.weighted_forecast", "sales.quarterly_forecast", "sales.average_deal_size", "sales.median_deal_size", "sales.win_rate" ] }, { "rogueId": "sales.pipeline_quarterly_forecasts", "slug": "pipeline_quarterly_forecasts", "domain": "sales", "defaultLabel": "Pipeline Quarterly Forecasts", "description": "Container handle for the addable per-quarter forecast rows — each row tracks quarter, totalPipelineValue, weightedPipelineValue, expectedCloses (committed forecast), and dealCount. Rendered via the AddableQuarterlyForecastTable widget. Provides the multi-quarter forward visibility view the board reviews to validate the next 2–4 quarters of revenue, not just the current quarter. Common pitfall: filling in only the current quarter and treating future quarters as \"we'll figure it out\" — multi-quarter forecasting forces honest top-of-funnel planning for the periods beyond the immediate one.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — addable rows of (quarter, totalPipelineValue, weightedPipelineValue, expectedCloses, dealCount). Per-row: totalPipelineValue = same as sales.pipeline_value for that quarter; weightedPipelineValue = same as sales.weighted_forecast; expectedCloses = same as sales.quarterly_forecast; dealCount = pipeline deal count attributed to that close period.", "whyItMatters": "Forward-quarter coverage view — the board needs to see whether next-quarter and next-next-quarter pipelines look credible, not just current. Many revenue misses are visible 2 quarters out if the multi-quarter pipeline view is honest; without this surface, the only data point is \"current quarter looks ok.\"", "interpretationGuidance": "Next-quarter pipeline coverage should be ≥ 2× quota at the start of current quarter (giving the cycle time to fill in). A pattern of pipeline shrinking quarter-by-quarter from current to current+3 = top-of-funnel capacity gap that demands investment now (3+ months before the affected revenue period).", "relatedKpiIds": [ "sales.pipeline_value", "sales.weighted_forecast", "sales.quarterly_forecast", "sales.pipeline_deal_count", "sales.new_opps_added_value" ] }, { "rogueId": "sales.pipeline_risk_factors", "slug": "pipeline_risk_factors", "domain": "sales", "defaultLabel": "Pipeline Risk Factors", "description": "Narrative listing the material risks to pipeline conversion or deal timing — specific deal slips, segment headwinds, budget freezes, competitive entry, ICP-fit misses on late-stage deals. Distinct from sales.key_concerns (which covers the whole sales motion) — this is specifically about the forecast / pipeline conversion math. Common pitfall: vague risks (\"market is choppy\") aren't actionable; a useful entry quantifies the at-risk dollar amount and names specific deals or segments. Renders side-by-side with sales.pipeline_assumptions in the TwoColumnTextarea widget.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Free-text narrative — no calculation. Convention: 3–5 bulleted risks, each quantified ($X at risk if Y materializes) and time-bound (in-quarter vs structural).", "whyItMatters": "Surfaces the forecast tail risk early enough for the board to engage — large-deal slip risks often have customer-side levers (CEO outreach, partnership offer) that only the board can pull. Without this surface those interventions happen reactively at quarter-end.", "interpretationGuidance": "Quantified risks (with dollar amounts) are actionable; un-quantified ones consume meeting time without producing decisions. Boards typically ask the team to rank the top 3 risks by expected loss and confirm mitigation owners — a healthy entry pre-empts this.", "relatedKpiIds": [ "sales.pipeline_assumptions", "sales.pipeline_context_notes", "sales.weighted_forecast", "sales.quarterly_forecast", "sales.key_concerns", "sales.competitive_alerts" ] }, { "rogueId": "sales.pipeline_sales_cycle", "slug": "pipeline_sales_cycle", "domain": "sales", "defaultLabel": "Sales Cycle Quarter-to-Quarter", "description": "Container handle for the three-section quarter-over-quarter compare object that tracks average days-to-close trend (lastQuarter / thisQuarter / improvement). Renders via the QuarterToQuarterImprovementGrid widget with three slots. The \"is the motion getting faster or slower\" diagnostic — cycle length trend is one of the most reliable leading indicators of ICP fit and packaging quality. Common pitfall: comparing without controlling for deal-size mix — if up-market mix is shifting, a flat cycle is actually an improvement (because up-market cycles are inherently longer). Note the mix context in commentary if material.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — three-slot composite. lastQuarter and thisQuarter slots = average sales cycle in days (sales.avg_sales_cycle_days for that period). improvement = (lastQuarter − thisQuarter) / lastQuarter × 100 (positive = cycle compressed = better). When deal-size mix changes materially, the slots should be ACV-segmented separately and the improvement read per segment.", "whyItMatters": "Cycle compression compounds dramatically — a 20% reduction in cycle time roughly translates to a 20% capacity increase for the same headcount. Cycle expansion does the inverse and usually predicts future-period coverage stress.", "interpretationGuidance": "Cycle compression of 10%+ QoQ at constant ACV mix is a strong signal that ICP / pricing / sales-process changes are working. Expansion of 20%+ at constant mix is the canonical \"something is broken in the buyer journey\" signal — usually procurement, security, or competitive friction worth a stage-by-stage diagnosis.", "relatedKpiIds": [ "sales.avg_sales_cycle_days", "sales.pipeline_stage_metrics", "sales.avg_contract_value", "sales.win_rate", "sales.pipeline_value" ] }, { "rogueId": "sales.pipeline_stage_metrics", "slug": "pipeline_stage_metrics", "domain": "sales", "defaultLabel": "Pipeline Stage Metrics", "description": "Container handle for the per-stage pipeline metrics grid — for each pipeline stage (qualification, discovery, evaluation, proposal, negotiation, closing) tracks dealCount, totalValue, closingProbability, winRateFromStage, and avgTimeToClose. The most diagnostic surface in the pipeline view: where deals are bunching, which stage is the bottleneck, where conversion math is breaking. Rendered via the StageMetricsGrid widget seeded from PipelineStageValues. Common pitfall: trusting unchanged stage probabilities even as the deal mix shifts — re-calibrate the per-stage close rates quarterly against actuals or the weighted forecast drifts unreliably.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — no scalar calculation. Per-stage rows: dealCount and totalValue are direct sums; closingProbability is the empirical historical close rate from that stage; winRateFromStage is the historical win rate of opportunities that reached that stage; avgTimeToClose is the average days from stage entry to close-won. Closing probabilities should be back-tested against actuals every 1–2 quarters and updated explicitly.", "whyItMatters": "Localizes pipeline problems to specific stages — flat pipeline value with a stage-2 buildup means lead-qualification is too loose; stage-5 stall means closing-skill or pricing-objection issues. Without this surface, the weighted forecast is opaque.", "interpretationGuidance": "Look for stage where deal count is bunching disproportionately — that is the current bottleneck. Compare win-rate-from-stage at the entry stage (top of funnel) vs late stages: large gaps imply the team is investing time on low-probability deals. The avgTimeToClose by stage should monotonically decrease (later stage = closer to close); if not, stage definitions are likely misaligned with actual buyer behavior.", "relatedKpiIds": [ "sales.pipeline_value", "sales.pipeline_deal_count", "sales.weighted_forecast", "sales.win_rate", "sales.avg_sales_cycle_days", "sales.pipeline_sales_cycle" ] }, { "rogueId": "sales.pipeline_value", "slug": "pipeline_value", "domain": "sales", "defaultLabel": "Pipeline Value", "description": "Sum of the dollar value of all active deals currently in the sales pipeline — unweighted (raw deal-value sum, not probability-weighted). Boards read this as the top-of-funnel sufficiency check: if pipeline coverage (pipeline value / forecast) drops below the historic conversion-rate-implied threshold, the forecast is at risk. Common pitfall: confusing pipeline value with weighted forecast — the unweighted number always exceeds the weighted, often by 3–5× depending on the stage mix. Always report both and the implied conversion ratio.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Pipeline Value = Σ (deal_value) across all open opportunities in stages between qualification and signature (excludes closed-won and closed-lost). No probability weighting — for that, see sales.weighted_forecast.", "whyItMatters": "The capacity number for the forecast — without sufficient pipeline value, the forecast is structurally unachievable regardless of close-rate execution. Coverage ratio (pipeline / quota) is the first read on whether the team can hit the period.", "interpretationGuidance": "Typical SaaS pipeline-coverage benchmark is 3× quota for the current quarter and 4–5× for the next quarter (industry folk-wisdom — varies meaningfully by historical win rate; the right multiple is 1 / historical-win-rate, not a fixed number). Coverage below the historic-conversion-implied threshold is the canonical \"you will miss\" signal.", "relatedKpiIds": [ "sales.weighted_forecast", "sales.pipeline_deal_count", "sales.average_deal_size", "sales.win_rate", "sales.quarterly_forecast", "sales.pipeline_stage_metrics" ], "calculationPolicy": { "inclusionRules": [ "Σ deal_value across all open opportunities in stages between qualification and signature — a point-in-time snapshot of the live pipeline.", "Unweighted: raw deal-value sum, NO probability weighting (for the probability-weighted number see `sales.weighted_forecast`).", "Apply a consistent stage-floor (typically SQL or higher) and the same value convention (TCV vs ACV) used across the other pipeline metrics." ], "exclusionRules": [ "Closed-won and closed-lost opportunities — those have left the pipeline (see `sales.closed_won_value` / `sales.closed_lost_value`).", "Probability-weighting of any kind — that is `sales.weighted_forecast`.", "Non-bona-fide opportunities below the stage floor (orphaned trials, demo requests that never became a real evaluation)." ], "requiredInputs": [ "Open opportunities with stage and deal_value at the snapshot date.", "The stage-floor and value (TCV / ACV) conventions.", "The current / next-period quota for the coverage read." ], "dataSourcePriority": [ "CRM pipeline report (Salesforce / HubSpot) at the snapshot date.", "Rev-ops pipeline export as a fallback — verify stage hygiene first." ], "edgeCases": [ "Stale \"open\" deals that should be closed-lost inflate pipeline value; enforce a max-age auto-flag so coverage is not overstated.", "A few oversized mega-deals can dominate the sum — inspect alongside `sales.average_deal_size` / median for concentration risk.", "Mid-stage re-scoping: use the current deal_value, consistently across the series." ], "validationChecks": [ "Pipeline value ≥ weighted forecast always (unweighted exceeds weighted, often 3–5× by stage mix) — if not, the weighting is wrong.", "Coverage ratio (pipeline value / quota) should be read against 1 / historical-win-rate, not a fixed 3× folk number; coverage below the historic-conversion-implied threshold is the canonical \"you will miss\" signal.", "Identity: pipeline_value = `sales.pipeline_deal_count` × `sales.average_deal_size`." ], "commonMiscomputations": [ "Reporting the weighted forecast as pipeline value (or vice versa) — the unweighted-vs-weighted distinction is the entire point of the two lines.", "Counting closed deals or sub-floor junk opportunities — overstates coverage.", "Switching the TCV / ACV convention between pipeline_value, `sales.closed_won_value`, and `sales.weighted_forecast` so the dashboard math stops reconciling." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "sales.quarterly_forecast", "slug": "quarterly_forecast", "domain": "sales", "defaultLabel": "Quarterly Forecast", "description": "The team's expected closed-won dollars for the current quarter — usually a sales-leader judgment call informed by weighted forecast but adjusted for deal-by-deal commit confidence. Distinct from weighted_forecast (which is mechanical, stage × probability). Boards read both: a quarterly_forecast materially below weighted_forecast means the team has explicit negative judgment on specific big deals; above it means they're calling deals stronger than the stage probabilities suggest. Common pitfall: anchoring the call to plan rather than reality — boards quickly learn to discount \"we will hit plan\" forecasts and reward calibrated commit-vs-actual track records.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Quarterly Forecast = Sales leadership's committed call on closed-won dollars for the current quarter. Convention: blends weighted forecast (mechanical) with deal-by-deal judgment overlays (commit / best-case adjustments). Typically reported as a single point estimate; some teams report commit / forecast / best-case ranges.", "whyItMatters": "The number the board commits against — quarter-end attainment vs this number is the primary execution scorecard. Track forecast-accuracy (forecast vs actual) over time to calibrate trust in the call.", "interpretationGuidance": "Forecast attainment within ±5% over 4+ quarters = well-calibrated forecast and a leader the board can rely on. Persistent over-shoot = sandbagging (rebase quota); persistent under-shoot = forecasting / qualification problem worth a methodology change. The drift between weighted forecast and quarterly forecast is itself a signal — large gaps demand explicit explanation.", "relatedKpiIds": [ "sales.weighted_forecast", "sales.pipeline_value", "sales.closed_won_value", "sales.win_rate", "sales.pipeline_quarterly_forecasts" ], "calculationPolicy": { "inclusionRules": [ "Sales leadership's committed call on closed-won dollars for the current quarter — a point-in-time judgment number.", "Blends the mechanical weighted forecast with deal-by-deal commit / best-case judgment overlays.", "State the reporting convention explicitly (single point estimate vs commit / forecast / best-case range)." ], "exclusionRules": [ "The mechanical stage × probability number itself — that is `sales.weighted_forecast`; the quarterly forecast is judgment-adjusted, not mechanical.", "Unweighted pipeline capacity — `sales.pipeline_value`.", "Plan / quota — the forecast is a reality call, not the plan number." ], "requiredInputs": [ "`sales.weighted_forecast` as the mechanical anchor.", "Deal-by-deal commit-confidence overlays from the sales team.", "Current-quarter boundaries and quota for the attainment read." ], "dataSourcePriority": [ "Forecast-call system / CRM forecast categories (commit / best-case).", "Sales-leadership judgment captured in the weekly forecast review." ], "edgeCases": [ "Forecast materially below weighted forecast = explicit negative judgment on specific big deals; above it = calling deals stronger than the stage probabilities — both demand an explicit explanation.", "Anchoring the call to plan rather than reality — boards quickly discount \"we will hit plan\" forecasts and reward calibrated commit-vs-actual track records." ], "validationChecks": [ "Track forecast accuracy (forecast vs actual `sales.closed_won_value`) over 4+ quarters: within ±5% = well-calibrated; persistent over-shoot = sandbagging; persistent under-shoot = a forecasting / qualification problem.", "The drift between `sales.weighted_forecast` and quarterly_forecast is itself a signal — large gaps require commentary." ], "commonMiscomputations": [ "Reporting the mechanical weighted forecast as the quarterly forecast (or vice versa) — they are different numbers by construction.", "Anchoring the call to plan / quota rather than to deal-by-deal reality.", "Comparing attainment against pipeline value instead of against the committed forecast." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "sales.starting_arr", "slug": "starting_arr", "domain": "sales", "defaultLabel": "Starting ARR", "description": "Opening ARR at the beginning of the period — the baseline against which the period's ARR waterfall (new + expansion − downgrades − churn) reconciles to ending ARR. Equal to the prior period's closing ARR by construction. The FlowSubform widget binds starting_arr as the `start` slot of the ARR-bridge flow, and the ending position is computed as start + Σ(deltas). Common pitfall: restating starting_arr mid-period to \"fix\" a prior-period reporting error breaks the period-over-period audit trail; corrections should land as a separate restatement note, not by editing the opening balance.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "Sales" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Starting ARR = ARR snapshot at period open = the prior period's closing ARR. Identity that must hold: starting_arr + new_business + expansion − downgrades − churn_arr = ending ARR (sales.arr at period close). Reconcile any gap as a \"data quality\" line and root-cause it before next period.", "whyItMatters": "The anchor of the ARR waterfall — without an explicit starting point, the period's net-new ARR cannot be audited. Boards expect the waterfall to reconcile to the penny, period over period.", "interpretationGuidance": "If starting_arr ≠ prior-period ending ARR, there is either a restatement or a data issue — surface it explicitly. Beyond that the value itself is descriptive, not interpretive; the interpretive work happens on the delta lines.", "relatedKpiIds": [ "sales.arr", "sales.new_business", "sales.expansion", "sales.churn_arr", "sales.downgrades" ], "calculationPolicy": { "inclusionRules": [ "ARR snapshot at the exact open of the period.", "By identity, equals the prior period's closing ARR (`sales.arr` at prior period close)." ], "exclusionRules": [ "Any in-period activity (new business, expansion, churn, downgrades) — Starting ARR is the opening balance only.", "Restatement corrections — never edit the opening balance to fix a prior error; land corrections as an explicit restatement line." ], "requiredInputs": [ "Prior period's closing ARR." ], "dataSourcePriority": [ "Prior period's board-reported closing ARR (the audited / agreed number)." ], "edgeCases": [ "First period a company tracks ARR: Starting ARR is whatever the historical ARR was at that open; if unknown, disclose as \"first tracked period — opening balance estimated.\"", "Restatement of a prior period: Starting ARR for the current period uses the RESTATED prior close, with the restatement disclosed. Do not silently absorb it.", "Acquisition that closed exactly at period open: decide whether acquired ARR is in the opening balance or appears as an in-period inorganic line, and disclose." ], "validationChecks": [ "Starting ARR === prior period closing ARR. Any inequality is a restatement or a data error — never let it pass silently.", "Starting ARR + New Business + Expansion − Downgrades − Churn === Ending ARR. The waterfall must reconcile to the penny." ], "commonMiscomputations": [ "Restating Starting ARR mid-stream to \"fix\" a prior reporting error — breaks the period-over-period audit trail; corrections belong in a restatement note.", "Using current-period ARR as the starting balance (off-by-one-period error) — the whole waterfall then fails to reconcile.", "Letting Starting ARR drift from prior closing ARR because the two are computed by different teams from different snapshots.", "Folding acquired ARR into Starting ARR without disclosure — masks how much of \"growth\" was inorganic." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "contracted_arr", "dateBasis": "go_live", "production": "computed" } }, { "rogueId": "sales.strategic_context", "slug": "strategic_context", "domain": "sales", "defaultLabel": "Sales Strategic Context", "description": "Executive-summary narrative for the sales section of the board pack — the CRO/CEO's one-screen synthesis of overall sales performance, market dynamics, and the story behind the quarter's numbers. Categorical state derived from operational reporting — no calculation. Renders via ExecutiveCommentary widget as multi-section tabbed prose with per-section word counts. Common pitfall: writing it as a numbers-recap repeats what the KPI table already shows; the goal is the connective tissue — why the numbers moved, what changed in the market, what the next 90 days look like. Boards read this first when scanning the deck.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Free-text narrative — no calculation. Convention: 3–5 sentences per section across overall performance, market dynamics, and forward outlook. The ExecutiveCommentary widget enforces a soft word-count target per section.", "whyItMatters": "Provides the interpretive frame that turns the raw KPI table into a story the board can debate. Without it, board members default to their own (often wrong) interpretation of the numbers.", "interpretationGuidance": "A well-written entry calls out one or two surprises and links them to actionable next steps; a poorly-written entry just narrates the KPIs back. If the prose only describes what the numbers show, treat it as missing context — push back during pre-read.", "relatedKpiIds": [ "sales.key_concerns", "sales.focus_areas", "sales.competitive_alerts", "sales.arr", "sales.growth_rate_yoy" ] }, { "rogueId": "sales.total_revenue", "slug": "total_revenue", "domain": "sales", "defaultLabel": "Recognized Revenue", "description": "Total revenue recognized under the company's accounting standard (ASC 606 / IFRS 15) during the period — distinct from billings (what was invoiced) and from ARR (an annualized run-rate snapshot). The income-statement top line and the basis for GAAP reporting. Common pitfall: confusing recognized revenue with ARR — for a company with mid-year contract starts, ARR exit will exceed recognized revenue for that year; the gap shrinks as the cohort matures. Boards reviewing a recognition-heavy investor pack should always see ARR alongside revenue to avoid mis-pricing growth.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "recommended", "seed": "recommended", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Recognized Revenue = Sum of revenue earned during the period under ASC 606 (or IFRS 15). For subscription contracts, recognized ratably over the contract term; for usage / professional services, recognized as delivered. Distinct from bookings (signed contracts) and billings (invoiced amounts). Public-reporting companies should reconcile this line to the income statement.", "whyItMatters": "The audited top line that anchors every GAAP-based valuation multiple, debt covenant, and tax filing. Boards need it to track the path to profitability (revenue − cost), which subscription ARR alone cannot show.", "interpretationGuidance": "For an early subscription business, recognized revenue typically lags ARR by 20–40% on an annual basis depending on contract-start distribution within the year; the gap shrinks at steady state. A material divergence between recognized-revenue growth and ARR growth in the same period usually signals either a billing-policy change or a contract-mix shift (e.g. shift to upfront-billed multi-year).", "relatedKpiIds": [ "sales.arr", "sales.carr", "sales.bookings_backlog", "sales.bookings_backlog_total", "sales.gross_margin", "sales.growth_rate_yoy" ], "calculationPolicy": { "inclusionRules": [ "Revenue earned during the period under the company's accounting standard (ASC 606 / IFRS 15): subscription value recognized ratably over the contract term, usage / overage recognized as consumed, professional services recognized as delivered.", "All income-statement revenue lines for the period — subscription, usage, AND one-time services — because this is the GAAP top line, not a recurring-only run-rate.", "Public-reporting companies: reconcile this figure to the income-statement revenue line." ], "exclusionRules": [ "Bookings (signed contract value not yet earned) and billings (invoiced amounts) — recognized revenue is neither.", "ARR / run-rate snapshots — `sales.arr` is an annualized point-in-time contracted run-rate, NOT period-earned revenue. Keep the two distinct (see edge cases + miscomputations).", "Deferred revenue still on the balance sheet (invoiced-but-unearned) until it is actually earned." ], "requiredInputs": [ "Period revenue split by recognition category (subscription ratable, usage-as-consumed, services-as-delivered).", "Contract start dates and terms (to drive ratable subscription recognition).", "Period boundaries." ], "dataSourcePriority": [ "Audited / reviewed income statement (or the revenue sub-ledger that rolls up to it).", "Billing + revenue-recognition system (Zuora / Chargebee RevRec, NetSuite) when the close is not yet final.", "Spreadsheet revenue schedules only as a last resort — flag uncertainty in the output." ], "edgeCases": [ "Mid-year contract starts: recognized revenue for the year lags exit ARR by 20–40% depending on start-date distribution; the gap shrinks as the cohort matures.", "Multi-year upfront-billed contracts: recognize ratably regardless of the billing schedule — cash and recognized revenue diverge in that period.", "Multi-currency: convert each revenue stream on the period recognition-rate convention; never mix rates within a series." ], "validationChecks": [ "Recognized revenue ≤ cumulative billings to date (absent unbilled / accrued revenue) — a material breach signals a recognition-schedule error.", "Recognized-revenue growth and ARR growth in the same period should move together; a large divergence flags a billing-policy change or contract-mix shift (e.g. shift to upfront-billed multi-year), not a story.", "Sum of the monthly recognized-revenue numbers reconciles to the period total within rounding." ], "commonMiscomputations": [ "Reporting ARR — or MRR × 12, or run-rate revenue × the period count — as recognized revenue. ARR is a contracted run-rate snapshot; for mid-year starts it exceeds recognized revenue, so the swap overstates the GAAP top line. See `sales.arr`.", "Reporting billings or bookings as revenue — invoiced / signed is not earned.", "Dropping one-time services from the GAAP top line (or, conversely, folding them into a \"recurring revenue\" figure) — recognized revenue is ALL earned revenue; recurring-only belongs in `sales.arr`.", "Mixing cash receipts with recognized revenue on upfront-billed contracts — collapses the rev-rec schedule that this line exists to honor." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "recognized_revenue", "production": "primary" } }, { "rogueId": "sales.weighted_forecast", "slug": "weighted_forecast", "domain": "sales", "defaultLabel": "Weighted Pipeline Forecast", "description": "Total pipeline value with each deal multiplied by its stage-based close probability — the canonical probabilistic forecast number. More forecasting-useful than raw pipeline value because it accounts for the conversion-likelihood mix across stages (early-stage deals weighted ~10–25%, mid-stage ~40–60%, late-stage ~70–90%). Common pitfall: using globally-flat probabilities (e.g. always 50%) instead of stage-specific calibrated ones — a reliable weighted forecast requires the stage probabilities to be back-tested against actual close rates from prior periods.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Weighted Forecast = Σ (deal_value × stage_close_probability) across all open opportunities. Stage probabilities should be the empirical historical close rate by stage for the comparable cohort (segment / motion / quarter-of-year mix), not arbitrary fractions.", "whyItMatters": "The single most-cited number in the weekly forecast call — the team's probabilistic answer to \"what will we close.\" Boards compare it to commit and quota to assess delivery risk.", "interpretationGuidance": "Weighted forecast trending up while pipeline value is flat usually means deals are advancing through stages (good); trending flat while pipeline grows usually means new deals are entering early stages but not advancing (top-of-funnel-only growth — yellow flag). A weighted forecast meaningfully below quota mid-quarter is the canonical \"you will miss without intervention\" signal.", "relatedKpiIds": [ "sales.pipeline_value", "sales.quarterly_forecast", "sales.pipeline_stage_metrics", "sales.win_rate", "sales.closed_won_value" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "sales.win_rate", "slug": "win_rate", "domain": "sales", "defaultLabel": "Win Rate", "description": "Percentage of closed opportunities that resulted in closed-won (vs closed-lost) during the period. The single best read on bottom-of-funnel execution and the most direct input to pipeline-coverage math (required coverage = 1 / win rate). Common pitfall: computing win rate without disqualifying \"no decision\" outcomes inflates losses and depresses the rate artificially; the SaaS norm is to either bucket no-decisions separately or track a two-rate view (raw win rate vs ICP-fit win rate excluding no-decisions). Stage-segment cuts (SMB vs Enterprise) usually differ 2×–4× and should be reported separately when volume permits.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Win Rate = (Closed-Won Count / (Closed-Won Count + Closed-Lost Count)) × 100. Excludes \"no decision\" / paused opportunities (track separately). Compute on count basis for execution analysis; compute on value basis (Won Value / (Won Value + Lost Value)) for dollar-weighted view.", "whyItMatters": "Reciprocal of required pipeline coverage — a 25% win rate requires 4× pipeline coverage to hit quota. Drives capacity planning, quota setting, and the pipeline-coverage commit conversation.", "interpretationGuidance": "Typical SaaS win rates (industry folk-wisdom, not citation-grade): inbound-heavy SMB motions 25–40%, mid-market 15–25%, enterprise / outbound-heavy 10–20%. Sharp drops (≥ 10pp over 2 quarters) at constant motion mix is the canonical \"competitive entry\" or \"ICP drift\" signal — investigate loss-reason distribution before changing tactics.", "relatedKpiIds": [ "sales.closed_won_count", "sales.closed_lost_count", "sales.closed_won_value", "sales.closed_lost_value", "sales.pipeline_value", "sales.pipeline_stage_metrics", "sales.competitive_alerts" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } } ] }