{ "version": "1.3.0", "releasedAt": "2026-05-20", "kpis": [ { "rogueId": "customers.acv_trend_pct", "slug": "acv_trend_pct", "domain": "customers", "defaultLabel": "ACV Trend", "description": "Period-over-period percent change in Average Contract Value (mean ARR per active customer logo). A rising ACV trend signals pricing power, successful tier upgrades, or a mix-shift toward larger customers; a falling ACV trend signals seat compression, discounting pressure, or a mix-shift toward smaller customers. The board reads this alongside `total_customers` and `customers.net_revenue_retention` to disambiguate which lever is moving — logo growth vs. expansion vs. price. Common pitfall: ACV mix-shifts (a wave of new SMB logos at low ACV) can drag the average down even when existing-customer ACV is rising — segment-cut ACV is more diagnostic than the blended number.", "fieldType": "percentage", "unit": "%", "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 }, "formula": "acv_trend_pct = (ACV_current_period − ACV_prior_period) ÷ ACV_prior_period, where ACV = total ARR ÷ total active customer logos. The blended view is sensitive to logo-mix shifts; segment-cut ACV (by cohort, ACV band, or product tier) is more diagnostic.", "whyItMatters": "Separates \"more customers\" from \"bigger customers\" in growth narrative. Combined with logo count, isolates the pricing-power signal that NRR and ARR alone can blur.", "interpretationGuidance": "No citation-grade absolute benchmark exists — compare to the company's own trailing trend and to deliberate strategy (a downmarket push should show ACV declining). Pair with segment cuts: a blended ACV that's flat may hide an upmarket cohort growing 20% offset by a downmarket cohort growing 50% in count. Persistent decline with flat NRR signals discounting / seat compression — surface the cause in `retention_insights` or `expansion_opportunities`.", "relatedKpiIds": [ "sales.avg_contract_value", "customers.total_customers", "customers.net_revenue_retention", "customers.expansion_opportunities", "sales.arr" ], "metricBasis": { "timeBasis": "trailing_window", "production": "computed" } }, { "rogueId": "customers.arr_at_risk", "slug": "arr_at_risk", "domain": "customers", "defaultLabel": "ARR at Risk", "description": "Sum of ARR from customers flagged \"at-risk\" by the customer-success team — typically driven by usage decline, low health score, executive turnover at the customer, missed milestones, or explicit churn intent. The board reads this as the worst-case near-term churn exposure if no intervention happens. Common pitfall: the \"at-risk\" definition drifts across CSMs and quarters; standardize the criteria (e.g. health score below threshold OR 30-day usage drop > X% OR cancellation request received) and version-control the playbook so the absolute number is comparable period-over-period. Pair with `percent_arr_at_risk` for the proportional read.", "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 }, "formula": "arr_at_risk = Σ(ARR of customers flagged at-risk by CS team). The \"at-risk\" flag itself is a company-specific definition (typical components: health score below threshold, 30-day usage decline, executive churn at customer, missed onboarding milestones, explicit churn signal). Document the flag rule in `customer_definition_note` so the number is comparable across periods.", "whyItMatters": "Converts the qualitative CS pipeline into a board-readable dollar exposure. Forces the team to put a number on hand-wavy customer-health concerns and surfaces concentration risk (a single $500K at-risk account is a different conversation than fifty $10K accounts).", "interpretationGuidance": "Always present alongside `percent_arr_at_risk` — $500K at-risk is a 5% problem at $10M ARR but a 0.5% problem at $100M ARR. There is no citation-grade industry benchmark for the absolute number; the >15% destructive threshold the `ArrAtRiskGauge` widget uses is internal heuristic, not an external standard. Trend month-over-month — sustained growth in `arr_at_risk` is the leading indicator that NRR will deteriorate next quarter.", "relatedKpiIds": [ "customers.percent_arr_at_risk", "customers.churn_risks", "customers.top_customer_concentration", "customers.net_revenue_retention", "customers.gross_revenue_retention", "sales.arr" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "contracted_arr", "production": "primary" } }, { "rogueId": "customers.churn_risks", "slug": "churn_risks", "domain": "customers", "defaultLabel": "Churn Risks", "description": "Named at-risk accounts, root-cause analysis of why they're at risk, and the mitigation plan in flight. Pairs with the quantitative `arr_at_risk` and `percent_arr_at_risk` and gives the board the names + the playbook. Common pitfall: listing the at-risk accounts without the diagnosis or the plan — the board reader needs to see what the team is doing about it, not just what the team is worried about. Also: avoid using this surface as a generic \"things are bad\" venting forum — keep it account-specific and action-specific.", "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 }, "formula": "Qualitative — no calculation. Per-account list: account name, ARR exposure, churn driver (usage decline, exec churn, missed milestone, competitive loss, integration friction, etc.), mitigation owner, mitigation plan, next checkpoint date.", "whyItMatters": "Converts the dollar exposure (`arr_at_risk`) into a board-readable narrative of named accounts and concrete plans. Forces the CS team to articulate the diagnosis, not just the symptom.", "interpretationGuidance": "Anti-pattern: an aggregate \"we have $X at risk\" with no per-account breakdown. Strong content lists the top 3–5 at-risk accounts by ARR, with cause and plan for each. If the team is asking the board for help (intro, exec sponsor, pricing relief), surface the ask here explicitly — boards routinely catch resolvable churn that the team would not have escalated.", "relatedKpiIds": [ "customers.arr_at_risk", "customers.percent_arr_at_risk", "customers.top_customer_concentration", "customers.retention_insights", "customers.key_initiatives" ] }, { "rogueId": "customers.customers_churned", "slug": "customers_churned", "domain": "customers", "defaultLabel": "Customers Churned", "description": "Count of customer logos that ended their subscription/contract during the period. Includes voluntary cancellations and non-renewals. Some companies separately track downgrade-to-zero as churn — be explicit about whether downgrades that drop ARR to $0 count as churn (typical: yes) vs. material contraction that keeps ARR > 0 (typical: tracked under contraction, not churn). The board reads this as the raw count behind `logo_churn_rate`; the percentage tells you the rate, the absolute count tells you the volume of CS pain. Common pitfall: counting customers that re-activate (sometimes called \"boomerang\" or resurrection) — settle the rule (typical: count each cancellation event, do not net resurrection).", "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 }, "formula": "customers_churned = count of customer logos that ended their paid subscription/contract during the period. Voluntary cancellations + non-renewals. Downgrade-to-$0 typically counts; document the rule and hold it constant.", "whyItMatters": "The absolute volume read on customer loss. The percentage (`logo_churn_rate`) tells you the rate; the count tells you the CS team load and the number of post-mortem conversations needed.", "interpretationGuidance": "No citation-grade absolute benchmark exists — the right comparison is to the company's own trailing periods and to its starting logo count. Pair with `logo_churn_rate` for proportional context and with `churn_risks` for the qualitative narrative. A spike with stable rate means the install base grew; a spike with rising rate is a quality signal — both deserve a board comment.", "relatedKpiIds": [ "customers.logo_churn_rate", "customers.logo_retention_rate", "customers.total_customers", "customers.churn_risks" ], "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "customers.expansion_opportunities", "slug": "expansion_opportunities", "domain": "customers", "defaultLabel": "Expansion Opportunities", "description": "Identified upsell, cross-sell, and seat-expansion opportunities inside the existing customer base, with deal size and timing where known. This is the qualitative narrative behind the expansion component of NRR — what the CS / Sales team sees in the pipeline that has not yet converted. The board reads this as forward-looking signal on whether NRR will trend up or down next quarter. Common pitfall: confusing \"opportunities\" (real conversations with named accounts) with \"addressable upside\" (theoretical TAM uplift) — keep this field anchored in actual pipeline.", "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 }, "formula": "Qualitative — no calculation. Narrative list of named-account expansion opportunities (seat count, module add-on, tier upgrade, cross-sell) with estimated deal size and target close period when available.", "whyItMatters": "Forward-looking signal on NRR trajectory. A thin expansion pipeline is the leading indicator of NRR compression — boards catch it here before it shows up in the metric next quarter.", "interpretationGuidance": "Anti-pattern: vague \"we see room to expand in mid-market\" framing without named accounts or sizing. Strong content lists ≥3 named opportunities with deal size estimates and target timing, plus a short note on the blocking gate (procurement, integration, exec sponsor) for each. If the pipeline is genuinely thin, write that explicitly — the board needs to know.", "relatedKpiIds": [ "customers.net_revenue_retention", "customers.retention_insights", "customers.key_initiatives", "sales.arr" ] }, { "rogueId": "customers.gross_revenue_retention", "slug": "gross_revenue_retention", "domain": "customers", "defaultLabel": "Gross Revenue Retention (GRR)", "description": "Recurring revenue retained from the cohort of customers present at the start of the period, excluding expansion — so the metric captures only churn and contraction. Per the SaaS Metrics Standards Board (SMSB) GRR standard. GRR is bounded at 100% (cannot exceed it) and reads as the \"no-defense-against-churn\" floor on retention. The board reads GRR alongside NRR (`customers.net_revenue_retention`) — the gap between them is the expansion contribution. Common pitfall: treating GRR and NRR as substitutes — they answer fundamentally different questions, and a healthy NRR with sliding GRR signals churn masked by upsell.", "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": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/gross-revenue-retention", "sectionRef": "GRR", "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." }, "benchmark": { "p25": 82, "median": 91, "p75": 95, "unit": "%", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceYear": "2024", "higherIsBetter": true }, "formula": "GRR = (Starting ARR − Contraction − Churn) ÷ Starting ARR, on the cohort active at period start. Excludes expansion. Capped at 100% by definition. Per SMSB GRR standard.", "whyItMatters": "Isolates the \"do customers stay and not shrink\" signal from expansion noise. GRR is the true downside floor on retention — boards use it to spot product or onboarding deterioration that NRR can hide.", "interpretationGuidance": "Per KBCM/Sapphire Private SaaS Company Survey 2024 (§ \"Gross Dollar Retention\"), private SaaS GRR medians typically sit in the high-80s to low-90s, with top-quartile in the mid-90s — distributions vary by ACV cohort and vintage, so pull the current edition. The NRR − GRR gap quantifies expansion contribution; a widening gap with declining GRR is a yellow flag (expansion masking churn). Trend it quarterly — a single-period drop with steady NRR usually means a one-off contraction; persistent decline with flat NRR is a product issue.", "relatedKpiIds": [ "customers.net_revenue_retention", "customers.logo_retention_rate", "customers.logo_churn_rate", "customers.churn_risks", "sales.arr" ], "calculationPolicy": { "inclusionRules": [ "Cohort = customers active at the start of the period (same cohort as NRR).", "Numerator: Starting ARR − Contraction − Churn. Expansion is excluded by definition.", "Capped at 100% — if a calculation produces > 100%, expansion is leaking in." ], "exclusionRules": [ "Expansion ARR, cross-sell ARR, price increases — none of these enter GRR (that is exactly what distinguishes GRR from NRR).", "New-logo ARR (same exclusion as NRR)." ], "requiredInputs": [ "Customer-level ARR snapshot at period start (cohort identity).", "Customer-level ARR snapshot at period end for the same cohort.", "Classification of each per-customer change as contraction vs churn vs (excluded) expansion." ], "dataSourcePriority": [ "Same cohort-tracking source as NRR; the two metrics share inputs." ], "edgeCases": [ "Customer with both expansion and contraction in the period: zero out the expansion, keep the contraction.", "Customer renaming or re-keying: hold cohort identity by account, not by name." ], "validationChecks": [ "GRR ≤ 100% always; > 100% means expansion is being counted (recompute with strict exclusion).", "GRR ≤ NRR for the same cohort; the gap is the expansion contribution." ], "commonMiscomputations": [ "Letting expansion in — produces GRR > 100%, which is definitionally impossible; the most common GRR error.", "Reporting GRR alone without NRR — boards always want the pair to see whether expansion is masking churn.", "Conflating GRR with logo retention — GRR is dollar-based; logo retention is count-based; they answer different questions.", "Using a different cohort base than NRR — the two must use the same starting cohort to make the gap meaningful." ] }, "metricBasis": { "timeBasis": "period_flow", "cohortBasis": "closed_start_cohort", "production": "computed" } }, { "rogueId": "customers.key_initiatives", "slug": "key_initiatives", "domain": "customers", "defaultLabel": "Customer Success Initiatives", "description": "Active programs the CS / Product / Sales team is running to improve customer health, NPS, retention, or expansion — onboarding revamps, health-score model updates, success-plan rollouts, expansion playbooks, advocacy programs, executive-business-review cadence changes. The board reads this as the \"what are we doing about it\" companion to the metric pages and the at-risk narrative. Common pitfall: listing initiatives without owner, target metric movement, or checkpoint date — the board cannot follow up on vague programs.", "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 }, "formula": "Qualitative — no calculation. Per-initiative list: initiative name, target metric (which KPI it intends to move), owner, status (planned / in-progress / launched / measuring), next checkpoint date.", "whyItMatters": "Closes the loop between the metrics page and the \"what we're doing\" board narrative. Lets the board hold the team accountable to the actions, not just the outcomes — especially valuable when KPI movement lags initiative launch by a quarter or two.", "interpretationGuidance": "Anti-pattern: a wishlist of initiatives without owners or target metrics. Strong content states which KPI each initiative aims to move (e.g. \"Onboarding revamp → targeting +5pp lift in 90-day GRR for SMB cohort by Q2\"), names the owner, and gives a checkpoint date. Closed initiatives should report the actual metric movement vs. target — wins and misses both teach the board.", "relatedKpiIds": [ "customers.retention_insights", "customers.expansion_opportunities", "customers.churn_risks", "customers.net_revenue_retention", "customers.nps_score" ] }, { "rogueId": "customers.logo_churn_rate", "slug": "logo_churn_rate", "domain": "customers", "defaultLabel": "Logo Churn Rate", "description": "Share of customer logos lost during the period — the inverse of logo retention. Numerator is logos that churned during the period; denominator is logos present at period start. Per the KBCM/Sapphire Private SaaS Company Survey definition (treated as the de-facto private-SaaS reporting convention). The board reads this as the simplest churn signal — independent of revenue-weighting. Common pitfall: confusing annualized vs. period-rate (monthly churn × 12 ≠ annualized churn for a compounding base) — be explicit about the time window and annualization method.", "fieldType": "percentage", "unit": "%", "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": "Logo Churn", "publicationDate": "2024-09-01", "attributionNotice": null }, "benchmark": { "p25": 5, "median": 13, "p75": 20, "unit": "%", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceYear": "2024", "higherIsBetter": false }, "formula": "logo_churn_rate = customers_churned ÷ (customers active at period start). Mathematically: 1 − logo_retention_rate. Annualization for monthly/quarterly rates should be explicit (e.g. (1 − monthly_retention)^12, not monthly_churn × 12).", "whyItMatters": "Direct read on whether customers are walking away. Independent of revenue-weighting, so it cannot be masked by a few large expansions.", "interpretationGuidance": "Per KBCM/Sapphire Private SaaS Company Survey 2024 (§ \"Customer Churn\"), private SaaS logo churn typically sits in the high single digits annually, with top-quartile below 5% — but distributions are highly sensitive to ACV cohort (low-ACV SMB SaaS routinely sees 20%+ annual logo churn; six-figure enterprise contracts often see <3%). Pull the current vintage rather than citing a stale point estimate. Pair with `customers_churned` (absolute count) and `gross_revenue_retention` (revenue-weighted view).", "relatedKpiIds": [ "customers.logo_retention_rate", "customers.customers_churned", "customers.gross_revenue_retention", "customers.net_revenue_retention", "customers.churn_risks" ], "calculationPolicy": { "inclusionRules": [ "Numerator: count of logos that churned (fully left) during the period.", "Denominator: count of logos active at period start (the closed starting cohort).", "Result is a percentage; the exact complement of `customers.logo_retention_rate`." ], "exclusionRules": [ "Net-new logos acquired in-period — not in the denominator.", "Downgrades / contractions where the logo remains — this is a count-of-departures metric, not a revenue one.", "Trials / pilots that never converted." ], "requiredInputs": [ "Count of churned logos in the period.", "Count of logos active at period start.", "Time window + annualization method (state explicitly)." ], "dataSourcePriority": [ "Customer-level subscription ledger with churn events.", "CRM as a fallback." ], "edgeCases": [ "Annualizing a monthly or quarterly rate: use `1 − (1 − periodic_churn)^periods` (geometric), NOT `periodic_churn × periods` (arithmetic). The two diverge materially as churn rises.", "Account merger: the absorbed logo is not churn — the relationship continued.", "Reactivation within the period: if the logo is active at period end, it is retained, not churned. Disclose if reactivations are material.", "ACV-cohort mixing: blended logo churn is misleading when SMB and enterprise are pooled — SMB routinely 20%+, enterprise <3%. Segment when material." ], "validationChecks": [ "Logo Churn Rate + Logo Retention Rate = 100% exactly.", "Bounded 0–100%.", "Churned-logo count ≤ starting-cohort count." ], "commonMiscomputations": [ "Annualizing via `monthly_churn × 12` instead of the geometric `1 − (1 − monthly_retention)^12` — overstates annual churn, badly so when churn is high.", "Confusing logo churn with revenue churn — they diverge; logo churn cannot be masked by expansion, revenue churn can.", "Using period-end logo count as the denominator — the cohort must be fixed at period start.", "Counting account mergers or contractions as churn — only full departures count.", "Reporting a blended rate across wildly different ACV cohorts without segmenting — the blend is not actionable." ] }, "metricBasis": { "timeBasis": "period_flow", "cohortBasis": "closed_start_cohort", "production": "computed" } }, { "rogueId": "customers.logo_retention_rate", "slug": "logo_retention_rate", "domain": "customers", "defaultLabel": "Logo Retention Rate", "description": "Share of customer logos retained from the prior period, counted by logo (not by revenue). Per the SaaS Metrics Standards Board (SMSB) Logo Retention standard: numerator is logos present at both period start and period end; denominator is logos present at period start. New logos acquired during the period are excluded from both. The board reads this as a \"stickiness\" signal independent of ACV: high logo retention with weak NRR points to flat/contracting expansion; weak logo retention with strong NRR points to high concentration risk. Common pitfall: conflating logo retention with revenue retention — they answer different questions and routinely diverge.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/logo-retention", "sectionRef": "Logo Retention", "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." }, "formula": "logo_retention_rate = (logos active at period start AND active at period end) ÷ (logos active at period start). Excludes net-new logos acquired in-period. Per SMSB Logo Retention standard.", "whyItMatters": "Isolates retention quality from revenue-weighting effects. A handful of large expansions can mask high logo churn in NRR — logo retention surfaces it directly.", "interpretationGuidance": "Per KBCM/Sapphire Private SaaS Company Survey 2024, private SaaS logo retention concentrates in the high-80s to mid-90s (median around 90% for the broad sample, higher for enterprise contract ACVs). Treat distributional ranges as period- and segment-specific; pull the current vintage of the source rather than relying on a memorized number. Pair every value with `logo_churn_rate` (1 − this) for the inverse view and `customers_churned` for the absolute count.", "relatedKpiIds": [ "customers.logo_churn_rate", "customers.customers_churned", "customers.gross_revenue_retention", "customers.net_revenue_retention" ], "calculationPolicy": { "inclusionRules": [ "Numerator: count of logos active at BOTH period start and period end.", "Denominator: count of logos active at period start (the closed starting cohort).", "Result is a percentage; counted by logo, not by revenue." ], "exclusionRules": [ "Net-new logos acquired during the period — excluded from BOTH numerator and denominator.", "Logos that were never active (trials, unconverted pilots).", "Revenue weighting of any kind — this is a count metric. Revenue-weighted retention is GRR/NRR." ], "requiredInputs": [ "Logo list active at period start (with stable account IDs).", "Logo list active at period end.", "The \"logo unit\" definition (parent account vs billing entity) — consistent with the rest of the catalog." ], "dataSourcePriority": [ "Customer-level subscription ledger keyed by stable account ID.", "CRM customer table as a fallback." ], "edgeCases": [ "Account merger (two starting logos consolidate into one): count the survivor as retained; the absorbed logo is NOT churn (the relationship continued). Disclose the consolidation.", "Logo churned and then reactivated within the same period: per SMSB, if active at both endpoints it counts as retained; disclose if reactivations are material.", "Logo-unit change mid-trend: re-state, or the rate is not comparable." ], "validationChecks": [ "Logo Retention Rate + Logo Churn Rate = 100% (they are exact complements).", "Bounded 0–100%. A value > 100% means new logos leaked into the numerator.", "Retained-logo count ≤ starting-cohort count always." ], "commonMiscomputations": [ "Conflating logo retention with revenue retention (GRR/NRR) — they answer different questions and routinely diverge; a few big expansions can hide heavy logo churn in NRR.", "Letting new-logo acquisitions into the numerator — inflates retention above 100%, which is impossible for a count metric.", "Using period-end logo count as the denominator instead of period-start — the cohort must be fixed at the start.", "Counting an account merger as churn — the customer relationship continued; only the logo count changed.", "Logo-unit drift between periods." ] }, "metricBasis": { "timeBasis": "period_flow", "cohortBasis": "closed_start_cohort", "production": "computed" } }, { "rogueId": "customers.net_revenue_retention", "slug": "net_revenue_retention", "domain": "customers", "defaultLabel": "Net Revenue Retention (NRR)", "description": "Recurring revenue retained from the cohort of customers present at the start of the period, including expansion (upsell, cross-sell, price increases) and net of churn and contraction — but excluding revenue from net-new logos acquired in-period. Per the SaaS Metrics Standards Board (SMSB) NRR standard. NRR above 100% means the cohort grew faster than it lost — a hallmark of strong product-led expansion. The board reads NRR alongside GRR (`customers.gross_revenue_retention`) to separate the \"keep + expand\" signal from the \"just keep\" signal. Common pitfall: mixing GAAP revenue and ARR in numerator vs. denominator, or letting net-new logo revenue leak in — both inflate the number; SMSB is explicit that the cohort is closed at period start.", "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": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/net-revenue-retention", "sectionRef": "NRR", "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." }, "benchmark": { "p25": 96, "median": 101, "p75": 109, "unit": "%", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceYear": "2024", "higherIsBetter": true }, "formula": "NRR = (Starting ARR + Expansion − Contraction − Churn) ÷ Starting ARR, measured on the cohort active at period start. New-logo ARR acquired in-period is excluded from both numerator and denominator. Per SMSB NRR standard.", "whyItMatters": "The single best read on whether existing customers love the product enough to pay more over time. Strong NRR (>100%) compounds — it lets growth come from inside the install base, lowering reliance on new-logo acquisition and improving capital efficiency.", "interpretationGuidance": "Per KBCM/Sapphire Private SaaS Company Survey 2024 (§ \"Net Dollar Retention\"), private SaaS NRR medians have historically clustered around the low-to-mid 100s, with top-quartile in the 110s+ — but cuts vary year-over-year and by ACV segment, so pull the current edition rather than citing a stale point estimate. Top-quartile public SaaS (per typical Bessemer State of the Cloud commentary) cite NRR ≥ ~120% as the benchmark for \"best-in-class\" expansion — treat that thresholds as industry folk-wisdom unless cited to a named edition. Always pair NRR with GRR: a wide gap means expansion is propping up underlying churn.", "relatedKpiIds": [ "customers.gross_revenue_retention", "customers.logo_retention_rate", "customers.logo_churn_rate", "customers.expansion_opportunities", "sales.arr" ], "calculationPolicy": { "inclusionRules": [ "Cohort = customers active at the start of the period (closed cohort).", "Numerator components: Starting ARR + Expansion + Cross-sell − Contraction − Churn — for the same cohort only.", "Expansion includes price-increase ARR and upsell ARR (more product, more seats, higher tier)." ], "exclusionRules": [ "New-logo ARR acquired during the period — must NOT appear in numerator or denominator.", "Customers acquired and churned within the same period (they were never in the cohort).", "Implementation fees, one-time services — same exclusions as ARR." ], "requiredInputs": [ "Customer-level ARR snapshot at the start of the period.", "Customer-level ARR snapshot at the end of the period, filtered to the starting cohort.", "Per-customer change classification: expansion / contraction / churn (so contraction and churn are not double-counted)." ], "dataSourcePriority": [ "Customer-level ARR ledger keyed to a stable account ID (preserves cohort identity across mergers/renames).", "CRM customer table joined to subscription system as a fallback — flag stale joins." ], "edgeCases": [ "Account mergers (two customers consolidate to one): preserve the cohort identity of the survivor; the absorbed account is treated as churn unless the merge happened pre-period.", "Currency moves on multi-currency cohorts: hold FX flat across the cohort window so retention is not confused with FX swing.", "Pause / suspension: treat as contraction or churn per the same rule used in ARR; be consistent.", "Mid-period contract amendments: take the period-end value for the customer; do not double-book intermediate changes." ], "validationChecks": [ "NRR is unbounded above 100% but should never exceed ~150% for a healthy cohort; > 150% almost always means new-logo or expansion-of-new-logo leaked in.", "NRR − GRR = expansion contribution (in percentage points); the sign must be ≥ 0.", "Cohort definition matches between numerator and denominator (same start-of-period customer set)." ], "commonMiscomputations": [ "Letting new-logo ARR leak into the numerator — the most common error; produces an inflated NRR that looks like world-class retention but is just growth.", "Mixing recognized revenue with contracted ARR across numerator and denominator — the timing mismatch can produce 5–15 percentage points of phantom retention.", "Using rolling-12 ARR snapshots without locking the cohort — the cohort drifts and the metric becomes a blended growth + retention number.", "Reporting NRR without GRR — the gap is the expansion story and boards will ask for it; computing only one of the two is incomplete.", "Computing NRR on logos instead of revenue — that is logo retention, a different metric (`customers.logo_retention_rate`)." ] }, "metricBasis": { "timeBasis": "period_flow", "cohortBasis": "closed_start_cohort", "production": "computed" } }, { "rogueId": "customers.nps_score", "slug": "nps_score", "domain": "customers", "defaultLabel": "NPS Score", "description": "Net Promoter Score — % of survey respondents who are promoters (score 9–10) minus % detractors (0–6), passives (7–8) excluded. Per the original NPS methodology (Reichheld, Bain & Company, 2003). The score ranges from −100 to +100. The board reads NPS as one read on product-market fit and word-of-mouth potential, not as a precise customer-loyalty measurement — the methodology is well-known for being sensitive to sample bias, response rate, and survey timing. Common pitfall: comparing NPS across companies without normalizing for industry — B2B SaaS NPS distributions sit much higher than consumer-app NPS, and the absolute number means little without a peer cohort.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product", "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "published", "sourceName": "Retently NPS Benchmarks 2025", "sourceUrl": "https://www.retently.com/blog/good-net-promoter-score/", "sectionRef": "NPS Benchmarks", "publicationDate": "2025-01-01", "attributionNotice": null }, "benchmark": { "p25": 20, "median": 36, "p75": 50, "unit": "count", "sourceName": "Retently NPS Benchmarks 2025", "sourceYear": "2025", "higherIsBetter": true }, "formula": "NPS = (% promoters, score 9–10) − (% detractors, score 0–6). Passives (7–8) are excluded from both. Range: −100 to +100. Per Bain & Company / Reichheld NPS methodology (HBR 2003, \"The One Number You Need to Grow\").", "whyItMatters": "A coarse-grained directional read on customer affection and word-of-mouth potential. Sustained movement (especially regressions) is the signal the board should focus on, not absolute values — the methodology is too noisy for fine comparisons across companies.", "interpretationGuidance": "Per Retently NPS Benchmarks 2025, B2B SaaS NPS medians by industry cluster around the +30 to +50 band, with top-quartile +50 to +70. Translate scores to categories: −100 to 0 = needs work, 0–30 = good, 30–70 = great, 70–100 = excellent — these category bands are widely circulated industry folk-wisdom (Bain does not publish strict thresholds). Always pair the score with sample size and response rate; an NPS based on <50 responses or <10% response rate should be flagged as low-confidence.", "relatedKpiIds": [ "customers.nps_trend", "customers.retention_insights", "customers.churn_risks", "customers.key_initiatives" ], "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "customers.nps_trend", "slug": "nps_trend", "domain": "customers", "defaultLabel": "NPS Trend", "description": "Period-over-period change in NPS score — the trajectory signal that matters more than any single absolute score. A 5-point swing between adjacent quarters is usually more informative than a \"good\" or \"bad\" absolute label, because the methodology's noise floor is high enough that absolute comparisons across companies (or even across quarters with different sample sizes) are unreliable. The board reads this to spot deterioration early — a persistent multi-quarter decline is one of the leading indicators of pending churn. Common pitfall: comparing periods with very different sample sizes or response rates — a \"decline\" from 45 to 35 means very different things at n=30 vs. n=300.", "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 }, "formula": "nps_trend = NPS_current_period − NPS_prior_period (delta in points, not %). Sample size and response rate should be reported alongside both periods.", "whyItMatters": "NPS's methodology noise makes absolute scores hard to interpret across companies. The trend within a single company's own measurement cadence is more reliable — a sustained decline is a leading indicator of churn risk even when the absolute score still reads \"good\".", "interpretationGuidance": "There is no citation-grade benchmark for trend magnitude; treat any single-quarter swing of ±5 points or more as worth narrative explanation, and any 2+ consecutive declines as a yellow flag for the board. Always cite sample size deltas — if response rate or n changed materially, the trend may be measurement artifact rather than real movement.", "relatedKpiIds": [ "customers.nps_score", "customers.retention_insights", "customers.churn_risks", "customers.key_initiatives" ], "metricBasis": { "timeBasis": "trailing_window", "production": "computed" } }, { "rogueId": "customers.percent_arr_at_risk", "slug": "percent_arr_at_risk", "domain": "customers", "defaultLabel": "% ARR at Risk", "description": "Share of total ARR flagged as at-risk for churn or contraction — the proportional view that complements the absolute `arr_at_risk` dollar figure. Computed as `arr_at_risk ÷ total ARR`. The board reads this as the worst-case-near-term-NRR-impact ceiling: if every at-risk account actually churned in-period, NRR would drop by roughly this percentage (before expansion offset). Common pitfall: the \"at-risk\" definition is internal and varies by company — a 12% percent_arr_at_risk under a conservative flagging rule is a very different signal than 12% under an aggressive rule. Document the flag rule and hold it constant.", "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 }, "formula": "percent_arr_at_risk = arr_at_risk ÷ total ARR. The numerator inherits the company-specific \"at-risk\" flag definition documented on `customers.arr_at_risk`.", "whyItMatters": "Normalizes the at-risk dollar figure so it scales with the business. A 10% at-risk share is the same proportional threat at $5M ARR as at $50M ARR; the absolute figure alone hides that.", "interpretationGuidance": "No citation-grade industry benchmark; widely-cited industry folk-wisdom (not citation-grade) flags >15% percent_arr_at_risk as a destructive threshold worth board escalation — the `ArrAtRiskGauge` widget uses this internally. Trend it month-over-month — sustained growth in this share predicts a downward NRR move next quarter even if no single account has churned yet.", "relatedKpiIds": [ "customers.arr_at_risk", "customers.churn_risks", "customers.top_customer_concentration", "customers.net_revenue_retention", "customers.gross_revenue_retention", "sales.arr" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "customers.retention_insights", "slug": "retention_insights", "domain": "customers", "defaultLabel": "Retention Insights", "description": "Free-form commentary from the CS / Sales leadership on retention trends, cohort behavior, and underlying drivers of loyalty (or its absence). Pairs with the quantitative retention KPIs (NRR, GRR, logo retention) and gives the board the \"why\" behind the numbers — which cohorts are strong, which are weak, what feature engagement correlates with retention, what onboarding changes are landing. Common pitfall: filler prose that restates the numbers without adding causal insight — a board reader should learn something here they could not infer from the metrics page alone.", "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 }, "formula": "Qualitative — no calculation. Free-form narrative commentary, typically 100–300 words, with concrete cohort references (e.g. \"Q3 2024 cohort showing 12% better NRR than Q2 2024 cohort, driven by adoption of feature X within 30 days of go-live\").", "whyItMatters": "Adds causal explanation to the retention numbers — boards optimize for diagnoses, not just descriptions. Reading \"NRR slipped from 115% to 108%\" is half the story; reading \"NRR slipped because two large customers cut seat counts as they integrated us with an acquired vendor — non-recurring\" is the actionable version.", "interpretationGuidance": "Anti-pattern: prose that restates the numbers (\"NRR was 108% this quarter, down from 115%\") without explaining drivers. Strong content names specific cohorts, customer segments, or product surfaces and ties them to the metric movement. If the team cannot articulate the \"why\" yet, write \"diagnosis in progress — investigating with CS team, update next board\" rather than padding.", "relatedKpiIds": [ "customers.net_revenue_retention", "customers.gross_revenue_retention", "customers.logo_retention_rate", "customers.expansion_opportunities", "customers.churn_risks" ] }, { "rogueId": "customers.top_customer_concentration", "slug": "top_customer_concentration", "domain": "customers", "defaultLabel": "Top Customer Concentration", "description": "Share of total ARR contributed by the top N customers — typically top 5 or top 10. Measures revenue concentration risk: a high concentration means losing one big customer would materially dent ARR. The board reads this alongside `arr_at_risk` and the customer list to gauge how much of the company's future is tied to a handful of accounts. Common pitfall: hiding parent-account aggregation — if three \"customers\" are subsidiaries of the same parent, true concentration is higher than the count-by-logo view shows; settle parent-rollup rules and document them in `customer_definition_note`.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "top_customer_concentration = Σ(ARR of top N customers) ÷ total ARR. N is typically 5 or 10 — fix it for the company and hold it constant. Parent-account roll-up rules must be explicit and stable across periods.", "whyItMatters": "Quantifies \"single-account risk.\" For early-stage companies, high concentration is expected and not necessarily a problem; for growth-stage companies, it constrains valuation multiples and is a frequent due-diligence flag in fundraising and M&A.", "interpretationGuidance": "No single citation-grade benchmark exists; commonly-cited industry folk-wisdom (not citation-grade) holds that top-10 customer concentration above 50% is a yellow flag and any single customer above 20% of ARR is a serious risk that fundraising and acquirer diligence will flag. Trend it across quarters — falling concentration is healthy customer-base diversification; rising concentration deserves a board note even if the absolute number is acceptable today.", "relatedKpiIds": [ "customers.arr_at_risk", "customers.percent_arr_at_risk", "customers.total_customers", "customers.churn_risks", "sales.arr" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "customers.total_customers", "slug": "total_customers", "domain": "customers", "defaultLabel": "Total Customers", "description": "Count of active paying customer logos at the end of the period. \"Active\" means the customer has a live paid subscription or contract on the reporting date — not trial, not cancelled, not zero-revenue. The board reads this alongside ARR to triangulate whether growth is logo-driven (more customers at similar ACV) or expansion-driven (existing customers paying more). Common pitfall: definitions of \"customer\" drift over time as the company sells to subsidiaries, parent accounts, or self-serve users — settle the counting unit (parent vs. account vs. seat) and document it in `customer_definition_note` so cross-period comparisons stay honest.", "fieldType": "number", "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 }, "formula": "Count of customer logos with an active paid subscription/contract on the reporting date. Excludes trials, paused accounts, and $0 contracts. Counting unit (parent vs. account vs. seat) must be documented and held constant period-over-period.", "whyItMatters": "The denominator beneath every retention, churn, and concentration metric — and the simplest read on whether the company is winning new logos at the headline level. Boards use it to disambiguate logo-led vs. ARR-led growth.", "interpretationGuidance": "Net change = new logos − churned logos; pair with `customers_churned` and ARR delta. Stage-typical absolute counts vary so widely (B2B enterprise vs. SMB SaaS) that an absolute count is industry folk-wisdom, not citation-grade — compare instead to the company's own trailing 4-quarter trend. A definitional change to \"customer\" must be flagged on the chart, not absorbed silently.", "relatedKpiIds": [ "customers.customers_churned", "customers.logo_retention_rate", "customers.logo_churn_rate", "customers.top_customer_concentration", "sales.arr" ], "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "finance.assumptions", "slug": "assumptions", "domain": "finance", "defaultLabel": "Financial Assumptions", "description": "Narrative listing of the key inputs the forecast rests on — growth-rate assumptions, churn assumptions, hiring plan, FX rates, expected timing of large bookings, planned price changes, capitalized-vs-expensed R&D treatment, etc. Without this field, the board cannot tell whether a forecast change reflects a real-world update or a quietly changed assumption. Common pitfall: assumptions are written once at planning and never updated when the underlying reality shifts — track explicitly which assumption changed each quarter and why. Best practice (per \"Venture Deals\" by Feld & Mendelson, and standard board-pack guidance): every material variance vs. forecast should be traceable to either an executed plan or a changed assumption.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "recommended", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "No calculation — free-text narrative. Convention: enumerate top 5–8 assumptions with the value used and the source (plan, observed run-rate, investor letter, board-approved hiring cap).", "whyItMatters": "Makes the forecast auditable across periods. Boards cannot challenge or endorse a number whose assumptions are invisible — and quietly changing assumptions is the single most common source of forecast drift.", "interpretationGuidance": "Flag whenever an assumption changes vs. prior period and note the reason. If the list is missing or stale (unchanged for >2 reporting cycles while reality has clearly moved), treat as a yellow flag on financial-process maturity. No published threshold for completeness — coverage is judged by whether a board member can recompute the forecast from the listed assumptions.", "relatedKpiIds": [ "finance.forecast_notes", "finance.risk_factors", "finance.burn_rate_scenarios" ] }, { "rogueId": "finance.bank_accounts_list", "slug": "bank_accounts_list", "domain": "finance", "defaultLabel": "Bank Accounts", "description": "FX-aware enumeration of the company's bank, brokerage, and money-market accounts — each with bank name, account type, restricted flag, currency, balance, as-of date, and notes. The underlying data source for `finance.total_cash_in_bank`, `finance.total_restricted_cash`, `finance.total_unrestricted_cash`, and the FX conversion that turns multi-currency holdings into a single reporting-currency number. Common pitfall: a single forgotten account (often a legacy operational account or a money-market sweep) silently misstates the total — boards should ask for a checklist reconciliation against the prior board pack each cycle. Best practice: include account-number last-4 (not full numbers, for security) and the FX rate used per non-functional-currency account.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "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 }, "formula": "No calculation — structured list. Sum of balances (converted via per-row FX rate) equals `finance.total_cash_in_bank`; rows flagged `restricted: true` sum to `finance.total_restricted_cash`.", "whyItMatters": "The auditable line-item basis for every aggregate cash KPI on the board pack. Without it, the headline numbers cannot be reconciled and a missing account cannot be detected.", "interpretationGuidance": "Watch for account churn (new accounts opened mid-period without commentary, accounts dropped without explanation) and FX-rate staleness (rates older than the as-of date). A growing number of accounts at growth stage is normal (multiple currencies, multiple banks); a sudden change in account count warrants a footnote.", "relatedKpiIds": [ "finance.total_cash_in_bank", "finance.total_restricted_cash", "finance.total_unrestricted_cash", "finance.operationally_available_cash" ] }, { "rogueId": "finance.burn_rate_actual", "slug": "burn_rate_actual", "domain": "finance", "defaultLabel": "Actual Burn Rate (Past Period)", "description": "The single past-period observed burn — gross and net — that anchors the forecast-scenario matrix. The \"we just lived through this\" baseline against which conservative / most-likely / best-case forecasts are projected. Differs from `finance.gross_burn_rate` and `finance.net_burn_rate` in being explicitly a point-in-time historical anchor with both components paired in one object, rather than the standalone monthly KPI values. Common pitfall: anchoring forecasts off a single month with a known one-off (large bill, prepayment received) bakes a distortion into all scenarios — pick a representative period or document the adjustment.", "fieldType": "currency", "unit": "/month", "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "Paired historical observation: `{ gross: finance.gross_burn_rate_for_anchor_period, net: finance.net_burn_rate_for_anchor_period }`. The anchor period is typically the most recently closed reporting period.", "whyItMatters": "Anchors the credibility of the forecast matrix — scenarios that diverge wildly from the actual baseline without explicit drivers are not credible. Boards typically interrogate any scenario whose burn differs from actual by more than ~20% without a named driver.", "interpretationGuidance": "Cross-check the anchor against the 3-month trailing average; if they differ materially, the anchor period was atypical and the forecast may be unrealistic. Pair every anchor with a one-line note on what was one-off and how the forecast normalizes for it.", "relatedKpiIds": [ "finance.gross_burn_rate", "finance.net_burn_rate", "finance.burn_rate_scenarios", "finance.forecast_notes" ], "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "finance.burn_rate_scenarios", "slug": "burn_rate_scenarios", "domain": "finance", "defaultLabel": "Burn Rate Scenarios", "description": "Forecast burn-rate matrix across three scenarios — conservative (defensive cost plan, slow revenue), mostLikely (current best-estimate), bestCase (aggressive investment with strong revenue) — with gross + net burn for each. Bound to the ScenarioBurnRateMatrix widget alongside the historical `finance.burn_rate_actual` anchor. The board reads this to understand what range of cash trajectories the company is planning for and which one management has chosen as the base case. Common pitfall: the three scenarios cluster tightly (all within ±10% of each other) — that's not three scenarios, it's one scenario with rounding error. Real scenarios should reflect meaningfully different operating decisions and produce visibly different runways.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "Structured matrix: `{ conservative: { gross, net }, mostLikely: { gross, net }, bestCase: { gross, net } }`. Each scenario's implied runway = unrestricted_cash / scenario.net.", "whyItMatters": "Forces explicit scenario thinking and surfaces the risk-adjusted range of outcomes the board should plan for — without this, the single-number forecast invites false confidence.", "interpretationGuidance": "Inspect the spread between scenarios — a conservative net burn within 10–15% of best-case usually means the team has not stress-tested its plan (industry folk-wisdom, not citation-grade). Cross-check `mostLikely` against `finance.burn_rate_actual` (trailing 3 months) — divergence > ±15–20% should be footnoted with named drivers in `finance.forecast_notes`.", "relatedKpiIds": [ "finance.burn_rate_actual", "finance.net_burn_rate", "finance.gross_burn_rate", "finance.runway_months", "finance.forecast_notes", "finance.assumptions" ] }, { "rogueId": "finance.current_asset_adjustments", "slug": "current_asset_adjustments", "domain": "finance", "defaultLabel": "Current Asset Adjustments", "description": "Signed cash effect of period-over-period changes in current assets — accounts receivable, prepaid expenses, deposits, and other short-term assets. Positive when assets are converting back to cash (AR collections, prepaid expenses being consumed); negative when assets are growing and absorbing cash (AR balance up, new prepayments made). Half of the `finance.net_working_capital_adjustment` rollup. Common pitfall: a one-off enterprise prepayment to a vendor (e.g. 12-month infra commit) shows up here as a large negative without the P&L showing the cost yet — flag it explicitly so the board does not read deterioration where there is none.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "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 }, "formula": "-(Δ accounts_receivable + Δ prepaid_expenses + Δ other_current_assets) for the period. The negative sign converts the balance-sheet direction (asset increase = cash decrease) into a signed cash adjustment.", "whyItMatters": "Surfaces the cash impact of growing receivables and prepayments separately from operating spend — important when DSO is moving or large prepaid commitments are taken.", "interpretationGuidance": "A sustained negative trend usually means AR is growing faster than collections (DSO lengthening) — pair with sales-side bookings and ARR to confirm. Industry folk-wisdom (not citation-grade): the cash drag from a growing AR book typically peaks late in the year when annual contracts billed in Q4 land as Q1 receipts.", "relatedKpiIds": [ "finance.current_liability_adjustments", "finance.net_working_capital_adjustment", "finance.operationally_available_cash", "finance.working_capital_adjustments_list" ], "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "finance.current_liability_adjustments", "slug": "current_liability_adjustments", "domain": "finance", "defaultLabel": "Current Liability Adjustments", "description": "Signed cash effect of period-over-period changes in current liabilities — accounts payable, accrued payroll/taxes/bonuses, deferred revenue from customer prepayments, and other short-term liabilities. Positive when liabilities grow and absorb less cash than the matched expense suggests (e.g. AP balance growing means vendor cash payments lag); negative when liabilities are being paid down faster than they accrue. Deferred revenue is the most powerful component in SaaS — a large annual prepayment received increases deferred revenue and supplies cash now against expense recognized later. Common pitfall: a board reading this as straight cash improvement misses that deferred revenue must still be earned out, and a stretched AP balance signals supplier strain. Best practice: footnote large components (deferred revenue, accrued bonus) separately.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "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 }, "formula": "+(Δ accounts_payable + Δ accrued_liabilities + Δ deferred_revenue + Δ other_current_liabilities) for the period. Liability increase = cash supplied, so positive sign.", "whyItMatters": "Captures the cash benefit (or drag) of working-capital liability movements — deferred revenue inflows in particular can mask underlying cash burn at SaaS companies that book annual upfront.", "interpretationGuidance": "A sustained positive trend driven by AP growth (not deferred revenue) is a yellow flag — it means the company is funding itself by lengthening supplier payment cycles. A surge driven by deferred revenue (annual contract closes) is a one-time cash benefit that doesn't recur. Separate the components in commentary.", "relatedKpiIds": [ "finance.current_asset_adjustments", "finance.net_working_capital_adjustment", "finance.operationally_available_cash", "finance.working_capital_adjustments_list" ], "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "finance.forecast_notes", "slug": "forecast_notes", "domain": "finance", "defaultLabel": "Forecast Commentary", "description": "Executive narrative on what the latest forecast says and how it has changed since prior reporting — which scenarios were considered, which was picked as \"most likely\" and why, what changed since last quarter, and what would push the forecast into a different scenario. Pairs with `finance.burn_rate_scenarios` (the numeric scenarios) to provide the qualitative \"why\" beside the quantitative \"what\". Common pitfall: this becomes a restatement of the numbers rather than commentary — every paragraph should add interpretation the numbers do not by themselves convey (drivers, decisions taken, decisions deferred).", "fieldType": "text", "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": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "No calculation — narrative commentary. Convention: cover (1) selected scenario and rationale, (2) deltas vs. prior forecast with reasons, (3) trigger conditions that would move the forecast.", "whyItMatters": "Gives the board the interpretation layer that raw scenario numbers lack — without it, the burn-rate-scenarios table is data without meaning. Disciplined commentary also creates a record of management's rationale that can be re-examined when reality plays out.", "interpretationGuidance": "Compare commentary across periods — if the rationale shifts without the underlying numbers shifting, the team is rationalizing rather than analyzing. If numbers shift without the rationale acknowledging it, controls maturity is the concern. Length is not a quality signal; concrete drivers and named triggers are.", "relatedKpiIds": [ "finance.assumptions", "finance.burn_rate_scenarios", "finance.burn_rate_actual", "finance.risk_factors" ] }, { "rogueId": "finance.gross_burn_rate", "slug": "gross_burn_rate", "domain": "finance", "defaultLabel": "Gross Burn Rate", "description": "Average monthly cash outflow before any inflows are netted off — essentially the company's monthly cost base in cash terms. Tracked alongside net burn because net burn alone can mask a structural problem when revenue is masking high cost. The board reads gross burn to understand the absolute cost commitment (mostly payroll, infra, COGS, sales spend) regardless of revenue mix. Common pitfall: founders often optimize the net burn narrative (\"we cut burn 30%\") via a one-time inflow without addressing the gross-burn cost base — the next quarter without that inflow re-exposes the underlying spend. Always present gross and net side-by-side.", "fieldType": "currency", "unit": "/month", "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "recommended", "seed": "recommended", "seriesA": "recommended", "seriesB": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "gross_burn_rate = total_operational_outflow / months_in_period. Same denominator and averaging convention as net burn (3-month trailing average is standard). Always greater than or equal to net burn.", "whyItMatters": "Strips revenue volatility from the survival picture — shows the cost commitment the company must support each month regardless of bookings outcomes. A widening gap between gross and net burn that depends on a single deal or one-off inflow is a fragility signal.", "interpretationGuidance": "Compare gross-burn composition (payroll, infra, GTM, COGS) to revenue mix; sustained gross burn growing faster than ARR is a leading deterioration signal even when net burn looks flat. No single published gross-burn threshold exists — interpret relative to ARR and revenue per FTE (`hr.arr_per_fte`). Practitioner consensus (industry folk-wisdom, not citation-grade): payroll typically accounts for 65–80% of gross burn in venture-backed SaaS.", "relatedKpiIds": [ "finance.net_burn_rate", "finance.burn_rate_actual", "finance.total_operational_outflow", "finance.runway_months", "hr.arr_per_fte", "sales.arr" ], "calculationPolicy": { "inclusionRules": [ "All cash outflow from operations — payroll, benefits, infra, GTM, COGS, G&A, taxes paid, professional fees, software. No netting of inflows.", "Divide by months in period. Use the same trailing-3-month smoothing as net burn for direct comparability.", "Result is always positive (or zero in the degenerate case of a brand-new entity)." ], "exclusionRules": [ "Financing outflows: debt repayments, equity buybacks, dividend payments. Gross burn is an operating metric.", "M&A outflows (acquisition consideration, transaction fees). Flag separately.", "Non-cash expenses: D&A, stock-based compensation, accrued-but-unpaid items.", "Cash inflows of any kind — gross burn is outflow-only by definition." ], "requiredInputs": [ "Period-by-period total operational outflow.", "Period length and smoothing window.", "Optional: outflow composition breakdown (payroll / infra / GTM / G&A) for narrative." ], "dataSourcePriority": [ "Cash-basis P&L outflow lines.", "Accrual P&L with non-cash items removed (D&A, SBC, accruals)." ], "edgeCases": [ "Annual employer-tax payment cycles cause a 1–2-month outflow spike (typically Jan/Apr in the US). Smoothing window handles this if applied; if not, footnote it.", "Lumpy annual SaaS / infra prepayments (insurance, software renewals) spike outflow in their month. Same handling as employer-tax: smooth or footnote.", "Layoff severance: one-time outflow that can be 2-3x a normal month. ALWAYS flag as one-off and present a \"normalized gross burn\" alongside." ], "validationChecks": [ "Gross burn ≥ net burn always. If gross < net, the inflow side has crossed into the outflow accidentally.", "Payroll typically accounts for 65–80% of gross burn in venture-backed SaaS (industry consensus). Materially outside this band invites a composition narrative.", "Gross burn ÷ ARR provides a cost-coverage view; sustained growth in this ratio while ARR flatlines is a leading deterioration signal." ], "commonMiscomputations": [ "Subtracting any inflow — converts gross burn into net burn and erases the metric's purpose.", "Including financing outflows (debt repayment, buybacks) — makes \"operating cost base\" look higher than it is.", "Counting SBC or D&A as gross burn — these are accounting, not cash.", "Failing to flag severance / restructuring as one-off — a layoff month produces a gross-burn spike that mis-reads as a structural cost expansion." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "cash", "production": "computed" } }, { "rogueId": "finance.net_burn_rate", "slug": "net_burn_rate", "domain": "finance", "defaultLabel": "Net Burn Rate", "description": "Average monthly net cash outflow over the reporting period — total cash spent minus total cash collected, divided by the number of months in the period. The headline survival number for venture-backed startups: it pairs with `finance.total_cash_in_bank` to produce runway, and pairs with revenue growth to produce the Bessemer \"burn multiple\". Common pitfall: net burn is volatile — large quarterly bills (annual SaaS renewals, employer-tax true-ups), enterprise prepayments, and FX swings can mask the underlying trend. Smoothing over a trailing 3-month average is standard board practice. Equally important: do not silently include one-off cash events (acquisitions, settlements, large prepayments received) without flagging them — boards prefer a \"core burn\" and \"headline burn\" pair when the period is noisy.", "fieldType": "currency", "unit": "/month", "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "net_burn_rate = (total_operational_outflow − total_operational_inflow) / months_in_period. Most boards average over a trailing 3 months to dampen lumpy items; flag the methodology explicitly. When net burn is negative, the company is net-cash-generative for the period.", "whyItMatters": "Single most-watched metric below revenue at venture-backed companies — drives runway, valuation reads (via the burn multiple), and the calculus on when to fundraise vs. cut.", "interpretationGuidance": "Compare against the company's own forecast first (`finance.burn_rate_scenarios`); deviation > ±15–20% from the most-likely scenario typically warrants a board note (industry folk-wisdom, not citation-grade). Stage-level industry context: per the SaaS Capital 2025 Spending Benchmarks for Private B2B SaaS Companies, total median spend runs ~95% of ARR for bootstrapped and ~107% of ARR for equity-backed private SaaS, with 55% of equity-backed companies operating at a loss. For burn-multiple framing (net burn ÷ net new ARR), Series A medians sit near 1.2x and growth-stage companies above $25M ARR target ~1.4x with best performers below 1.0x (per cited 2025 industry analyses; pull the live edition to confirm).", "relatedKpiIds": [ "finance.gross_burn_rate", "finance.runway_months", "finance.total_cash_in_bank", "finance.burn_rate_actual", "finance.burn_rate_scenarios", "finance.total_operational_inflow", "finance.total_operational_outflow", "sales.arr" ], "calculationPolicy": { "inclusionRules": [ "Total cash outflow from operations over the period: payroll + benefits, infrastructure, GTM spend (S&M programs + tooling), COGS, G&A, professional fees, software, taxes.", "Subtract total cash inflow from operations: invoiced revenue collected, customer prepayments received, refunds received.", "Divide the net by the number of months in the period to produce a monthly rate.", "Standard board practice is a trailing-3-month average to dampen single-month lumpiness — state the smoothing window explicitly in any output." ], "exclusionRules": [ "Financing activities: equity raises, venture debt drawdowns, debt repayments. Burn is an operating metric.", "Acquisitions, divestitures, and other M&A cash movements. Flag as one-off, do not net into burn.", "Pure FX revaluation gains/losses on cash balances (when material).", "Stock-based compensation expense — it is not cash." ], "requiredInputs": [ "Period-by-period total operational outflow (`finance.total_operational_outflow`).", "Period-by-period total operational inflow (`finance.total_operational_inflow`).", "Period length and smoothing window (e.g. trailing-3-month).", "Flagged list of known one-off items in the period (large enterprise prepayments received, annual SaaS bills paid, true-ups)." ], "dataSourcePriority": [ "Cash-basis P&L for the period (closes faster than accrual; better matches \"burn\").", "Accrual P&L with a working-capital reconciliation as a fallback — net out non-cash items explicitly." ], "edgeCases": [ "Cash-flow-positive periods: net burn goes negative. Present as \"net cash generation\" rather than \"negative burn\" to avoid misreading.", "Annual SaaS prepayment from a large customer hits in one month: spike the inflow that month and net burn looks artificially good. Boards prefer a \"core burn excluding one-offs\" companion line.", "Employer-tax true-ups (typically Jan/Apr in the US): a single-month outflow up to 30-50% above run-rate. Note the calendar effect in commentary.", "FX swings on a foreign payroll: significant when the period spans currency volatility — break out the FX impact when material." ], "validationChecks": [ "Net burn ≤ gross burn always. If net > gross, the inflow definition is wrong (likely double-counting or including financing inflows).", "Sum of monthly net-burn numbers should reconcile to period-net-burn × months within 1-2%. Larger drift means smoothing is being misapplied.", "Net burn ÷ ARR (burn multiple) should sit within stage-typical bands — out-of-band burn multiple is more often a calculation error than a real outlier." ], "commonMiscomputations": [ "Using accrual-basis operating expenses without removing non-cash items (D&A, SBC, accrued-but-unpaid expense) — overstates burn.", "Netting in equity raise proceeds or venture debt — turns a fundraising month into \"negative burn\" and lies about run-rate spend.", "Spot-month burn instead of a trailing average — a single noisy month becomes the headline number and runway swings wildly.", "Silently including one-off prepayments or M&A consideration — boards want \"core\" and \"headline\" separated; collapsing them hides the trend.", "Counting refunds issued as part of the outflow but not refunds received in the inflow (or vice versa) — sign-mismatch errors are surprisingly common when refunds are large." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "cash", "production": "computed" } }, { "rogueId": "finance.net_working_capital_adjustment", "slug": "net_working_capital_adjustment", "domain": "finance", "defaultLabel": "Net Working Capital Adjustment", "description": "Signed net effect on cash of changes in current assets and current liabilities — receivables coming in (positive), payables going out (negative), prepaid expenses (negative when paid, positive when burned down), and accrued liabilities (positive when accrued, negative when settled). The rollup of `finance.current_asset_adjustments` and `finance.current_liability_adjustments`. Common pitfall: at early stage this is dominated by payroll-cycle noise and is near zero — once the company adds enterprise contracts with annual prepayments or 60-day net terms, this can swing 1–3 months of burn either direction. Becomes material at Series A+; ignored before that.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "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 }, "formula": "net_working_capital_adjustment = current_asset_adjustments + current_liability_adjustments (signed). Positive value means working capital is releasing cash; negative means working capital is consuming cash beyond what the P&L shows.", "whyItMatters": "Bridges the gap between accrual-basis P&L and cash-basis runway. A board reading the P&L alone can miss a working-capital headwind that is materially shortening runway.", "interpretationGuidance": "Track period-over-period: a multi-period negative trend (working capital absorbing cash) usually means DSO is lengthening or supplier terms are tightening — both warrant a board note. No published threshold exists for \"good\" magnitude — it scales with revenue and contract mix.", "relatedKpiIds": [ "finance.current_asset_adjustments", "finance.current_liability_adjustments", "finance.operationally_available_cash", "finance.working_capital_adjustments_list" ], "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "cash", "production": "computed" } }, { "rogueId": "finance.operationally_available_cash", "slug": "operationally_available_cash", "domain": "finance", "defaultLabel": "Operationally Available Cash", "description": "Unrestricted cash adjusted for near-term working-capital effects — i.e. the cash that is actually deployable after accounting for receivables coming in, payables going out, and accrued obligations crystallizing in the next reporting period. More conservative than `finance.total_unrestricted_cash` because it nets out the cash a healthy AR/AP cycle is already promising or claiming. The board reads this as the \"real\" cash position when working capital is material to the business (typical at Series A+, when AR/AP cycles get sizeable). Common pitfall: at early stage AR is small and AP is mostly payroll/SaaS, so this collapses to unrestricted cash — once enterprise deals or 60-day net terms appear, the gap widens fast.", "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 }, "formula": "finance.total_unrestricted_cash + finance.net_working_capital_adjustment. The working-capital adjustment is signed (positive when AR collection > AP outflow over the horizon, negative otherwise).", "whyItMatters": "Best single-number answer to \"how much cash do we really have to deploy this quarter\" once working capital is material. Substituted for unrestricted cash in the runway denominator at growth stage.", "interpretationGuidance": "A large negative gap between unrestricted and operationally-available cash means working-capital headwinds are eating into apparent runway — common when DSO is lengthening. Track the gap quarter-over-quarter; widening signals deteriorating collections or stretched payables. No published industry threshold — interpretation is company- and cycle-specific.", "relatedKpiIds": [ "finance.total_unrestricted_cash", "finance.net_working_capital_adjustment", "finance.current_asset_adjustments", "finance.current_liability_adjustments", "finance.runway_months" ], "calculationPolicy": { "inclusionRules": [ "Start with `finance.total_unrestricted_cash` (all unrestricted cash + cash equivalents, not segregated for a specific purpose).", "Add the signed `finance.net_working_capital_adjustment` for the lookahead horizon (positive when AR collections exceed AP outflows over the window, negative otherwise).", "Use the same lookahead horizon as the company's burn calculation — typically one reporting period (month or quarter)." ], "exclusionRules": [ "Restricted cash (collateral for leases, prepaid customer balances, escrow). It is not deployable.", "Long-term receivables that will not collect within the lookahead horizon.", "Undrawn venture debt or credit facilities — those are funding capacity, not cash." ], "requiredInputs": [ "Period-end unrestricted cash balance.", "AR aging bucketed by collection horizon.", "AP aging + scheduled cash outflows over the lookahead horizon.", "Any accrued obligations crystallizing in the horizon (payroll true-ups, employer-tax payments)." ], "dataSourcePriority": [ "Audited or reviewed balance sheet for cash + AR + AP + accruals.", "Treasury / FP&A working-capital forecast as a fallback when accounting is closing-period-only." ], "edgeCases": [ "Multi-currency cash: convert each currency to reporting currency at a stable period-end rate, then sum.", "Customer prepayments held in restricted accounts: NOT deployable — flag separately.", "Pending acquisition or M&A consideration earmarked but not yet wired: exclude from operationally-available; show as a memo line." ], "validationChecks": [ "Operationally-available cash ≤ total unrestricted cash + maximum-net-positive working-capital swing — if it exceeds, the working-capital adjustment is wrong.", "When working capital is small (typical pre-Series-A), this should be within ~5% of `finance.total_unrestricted_cash`. Wide divergence at early stage is a calculation red flag." ], "commonMiscomputations": [ "Using total cash (including restricted) — inflates the deployable position and overstates runway.", "Omitting the working-capital adjustment entirely — defaults back to unrestricted cash and misses the AR/AP timing mismatch that this KPI exists to capture.", "Mixing fiscal-year-end snapshot with mid-quarter working-capital adjustment — periods must align.", "Treating an undrawn credit facility as \"operationally available\" — facility access is not cash on hand." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "computed" } }, { "rogueId": "finance.risk_factors", "slug": "risk_factors", "domain": "finance", "defaultLabel": "Financial Risk Factors", "description": "Material risks that could break the forecast or the cash position — customer concentration, contract renewal risk in the next 2 quarters, debt-covenant proximity, FX exposure on multi-currency revenue/cost mix, payment-processor concentration, audit/tax adjustments under review, regulatory changes affecting revenue recognition. Distinct from `risk_factors` at the operations level — this is explicitly financial. Common pitfall: this field becomes boilerplate (\"market risk, execution risk\") instead of naming the specific risks the board can act on this quarter. Best practice (per the standard board-pack guidance reflected in NVCA Model Investor Rights Agreement information-rights conventions): name the top 3–5 risks with a probability/impact note and a current mitigation status.", "fieldType": "text", "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": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "No calculation — narrative. Convention: 3–5 risks, each with a one-line statement, qualitative likelihood, qualitative impact, and current mitigation action.", "whyItMatters": "Gives the board a defensible answer to \"what should worry us next quarter\" — and creates an audit trail of which risks management saw coming vs. which surprised them. Frequently the highest-signal part of the cash dashboard at growth stage.", "interpretationGuidance": "Track risks across periods — risks that disappear without explicit resolution are usually still active, just not being managed. Boards should treat a thin or unchanged list (no movement quarter-over-quarter on multiple periods) as a yellow flag on financial-controls maturity.", "relatedKpiIds": [ "finance.assumptions", "finance.forecast_notes", "finance.burn_rate_scenarios", "fundraising.risk_factors" ] }, { "rogueId": "finance.runway_months", "slug": "runway_months", "domain": "finance", "defaultLabel": "Runway (Months)", "description": "Estimated number of months the company can operate at the current net burn before unrestricted cash reaches zero, holding everything else constant. The single most consequential survival input for venture-backed companies — it sets the urgency of every fundraising, hiring, and cost decision. Common pitfall: runway is often quoted off `finance.total_cash_in_bank` and a single-month spot-burn instead of operationally-available cash and a 3-month-trailing burn — the result is a runway that looks 2–4 months longer than it actually is when working capital tightens. Boards should ask which cash and which burn went into the calculation.", "fieldType": "number", "unit": "months", "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "recommended" }, "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": "Months of Cash (Runway) by ARR Cohort", "publicationDate": "2024-09-01", "attributionNotice": null }, "formula": "runway_months = cash_basis / finance.net_burn_rate, where cash_basis is finance.operationally_available_cash when working capital is material (Series A+), and finance.total_unrestricted_cash otherwise (early stage, when AR/AP is immaterial and the two converge). Never use max() of the two — that discards the more conservative number exactly when working capital is a headwind, the very pitfall this KPI warns about. When net burn is negative (cash-flow positive), runway is unbounded — render as ∞ rather than negative. Most boards use a 3-month-trailing-average net burn for the denominator to dampen single-month noise.", "whyItMatters": "Drives the timing of every fundraise, hire, and budget cut — and is the number investors lead with in diligence. Crossing under stage-typical thresholds usually triggers a board-level cost or fundraising conversation.", "interpretationGuidance": "Stage-typical industry context (per the 2024 KeyBanc Capital Markets & Sapphire Ventures SaaS Survey §runway / month-of-cash discussion): private SaaS companies with $10M–$50M year-end ARR median ~25 months of cash; those <$10M or >$50M ARR median ~18 months. Practitioner heuristics (industry folk-wisdom, not citation-grade): under 6 months is critical (immediate fundraise or cost action); 12–18 months is healthy for active fundraising; 24+ months gives optionality. Recalculate any time burn changes materially or a tranche closes.", "relatedKpiIds": [ "finance.total_cash_in_bank", "finance.total_unrestricted_cash", "finance.operationally_available_cash", "finance.net_burn_rate", "finance.burn_rate_scenarios", "fundraising.target_raise" ], "calculationPolicy": { "inclusionRules": [ "Numerator: at growth stage (Series A+) use `finance.operationally_available_cash`. At early stage, `finance.total_unrestricted_cash` is acceptable when AR/AP are immaterial.", "Denominator: `finance.net_burn_rate` on a trailing-3-month-average basis. Match the smoothing window used in the burn calculation.", "Result is in months. Express to one decimal place when ≥ 6; whole months when < 6 (decimals at sub-6-month runway suggest false precision)." ], "exclusionRules": [ "Restricted cash from the numerator (collateral, escrow, customer-prepaid-restricted balances).", "Undrawn credit facilities or venture-debt capacity — those are funding capacity, not runway. List separately as \"available capital outside runway.\"", "Equity raises in process but not closed. Runway is a backward-looking metric; pending fundraises go in the fundraising-strategy KPI, not here." ], "requiredInputs": [ "Operationally-available (or unrestricted) cash for the period close.", "Trailing-3-month net burn rate.", "Methodology flag: which cash definition and which burn smoothing window were used." ], "dataSourcePriority": [ "Audited or reviewed cash balance + a closed-period burn calculation.", "Treasury-system cash + FP&A burn forecast as a fallback — flag uncertainty." ], "edgeCases": [ "Negative net burn (cash-flow positive): runway is mathematically unbounded. Render as \"∞\" or \"cash-flow positive\" — never a negative or null number.", "Net burn very close to zero (break-even): runway becomes hyper-sensitive to denominator noise. Use a wider smoothing window (6-month) or flag the runway as \"approaching breakeven, not meaningful as a single number.\"", "Pending tranche close: typical practice is to compute runway both with and without the expected tranche, label clearly.", "Material foreign-currency cash: convert to reporting currency at a stable rate and disclose the conversion." ], "validationChecks": [ "Result is positive (or infinity). A negative or NaN runway indicates a bug — most often a negative cash balance or a zero burn.", "Recompute monthly; runway should change roughly linearly with elapsed time when burn is stable. Step-function jumps usually mean the burn smoothing window slid or a tranche closed.", "Cross-check against stage-typical KBCM bands (~25 months for $10–50M ARR, ~18 months below or above). Out-of-band runway is more often a calculation issue than a real outlier." ], "commonMiscomputations": [ "Using total cash (including restricted) in the numerator — overstates runway by the restricted balance.", "Using a single-month spot burn instead of a trailing average — runway whipsaws on monthly noise; boards see \"we lost 4 months of runway in a month\" when it's just a lumpy outflow.", "Mixing unrestricted-cash numerator with operationally-available-cash burn (or vice versa) — definitions must agree on what cash is being depleted.", "Counting undrawn venture debt as \"runway\" — boards see ~6 extra months of runway that aren't actually deployable without drawing the facility (which itself takes weeks and has covenants).", "Reporting runway from total cash but using a burn that already includes financing inflows — double counts and reads ~2x longer than reality." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "finance.total_cash_in_bank", "slug": "total_cash_in_bank", "domain": "finance", "defaultLabel": "Total Cash in Bank", "description": "Sum of all bank account balances at the reporting cut-off, expressed in a single reporting currency after FX conversion. This is the gross top-of-house cash number — it does not net out restrictions, near-term liabilities, or commitments. The board reads this as the absolute denominator for runway and as a checksum against the cap table (capital raised − cumulative net burn ≈ cash). Common pitfall: founders sometimes report a USD figure that silently includes ILS/EUR accounts at stale FX rates — always reconcile against the bank-accounts list (per FX-aware MultiCurrencyAccountList) and tag the rate date.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "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 }, "formula": "Sum of period-end balances across all bank accounts, converted to the board reporting currency at the cut-off date FX rate. See `finance.bank_accounts_list` for the underlying line items.", "whyItMatters": "The denominator of runway and the single most important survival input — every other cash KPI is read in proportion to this number. Also the basic cap-table sanity check: capital raised minus cumulative net burn should reconcile to total cash within working-capital noise.", "interpretationGuidance": "Read in conjunction with `finance.total_restricted_cash` and `finance.net_burn_rate` to derive operationally available runway. A drop materially larger than net burn for the period signals an unreported outflow (deposit, settlement, FX) that deserves a board note. No published industry threshold exists for \"good\" — interpretation is always company- and stage-specific.", "relatedKpiIds": [ "finance.total_restricted_cash", "finance.total_unrestricted_cash", "finance.operationally_available_cash", "finance.net_burn_rate", "finance.runway_months", "finance.bank_accounts_list" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "finance.total_operational_inflow", "slug": "total_operational_inflow", "domain": "finance", "defaultLabel": "Total Operational Inflow", "description": "Sum of cash actually received from operating activities for the period — customer collections (subscription, services, transactional revenue), refunds claimed back from vendors, and any operating tax credits. Excludes financing activities (debt draws, equity proceeds) and investing activities (asset sales, investment income). This is the numerator-side of the net-burn equation, and the cash-basis counterpart to recognized revenue on the P&L. Common pitfall: companies sometimes book annual SaaS prepayments here as a single-month inflow, masking the underlying monthly run-rate — split lumpy items out or smooth over a trailing 3 months.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "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 }, "formula": "Sum of operating-activity cash receipts for the period. Subtract from total_operational_outflow to get the absolute net-burn dollar value (before dividing by months to get the rate).", "whyItMatters": "Inputs the cash-basis revenue side of net burn. A growing inflow at flat-or-falling outflow is the textbook \"earning its runway\" trajectory; the reverse means the company is more dependent on the cash balance than on revenue.", "interpretationGuidance": "Reconcile against recognized revenue from `sales.arr` and bookings — a persistent gap means deferred-revenue or DSO is moving. Watch lumpy enterprise prepayments and isolate them; they distort the trailing-average net burn read.", "relatedKpiIds": [ "finance.total_operational_outflow", "finance.net_burn_rate", "finance.net_working_capital_adjustment", "sales.arr" ], "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "finance.total_operational_outflow", "slug": "total_operational_outflow", "domain": "finance", "defaultLabel": "Total Operational Outflow", "description": "Sum of cash actually paid for operating activities for the period — payroll and benefits, employer taxes, vendor payments (infra, tooling, contractors), sales and marketing spend, rent, professional services, refunds issued. Excludes financing activities (debt repayment, dividend payments) and investing activities (acquisitions, capex). Direct input to gross burn. Common pitfall: capitalized R&D and long-term capex sometimes get bucketed here; if so they distort gross burn. Keep this strictly operating-cash and surface investing/financing outflows separately so the board can see \"ongoing cost base\" vs. \"discretionary capital deployment\".", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "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 }, "formula": "Sum of operating-activity cash payments for the period. Equals gross burn × months_in_period when there are no working-capital re-classifications.", "whyItMatters": "The denominator-side of net burn and the basis of gross burn — controlling the structural cost base is the lever most boards can directly act on between fundraises.", "interpretationGuidance": "Decompose by spend category each board cycle (payroll vs. infra vs. GTM) — a sustained shift toward GTM or infra usually signals a strategic decision worth explicit board endorsement. No single industry threshold for \"good\" — interpretation is always against ARR, revenue per FTE, and gross-margin context.", "relatedKpiIds": [ "finance.total_operational_inflow", "finance.gross_burn_rate", "finance.net_burn_rate", "hr.arr_per_fte" ], "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "finance.total_restricted_cash", "slug": "total_restricted_cash", "domain": "finance", "defaultLabel": "Restricted Cash", "description": "Cash on the balance sheet that is not available for general operating use because it is contractually pledged or held for a specific purpose — typical examples include landlord lease-deposit escrows, customer-funds collateral, security deposits backing letters of credit, payment-processor reserves, and debt-covenant minimum-balance requirements. Per IFRS and US GAAP balance-sheet presentation, restricted cash must be disclosed separately from unrestricted cash; the board should treat this number as removed from runway. Common pitfall: payment-processor \"reserve\" balances and large customer-deposit floats are often missed when reporting unrestricted cash, inflating apparent runway.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "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 }, "formula": "Sum of bank-account balances flagged `restricted: true` in `finance.bank_accounts_list`, plus any restricted balances held in non-bank vehicles (escrow agents, payment-processor reserve accounts).", "whyItMatters": "Excluded from operationally available cash and from the runway calculation — reporting it inside total cash without flagging the restriction overstates runway and can mask a covenant or liquidity issue.", "interpretationGuidance": "A non-trivial restricted balance (say, >5% of total cash — industry folk-wisdom, not citation-grade) usually warrants a footnote on the source of the restriction and any release schedule. Watch for restricted cash that grows faster than the corresponding operating activity (e.g. payment-processor reserves growing faster than GMV) — that often signals a tightening processor relationship.", "relatedKpiIds": [ "finance.total_cash_in_bank", "finance.total_unrestricted_cash", "finance.operationally_available_cash", "finance.bank_accounts_list" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "finance.total_unrestricted_cash", "slug": "total_unrestricted_cash", "domain": "finance", "defaultLabel": "Unrestricted Cash", "description": "Cash that the company can freely deploy for any operational purpose — total bank balances minus any contractually restricted balances. This is the input most boards actually want when judging runway, because it strips out escrows, security deposits, and processor reserves that cannot be spent on payroll or vendors. The distinction matters more as the company adds enterprise contracts (deposit obligations), debt facilities (covenant balances), and payment processing volume (rolling reserves). Common pitfall: at early stage, restricted cash is often near zero so teams equate this with `finance.total_cash_in_bank` — track them separately from day one to avoid surprise reclassifications later.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "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 }, "formula": "finance.total_cash_in_bank − finance.total_restricted_cash. Equivalent to the sum of bank-account balances flagged `restricted: false` in `finance.bank_accounts_list`.", "whyItMatters": "The right cash number to divide by net burn when computing the spendable runway a board can act on — restricted cash cannot bridge a payroll gap.", "interpretationGuidance": "A meaningful divergence between unrestricted and total cash (industry folk-wisdom: >5–10%) is the trigger to surface a restricted-cash schedule in the board pack. Compare period-over-period — a sudden drop in unrestricted cash that does not match burn usually means a reclassification (e.g. a new lease deposit) rather than spending.", "relatedKpiIds": [ "finance.total_cash_in_bank", "finance.total_restricted_cash", "finance.operationally_available_cash", "finance.runway_months", "finance.bank_accounts_list" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "computed" } }, { "rogueId": "finance.working_capital_adjustments_list", "slug": "working_capital_adjustments_list", "domain": "finance", "defaultLabel": "Working Capital Adjustments", "description": "Itemized list of working-capital adjustments with explicit sign-prefix driving the additive-vs-subtractive multiplier — e.g. \"+ AR collected: $250k\", \"− Prepaid infra: $80k\", \"+ Deferred revenue: $600k\". The line-item basis for `finance.net_working_capital_adjustment` and its child KPIs (current_asset_adjustments, current_liability_adjustments). The signed-prefix UI convention prevents the most common working-capital reporting bug — sign-flips that double-count or invert the cash effect. Common pitfall: lumping unrelated items into a single \"other working capital\" line loses the diagnostic value; break out the top 3–5 components.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "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 }, "formula": "Each row contributes `± amount` based on its sign prefix. Sum of signed amounts equals `finance.net_working_capital_adjustment`. Asset-side rows roll up to `finance.current_asset_adjustments`; liability-side rows roll up to `finance.current_liability_adjustments`.", "whyItMatters": "Makes the working-capital aggregate auditable — the board can see exactly which items moved the number and which direction. Critical at Series A+ when working capital is material.", "interpretationGuidance": "Track the same line items across periods; a previously material line that vanishes from the list usually indicates a hidden reclassification rather than resolution. New material lines deserve a one-line footnote on what happened.", "relatedKpiIds": [ "finance.net_working_capital_adjustment", "finance.current_asset_adjustments", "finance.current_liability_adjustments", "finance.operationally_available_cash" ] }, { "rogueId": "fundraising.assumptions", "slug": "assumptions", "domain": "fundraising", "defaultLabel": "Fundraising Assumptions", "description": "Explicit assumptions underlying the fundraising plan: valuation expectation, lead-investor probability, time-to-close, post-close runway, and what changes if any assumption breaks. Common pitfall: assumptions are made implicitly and only surface in the postmortem. Boards should require this section to be reviewed each update — a board update where assumptions never change suggests they are not being tested, not that they are correct.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "recommended", "seed": "recommended", "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "Narrative — enumerated assumptions, each ideally with (1) the assumption, (2) the rationale, (3) what changes if it breaks.", "whyItMatters": "Anchors the fundraising plan to falsifiable beliefs. Lets the board pre-agree on what would constitute a \"this is not working, change the plan\" trigger.", "interpretationGuidance": "Assumptions that diverge from `risk_factors` are a signal of inconsistency. Assumptions that have been broken without triggering plan change are the strongest red flag — pair with a board discussion of when to change course.", "relatedKpiIds": [ "fundraising.strategy", "fundraising.risk_factors", "fundraising.target_raise", "fundraising.planned_close_date" ] }, { "rogueId": "fundraising.committed_amount", "slug": "committed_amount", "domain": "fundraising", "defaultLabel": "Committed Amount", "description": "Capital that investors have agreed to invest — including both soft commitments (verbal / handshake / IOI) and hard commitments (signed term sheet or executed subscription docs). Treat this as the round-progress odometer. Common pitfall: soft commitments are notoriously squishy — every published fundraising postmortem (per First Round Review and Bessemer founder essays) warns that founders over-count soft commits. Board-best-practice is to track soft vs hard separately or to define a haircut convention (e.g. 50% of soft) at the start of the round.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "Sum of all investor commitments (soft + hard). Define and document the soft-vs-hard convention per round — some companies report only hard commitments to the board, others report a blended number with footnote.", "whyItMatters": "Primary leading indicator for whether the round will close on target and on time. Pacing against `target_raise` and `planned_close_date` tells the board whether intervention is needed.", "interpretationGuidance": "Healthy rounds typically hit 50% committed at the round midpoint and 80%+ before final closing mechanics begin. A committed amount stuck below 30% past the midpoint usually signals a re-pricing or scope-cut conversation with the board.", "relatedKpiIds": [ "fundraising.target_raise", "fundraising.total_received", "fundraising.round_completion_pct", "fundraising.investors_in_pipeline", "fundraising.minimum_close_amount" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "fundraising.convertible_outstanding", "slug": "convertible_outstanding", "domain": "fundraising", "defaultLabel": "Outstanding Convertible Amount", "description": "Total principal value of SAFEs and convertible notes outstanding that have not yet converted to equity. These convert at the next priced round, typically at a discount or valuation cap (per the standard Y Combinator SAFE templates and the National Venture Capital Association convertible-note model). Common pitfall: a SAFE stack quietly accumulating between rounds can convert into 15–25% dilution at the next priced round, surprising founders who modeled \"we only sold 10% in this priced round\" math. Boards should always see the fully-diluted cap table including SAFE conversion.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "recommended" }, "definitionSource": { "tier": "published", "sourceName": "Y Combinator Post-Money SAFE (2018+ standard form)", "sourceUrl": "https://www.ycombinator.com/documents", "sectionRef": "Post-Money SAFE — Definitions (Purchase Amount)", "publicationDate": "2018-09-01", "attributionNotice": null }, "formula": "Sum of principal outstanding on all unconverted convertible instruments (SAFEs per the Y Combinator post-money SAFE template; convertible notes per the NVCA Model Documents). Pre-conversion — actual dilution depends on the next-round price and the SAFE caps/discounts.", "whyItMatters": "Hidden dilution that hits at the next priced round. A material SAFE stack changes the math on what a \"20% Series A\" actually costs the founders.", "interpretationGuidance": "When `convertible_outstanding` is more than ~10% of the company's next-likely post-money valuation, the board should require a fully-diluted cap-table walk-through at the next priced round modeling exercise. Highest-cap and lowest-cap SAFE conversion paths should both be modeled.", "relatedKpiIds": [ "fundraising.pre_money_valuation", "fundraising.post_money_valuation", "fundraising.founder_dilution" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "fundraising.founder_dilution", "slug": "founder_dilution", "domain": "fundraising", "defaultLabel": "Founder Dilution", "description": "Percentage of founders' fully-diluted ownership that is given up in the new round, including any pre-close option-pool top-up (the \"option pool shuffle\" — option-pool expansion taken in the pre-money dilutes existing holders rather than new investors). Common pitfall: founders often quote the \"investor dilution\" (new money / post-money) and forget the option-pool top-up component. The Carta State of Private Markets quarterly reports publish stage-typical dilution ranges that boards should use as a sanity check.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "published", "sourceName": "Carta State of Private Markets Q3 2025", "sourceUrl": "https://carta.com/data/state-of-private-markets-q3-2025/", "sectionRef": "Seed Round Dilution", "publicationDate": "2025-10-01", "attributionNotice": null }, "benchmark": { "p25": 12, "median": 18, "p75": 24, "unit": "%", "sourceName": "Carta State of Private Markets Q3 2025", "sourceYear": "2025", "higherIsBetter": false }, "formula": "founder_dilution_pct = (founder_shares_pre − founder_shares_post) / founder_shares_pre × 100. Includes both new-money dilution and any pre-close option-pool top-up borne in the pre-money. Per Carta State of Private Markets methodology.", "whyItMatters": "Tracks founder skin-in-the-game over time — sustained ownership matters for long-term motivation and signaling to future investors. Boards balance dilution discipline against capital needs.", "interpretationGuidance": "Per Carta State of Private Markets benchmarks, typical per-round dilution for the priced round (excluding pool top-up) is 18–22% at seed, 18–22% at A, 12–18% at B, 10–15% at C+. Out-of-band dilution either signals weak negotiating position or a strategic priced-up next-round set-up.", "relatedKpiIds": [ "fundraising.pre_money_valuation", "fundraising.post_money_valuation", "fundraising.total_round_size" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "fundraising.investors_in_pipeline", "slug": "investors_in_pipeline", "domain": "fundraising", "defaultLabel": "Investors in Pipeline", "description": "Count of distinct investors actively engaged in the current round — defined as taken a first meeting and not yet declined or fully committed. Effectively a fundraising-funnel \"qualified leads\" number. Common pitfall: rosy pipelines that include investors who ghosted weeks ago — best practice (echoed across NfX, First Round Review, and Bessemer founder essays) is to age-out any investor with no contact in 14+ days. Track separately from total intros taken and from hard commitments to make the conversion math legible.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "Count of distinct investors in active engagement (intro / first meeting / partner meeting / diligence). Excludes declined, closed, or stale (>14 days no contact) investors.", "whyItMatters": "Healthy round dynamics rest on competitive tension — a thin pipeline means weaker negotiating position on price and terms. Board reads this to gauge whether the CEO needs help with intros.", "interpretationGuidance": "Rule of thumb across stages: ~40–60 first meetings → ~10–15 partner meetings → ~3–5 term sheets → 1 lead. Active pipeline (post first meeting, pre decline) below 8–10 at the round midpoint typically warrants the board opening their networks.", "relatedKpiIds": [ "fundraising.committed_amount", "fundraising.round_status", "fundraising.strategy" ], "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "fundraising.minimum_close_amount", "slug": "minimum_close_amount", "domain": "fundraising", "defaultLabel": "Minimum Close Amount", "description": "Floor — the smallest amount of committed capital required to legally close the round (often set in the subscription agreement) or the strategically smallest amount management would accept before re-pricing or pausing. Common pitfall: a `target_raise` of $10M and a `minimum_close_amount` of $4M tells a very different story than a target of $10M and a minimum of $9M — boards should always see both. Per common practice (NVCA Model Documents allow flexibility here), the minimum is typically 50–75% of target at seed, 70–90% at A+.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "recommended", "seed": "recommended", "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "Currency floor — typically defined in the subscription agreement or by management. Distinct from `target_raise` (the ask) and `committed_amount` (in-progress signal). Per NVCA Model Documents convention.", "whyItMatters": "Defines the round's \"this is enough to ship\" line. Pacing relative to the minimum is the worst-case board view; pacing relative to target is the best-case view — both matter.", "interpretationGuidance": "Per common practice: minimum 50–75% of target at seed, 70–90% of target at A+. A minimum-equals-target round signals high commitment to the headline number; a minimum well below target signals optionality for a \"step-down close.\" Triggered minimums (below floor) require management to revise scope and re-baseline runway.", "relatedKpiIds": [ "fundraising.target_raise", "fundraising.committed_amount", "fundraising.round_completion_pct", "finance.runway_months" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "fundraising.planned_close_date", "slug": "planned_close_date", "domain": "fundraising", "defaultLabel": "Planned Close Date", "description": "Calendar date by which the round is expected to close (final wires received, definitive documents signed). Compared against `finance.runway_months` to detect a fundraising-against-the-clock situation. Common pitfall: planned close dates routinely slip 30–90 days in practice (collected founder postmortems on First Round Review) — boards should ask for both an \"expected\" and a \"no-deal\" date and watch the gap to actual runway exhaustion.", "fieldType": "date", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "Calendar date. Not derived — set by management. Compare to today + `finance.runway_months` to surface runway-versus-close risk.", "whyItMatters": "Single most-important fundraising deadline — drives urgency, board cadence, and bridge-financing decisions. Slippage here is the leading indicator that the round is in trouble.", "interpretationGuidance": "When the planned close date is within 2 months of runway exhaustion (i.e. `runway_months` ≤ months_to_planned_close + 2), the board should be in active conversation about bridge financing or scope cuts. A slipping date should be paired with explicit re-baseline of runway.", "relatedKpiIds": [ "fundraising.round_status", "fundraising.committed_amount", "fundraising.target_raise", "finance.runway_months" ] }, { "rogueId": "fundraising.post_money_valuation", "slug": "post_money_valuation", "domain": "fundraising", "defaultLabel": "Post-Money Valuation", "description": "Company valuation immediately after the new round closes, including the new capital raised — the canonical \"valuation\" number quoted in TechCrunch headlines. Per NVCA Model Documents, post-money = pre-money + new money raised. Common pitfall: post-money math gets messy with SAFEs — modern post-money SAFEs (the YC 2018+ form, per the Y Combinator SAFE primer) fix dilution at the SAFE's valuation cap regardless of subsequent priced-round pricing, so the board should always reconcile the headline post-money against the fully-diluted cap table.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "recommended", "seed": "recommended", "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended" }, "definitionSource": { "tier": "published", "sourceName": "NVCA Model Legal Documents (2024 revision)", "sourceUrl": "https://nvca.org/model-legal-documents/", "sectionRef": "Series A Charter — Post-Money Valuation convention", "publicationDate": "2024-01-01", "attributionNotice": null }, "formula": "post_money_valuation = pre_money_valuation + total_round_size. Per NVCA Model Documents. With outstanding post-money SAFEs, reconcile against the fully-diluted cap table — SAFE dilution is fixed at the cap regardless of priced-round price.", "whyItMatters": "The headline number the company carries forward — sets the goalposts for the next round (a down-round means raising at a lower post-money) and the strike-price floor for new option grants.", "interpretationGuidance": "Watch the post-money-to-ARR multiple (or post-money-to-net-burn if pre-revenue): public sources covering 2024–2025 (e.g. SaaS Capital \"Private SaaS Company Valuations\" report, valuation-multiples section; Sapphire / KBCM SaaS Survey, \"valuations\" chapter) show median ARR multiples have compressed materially from 2021 peaks. Pull the current edition for the live range — do not rely on a memorized number — and flag out-of-band multiples as next-round price risk. Where you only have rough heuristics, mark them as \"directional, not citation-grade\" rather than fabricating a precise band.", "relatedKpiIds": [ "fundraising.pre_money_valuation", "fundraising.total_round_size", "fundraising.founder_dilution", "sales.arr", "finance.net_burn_rate" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "fundraising.pre_money_valuation", "slug": "pre_money_valuation", "domain": "fundraising", "defaultLabel": "Pre-Money Valuation", "description": "Company valuation negotiated with investors immediately before the new round closes — the denominator for the new investors' ownership math. Per the NVCA Model Documents, pre-money = post-money − new money raised. Common pitfall: when convertible instruments (SAFEs, notes) are outstanding, the \"headline\" pre-money the CEO quotes and the effective pre-money after conversion can differ materially — the board should always ask for both. Equally important: option-pool top-ups taken pre-close come out of the pre-money share count, diluting founders not investors (the \"option pool shuffle\").", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "published", "sourceName": "NVCA Model Legal Documents (2024 revision)", "sourceUrl": "https://nvca.org/model-legal-documents/", "sectionRef": "Series A Charter — Original Issue Price", "publicationDate": "2024-01-01", "attributionNotice": null }, "formula": "pre_money_valuation = post_money_valuation − total_round_size. Per NVCA Model Documents convention. Effective pre-money after SAFE/note conversion can be lower than headline — surface both when convertibles are material.", "whyItMatters": "Sets the price for the round. Drives `founder_dilution`, the option-pool top-up math, and the precedent for the next round (down-rounds are punishing to recover from).", "interpretationGuidance": "Compare to stage-relative ranges from quarterly Carta / PitchBook reports (e.g. seed median has moved $12–18M post-money in 2024–2025). A pre-money below stage median typically signals either harsher terms or a strategic discount; above stage median demands real metric backing.", "relatedKpiIds": [ "fundraising.post_money_valuation", "fundraising.total_round_size", "fundraising.founder_dilution", "fundraising.convertible_outstanding" ], "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "fundraising.risk_factors", "slug": "risk_factors", "domain": "fundraising", "defaultLabel": "Fundraising Risk Factors", "description": "Named risks that could prevent the round from closing as targeted — market conditions (general venture sentiment, sector-specific freeze), investor-side risk (anchor investor wobble, partner-meeting drop-off), company-side risk (a metric trending wrong direction, customer concentration concern surfaced in diligence), and timing risk (runway versus close date). Common pitfall: optimistic CEOs under-report risk factors. Boards should expect at least 2–3 named risks even in a healthy round — \"no risks\" is itself a risk signal.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "recommended", "seed": "recommended", "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "Narrative — list of named risks, each ideally with a likelihood / mitigation pair.", "whyItMatters": "Surfaces what could go wrong before it does — boards earn their seat by spotting risks the CEO is too close to see. Also a contract between CEO and board on what to watch.", "interpretationGuidance": "Watch for risks that persist across multiple updates with no mitigation movement — usually a sign the CEO needs board help. A new risk appearing late in the round (post-term-sheet) deserves immediate board attention.", "relatedKpiIds": [ "fundraising.round_status", "fundraising.strategy", "fundraising.assumptions" ] }, { "rogueId": "fundraising.round_completion_pct", "slug": "round_completion_pct", "domain": "fundraising", "defaultLabel": "Round Completion %", "description": "Progress of the round expressed as committed capital divided by target. Read alongside `round_status` and elapsed-time-in-round to detect stalls. Common pitfall: percentage progress is misleading when measured against a shifting `target_raise` — when management lowers the target mid-round, the percentage jumps without any new commitments arriving. The board should always be told when this is a target revision vs. a real progress event.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "round_completion_pct = (committed_amount / target_raise) × 100. When using soft+hard committed, footnote the convention.", "whyItMatters": "Single-number pacing signal — board members glance at it first when scanning a fundraising update. Pairs naturally with elapsed-time-in-round to surface stalls.", "interpretationGuidance": "Rough pacing checkpoints from collected practitioner essays (NfX, Bessemer founder content): 30% by 4–6 weeks in, 60% by week 8–10, 90%+ by week 12. Sustained pacing below these typically signals a need to widen the investor net or revise the target.", "relatedKpiIds": [ "fundraising.target_raise", "fundraising.committed_amount", "fundraising.round_status", "fundraising.planned_close_date" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "fundraising.round_status", "slug": "round_status", "domain": "fundraising", "defaultLabel": "Round Status", "description": "Current phase of the active fundraising round on a coarse state machine (e.g. not-started, in-progress, term-sheet, closing, closed). The board reads this to know which playbook applies — pipeline-building, diligence, closing, or post-close communications. Common pitfall: the field drifts when a round stalls or pivots, so treat each phase change as a board-update trigger. The PhasePlaybook widget binds to this enum and surfaces the appropriate phase guidance read-only beside the editor.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "Categorical state derived from operational status — no calculation. Typical states: not-started, in-progress, term-sheet, closing, closed, paused.", "whyItMatters": "Anchors every other fundraising number in board context — the same target_raise is read differently mid-pipeline than at closing. Drives which phase playbook the board should be advising on.", "interpretationGuidance": "Treat a phase regression (e.g. term-sheet → in-progress) as a yellow flag and pair it with `risk_factors`. Time spent in any single phase beyond stage-typical norms (6–9 months at seed, 4–6 months at A/B) signals a stalled round.", "relatedKpiIds": [ "fundraising.target_raise", "fundraising.committed_amount", "fundraising.planned_close_date", "fundraising.risk_factors" ] }, { "rogueId": "fundraising.strategy", "slug": "strategy", "domain": "fundraising", "defaultLabel": "Fundraising Strategy", "description": "Free-text narrative covering the planned fundraising approach for the current round: target investor types (lead profile, co-investors), timing, sequencing of the conversation, use of proceeds, milestones the round will get the company to, and the alternative scenarios if the primary plan slips. This is the \"what is the CEO actually doing\" section of the fundraising update. Common pitfall: strategy that does not name a target lead investor profile or use-of-proceeds milestone is not strategy — it is intent. Boards should push for specificity here.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "Narrative — no calculation. Should cover (1) target investor profile, (2) sequencing / timing plan, (3) use of proceeds, (4) milestones funded, (5) downside scenarios.", "whyItMatters": "Forces the CEO to articulate \"what game we are playing\" — boards offer better help when they understand the strategy, not just the numbers.", "interpretationGuidance": "A strategy that has not changed across consecutive board updates while the round has stalled is a red flag — typically requires a reframing conversation. A strategy that pivots every update is also a red flag — typically requires the board to push for commitment.", "relatedKpiIds": [ "fundraising.round_status", "fundraising.target_raise", "fundraising.investors_in_pipeline", "fundraising.risk_factors", "fundraising.assumptions" ] }, { "rogueId": "fundraising.target_raise", "slug": "target_raise", "domain": "fundraising", "defaultLabel": "Target Raise", "description": "Target gross capital the company intends to raise in the currently active round (the \"ask\"). This is the headline number the CEO walks investors through and the board uses to sanity-check dilution and runway implications. Note the distinction from `total_round_size` (which can include third-party participation beyond the company-led ask) and from `minimum_close_amount` (the floor at which the round can close). Common pitfall: the target is updated mid-process when investor demand or strategy shifts — every change deserves a board note.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "Plain currency target — no derivation. Distinct from `total_round_size` (which may include strategic / employee allocations beyond the lead ask) and `minimum_close_amount` (the floor for the round to close).", "whyItMatters": "Defines the contract between management and the board for this round — every downstream KPI (round_completion_pct, founder_dilution, runway extension) is calibrated against it.", "interpretationGuidance": "Compare against stage norms (per Carta / PitchBook quarterly reports): pre-seed $0.5–3M, seed $2–5M, Series A $8–20M, Series B $20–60M. A target significantly above stage norm warrants extra board scrutiny on burn assumptions and investor fit.", "relatedKpiIds": [ "fundraising.committed_amount", "fundraising.total_round_size", "fundraising.minimum_close_amount", "fundraising.round_completion_pct", "fundraising.founder_dilution" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "fundraising.total_capital_raised", "slug": "total_capital_raised", "domain": "fundraising", "defaultLabel": "Total Capital Raised to Date", "description": "Cumulative gross equity capital raised across all prior rounds (and the current round in-progress). Treated as historical context — investors and board members look at this to gauge capital efficiency (capital raised vs. ARR achieved). Common pitfall: includes all equity but typically excludes convertible debt that has not converted, venture debt principal, and grants — be explicit about what is and is not included when the number is presented. Capital efficiency benchmarks (per KBCM, SaaS Capital, and Bessemer State-of-the-Cloud) compare `total_capital_raised` to current ARR — e.g. \"$30M raised, $10M ARR\" is efficient at A but lean at B+.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "recommended", "seed": "recommended", "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "Sum of gross equity capital raised across all rounds. Be explicit about inclusion of convertibles and exclusion of venture debt / grants — surface in a footnote.", "whyItMatters": "Tracks capital efficiency over time and frames the company's next-round narrative (\"we raised $X to get to $Y ARR\"). Investors and board members use this for stage-vs-traction sanity-checking.", "interpretationGuidance": "Compare to current ARR for capital efficiency. The right ratio is ARR ÷ capital raised — most early-stage SaaS companies generate noticeably less ARR than they have raised (ratio typically well under 1.0x at Series A, with the gap intentional during growth-spend ramps). The KBCM (now Sapphire / KBCM) Private SaaS Company Survey publishes a \"capital efficiency\" cut for the current vintage; the Bessemer State of the Cloud report covers the same axis qualitatively. Pull the current edition for the live benchmark rather than relying on a memorized number, and tag any heuristic range as \"directional, not citation-grade\" if you cannot cite a specific section.", "relatedKpiIds": [ "fundraising.total_round_size", "fundraising.total_received", "sales.arr", "finance.net_burn_rate" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "fundraising.total_received", "slug": "total_received", "domain": "fundraising", "defaultLabel": "Total Received", "description": "Cash that has actually been wired and cleared the company's bank account from investors in the current round. This is the cash-in-the-bank version of `committed_amount`. Common pitfall: commitments do not pay the bills — wiring can lag commitments by weeks to months for the second / third closes, and a committed-but-not-received delta of $5M+ can quietly extend the runway forecast incorrectly. Reconcile this against `finance.total_cash_in_bank` increases each period.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "Sum of investor wires received and cleared in the current round. Always less-than-or-equal-to `committed_amount`; difference equals \"to-be-wired\" balance.", "whyItMatters": "The only line of capital the company can actually deploy — runway forecasts based on `committed_amount` rather than `total_received` are aspirational, not operational.", "interpretationGuidance": "A widening gap between `committed_amount` and `total_received` past the first close warrants a follow-up — wiring delays beyond 30 days from signature increasingly correlate (per founder postmortems published on First Round Review) with investor regret or strategic shifts.", "relatedKpiIds": [ "fundraising.committed_amount", "fundraising.target_raise", "finance.total_cash_in_bank", "finance.runway_months" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "fundraising.total_round_size", "slug": "total_round_size", "domain": "fundraising", "defaultLabel": "Total Round Size", "description": "Total new capital being raised in the current round across all participants — the lead, follow-on investors, employee/strategic allocations, and any side-letter pieces. This is the figure that goes into the post-money math. Common pitfall: companies sometimes confuse `total_round_size` with `target_raise` — the round size is final and used in valuation math, while the target is what management is aiming for and can move during the raise. Boards should expect a specific breakdown by investor when this number is reported.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "published", "sourceName": "NVCA Model Legal Documents (2024 revision)", "sourceUrl": "https://nvca.org/model-legal-documents/", "sectionRef": "Series A Stock Purchase Agreement — Aggregate Investment", "publicationDate": "2024-01-01", "attributionNotice": null }, "formula": "Sum of all new-money allocations in the round (lead + follow-on + strategic + employee + side letters). Distinct from `target_raise` (intent) and `committed_amount` (in-progress signal).", "whyItMatters": "Determines the round's post-money valuation and dilution math. Also signals investor concentration risk — a round with 80% from one investor differs structurally from a round with 5 equal participants.", "interpretationGuidance": "Round size noticeably below target typically signals investor demand weakness (consider repricing or scope cut). Round size meaningfully above target signals oversubscription — a healthy signal but raises governance questions on how allocations are decided.", "relatedKpiIds": [ "fundraising.target_raise", "fundraising.committed_amount", "fundraising.pre_money_valuation", "fundraising.post_money_valuation", "fundraising.founder_dilution" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "fundraising.venture_debt_available", "slug": "venture_debt_available", "domain": "fundraising", "defaultLabel": "Venture Debt Available", "description": "Undrawn capacity remaining on existing venture debt facilities. Optionality the company can call on quickly without re-pricing. Common pitfall: availability is conditional — most facilities require continued covenant compliance, and an available line can be pulled or frozen by the lender if cash, ARR, or other covenants slip (per the Bessemer venture-debt content and Battery Ventures primer). The board should treat `venture_debt_available` as a soft commitment, not a hard one, until drawn.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "venture_debt_available = total_facility_committed − venture_debt_drawn − amounts no longer drawable (covenant restrictions, time-window expirations).", "whyItMatters": "Strategic optionality — drawable capacity is a buffer for unexpected burn or a bridge to the next round. But it is contingent on staying inside covenants, so the board needs both this number and `venture_debt_covenant_status`.", "interpretationGuidance": "Available capacity of 3–6 months of net burn provides meaningful optionality. Less than ~1 month of burn in availability rarely justifies the facility complexity. Watch for facilities with expiring draw windows — undrawn capacity that vanishes on a calendar date.", "relatedKpiIds": [ "fundraising.venture_debt_drawn", "fundraising.venture_debt_covenant_status", "finance.net_burn_rate", "finance.runway_months" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "fundraising.venture_debt_covenant_status", "slug": "venture_debt_covenant_status", "domain": "fundraising", "defaultLabel": "Venture Debt Covenant Status", "description": "Stoplight state of the venture-debt facility covenants — typically minimum-cash, minimum-ARR or revenue, maximum-burn, customer-concentration, and material-adverse-change clauses (per the standard Bessemer / Battery Ventures venture-debt primers). A covenant trip can freeze the draw line, accelerate repayment, or both. Common pitfall: covenants are not always actively monitored between board meetings — drift between an internal forecast and a covenant threshold can cross the line silently. Boards should require monthly covenant headroom reporting when material debt is drawn.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "Stoplight categorical: in-compliance (with headroom) / at-risk (headroom ≤ 1 quarter) / tripped / waived. List the binding covenant and current headroom.", "whyItMatters": "A covenant trip can cascade into a liquidity crisis fast — frozen facility, accelerated repayment, MAC clause triggering. Board catches this only if it is on the dashboard explicitly.", "interpretationGuidance": "Headroom of less than one quarter on the binding covenant is \"at-risk\" — board action required. Headroom of less than one month is a crisis-management situation regardless of stoplight color. Always pair with the binding-covenant name (e.g. \"minimum cash $5M, current $7.2M, headroom = $2.2M\").", "relatedKpiIds": [ "fundraising.venture_debt_drawn", "fundraising.venture_debt_available", "finance.total_cash_in_bank", "finance.net_burn_rate" ] }, { "rogueId": "fundraising.venture_debt_drawn", "slug": "venture_debt_drawn", "domain": "fundraising", "defaultLabel": "Venture Debt Drawn", "description": "Principal currently drawn from venture debt facilities (e.g. Silicon Valley Bank, Hercules Capital, Trinity Capital, Western Alliance, Bridge Bank facilities). Venture debt typically extends runway 6–12 months alongside the equity round — used well, it dilution-efficiently bridges to the next equity event; used poorly, it concentrates default risk into a single covenant covenant trip. Common pitfall: drawn debt creates interest expense and a repayment schedule that compresses runway in 18–24 months even though it extends runway today (per the Battery Ventures venture-debt primer and the Bessemer \"venture debt playbook\" series).", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "Sum of principal drawn (and not yet repaid) across all active venture debt facilities. Distinct from `venture_debt_available` (undrawn capacity). Servicing cost = drawn × (rate + fees) — reduces runway.", "whyItMatters": "Drawn debt accelerates cash burn through interest plus principal amortization (typically 24–36 month amortization after a 6–18 month interest-only period). Misjudging the trade-off between dilution avoided and forced repayment is a common venture-backed startup failure mode.", "interpretationGuidance": "Drawn debt above ~30% of unrestricted cash starts to dominate the runway forecast and the covenant exposure. Pair with `venture_debt_covenant_status` and the next-round timeline — if the next equity event is uncertain past the amortization start date, the board should be in active conversation about refinancing.", "relatedKpiIds": [ "fundraising.venture_debt_available", "fundraising.venture_debt_covenant_status", "finance.total_cash_in_bank", "finance.runway_months" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "hr.approved_headcount_budget", "slug": "approved_headcount_budget", "domain": "hr", "defaultLabel": "Approved Headcount Budget", "description": "Board-approved end-of-period headcount target. The contractual reference point against which `hr.total_headcount` and `hr.open_positions` are read — drift means either hiring under plan (typically a growth concern) or over plan (typically a burn-discipline concern). Common pitfall: silent in-year adjustments — boards approve a number, the CEO informally expands or contracts to it, and the variance never gets reconciled. Best practice is to treat changes to this number as board-action items, recorded in `hr.board_actions`.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR", "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 }, "formula": "Plain board-approved end-of-period FTE target. No derivation — set by board resolution as part of the annual or semi-annual budget. Changes require board approval and should be logged in `hr.board_actions`.", "whyItMatters": "The single number that converts strategic intent into operating constraint. Variance against this number drives the budget-vs-actual conversation that anchors most board meetings' HR section.", "interpretationGuidance": "Pair with `hr.total_headcount` and `hr.headcount_change` for variance reporting. A sustained gap >10% under plan typically signals recruiting capacity issues; sustained over plan signals approval-gate slippage or contractor-conversion that bypassed the budget process (industry folk-wisdom, not citation-grade).", "relatedKpiIds": [ "hr.total_headcount", "hr.headcount_change", "hr.open_positions", "hr.hiring_plan", "hr.board_actions" ], "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "hr.arr_per_fte", "slug": "arr_per_fte", "domain": "hr", "defaultLabel": "ARR per FTE", "description": "Annual Recurring Revenue divided by total FTE-equivalent workforce — the canonical SaaS workforce-productivity ratio anchored to the SaaS Capital Annual Survey methodology (revenue per employee benchmarks). A high-signal denominator for \"are we over- or under-staffed for our revenue scale?\" Common pitfall: choosing different ARR conventions (ending vs average, GAAP-reconciled vs raw) without locking in a board-level standard. Best practice is to pair this with `sales.arr` so the numerator is unambiguous and to disclose whether contractors are included in the FTE denominator.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR", "Finance" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Capital Annual Survey 2025 (14th Annual)", "sourceUrl": "https://www.saas-capital.com/blog-posts/revenue-per-employee-benchmarks-for-private-saas-companies/", "sectionRef": "Revenue per Employee", "publicationDate": "2025-06-01", "attributionNotice": null }, "benchmark": { "p25": 100000, "median": 130000, "p75": 175000, "unit": "$", "sourceName": "SaaS Capital Annual Survey 2025 (14th Annual)", "sourceYear": "2025", "higherIsBetter": true }, "formula": "ARR per FTE = `sales.arr` / `hr.total_headcount` (or FTE-equivalent including contractor adjustment from `hr.fte_metrics`). Document the denominator convention in board materials. Per SaaS Capital Annual Survey 2025 methodology (Revenue per Employee).", "whyItMatters": "Investors use this as a quick scalability and operating-leverage proxy — companies with higher ARR/FTE at a given scale typically command premium multiples. Internally, the metric anchors hiring-plan discipline: does each net new FTE earn its keep?", "interpretationGuidance": "SaaS Capital Annual Survey 2025 (§Revenue per Employee) reports private SaaS medians clustering in the $150K–$250K range, with top quartile $250K+ and bottom quartile under $150K (verify exact figures against the cited report — distributions vary by ARR band). Sub-$100K sustained at Series B+ is a board-level efficiency conversation. Reads should be paired with stage and growth rate — high-growth-stage companies tolerate lower ratios for a window in exchange for growth.", "relatedKpiIds": [ "sales.arr", "hr.total_headcount", "hr.fte_metrics", "hr.payroll_run_rate", "operations.rule_of_40" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "contracted_arr", "production": "computed" } }, { "rogueId": "hr.at_risk_count", "slug": "at_risk_count", "domain": "hr", "defaultLabel": "At-Risk Employees", "description": "Count of employees actively flagged as flight risk by managers, based on engagement signals (skip-level surveys, manager 1:1s, counter-offer activity, tenure-curve risk). A leading indicator that complements the lagging `hr.voluntary_exits` number. Common pitfall: stale flags that never get cleared — at-risk lists tend to drift toward \"every senior IC ever\" without manager discipline. Best practice is a quarterly refresh with explicit add/remove notes and an action attached to each flag.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "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 }, "formula": "Count of currently-flagged active employees on the retention watchlist. Flag criteria are company-defined but typically include: declining 1:1 engagement, missed comp expectations, counter-offer activity, or manager-flagged tenure-curve risk. Convention: flags expire 90 days after entry unless renewed.", "whyItMatters": "Converts manager intuition into a board-readable risk count, and pairs naturally with `hr.retention_initiatives` so the board sees risk and response together. A rising at-risk count without rising retention activity is a yellow flag.", "interpretationGuidance": "Read alongside `hr.voluntary_exits` — at-risk count should lead exits by 1–2 quarters. Concentration in one team or level is more diagnostic than the absolute number. Sustained at-risk count above ~10–15% of headcount typically warrants a targeted retention program (industry folk-wisdom, not citation-grade).", "relatedKpiIds": [ "hr.voluntary_exits", "hr.voluntary_turnover_rate", "hr.retention_initiatives", "hr.talent_challenges" ], "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "hr.avg_days_to_fill", "slug": "avg_days_to_fill", "domain": "hr", "defaultLabel": "Average Days to Fill", "description": "Mean elapsed days between requisition opening (approved and posted) and offer acceptance, averaged across requisitions filled in the period. The headline recruiting-velocity KPI commonly tracked in the SHRM Talent Acquisition Benchmarking Report. Common pitfall: choosing between time-to-fill (req-opened to offer-accepted) and time-to-hire (first-applicant to offer-accepted) without locking the convention — the two can differ by weeks. Best practice is to standardize on time-to-fill (the SHRM benchmark convention) and document any deviation.", "fieldType": "number", "unit": "days", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "published", "sourceName": "SHRM Talent Acquisition Benchmarking Report", "sourceUrl": "https://www.shrm.org/topics-tools/research/talent-acquisition-benchmarking-report", "sectionRef": "Time-to-Fill", "publicationDate": "2023-01-01", "attributionNotice": null }, "formula": "Average Days to Fill = Σ(offer-accepted-date − requisition-opened-date) / count of requisitions filled in the period. Convention: time-to-fill per SHRM Talent Acquisition Benchmarking Report — req-opened to offer-accepted, not first-applicant to offer-accepted.", "whyItMatters": "A stretching time-to-fill is one of the earliest leading indicators of either comp-band misfit, role-spec creep, or recruiter capacity exhaustion. Combined with `hr.open_positions`, it projects when promised capacity actually arrives.", "interpretationGuidance": "SHRM Talent Acquisition Benchmarking Report typically reports cross-industry medians around 40–45 days time-to-fill, with technical roles (engineering, data) often longer (60–90+ days). Verify against the most recent SHRM report for the exact figure. A sustained increase of >20% with no role-mix change typically signals a recruiting-pipeline issue (industry folk-wisdom, not citation-grade).", "relatedKpiIds": [ "hr.open_positions", "hr.hiring_plan", "hr.new_hires", "hr.key_openings", "hr.key_hires" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "hr.board_actions", "slug": "board_actions", "domain": "hr", "defaultLabel": "HR Board Actions", "description": "Explicit list of HR items requiring board attention, approval, or decision in this meeting — executive comp changes, headcount-budget changes, equity-pool top-ups, employment-policy approvals, and any items needing a board resolution. Common pitfall: burying decisions inside other narrative sections — boards consistently miss requests that are not explicitly tagged as \"decision required.\" Best practice is to label each item as approval-required vs awareness-only and give a one-line ask.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "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 }, "whyItMatters": "The single most under-served section on most board packs. CEOs often expect their narrative to drive a decision; boards often miss the implicit ask. An explicit \"board actions\" section is a low-cost forcing function for board-level decision hygiene.", "interpretationGuidance": "Each item should be one of: approval-required (specific resolution wording or vote), assistance-required (intro / reference / open-door request), or awareness-only (FYI for governance log). Use `hr.risk_items` for the structured-table version once the board adopts that pattern.", "relatedKpiIds": [ "hr.risk_items", "hr.approved_headcount_budget", "hr.talent_challenges", "hr.retention_initiatives" ] }, { "rogueId": "hr.departments", "slug": "departments", "domain": "hr", "defaultLabel": "Departments", "description": "Field-array of per-department rows — department name, leader status (resolved against `hr.leader_status`), and headcount metrics with stable-count auto-calc — rendered as a drag-sortable table grouped by department. Common pitfall: department boundaries drift over time (Eng+R&D merging, GTM splitting into Sales/Marketing/CS) — when boundaries change, prior-period comparisons need an explicit reconciliation note. This KPI is structural, not numeric — no formula applies.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "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 }, "whyItMatters": "Shows the org map at a glance — where capacity is allocated, which departments are short-staffed, where leader-vacancies are concentrated. Boards use this to validate the strategy-vs-investment alignment (\"we say we are product-led but R&D is 20% of headcount\").", "interpretationGuidance": "Read with `hr.leader_status` alongside — a department with strong leader and on-plan headcount tells a very different story from one with interim/vacant leader and growing headcount. Material department-shape changes should be called out in `hr.talent_highlights` or `hr.talent_challenges` narrative.", "relatedKpiIds": [ "hr.leader_status", "hr.total_headcount", "hr.key_hires", "hr.key_openings", "hr.executive_commentary" ] }, { "rogueId": "hr.executive_commentary", "slug": "executive_commentary", "domain": "hr", "defaultLabel": "HR Executive Commentary", "description": "Stacked commentary editor with per-section icon and live word count, hosting the four canonical HR narrative slots (talent highlights, talent challenges, hiring plan, retention initiatives) under a single base path — each section persists under `.`. The composite container for the narrative side of the HR scorecard, paired with `hr.departments` and `hr.risk_items` for the structured side. Common pitfall: writing each section in isolation — strong commentary cross-references the numbers (\"voluntary turnover up 4 points QoQ, here is what we are doing\").", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "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 }, "whyItMatters": "Centralizes the narrative around the HR numbers in one editing surface, with word-count feedback that prevents both under- and over-writing. The structure mirrors how boards expect HR to be presented: positives, concerns, plan, mitigations.", "interpretationGuidance": "Each section should weigh in at roughly the same length (target 80–150 words per section is a reasonable convention) — wildly uneven sections signal the CEO/CHRO is avoiding one of the four. Word-count outliers are an editorial check, not a hard rule.", "relatedKpiIds": [ "hr.talent_highlights", "hr.talent_challenges", "hr.hiring_plan", "hr.retention_initiatives", "hr.departments", "hr.risk_items" ] }, { "rogueId": "hr.fte_metrics", "slug": "fte_metrics", "domain": "hr", "defaultLabel": "FTE Metrics", "description": "Derived triple — effective FTE, cost-per-FTE, and annualized payroll — computed from `hr.payroll_run_rate` + `hr.total_contractors` and a contractor-to-FTE conversion factor. Lets the board see capacity in normalized terms even when the staffing mix shifts. Common pitfall: choosing a contractor-to-FTE factor without explicit board agreement — some companies use 1.0 (1 contractor = 1 FTE for capacity), others use 0.8 (account for ramp / partial-engagement), others use cost-equivalent ratios. Lock the convention.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR", "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 }, "formula": "effectiveFTE = `hr.total_headcount` + (`hr.total_contractors` × contractorFactor). costPerFTE = `hr.payroll_run_rate` / effectiveFTE. annualizedPayroll = effectiveFTE × costPerFTE. Default contractor factor 0.8 unless the board adopts a different convention.", "whyItMatters": "Normalizes capacity and cost across companies with very different contractor strategies, making `hr.arr_per_fte` and `hr.payroll_as_pct_of_burn` more comparable over time. Surfaces hidden cost inflation when contractor headcount grows faster than employee headcount.", "interpretationGuidance": "Watch the drift between `hr.total_headcount` and effectiveFTE — divergence indicates contractor expansion that may warrant a build-vs-rent conversation. CostPerFTE materially above stage-typical comp benchmarks suggests either a senior-heavy mix or contractor-rate premium creep (industry folk-wisdom, not citation-grade — varies by geography and role mix).", "relatedKpiIds": [ "hr.total_headcount", "hr.total_contractors", "hr.payroll_run_rate", "hr.arr_per_fte", "hr.payroll_as_pct_of_burn" ] }, { "rogueId": "hr.headcount_change", "slug": "headcount_change", "domain": "hr", "defaultLabel": "Net Headcount Change", "description": "Net change in employee headcount during the period — new hires minus (voluntary exits + terminations). The bottom-line growth-or-contraction number on the HR scorecard. Common pitfall: reporting net change without showing the gross-in / gross-out components — boards can't diagnose a flat net number caused by 5 hires and 5 exits the same way they'd diagnose a flat number from zero on each side. Best practice is to surface the four components (new hires, voluntary exits, terminations, net change) together.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "preSeed": "recommended", "seed": "recommended", "seriesA": "core", "seriesB": "core", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "Net Headcount Change = `hr.new_hires` − (`hr.voluntary_exits` + `hr.terminations`). Sign convention: positive = growth, negative = contraction. Does not include contractor changes (those flow through `hr.total_contractors`).", "whyItMatters": "Single-number summary of HR's execution in the period and the simplest reconciliation point between this period's `hr.total_headcount` and the prior period's. Variance from `hr.hiring_plan` is the board-conversation trigger.", "interpretationGuidance": "Pair with the gross flows for diagnosis. A small positive net with high gross-in and gross-out tells a churn story; a large positive net during contraction periods raises plan-discipline questions. Compare to `hr.approved_headcount_budget` for budget-vs-actual posture.", "relatedKpiIds": [ "hr.new_hires", "hr.voluntary_exits", "hr.terminations", "hr.total_headcount", "hr.approved_headcount_budget" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "hr.hiring_plan", "slug": "hiring_plan", "domain": "hr", "defaultLabel": "Hiring Plan", "description": "Forward-looking narrative on next-period hiring priorities — target roles, sequence, sourcing strategy, and any unusual asks (executive search, specialized recruiter spend, location flexibility shifts). Anchors the board's understanding of where capacity is heading and what approvals or help are needed. Common pitfall: a stale plan that gets copy-pasted across quarters — the hiring plan should evolve with strategy shifts. Best practice is to lead with the 2–3 highest-priority hires and their justification, then a brief on backfills and bench-builds.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "preSeed": "recommended", "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 }, "whyItMatters": "Converts `hr.approved_headcount_budget` (a number) into a board-relevant sequence (a story). Without this, board members lack the context to help with intros, validate strategic-role timing, or push back on questionable role specs.", "interpretationGuidance": "Strong plans name specific roles, target start dates, and what board help would accelerate the hire. Pair with `hr.key_openings` for the structured priority list — narrative here, table there.", "relatedKpiIds": [ "hr.approved_headcount_budget", "hr.open_positions", "hr.key_openings", "hr.avg_days_to_fill", "hr.new_hires" ] }, { "rogueId": "hr.involuntary_turnover_rate", "slug": "involuntary_turnover_rate", "domain": "hr", "defaultLabel": "Involuntary Turnover Rate", "description": "Annualized rate of company-initiated separations as a percentage of average headcount. Complement to `hr.voluntary_turnover_rate`; together they form the total turnover picture per the Mercer US Turnover Survey methodology. Common pitfall: lumping one-time RIFs into the steady-state rate, which makes the trend unreadable. Best practice is to report steady-state involuntary turnover and call out any RIF events separately in `hr.board_actions` with the headcount delta.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "published", "sourceName": "Mercer US Turnover Survey 2025", "sourceUrl": "https://www.imercer.com/articleinsights/workforce-turnover-trends", "sectionRef": "Involuntary Turnover", "publicationDate": "2025-03-01", "attributionNotice": null }, "formula": "Involuntary Turnover Rate (annualized) = (Terminations in period / Average Headcount in period) × (12 / months in period) × 100. Convention: exclude announced RIF events from the steady-state series; report them separately with headcount delta. Per Mercer US Turnover Survey methodology.", "whyItMatters": "A read on performance-management cadence and any active restructuring. Sustained near-zero raises questions about management discipline; sustained-elevated raises questions about hiring quality or strategy thrash.", "interpretationGuidance": "US all-industry total turnover historically clusters in the 18–25% annualized range per Mercer US Turnover Survey 2025 (§Total Turnover); involuntary typically represents 4–8% of that total (verify exact splits against the cited report — distributions vary by industry). Companies with very low involuntary rates (<2% annualized) often have buried under-performers; companies above ~8% steady-state typically have a hiring or onboarding-quality issue (industry folk-wisdom on the upper bound, not citation-grade).", "relatedKpiIds": [ "hr.terminations", "hr.performance_watch_count", "hr.voluntary_turnover_rate", "hr.talent_challenges" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "hr.key_hires", "slug": "key_hires", "domain": "hr", "defaultLabel": "Key Hires", "description": "Field-array of notable individual hires that warrant board-level visibility — typically C-1 executives, director-level functional leaders, and strategic specialist hires. Per-item shape: name, level, role, start status, days-to-fill. Rendered via the T2 collapsible-card gallery pattern. Structural, not numeric — formula does not apply. Common pitfall: listing every hire instead of the strategic few — boards lose signal quickly when this section turns into a directory.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "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 }, "whyItMatters": "Gives the board context for the headline `hr.new_hires` count — five generalist engineers reads very differently from five senior staff engineers plus a new VP Eng. Boards routinely volunteer reference checks and network help when key hires are surfaced.", "interpretationGuidance": "Keep this list short (typically 3–8 items per board period). Each entry should be defensibly \"board-relevant\" — strategic role, executive level, or a market-significant external hire. Tie related items to `hr.talent_highlights` narrative where additional context is warranted.", "relatedKpiIds": [ "hr.new_hires", "hr.avg_days_to_fill", "hr.talent_highlights", "hr.key_openings", "hr.leader_status" ] }, { "rogueId": "hr.key_openings", "slug": "key_openings", "domain": "hr", "defaultLabel": "Key Openings", "description": "Field-array of priority open roles the board should be aware of and may be able to accelerate — typically C-1 executives, hard-to-fill specialists, and any role open >60 days. Per-item shape: title, department, level, urgency, owner. Rendered via the T2 collapsible-card gallery pattern. Structural, not numeric. Common pitfall: padding the list with every open req — boards add the most value on the 3–8 strategic openings, not on backfilling the next IC.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "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 }, "whyItMatters": "Turns the scalar `hr.open_positions` count into board-actionable context. Every entry is an opportunity for the board to help with intros, references, or compensation reality-checks. The owner field also surfaces accountability for the search.", "interpretationGuidance": "Items should name the role, the owner (recruiter or hiring manager), days open, and the ask (intros / references / approval for higher comp band). A role open >90 days without a board narrative or escalation usually signals either insufficient executive attention or unrealistic specifications.", "relatedKpiIds": [ "hr.open_positions", "hr.avg_days_to_fill", "hr.hiring_plan", "hr.key_hires", "hr.leader_status", "hr.talent_challenges" ] }, { "rogueId": "hr.leader_status", "slug": "leader_status", "domain": "hr", "defaultLabel": "Leader Status", "description": "Tri-state leader status (permanent / interim / vacant) for each board-tracked department. Permanent shows name+title; interim shows the covering person; vacant shows the gap explicitly. The single most board-relevant org-design signal — an extended interim or vacant status in a strategic function is almost always a board-level concern. Common pitfall: leaving \"interim\" indefinitely as a way to avoid the search-and-hire conversation — boards should set a maximum interim duration and treat overruns as board-action items. Structural KPI; no formula.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "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 }, "whyItMatters": "Leader-coverage gaps in strategic functions (e.g., engineering, sales, product) are leading indicators of execution risk. Boards routinely under-weight this signal because the headcount number can look healthy while the leadership layer is hollow.", "interpretationGuidance": "Interim status sustained >90 days warrants a board narrative on the search; vacant status in a board-relevant function is a board-action item on day one. Pair with `hr.key_openings` for the structured search-status view and `hr.talent_challenges` for narrative on the search difficulty.", "relatedKpiIds": [ "hr.departments", "hr.key_openings", "hr.talent_challenges", "hr.board_actions" ] }, { "rogueId": "hr.new_hires", "slug": "new_hires", "domain": "hr", "defaultLabel": "New Hires", "description": "Count of employees whose first day fell within the reporting period. The growth-input side of the headcount equation, paired with `hr.voluntary_exits` and `hr.terminations` on the loss side. Common pitfall: counting accepted offers vs actual start dates — these can diverge by weeks (notice period) or fall through entirely (offer rescind, candidate ghosting). The board number should be actual starts, not signed offers; pipeline movement belongs in `hr.hiring_plan` narrative.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "preSeed": "recommended", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "Count of employees whose official start date is within the reporting period. Exclude rehires within 90 days (boomerangs) from this count if the board has adopted that convention; otherwise include and note in `hr.talent_highlights`.", "whyItMatters": "Directly drives `hr.headcount_change` and validates execution against `hr.hiring_plan`. Persistent gaps between hiring-plan targets and actual new hires usually indicate either a pipeline problem or compensation-market mismatch — both board-action triggers.", "interpretationGuidance": "Reconcile against `hr.open_positions` closed in period and against `hr.hiring_plan` targets. A new-hire count materially below plan (e.g. <70% of target for two consecutive periods) typically warrants a board conversation about recruiting capacity, comp band competitiveness, or scope realism (industry folk-wisdom, not citation-grade).", "relatedKpiIds": [ "hr.open_positions", "hr.hiring_plan", "hr.headcount_change", "hr.avg_days_to_fill", "hr.key_hires", "hr.total_headcount" ], "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "hr.open_positions", "slug": "open_positions", "domain": "hr", "defaultLabel": "Open Positions", "description": "Count of board-approved roles that are currently posted and unfilled (requisition open, offer not yet accepted). The leading-edge indicator for upcoming hiring capacity demand. Common pitfall: \"approved\" drift — roles that were verbally green-lit but never went through the approval gate get counted here, inflating the number. The board number should match the approved headcount budget; everything else belongs in narrative as \"pipeline ideas.\"", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "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 }, "formula": "Count of requisitions where status = open AND approval = granted AND no candidate has accepted. Excludes positions filled but not yet started (those belong to `hr.new_hires` in the next period). Excludes role ideas not yet approved.", "whyItMatters": "Quantifies the hiring debt — every open role is unrealized capacity. Combined with `hr.avg_days_to_fill`, it projects when capacity actually arrives. A growing open-position count while time-to-fill stretches is a recruiting-capacity yellow flag.", "interpretationGuidance": "Open positions ÷ approved budget gap = recruiting load. If open positions exceed 15–20% of total headcount sustained over multiple periods, it usually signals either compensation issues, recruiter capacity issues, or unrealistic role specs (industry folk-wisdom, not citation-grade). Tie to `hr.key_openings` for priority-weighted context.", "relatedKpiIds": [ "hr.approved_headcount_budget", "hr.avg_days_to_fill", "hr.hiring_plan", "hr.key_openings", "hr.new_hires" ], "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "hr.payroll_as_pct_of_burn", "slug": "payroll_as_pct_of_burn", "domain": "hr", "defaultLabel": "Payroll as % of Burn", "description": "Monthly fully-loaded payroll cost as a percentage of `finance.gross_burn_rate`. Tells the board what share of cash outflow funds people vs everything else (infra, GTM spend, professional services, facilities). Common pitfall: comparing this ratio across companies without normalizing for stage and capex intensity — a pure-software seed company will run very payroll-heavy; a hardware-or-bio company will not. Best practice is to read this in conjunction with the burn-rate trend, not in isolation.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "HR" ], "stageRelevance": { "preSeed": "recommended", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null }, "formula": "Payroll as % of Burn = (Monthly payroll run rate from `hr.payroll_run_rate` / 12) / `finance.gross_burn_rate` × 100. Use gross burn (not net) so growing revenue does not distort the share. Document any non-cash comp adjustments (e.g., stock-based comp included vs excluded).", "whyItMatters": "Cost-structure shape indicator — pairs naturally with runway math. A rising share without rising headcount can signal comp-band drift; a falling share with rising headcount often signals contractor / GTM expansion. Boards use this for the people-vs-program trade-off conversation.", "interpretationGuidance": "Early-stage pure-software companies often run 60–75% payroll-of-burn (people-heavy by design); later-stage companies with material GTM spend typically run 40–55%; hardware-heavy or bio-tech companies can run lower still (industry folk-wisdom, not citation-grade — varies materially by business model). Sudden drops without a hiring freeze or program-spend spike are usually accounting reclassifications, not real economics.", "relatedKpiIds": [ "hr.payroll_run_rate", "finance.gross_burn_rate", "finance.net_burn_rate", "hr.total_headcount", "hr.arr_per_fte" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "hr.payroll_run_rate", "slug": "payroll_run_rate", "domain": "hr", "defaultLabel": "Payroll Run Rate", "description": "Annualized fully-loaded payroll cost based on current employee compensation — wages plus employer-paid taxes, benefits, and typical equity refresh allocation. Used as the dominant input into `hr.payroll_as_pct_of_burn` and the projection for `hr.fte_metrics`. Common pitfall: reporting base-salary-only and missing employer payroll taxes, benefits, and bonus accrual — this can understate true cost by 15–30%. Document the loading convention (typically wages × 1.20–1.30 for US fully-loaded) and apply consistently.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR", "Finance" ], "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 }, "formula": "Payroll Run Rate = Σ(employee fully-loaded annual comp). Fully-loaded ≈ base + bonus + employer taxes (Social Security, Medicare, FUTA, SUTA) + benefits (health, dental, 401k match) + equity refresh accrual. US-typical loading factor 1.20–1.30× base; international varies materially by country.", "whyItMatters": "The single largest line in most operating budgets — drives runway calculus, dilution sensitivity at fundraise, and the unit economics conversation. Visible upward steps without a corresponding revenue or headcount-plan justification are board-action triggers.", "interpretationGuidance": "Trend month-over-month; flag step-changes >5% that are not attributable to net new hires or planned comp cycles. Compare against `hr.approved_headcount_budget` × stage-typical avg comp (industry folk-wisdom, not citation-grade) to surface comp-band drift.", "relatedKpiIds": [ "hr.payroll_as_pct_of_burn", "hr.fte_metrics", "hr.total_headcount", "hr.arr_per_fte", "finance.gross_burn_rate" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "computed" } }, { "rogueId": "hr.performance_watch_count", "slug": "performance_watch_count", "domain": "hr", "defaultLabel": "Performance Watch", "description": "Count of employees currently on a formal Performance Improvement Plan (PIP) or equivalent performance-bar process. Leading indicator for `hr.terminations` — most PIPs that do not resolve with measurable improvement convert to involuntary exits within one quarter. Common pitfall: confusing PIPs with informal coaching — only employees on a written, time-bound plan with defined exit criteria should be counted here. Informal \"we need to talk\" relationships belong in the at-risk count, not this number.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "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 }, "formula": "Count of active employees on a written, time-bound Performance Improvement Plan with explicit success criteria and an end date (typically 30/60/90 days). Excludes informal coaching relationships and probationary new hires unless the new-hire is on a formal extension PIP.", "whyItMatters": "Leading indicator for `hr.terminations` and a read on management discipline — managers who avoid PIPs accumulate B-players, managers who over-use them are training-out coachable performers. The trend matters more than the snapshot.", "interpretationGuidance": "A sustained PIP count of ~1–3% of headcount typically reflects healthy performance management; near-zero suggests management avoidance; >5% sustained suggests either hiring-quality issues or unrealistic performance bars (industry folk-wisdom, not citation-grade). PIP-to-termination conversion rate (tracked privately) usually settles in the 60–80% range when the program is well-run.", "relatedKpiIds": [ "hr.terminations", "hr.involuntary_turnover_rate", "hr.at_risk_count", "hr.talent_challenges" ], "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "hr.retention_initiatives", "slug": "retention_initiatives", "domain": "hr", "defaultLabel": "Retention Initiatives", "description": "Narrative on the programs and actions in flight to retain key talent and reduce voluntary turnover — refresh grants, comp-band adjustments, manager training, career-pathing programs, and similar. The response side of the `hr.at_risk_count` and `hr.voluntary_turnover_rate` story. Common pitfall: listing perks (snacks, swag) instead of actions tied to retention drivers. Best practice is to name the initiative, the at-risk population it targets, and the leading-indicator metric you'll watch.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "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 }, "whyItMatters": "Shows the board that retention risk is being actively managed, not just measured. Initiatives without measurement plans are typically performative — pairing each initiative with a leading-indicator KPI (engagement score, manager 1:1 cadence, refresh-grant acceptance) shows operational rigor.", "interpretationGuidance": "Strong examples: equity refresh program targeting tenure-3+ engineers; manager-effectiveness training tied to attrition-by-manager data; career-laddering for senior ICs. Weak examples: generic culture/perks investments without a specific retention thesis.", "relatedKpiIds": [ "hr.voluntary_turnover_rate", "hr.at_risk_count", "hr.voluntary_exits", "hr.talent_challenges" ] }, { "rogueId": "hr.risk_items", "slug": "risk_items", "domain": "hr", "defaultLabel": "HR Risk Items", "description": "Structured field-array of board-attention items, each with type / department / action / narrative quartet (problem / impact / proposal / ask). Chip color follows boardActionNeeded: approval=red, assistance=yellow, awareness=blue. The structured-table version of `hr.board_actions` — preferred when the board has adopted the formal risk-item pattern. Common pitfall: drift toward vague \"we are working on it\" entries — strong items name a specific action with a date.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "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 }, "whyItMatters": "Forces explicit categorization of each item (approval / assistance / awareness) so the board cannot accidentally skip a decision item. The color chips make scanning faster than narrative text alone.", "interpretationGuidance": "Red chips (approval) demand a vote or formal resolution this meeting. Yellow chips (assistance) need specific board-member action (intros, references) — name the asks. Blue chips (awareness) are FYI for governance log. A standing meeting with all-blue is well-run; all-red signals a governance backlog.", "relatedKpiIds": [ "hr.board_actions", "hr.talent_challenges", "hr.retention_initiatives", "hr.executive_commentary" ] }, { "rogueId": "hr.talent_challenges", "slug": "talent_challenges", "domain": "hr", "defaultLabel": "Talent Challenges", "description": "Narrative on key hiring difficulties, attrition concerns, comp-market pressure, and market-driven talent risks that the board should weigh in on or be aware of. The \"watch this\" companion to `hr.talent_highlights`. Common pitfall: sanitizing this section to avoid uncomfortable conversations — but talent challenges are precisely where boards add the most value (warm intros, comp benchmarking, executive search). Best practice is to name the specific role, team, or risk and the ask explicitly.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "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 }, "whyItMatters": "The mechanism by which the board's network and judgment get applied to talent gaps. Numbers in `hr.voluntary_exits` and `hr.at_risk_count` show the symptom; this section names the cause and the ask.", "interpretationGuidance": "Treat each item as a problem-statement plus ask. Example structure: \"Senior PM role open 90 days; market comp drift +12% over our band; ask: board intros + comp-band re-baseline.\" Vague items signal either insufficient management attention or unwillingness to surface the issue.", "relatedKpiIds": [ "hr.voluntary_exits", "hr.at_risk_count", "hr.open_positions", "hr.avg_days_to_fill", "hr.board_actions", "hr.risk_items" ] }, { "rogueId": "hr.talent_highlights", "slug": "talent_highlights", "domain": "hr", "defaultLabel": "Talent Highlights", "description": "Free-form narrative on notable hires, promotions, internal moves, and other positive organizational developments the board should be aware of. The \"good news\" companion to `hr.talent_challenges`. Common pitfall: listing every internal move and burying the genuinely important signals (key executive hires, strategic team-build milestones). Best practice is 3–5 bulleted items per period, each tied to a board-relevant outcome or risk-it-mitigates rather than a generic celebration.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "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 }, "whyItMatters": "Gives the board context for the headline numbers — a flat headcount with a major engineering leader hired tells a different story than a flat headcount with no narrative. Also primes board members for warm-intro asks and reference checks.", "interpretationGuidance": "Quality > quantity. Items should answer \"why does the board care?\" — a senior IC promotion to manager matters because it filled a key vacancy; a generic \"we promoted 4 people\" doesn't. Pair each highlight with the role/team it impacts.", "relatedKpiIds": [ "hr.key_hires", "hr.executive_commentary", "hr.talent_challenges", "hr.new_hires" ] }, { "rogueId": "hr.terminations", "slug": "terminations", "domain": "hr", "defaultLabel": "Terminations", "description": "Count of company-initiated employee separations during the period — performance-management exits, layoffs, redundancies, and for-cause terminations. The numerator of `hr.involuntary_turnover_rate` and the inverse of `hr.voluntary_exits` on the attrition page. Common pitfall: bundling layoff events (often one-time, board-known) with normal performance-management churn (steady-state, manager-driven). Best practice is to break out layoffs in `hr.talent_challenges` narrative and reserve this number for the recurring stream.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "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 }, "formula": "Count of company-initiated employee separations within the reporting period — performance terminations, RIFs, role eliminations, and for-cause exits. Excludes voluntary resignations (those are `hr.voluntary_exits`) and contractor-end events.", "whyItMatters": "A direct read on performance-management cadence and any organizational restructuring activity. Spikes correlate with strategy pivots, post-fundraise rebalancing, or recovery from over-hiring — each implies different board narratives.", "interpretationGuidance": "Sustained termination volume above ~1% of headcount per month (excluding announced RIFs) typically signals hiring-quality issues, performance-bar drift, or comp-band misfit (industry folk-wisdom, not citation-grade). One-time RIF events should be reported separately in `hr.board_actions` with the headcount delta noted.", "relatedKpiIds": [ "hr.involuntary_turnover_rate", "hr.performance_watch_count", "hr.headcount_change", "hr.talent_challenges", "hr.board_actions" ], "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "hr.total_contractors", "slug": "total_contractors", "domain": "hr", "defaultLabel": "Total Contractors", "description": "Count of active 1099 contractors, consultants, agencies-of-record, and similar non-employee labor at period end. Tracked separately from `hr.total_headcount` because the cost structure, retention dynamics, and classification risk are different. Common pitfall: under-counting agencies that bill on a project basis without per-head visibility — these often slip out of HR systems and surface only in finance AP detail. A contractor-to-FTE ratio above ~30% sustained typically warrants a classification audit and a deliberate \"build vs rent\" board conversation.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "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 }, "formula": "Count of active non-employee workers (1099 contractors, agency contractors, consultants) with engagement status = active at period end. Convert to FTE-equivalent in `hr.fte_metrics` using a contractor-to-FTE factor (e.g., 0.8) if applying to capacity math.", "whyItMatters": "Hidden capacity and hidden cost — contractors expand effective capacity without going through the headcount-approval gate, but they carry classification risk and tend to convert into permanent cost without explicit board approval. Surfacing the count counters that quiet expansion.", "interpretationGuidance": "Contractor share of total workforce above ~30% sustained signals either a hiring-gate workaround or a deliberate flex-staffing strategy — both warrant a narrative explanation. Under US IRS rules and similar in other jurisdictions, sustained \"contractors\" working full-time under direction risk reclassification (industry folk-wisdom on the 30% threshold, not citation-grade).", "relatedKpiIds": [ "hr.total_headcount", "hr.fte_metrics", "hr.hiring_plan", "hr.payroll_run_rate" ], "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "hr.total_headcount", "slug": "total_headcount", "domain": "hr", "defaultLabel": "Total Headcount", "description": "Total number of employees (W-2 / direct-employment equivalents) across all departments at period end. The base denominator for nearly every other HR ratio — turnover rate, revenue per FTE, payroll as % of burn — so getting the snapshot date and the FTE-vs-headcount convention right matters. Common pitfall: mixing headcount (people) with FTE (capacity) — they diverge whenever part-time, contractor, or shared-services arrangements exist. Document the convention (typically \"FTE-equivalent, employees only, end-of-period\") at the board level once and apply consistently.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "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 }, "formula": "Count of active employees at period end. Convention: FTE-equivalent (a 0.5 FTE counts as 0.5), employees only (contractors tracked separately in `hr.total_contractors`). Snapshot is end-of-period unless the board has explicitly adopted an average-headcount convention for ratio math.", "whyItMatters": "The denominator for every HR ratio the board reads — turnover %, revenue/FTE, payroll as % of burn. Drift in this number without a corresponding hiring-plan update is a leading signal of unmanaged growth or quiet attrition.", "interpretationGuidance": "Compare quarter-over-quarter against the approved headcount budget (`hr.approved_headcount_budget`). A delta above ±5% without a board note typically warrants explanation. Stage norm for SaaS (industry folk-wisdom, not citation-grade): seed 5–15, Series A 20–50, Series B 50–150, Series C 150–400.", "relatedKpiIds": [ "hr.headcount_change", "hr.approved_headcount_budget", "hr.new_hires", "hr.voluntary_exits", "hr.terminations", "hr.total_contractors", "hr.arr_per_fte" ], "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "hr.voluntary_exits", "slug": "voluntary_exits", "domain": "hr", "defaultLabel": "Voluntary Exits", "description": "Count of employees who resigned during the period (initiated by employee, not the company). The numerator of the `hr.voluntary_turnover_rate` calculation and the headline \"are we losing people\" number boards anchor on. Common pitfall: ambiguous \"mutually agreed\" exits — companies sometimes log managed-out exits as voluntary to keep the visible number low. Define the test: if the employee initiated the conversation and there was no formal performance trigger, it is voluntary; otherwise log as termination.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "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 }, "formula": "Count of employees with employee-initiated separations (resignations, retirements) during the period. Excludes terminations (those go in `hr.terminations`), exclusions for cause, and contractor-end events.", "whyItMatters": "The leading indicator the board reads for retention health and culture risk. Concentration in a single team, level, or tenure cohort is more informative than the absolute number — investigate the pattern, not just the headline.", "interpretationGuidance": "Convert to `hr.voluntary_turnover_rate` (annualized %) for cross-period comparison and benchmarking. Spike triggers: 3+ voluntary exits from one team in a quarter, or any C-1 (executive direct-report) departure — both warrant board narrative in `hr.talent_challenges`.", "relatedKpiIds": [ "hr.voluntary_turnover_rate", "hr.at_risk_count", "hr.retention_initiatives", "hr.talent_challenges", "hr.total_headcount" ], "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "hr.voluntary_turnover_rate", "slug": "voluntary_turnover_rate", "domain": "hr", "defaultLabel": "Voluntary Turnover Rate", "description": "Voluntary exits over a trailing period, expressed as an annualized percentage of average headcount — the headline attrition number on the HR scorecard. Anchored to the Mercer US Turnover Survey methodology (Mercer reports voluntary vs involuntary turnover annually). Common pitfall: comparing a single quarter's annualized rate against an annual benchmark — short-window annualization is noisy. Best practice is trailing-12-months for benchmark comparison and trailing-3 or trailing-6 for trend reads. Per #1426: stage-specific industry norms here are folk-wisdom unless tied to a specific Mercer or comparable published cut.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "Mercer US Turnover Survey 2025", "sourceUrl": "https://www.imercer.com/articleinsights/workforce-turnover-trends", "sectionRef": "Voluntary Turnover", "publicationDate": "2025-03-01", "attributionNotice": null }, "benchmark": { "p25": 7, "median": 11, "p75": 17, "unit": "%", "sourceName": "Mercer US Turnover Survey 2025", "sourceYear": "2025", "higherIsBetter": false }, "formula": "Voluntary Turnover Rate (annualized) = (Voluntary Exits in period / Average Headcount in period) × (12 / months in period) × 100. Average headcount = (start headcount + end headcount) / 2 is the simplest acceptable convention; (Σ daily headcount / days in period) is more precise. Per Mercer US Turnover Survey methodology.", "whyItMatters": "The canonical retention KPI investors and boards benchmark against. Tracks the cost of churn — every voluntary exit triggers a replacement-cost cycle (recruiting + onboarding + ramp), commonly estimated at 0.5–2× the role's annual salary depending on level (industry folk-wisdom, not citation-grade).", "interpretationGuidance": "US all-industry voluntary turnover is typically 13–17% annualized per Mercer US Turnover Survey 2025 (§Voluntary Turnover). Tech sector typically runs higher than the all-industry average; engineering and sales roles run highest within tech. Sustained voluntary turnover above ~20% annualized at any stage is a board-action trigger; sustained sub-5% can indicate under-performance management (managers not exiting B-players). Compare trailing-12-month rates, not quarterly snapshots.", "relatedKpiIds": [ "hr.voluntary_exits", "hr.involuntary_turnover_rate", "hr.at_risk_count", "hr.retention_initiatives", "hr.talent_challenges" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "operations.rule_of_40", "slug": "rule_of_40", "domain": "operations", "defaultLabel": "Rule of 40", "description": "Composite SaaS health score that sums the company's revenue growth rate and a profitability proxy (commonly EBITDA margin or free-cash-flow margin) into a single percentage. Originally articulated by Brad Feld in 2015 and codified by the SaaS Metrics Standards Board, the rule frames the growth-vs-profitability tradeoff: a company growing at 60% with a −20% margin scores 40, equal to a company growing at 20% with a +20% margin. The board reads it to sanity-check whether growth is being bought at unhealthy burn or whether margin discipline is constraining growth too far. Common pitfall: which profitability proxy is used materially changes the score (FCF margin is the strictest, EBITDA more flattering, \"operating margin\" inconsistently defined), so pick one and disclose it next to the number.", "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": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/rule-of-40", "sectionRef": "Rule of 40", "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." }, "benchmark": { "p25": -4, "median": 15, "p75": 31, "unit": "%", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceYear": "2024", "higherIsBetter": true }, "formula": "Rule of 40 = revenue_growth_rate (%) + profitability_margin (%). Per SMSB, `revenue_growth_rate` is typically YoY ARR or revenue growth; `profitability_margin` is typically EBITDA margin or FCF margin (disclose which). Both inputs are percentages — the output is also a percentage and can be negative when negative margin overwhelms growth.", "whyItMatters": "Single-number readout of the growth-vs-burn tradeoff. Lets the board compare a high-growth / high-burn company to a slow-growth / profitable one on one axis, and surfaces unhealthy growth (high growth paid for with margin much worse than negative growth-rate offset).", "interpretationGuidance": "Per the rule as originally framed by Brad Feld (2015) and the SaaS Metrics Standards Board, a score at or above 40% is the canonical \"healthy\" threshold for growth-stage SaaS; below 40% signals either growth or margin is under-delivering. Finer stratifications often cited (>50% strong, >60% best-in-class) are industry folk-wisdom, not citation-grade. Always disclose which profitability proxy is used — comparing an EBITDA-margin Rule of 40 to an FCF-margin Rule of 40 is apples-to-oranges and a frequent board-deck error.", "relatedKpiIds": [ "sales.growth_rate_yoy", "sales.gross_margin", "finance.net_burn_rate", "finance.runway_months" ], "calculationPolicy": { "inclusionRules": [ "Sum two percentages: revenue growth rate + profitability margin.", "Growth rate: YoY ARR or YoY recognized-revenue growth (pick one, disclose which — they diverge for sub-scale companies).", "Profitability margin: EBITDA margin OR free-cash-flow margin OR operating margin — pick one, disclose which.", "Both inputs and the output are percentages; the output can be negative." ], "exclusionRules": [ "Do not mix metric bases across the two terms (e.g. ARR-growth + GAAP-operating-margin is acceptable only if both are disclosed; never silently swap proxies between periods).", "Do not annualize a quarterly growth figure by ×4 for this — use a true YoY growth rate." ], "requiredInputs": [ "Revenue (or ARR) growth rate, YoY.", "Profitability margin for the same period.", "Disclosure of WHICH growth basis and WHICH margin proxy were used." ], "dataSourcePriority": [ "`sales.growth_rate_yoy` for the growth term.", "Audited / reviewed financials for the margin term." ], "edgeCases": [ "Margin-proxy choice materially changes the score: FCF margin is strictest, EBITDA more flattering, \"operating margin\" inconsistently defined. The same company can score 35 or 45 depending on the proxy — always disclose.", "Pre-revenue or near-zero-revenue company: Rule of 40 is not meaningful; report N/A rather than a wild number.", "Heavily seasonal business: use trailing-twelve-month figures for both terms so a single quarter does not distort the score.", "One-off items in the margin (litigation settlement, restructuring): present a \"normalized\" Rule of 40 alongside the headline." ], "validationChecks": [ "Rule of 40 = growth% + margin% — recompute and verify against any pre-computed value.", "If the score looks implausibly high (> 80) or low (< −40), check whether the growth rate was QoQ-annualized or whether the margin proxy is mis-signed.", "The growth term should reconcile with `sales.growth_rate_yoy`; the margin term should reconcile with the income statement." ], "commonMiscomputations": [ "Switching the profitability proxy between periods (EBITDA one quarter, FCF the next) — the trend then reflects bookkeeping, not the business.", "Comparing one company's EBITDA-margin Rule of 40 to another's FCF-margin Rule of 40 — apples to oranges; the most frequent board-deck error.", "Using QoQ growth ×4 instead of true YoY growth — overstates the growth term for any company with momentum or seasonality.", "Adding gross margin instead of a profitability margin — gross margin is ~70-80% for SaaS, so the score balloons past 100 and becomes meaningless.", "Sign error on a negative margin — adding +20 instead of −20 flips an unhealthy company into a healthy-looking score." ] }, "metricBasis": { "timeBasis": "trailing_window", "production": "computed" } }, { "rogueId": "product.capacity_allocation_pct", "slug": "capacity_allocation_pct", "domain": "product", "defaultLabel": "Capacity Allocation", "description": "Breakdown of engineering capacity across new features, maintenance, and tech debt — typically reported as a three-way split summing to 100%. The execution-level view of where engineering hours are actually going (vs. `innovation_capacity_pct` which is a single percentage for new-capabilities work, and vs. `offensive_roadmap_pct` which is a roadmap-classification percentage). Common pitfall: capacity allocation reported in plan rather than actuals. The plan can say 60% new features but the actuals can be 30% new features and 50% support work — the gap is the operating signal. Boards should require both planned and actual splits, at least quarterly.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product" ], "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 }, "formula": "Three-way breakdown: new_features_pct + maintenance_pct + tech_debt_pct = 100%. Measured in the same unit as capacity (eng-weeks, story points, or sprint capacity). Report planned vs actual split — the gap is the operational signal.", "whyItMatters": "Names where engineering hours actually go. The plan-versus-actual gap is one of the highest-signal operational metrics for the board — a persistent 20+ point gap between planned and actual new-feature allocation is the loudest possible flag that the company is under-investing in platform health (the missing hours are going to firefighting).", "interpretationGuidance": "Industry folk-wisdom, not citation-grade: a healthy steady-state split at growth-stage SaaS is roughly 50–70% new features, 15–30% maintenance, 10–20% tech debt. Companies in platform-investment cycles will skew toward maintenance and tech debt. Pair with `innovation_capacity_pct` and `delivery_predictability` — capacity allocation tells you where time goes, predictability tells you whether commitments hold, innovation capacity tells you the available headroom for offense.", "relatedKpiIds": [ "product.innovation_capacity_pct", "product.offensive_roadmap_pct", "product.defensive_roadmap_pct", "product.delivery_predictability", "product.total_engineers" ], "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "product.defensive_roadmap_pct", "slug": "defensive_roadmap_pct", "domain": "product", "defaultLabel": "Revenue Protection %", "description": "Percentage of the planned roadmap allocated to defensive work — platform reliability, security/compliance, scalability rearchitecture, table-stakes parity with competitors, customer-retention features. The complement of `offensive_roadmap_pct`. Common pitfall: defensive work is chronically under-funded (less visible to customers, harder to demo) until a quality-churn or scalability event forces a reactive surge. Boards should treat sustained zero or near-zero defensive allocation in a maturing product as a leading indicator of future quality issues — per the standard product-management argument (Marty Cagan and similar product-leadership writing), a healthy roadmap pays both growth and platform-health rent.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product" ], "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 }, "formula": "defensive_roadmap_pct = (roadmap_capacity_allocated_to_defensive_initiatives / total_roadmap_capacity) × 100, where \"defensive\" includes reliability, security, compliance, scalability, parity, retention features, and tech-debt paydown. Complement of `offensive_roadmap_pct` (they sum to ~100% in a fully-classified roadmap).", "whyItMatters": "Names the investment in not-losing alongside the investment in winning. A defensive % that responds to `quality_churn_pct` and `scalability_headroom` trends (rising when those degrade) is a sign of a healthy operating cadence; a defensive % stuck near zero while quality churn rises is a sign the board needs to push for re-prioritization.", "interpretationGuidance": "Industry folk-wisdom, not citation-grade: 20–40% defensive at growth-stage SaaS with stable platform health; 40–60% during platform-investment cycles; below 15% rarely sustainable in a maturing product. Read alongside `quality_churn_pct` — a defensive ratio that has not increased while quality churn has been rising for 2+ quarters usually warrants a board-level conversation about reprioritization.", "relatedKpiIds": [ "product.offensive_roadmap_pct", "product.innovation_capacity_pct", "product.quality_churn_pct", "product.scalability_headroom", "product.key_initiatives_status" ], "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "product.delivery_predictability", "slug": "delivery_predictability", "domain": "product", "defaultLabel": "Delivery Predictability", "description": "Percentage of committed deliverables shipped on or before the originally-promised date within a measurement window (typically a quarter). Surfaces whether the engineering organization can be trusted to hit commitments the company makes externally — to customers in contracts, to the board in quarterly plans, to GTM teams sequencing launches. Common pitfall: gaming. Teams over-deliver by under-promising (predictability climbs while velocity drops) or move the goalposts (re-baseline mid-quarter so \"on-time\" stays high). Boards should ask for \"predictability against original commitment\", not \"against current plan\", and pair with throughput trends.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "R&D", "Product" ], "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 }, "benchmark": { "p25": 55, "median": 70, "p75": 85, "unit": "%", "sourceName": "imboard Editorial", "sourceYear": "2026", "higherIsBetter": true }, "formula": "delivery_predictability_pct = (commitments_delivered_on_time / total_commitments) × 100, measured against the originally-promised date (not the most recently re-baselined date). Define \"on time\" explicitly — within the promised week, sprint, or quarter — and apply consistently.", "whyItMatters": "Predictability is the contract between engineering and the rest of the business. When it slips, GTM cannot sequence launches, sales cannot promise dates, and the board cannot trust the quarterly plan. Sustained low predictability is a leading indicator of either capacity mismatch, planning hygiene problems, or accumulated technical debt.", "interpretationGuidance": "Industry folk-wisdom, not citation-grade: 70–85% predictability is typical for healthy growth-stage engineering organizations; 90%+ usually means sandbagging (commitments are too soft); below 60% means the planning process is broken or capacity is mismatched. Trend matters more than absolute level — a stable 75% is healthier than a 90% sliding to 70% quarter-over-quarter.", "relatedKpiIds": [ "product.key_initiatives_status", "product.capacity_allocation_pct", "product.innovation_capacity_pct", "product.scalability_headroom" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "product.feature_adoption", "slug": "feature_adoption", "domain": "product", "defaultLabel": "Weighted Feature Adoption", "description": "Percentage of customers (weighted by ARR) actively using a defined set of strategic features within a measurement window. The \"ARR-weighted\" framing matters: a feature used by 30% of customers covering 70% of ARR is a different signal than 30% of customers covering 5% of ARR. Common pitfall: defining adoption as \"ever used\" rather than \"actively using\" (returning use in the measurement window) — the first metric only goes up and tells the board nothing. Boards should require an active-use definition (e.g. used in 2 of the last 4 weeks) and a per-feature breakdown for the strategic feature set.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product" ], "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 }, "benchmark": { "p25": 40, "median": 60, "p75": 75, "unit": "%", "sourceName": "imboard Editorial", "sourceYear": "2026", "higherIsBetter": true }, "formula": "weighted_feature_adoption_pct = Σ (customer_arr × is_actively_using_feature) / Σ (customer_arr) × 100, where \"actively using\" is defined explicitly (e.g. ≥2 sessions in the last 4 weeks, or domain-appropriate usage threshold). Weight by ARR — not by customer count — to surface the strategic-account signal.", "whyItMatters": "Leading indicator of product-market fit for new capabilities. Adoption that does not reach a critical mass of ARR-weighted customers within 2–3 quarters is the strongest signal that the feature is either mis-targeted, mis-priced, or hidden in the UX. Drives roadmap continue-vs-cut decisions.", "interpretationGuidance": "Industry folk-wisdom, not citation-grade: for a strategic feature, 30–50% ARR-weighted adoption within 6 months is healthy; below 20% after 6 months usually warrants a retrospective. The product-management literature (Marty Cagan, \"INSPIRED\"; Pendo / Amplitude product-analytics playbooks) consistently emphasizes the active-use definition over cumulative reach, but does not publish citation-grade numeric ranges by company stage. Always pair this with `quality_churn_pct` — high adoption that coincides with rising quality-churn means the feature is shipping pain alongside use.", "relatedKpiIds": [ "product.quality_churn_pct", "product.offensive_roadmap_pct", "product.portfolio_strategy", "sales.arr", "customers.net_revenue_retention" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "product.innovation_capacity_pct", "slug": "innovation_capacity_pct", "domain": "product", "defaultLabel": "Innovation Capacity %", "description": "Percentage of R&D capacity (typically measured in engineering-weeks or story points over a quarter) allocated to net-new capabilities, as opposed to maintenance, bug fixes, internal tooling, or customer-support engineering. The \"available bandwidth for offense\" view. Common pitfall: confusing innovation capacity (input — how much team-time is available for new work) with `offensive_roadmap_pct` (output — what proportion of the planned roadmap is growth-oriented). A team can have 60% innovation capacity allocated entirely to defensive work if the roadmap demands it. Boards should look at both together.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "R&D", "Product" ], "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 }, "formula": "innovation_capacity_pct = (engineering_capacity_on_new_capabilities / total_engineering_capacity) × 100. Define \"new capabilities\" explicitly — typically excludes bug fixes, performance work, internal tooling, support engineering, and tech-debt paydown. Measured in the same unit as capacity allocation (eng-weeks, story points, or sprint capacity).", "whyItMatters": "Surfaces structural friction. A team with only 20% innovation capacity is being eaten by maintenance and reactive work — the board should be asking why (platform debt, support load, headcount mismatch) before approving new feature commitments.", "interpretationGuidance": "Industry folk-wisdom, not citation-grade: 50–70% innovation capacity is typical for healthy growth-stage product engineering; below 40% suggests the team is operating in firefighting mode; above 80% suggests under-investment in platform health (will eventually pay back in `quality_churn_pct` and `scalability_headroom` compression). Trend matters most — a steady decline quarter-over-quarter is a leading indicator of accumulating maintenance debt.", "relatedKpiIds": [ "product.capacity_allocation_pct", "product.offensive_roadmap_pct", "product.defensive_roadmap_pct", "product.rd_efficiency", "product.delivery_predictability" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "product.key_initiatives_status", "slug": "key_initiatives_status", "domain": "product", "defaultLabel": "Key Initiatives Status", "description": "Stoplight-plus-narrative status of the strategic product initiatives committed for the current quarter / half — each initiative ideally tagged on-track / at-risk / blocked / shipped, with a one-line explanation. The execution-pulse view that connects strategy intent to delivery reality. Common pitfall: every initiative defaults to \"on track\" until two weeks before the deadline, then turns red — a board that only sees binary green-or-red status without intermediate \"at-risk\" signaling is being managed reactively. Pair with `delivery_predictability` to detect this pattern; require at-risk initiatives to surface a mitigation plan, not just a label.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product" ], "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 }, "formula": "Narrative — list of named strategic initiatives, each with (1) status (on-track / at-risk / blocked / shipped / cut), (2) one-line explanation, (3) for at-risk and blocked: a mitigation plan or escalation request.", "whyItMatters": "Connects the strategic narrative to delivery reality at the level the board can act on. Surfaces where engineering needs unblocking, where commitments are slipping, and where the strategy needs revision. The board's most efficient leverage point on the product organization.", "interpretationGuidance": "Watch for two patterns: (1) chronic \"at-risk\" without escalation — usually a sign that the team has accepted the slippage and the board is being notified, not asked for help. (2) all-green status alongside declining `delivery_predictability` — usually a sign that the status field is being optimistically managed. The right cadence: at-risk should appear early and resolve via mitigation, not by re-labeling at the deadline.", "relatedKpiIds": [ "product.delivery_predictability", "product.portfolio_strategy", "product.offensive_roadmap_pct", "product.defensive_roadmap_pct", "product.capacity_allocation_pct" ] }, { "rogueId": "product.offensive_roadmap_pct", "slug": "offensive_roadmap_pct", "domain": "product", "defaultLabel": "Growth & Differentiation %", "description": "Percentage of the planned roadmap (typically next 1–2 quarters) allocated to offensive bets — net-new capabilities, market expansion, differentiation moats, new monetization. The \"what proportion of the plan is about winning\" view. Common pitfall: counting \"improvements to existing features\" as offensive when the change is really table-stakes parity work. Boards should expect a McKinsey-style horizon framing (Horizon 1 = core, Horizon 2 = adjacent, Horizon 3 = transformational) or an equivalent classification, and apply it consistently. Per the original McKinsey \"Three Horizons\" framing (Baghai/Coley/White, \"The Alchemy of Growth\", 1999), a healthy portfolio funds all three — over-indexing on any one is a strategic risk.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product" ], "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 }, "formula": "offensive_roadmap_pct = (roadmap_capacity_allocated_to_offensive_initiatives / total_roadmap_capacity) × 100, where \"offensive\" includes net-new capabilities, market-expansion work, differentiation features, and new monetization. Complement of `defensive_roadmap_pct` (they should sum to ~100% in a fully-classified roadmap).", "whyItMatters": "Encodes the company's strategic posture in one number. Boards use this to check the roadmap against the strategy narrative — a company saying it is \"going on offense\" while showing a 30% offensive roadmap has a story-versus-execution gap worth flagging.", "interpretationGuidance": "Industry folk-wisdom, not citation-grade: 50–70% offensive in growth-stage companies pursuing market expansion; 30–50% in companies stabilizing a platform; below 30% in turnaround / harden-the-base modes. Pair with `defensive_roadmap_pct` and `innovation_capacity_pct` — strategic offense requires both intent (this metric) and available bandwidth (innovation capacity). The right number is stage-, market-, and strategy-dependent — the trend and the stated rationale matter more than the absolute level.", "relatedKpiIds": [ "product.defensive_roadmap_pct", "product.innovation_capacity_pct", "product.portfolio_strategy", "product.feature_adoption", "product.key_initiatives_status" ], "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "product.portfolio_strategy", "slug": "portfolio_strategy", "domain": "product", "defaultLabel": "Product Portfolio Strategy", "description": "Narrative overview of the product portfolio — which products are growth engines, which are cash cows, which are innovation bets, and which are candidates for sunset. The CEO/CPO articulation of \"what game each product line is playing.\" Frequently structured along the McKinsey Three Horizons framing or the classic BCG growth-share matrix (stars / cash cows / question marks / dogs — per Bruce Henderson's \"The Product Portfolio\", 1970). Common pitfall: the portfolio narrative does not name horizons, life-cycle stages, or sunset candidates — a portfolio described entirely as \"growth engines\" is not a portfolio strategy, it is a wishlist. Boards should push for explicit classification of every material product.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product" ], "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 }, "formula": "Narrative — no calculation. Should cover (1) classification of each material product (e.g. Horizon 1/2/3 or BCG matrix quadrant), (2) ARR concentration by product, (3) investment thesis per product, (4) any sunset candidates and timing, (5) cross-product synergies or cannibalization risks.", "whyItMatters": "Forces explicit articulation of the multi-product story — boards offer better strategic guidance when they understand which product is being optimized for growth vs cash vs option-value. Reveals whether the company has a portfolio strategy or just a list of products it happens to ship.", "interpretationGuidance": "A portfolio narrative that has not evolved across multiple quarterly updates while the market has shifted is a flag — the strategy is either uncontested or unmonitored. A narrative that pivots every update is also a flag — typically signals over-reactivity. Compare against `top_product_arr_concentration` — heavy concentration without an explicit portfolio-diversification thesis is a strategic risk the board should name.", "relatedKpiIds": [ "product.top_product_arr_concentration", "product.offensive_roadmap_pct", "product.defensive_roadmap_pct", "product.key_initiatives_status", "sales.arr" ] }, { "rogueId": "product.quality_churn_pct", "slug": "quality_churn_pct", "domain": "product", "defaultLabel": "Churn from Quality Issues", "description": "Percentage of customer churn (logo or ARR, define explicitly) where the primary stated reason is product or quality problems — bugs, performance, missing core functionality, reliability incidents. Distinguishes product-driven churn from pricing-driven, competitor-driven, or use-case-fit-driven churn. Common pitfall: relying on free-text exit-survey reasons. Customers commonly cite \"price\" when the underlying issue was reliability or missing features — boards should require both the customer-stated reason and the CSM/Account-Manager-assigned root cause, and watch the gap. The Pendo \"Product-Led Growth Benchmark\" and similar product-analytics publishers cover product-driven churn qualitatively, not as published numeric ranges.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "R&D", "Product" ], "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 }, "benchmark": { "p25": 5, "median": 10, "p75": 20, "unit": "%", "sourceName": "imboard Editorial", "sourceYear": "2026", "higherIsBetter": false }, "formula": "quality_churn_pct = (churn_attributable_to_quality / total_churn) × 100. Be explicit about whether the numerator and denominator are logo-churn or ARR-churn; the two can diverge sharply if quality issues hit small-customer vs strategic-account differently. Define \"attributable to quality\" explicitly (CSM root-cause assignment is more reliable than customer-stated exit reason).", "whyItMatters": "Isolates the share of revenue loss the R&D organization can directly act on. High and rising quality-churn is the loudest signal that engineering investment should shift from new-feature to platform-hardening. Low quality-churn alongside high overall churn signals the problem is GTM or product-market-fit, not engineering.", "interpretationGuidance": "Industry folk-wisdom, not citation-grade: at healthy growth-stage SaaS, quality-driven churn is typically a minority of total churn (under one-third). Quality-churn rising past 40% of total churn is a strong \"harden the platform\" signal — the board should expect a `defensive_roadmap_pct` increase in response. Cross-reference with `scalability_headroom`: a thin headroom paired with rising quality-churn usually means the company is hitting a reliability cliff.", "relatedKpiIds": [ "product.feature_adoption", "product.defensive_roadmap_pct", "product.scalability_headroom", "customers.logo_churn_rate", "customers.gross_revenue_retention" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "product.rd_efficiency", "slug": "rd_efficiency", "domain": "product", "defaultLabel": "R&D Efficiency", "description": "Ratio of net-new ARR generated in a period to R&D spend in the same period — answers \"how much revenue does each R&D dollar produce?\" Distinct from sales-efficiency metrics (Magic Number, CAC payback) which measure sales/marketing productivity. Common pitfall: R&D-driven ARR (new capabilities, expansion features) shows up on a 2–4 quarter lag after the spend — single-period ratios mis-state the relationship. Boards should look at trailing-twelve-month R&D efficiency, not month-over-month, and pair with `innovation_capacity_pct` to understand whether the spend is on growth bets or maintenance.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "R&D" ], "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 }, "benchmark": { "p25": 0.15, "median": 0.27, "p75": 0.4, "unit": "ratio", "sourceName": "imboard Editorial", "sourceYear": "2026", "higherIsBetter": true }, "formula": "rd_efficiency = net_new_arr_in_period / rd_monthly_spend_in_period. Best computed on a trailing-twelve-month basis to absorb the spend-to-revenue lag. Note: not the same as \"R&D ROI\" (which would deduct R&D cost from revenue); this is a velocity ratio, not a profitability ratio.", "whyItMatters": "Highest-leverage indicator of whether R&D investment is converting into revenue. A persistent decline signals either an over-built team relative to demand, a feature-product fit gap, or accumulated tech debt slowing throughput — each prescribes different board action.", "interpretationGuidance": "No single published benchmark applies across stages and business models. Industry folk-wisdom, not citation-grade: at growth-stage SaaS, $1 of R&D spend producing $1–2 of net-new ARR is healthy; below $0.5 is a flag; above $3 typically signals either underinvestment in R&D (about to hit a velocity wall) or a one-time price-increase boost. Always pair with `quality_churn_pct` — high efficiency with rising quality-churn means the ratio is borrowing from future periods.", "relatedKpiIds": [ "product.rd_monthly_spend", "product.total_engineers", "product.innovation_capacity_pct", "product.quality_churn_pct", "sales.arr" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "product.rd_monthly_spend", "slug": "rd_monthly_spend", "domain": "product", "defaultLabel": "R&D Monthly Spend", "description": "Total monthly cash outflow on research and development — fully-loaded engineering, product, and design payroll plus tooling, infrastructure dedicated to product development, contractors, and direct R&D vendor spend. The \"input\" side of R&D efficiency. Common pitfall: companies report base-payroll R&D and exclude the loaded cost (benefits, stock comp at cash-cost basis, allocated rent, dev tooling), under-reporting true R&D burn by 25–40%. Boards should always ask whether the number is base-payroll, fully-loaded, or GAAP R&D expense — they tell different stories. The KBCM/Sapphire SaaS Survey reports R&D as a percentage of revenue for its company panel — use that as the benchmarking lens.", "fieldType": "currency", "unit": "/month", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "R&D", "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": "R&D as % of Revenue (capital-allocation section)", "publicationDate": "2024-09-01", "attributionNotice": null }, "formula": "Sum of fully-loaded R&D-team payroll + benefits + allocated stock-comp + R&D-dedicated infrastructure + R&D tooling + R&D vendor spend, expressed as a monthly figure. Different from GAAP R&D expense (which capitalizes some software development costs); footnote the convention.", "whyItMatters": "Largest single line of operating spend at most growth-stage SaaS companies — the input that `rd_efficiency` converts into revenue. The board reads this to gauge whether the company is over- or under-investing in product velocity relative to revenue ramp.", "interpretationGuidance": "Compare R&D spend to revenue (or ARR run-rate) to derive R&D-as-% of revenue. Per the KBCM/Sapphire SaaS Survey (latest annual edition — see capital-allocation section), median R&D-as-% of revenue runs ~25–35% at early-growth SaaS and compresses with scale. Out-of-band (e.g. 60%+ at a $20M ARR company) usually signals either heavy platform-investment cycles or under-monetization — flag for context. Always pull the current KBCM/Sapphire edition rather than relying on a memorized range.", "relatedKpiIds": [ "product.rd_efficiency", "product.total_engineers", "product.innovation_capacity_pct", "sales.arr", "finance.net_burn_rate" ], "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "product.scalability_headroom", "slug": "scalability_headroom", "domain": "product", "defaultLabel": "Time to Capacity Limit", "description": "Months of system capacity remaining at the current growth rate before the platform requires major (not incremental) infrastructure investment — typically driven by the binding bottleneck (database, message bus, single-tenant compute ceiling, regional capacity, or compliance-driven re-architecture). Surfaces the \"scale runway\" alongside the financial runway. Common pitfall: a single number hides which bottleneck binds. Boards should require the bottleneck to be named (\"database shard hot-spot binds at ~150K accounts at current growth, ~4 months out\"), not just the headline months — a named bottleneck makes the investment decision concrete.", "fieldType": "number", "unit": "months", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "R&D" ], "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 }, "benchmark": { "p25": 4, "median": 9, "p75": 18, "unit": "months", "sourceName": "imboard Editorial", "sourceYear": "2026", "higherIsBetter": true }, "formula": "Engineering-attested estimate: months_until_binding_bottleneck_at_current_growth_rate. Recompute when growth-rate assumption changes or when capacity work lands. Always surface the binding bottleneck name alongside the months number — `12 months (database write throughput)` not just `12`.", "whyItMatters": "Sequences major infrastructure work against revenue growth. A 6-month scalability headroom against a 9-month financial runway is a foreseeable crisis the board should be addressing now. Pairs naturally with `defensive_roadmap_pct` (which funds the work).", "interpretationGuidance": "Industry folk-wisdom, not citation-grade: 12+ months of headroom is comfortable; 6–12 months means the rearchitecture project should be in flight; under 6 months means the project is critical-path and may already be late. Compare against `finance.runway_months` — financial runway shorter than scalability headroom means the company will hit the cash wall first; the inverse means the company will hit the scale wall first and should be planning the rearchitecture into the current operating plan.", "relatedKpiIds": [ "product.defensive_roadmap_pct", "product.capacity_allocation_pct", "product.quality_churn_pct", "finance.runway_months", "sales.growth_rate_yoy" ], "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "product.top_product_arr_concentration", "slug": "top_product_arr_concentration", "domain": "product", "defaultLabel": "Top Product ARR Concentration", "description": "Percentage of total ARR contributed by the single largest product line. Diversification-risk indicator at the product level (parallel to customer-concentration risk at the GTM level). Common pitfall: concentration risk is dismissed when the dominant product is performing well — but a one-product company is a one-feature-decision-away from existential risk. Boards should track this number alongside the portfolio narrative; sustained 70%+ concentration in a maturing company should pair with a documented diversification thesis or an explicit decision to remain a single-product company. Frames analogous to customer-concentration discussions in venture diligence (NfX / Bessemer founder essays cover the customer-side; the product-side analogue follows the same logic).", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product", "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 }, "formula": "top_product_arr_concentration_pct = (arr_from_largest_product / total_arr) × 100. Define \"product\" explicitly — a SKU, a billable module, or a packaging unit — and hold the definition stable. Surface both the percentage and the named top product.", "whyItMatters": "Quantifies single-point-of-failure risk in the product portfolio. The board reads this alongside `portfolio_strategy` to assess whether the company has a real second product or is effectively still single-SKU. Drives both strategic (build / buy / partner for diversification) and financial (valuation framing) conversations.", "interpretationGuidance": "Industry folk-wisdom, not citation-grade: concentration of 60–80% in the flagship product is common at early-growth multi-product SaaS; sustained 90%+ should be paired with an explicit single-product-strategy thesis or a documented diversification plan. The trend matters most — concentration falling from 95% to 70% over 4–6 quarters signals successful diversification; rising concentration during a multi-product strategy is a flag the secondary products are underperforming.", "relatedKpiIds": [ "product.portfolio_strategy", "product.offensive_roadmap_pct", "sales.arr", "customers.gross_revenue_retention" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "product.total_engineers", "slug": "total_engineers", "domain": "product", "defaultLabel": "Total Engineers", "description": "Headcount of engineers (software, infrastructure, security, data, ML) in the R&D organization, typically including full-time employees plus contractors at a defined FTE-equivalence factor. The \"capacity input\" side of all R&D ratios. Common pitfall: definition drift. Some companies include only software engineers, others include product managers and designers, others include all of R&D plus QA, plus support engineers. Boards should anchor the definition once and hold it stable — otherwise quarter-over-quarter comparisons are noise. Pair with `rd_monthly_spend` to derive fully-loaded cost-per-engineer.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "R&D" ], "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 }, "formula": "Count of engineering headcount (FTE + contractor FTE-equivalence). Define inclusion explicitly: SWE-only vs SWE+PM+Design vs all-of-R&D-including-QA. Hold the definition stable across quarters; surface the definition in a footnote.", "whyItMatters": "Capacity denominator for every R&D ratio — `rd_efficiency`, ARR-per-engineer, cost-per-engineer, throughput-per-engineer. The board reads this to gauge whether team growth is keeping pace with revenue and product-surface-area growth.", "interpretationGuidance": "No single benchmark; the right number depends on product complexity, business model, and platform vs. point-solution architecture. The SaaS Capital Annual Survey reports revenue-per-employee for its private SaaS panel (see revenue-per-employee section of the latest edition) — pair `total_engineers` with company-wide headcount and ARR to derive both engineer-density (engineers ÷ total headcount) and ARR-per-engineer. Industry folk-wisdom, not citation-grade: engineer density of 25–40% is typical at product-led growth-stage SaaS; lower at sales-led, higher at infrastructure / platform companies.", "relatedKpiIds": [ "product.rd_monthly_spend", "product.rd_efficiency", "product.capacity_allocation_pct", "product.innovation_capacity_pct", "hr.arr_per_fte" ], "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "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." }, "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." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "contracted_arr", "dateBasis": "go_live", "production": "computed" } }, { "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 }, "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 }, "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 }, "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.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." }, "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 }, "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_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 }, "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." }, "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." }, "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." }, "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" } }, { "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 }, "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" } }, { "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 }, "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" ], "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 }, "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" ], "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 }, "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" ], "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 }, "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" ], "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 }, "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.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 }, "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 }, "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." }, "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 }, "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 }, "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 }, "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 }, "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 }, "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 }, "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." }, "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 }, "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 }, "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" ], "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 }, "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 }, "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_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 }, "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 }, "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" ], "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 }, "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 }, "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 }, "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 }, "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 }, "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 }, "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 }, "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" ], "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 }, "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" ], "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 }, "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 }, "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 }, "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" ], "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 }, "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 }, "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" } } ] }