revops-incident-response

/revops-incident-response — Decide which leak to fix first

/revops measures the plumbing and stops. This decides what to do about it, in what order, by when.

The unit rule, because it's easy to get wrong: evidence is per-lead, the verdict is systemic. A cohort stat ("483 companies died at intro→trial") names a leak but can't explain it — and an explanation invented from a cohort stat is exactly what gets invalidated on review. Tracing twenty named leads individually tells you why, which tells you what to fix. You ship a systemic decision backed by named leads, not a list of leads to chase.

---

Workflow at a glance

Phase	Purpose	Output
0. Data-quality gate	Is the CRM trustworthy enough to draw a conclusion from?	PASS / PASS_WITH_CAVEATS / HALT
1. Detection	Which named leads are stalled beyond SLA, per stage?	Named leads — never cohorts
2. Investigation	Why did each one stall?	Per-lead root cause, each citing a quote
3. Triage	Which leak first, how long, in what order?	Branch + fix-time + Day-0/1/14
4. Hand-off	Who executes?	Named skill + a history.md entry

Phase 0 can end the run. That is a feature, not a failure mode — see below.

---

Phase 0 — The data-quality gate (runs first, can halt)

Never trust a leak number before you've checked whether the CRM can support one.

This exists because it already went wrong. ClientCo's 0226-funnel-analysis.md shipped a confident H2-decline story attributed to a named rep's departure. Team review found she worked in CS, not sales, and her attributed deals were likely CRM reassignments. The same doc flags "57% of deals have no assigned rep" — then corrects itself: "this is likely a CRM data quality issue (no automated self-serve deal creation exists), not evidence of self-serve dominance." Its own priority action reads: "Before requesting rep-level data, audit HubSpot deal lifecycle practices first."