forecast-accuracy · git:20260603.668ed88 · 2026-06-03 · sha256 f058ea2d3065ca5b
forecast-accuracy git:20260603.668ed88A
Immutable. This exact content is served forever at /api/v1/blob/f058ea2d3065ca5b.
--- model_tier: high name: forecast-accuracy description: "Use when constructing the forecast call — commit / best-case / pipeline categorisation, deal-level evidence test, accuracy retro-loop. Triggers on 'build the forecast', 'why does our commit miss'." status: active tier: senior domain: product context_spine: [product, customer-segment] recommended_for_user_types: [gtm, finance] workspaces: - gtm packs: - gtm-sales trust: level: professional install: removable: true --- # forecast-accuracy ## When to use - The quarterly forecast call is being constructed and the team needs a categorisation rule that survives retro — not a feel-good number that flatters this week. - Commit has missed two or more quarters and nobody can name which signals broke — the retro-loop is missing or the categorisation rule is unwritten. - A new RevOps lead inherits a pipeline and needs to rebuild the forecast call without inheriting last regime's optimism bias. Do NOT use to design pipeline stages (route to `pipeline-strategy`), qualify a single deal (route to `deal-qualification-meddic`), or build the finance-side top-down / bottom-up model (composes against — but does not duplicate — the finance-partner forecasting capability, via the `forecast-construction-shape` interface). ## Cognition cluster - **Mental model 16 — Leading vs. lagging indicators.** Closed-won is lagging; per-stage conversion and MEDDIC-slot completeness are leading. A forecast built on lagging signals can only confirm the result after it lands. See [`docs/contracts/mental-models.md`](../../../docs/contracts/mental-models.md) § 16. - **Mental model 29 — Premortem.** Before locking the call, write the post-quarter retro as if commit missed by 20 %. The premortem surfaces which categorisations are riding on weak evidence; demote those before the call locks. See `mental-models.md` § 29. - **Mental model 9 — Hypothesis-driven thinking.** Each commit deal carries a falsifiable claim: *"this closes by \<date\> because \<evidence\>."* If the claim cannot be falsified inside the quarter, the deal is best-case, not commit. See `mental-models.md` § 9. - **Context-spine — product + customer-segment.** Read the **product** slot for what is actually GA-shippable this quarter (deals depending on non-shipped scope are not commit), and the **customer-segment** slot for segment-historical close rates — pricing-power and cycle-length differ by segment and the forecast must too. See [`context-spine`](../../../docs/contracts/context-spine.md). ## Procedure ### Step 0: Inspect — inherit pipeline + qualification artefacts Pull `stage-definitions.md`, `coverage-by-cell.md` from `pipeline-strategy`, and the latest `meddic-card.md` per deal from `deal-qualification-meddic`. Inspect whether each commit-candidate deal carries falsifiable evidence per MEDDIC slot — a forecast built without that inspection is rep opinion, not categorisation. ### Step 1: Lock the three categories with falsifiable rules 1. **Commit** — deal closes in-window with ≥ 90 % subjective probability **and** MEDDIC slots all filled with evidence **and** decision-process has buyer-written dates inside the window. 2. **Best-case** — deal *could* close in-window with ≥ 50 % probability **and** ≤ 2 MEDDIC slots unfilled **and** at least one decision-process date inside the window. 3. **Pipeline** — everything else. Pipeline is not a forecast category; it is the population from which commit and best-case are drawn. Reject *"commit"* placements that do not meet all three commit criteria, regardless of $ value or rep confidence. ### Step 2: Apply the segment-historical close rate For each deal, compute *expected $* = $ × segment-historical in-window close-rate (trailing four quarters). Aggregate by category. If commit-$ exceeds (segment historical commit close-rate × pipeline-$ in commit), the call is structurally optimistic — find the optimism source before defending the number. ### Step 3: Premortem the commit list Write *"if commit misses by 20 %, the reason is \_\_\_."* The most common patterns: (a) one anchor deal slipped, (b) segment cycle lengthened, (c) procurement/legal queues bunched at quarter-end. Tag each commit deal with which of these would kill it; deals tagged with two or more move to best-case. ### Step 4: Construct the call with confidence bands Report **commit $** = sum of commit-tagged after Step 3 demotions. **Best-case $** = commit + best-case-tagged. Attach the band: *"commit ± \<historical-deviation\>; best-case ± \<historical upside\>"*. A call without a band has no honesty about its prior miss-rate. ### Step 5: Run the accuracy retro-loop at quarter-end Compare predicted commit / best-case / pipeline to actual closed-won by category. Compute per-rep, per-segment, and per-stage miss-rate. Patterns that repeat for two quarters become categorisation rule changes in Step 1; one-off misses become deal-level evidence upgrades in Step 0. ## Related Skills **WHEN to use this** - Constructing the quarterly forecast call from a qualified pipeline. - Running the accuracy retro-loop and feeding it back into Step 1. **WHEN NOT to use this** - Designing pipeline stages or per-stage conversion targets — route to [`pipeline-strategy`](../pipeline-strategy/SKILL.md). - Single-deal qualification or disqualification — route to [`deal-qualification-meddic`](../deal-qualification-meddic/SKILL.md). - Finance-side top-down model or board-deck forecast — composes against (does not replace) the finance-partner forecasting capability via the `forecast-construction-shape` interface. ## When the agent should load this - "Build the Q3 forecast call." - "Why does our commit keep missing?" - "Run the forecast retro for last quarter." - "Welche Deals gehören wirklich in Commit?" ## Output 1. **`forecast-call.md`** — commit $ and best-case $ with confidence bands; per-segment breakdown. 2. **`commit-list.md`** — one row per commit deal: $, segment, MEDDIC-completeness, decision-process date, premortem tag (none / single-risk / two-risk demoted). 3. **`retro-deltas.md`** *(at quarter-end)* — predicted vs actual per category, per-segment, per-rep miss-rate, and the categorisation-rule change (if any) for next quarter. ## Gotcha - *"Strong commit"* without buyer-written dates inside the window is a wish, not a forecast. Subjective probability without artefact evidence is what the retro will punish. - Segment-historical close rates change after a pricing change, a packaging change, or a competitive shift. Recompute the rates when the segment shape changes, otherwise the call inherits the old regime's optimism. - Reporting commit as a point estimate without the band hides the prior miss-rate. A team that has missed by 18 % twice and reports commit ± 0 % is performing forecasting, not doing it. ## Do NOT - Do NOT place a deal in commit because the size is large; size is independent of evidence. - Do NOT skip the premortem on commit deals — most misses come from a small number of anchor deals slipping, and the premortem is where you catch them. - Do NOT change categorisation rules on a single-quarter miss; rules change on a two-quarter pattern. ## Runnable example End of Q2, last two commits missed by 14 % and 21 %. - Step 1 enforcement — three deals placed in commit had ≥ 2 MEDDIC slots open; demoted to best-case (–$ 540 k commit, +$ 540 k best-case). - Segment close-rate — Mid-Market historical commit close-rate is 78 %; commit-$ implies 91 % aggregate close-rate; structural optimism of ~$ 320 k. - Premortem — two anchor deals (each > 10 % of commit) tagged single-risk (procurement queue); one tagged two-risk (no buyer-written date) → demoted. - Final call — *"commit $ 4.1 m ± 12 % (historical deviation); best-case $ 6.7 m + 8 % / – 14 %."* Commit-list flags the two procurement-risk anchors for VP-level intervention. - Retro at quarter-end — predicted commit $ 4.1 m, actual $ 4.0 m; rule unchanged; one rep over-commits two quarters running → categorisation-coaching action.