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

SkillMonitoring & ops

'Triage decision tree for revenue-funnel leaks — the paired triage half of /revops per audit-triage-pairing.md.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the /revops-incident-response — Decide which leak to fix first skill

What this skill tells your AI

The instructions your AI receives, as published by matteotitta/genesys-skills in skills/primitives/sales-enablement/revops-incident-response/SKILL.md and read by ahel’s review.

/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

PhasePurposeOutput
0. Data-quality gateIs the CRM trustworthy enough to draw a conclusion from?PASS / PASS_WITH_CAVEATS / HALT
1. DetectionWhich named leads are stalled beyond SLA, per stage?Named leads — never cohorts
2. InvestigationWhy did each one stall?Per-lead root cause, each citing a quote
3. TriageWhich leak first, how long, in what order?Branch + fix-time + Day-0/1/14
4. Hand-offWho 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."

That is this phase, written by the client's own analysis, in advance.

Check five things (detail + thresholds → the premium reference):

  1. Unassigned deals — what share have no owner? Is that real self-serve or missing automation?
  2. Defunct stages — is any stage still in the schema but dead in practice? (ClientCo: "the MQL stage is effectively defunct since the HubSpot migration".)
  3. Stage-skipping — deals jumping stages mean stage timestamps can't carry a stall calculation.
  4. Attribution integrity — are owners assigned by role, or by reassignment artifact?
  5. Definition drift across systems — the same word meaning different things in two tools. (ClientCo: "'MQL' means different things across HubSpot and Triple Dart".)

Verdicts.

  • PASS → proceed to Phase 1.
  • PASS_WITH_CAVEATS → proceed, but every downstream verdict carries the named caveat inline. Not a footnote.
  • HALTstop. Emit no leak verdict. The finding is the data problem, and the deliverable is the fix-list for it. Hand back to /revops.

A HALT is a successful run. Shipping a confident leak verdict on untrustworthy data is the failure this skill exists to prevent — and it has already happened once on this client.


Phase 1 — Detection (named leads, never cohorts)

Read the live CRM. Query stage-entry timestamps and find leads sitting past their stage SLA.

Output shape: a named lead, its stage, days stalled, owner, and deal context. Twenty named rows beat a percentage. If the answer comes back as "59.3% converted," you've reproduced the audit, not triaged it.

Live read via HubSpot MCP (query_crm_data, search_crm_objects, get_crm_objects). Read-only — never write to a client CRM. This is the first skill in the workspace declaring mcps_used: [hubspot]; access is viewer-level per ClientCo/goals/measurement.md.

Redact before you reason: end-client names, emails, phones, account numbers → [CLIENT-n] per pii-redaction.md. ClientCo is FCA-regulated and their CRM carries end-client financial detail. Keep the roles, the company, the deal shape — mask the identity.


Phase 2 — Investigation (root cause, quoted)

For each stalled lead, trace across systems and answer why this one.

Sources: CRM stage history (what moved, when, and what didn't) + call transcripts. Parse transcripts with the existing adapter spec at `research/win-loss/the premium reference — WebVTT / SRT / Gong / Fireflies / Otter / Grain / generic JSON / plaintext. Don't rebuild it. (Granola arrives via MCP as a delivery source, not a sniffed format.)

Every root cause cites a verbatim quote + speaker, per evidence-bound-outputs.md. No quote → mark [INFERRED: from X + Y] or drop the claim. Never invent the reason a deal stalled.

[CLIENT-7] · Intro → Trial · stalled 34d · owner: [REP]
Root cause: pricing, not fit — "we'd need sign-off above 20k and I can't get that this quarter"
            (buyer, [11:04]). Trial never provisioned.

Do not screenshot the journey. Zapier's system reconstructed lead journeys via browser automation because their security team blocked MCP connectors. That was their constraint; HubSpot is a live connector here. MCP reads beat screenshots — importing their workaround would import their handicap.


Phase 3 — Triage (branch → fix-time → Day-0/1/14)

Aggregate the per-lead causes, then decide. Five branches — full trees, thresholds, and fix-time estimates → the premium reference:

BranchFires when the per-lead causes cluster on…First action
1. Qualification leakWrong-fit leads reaching a stage they can't clear (pricing shock, size mismatch)Add the qualification gate one stage earlier
2. No-nurture leakRight-fit leads going quiet with no follow-up mechanismShip the missing sequence for the largest cohort
3. Handoff leakStalls at an owner change or an SLA with no trackingInstrument the SLA before changing it
4. Product/proof leakA recurring objection engineering or marketing must answerRoute the objection, don't re-sell it
5. Phantom leakThe "leak" is a reporting artifactBack to /revops — this isn't a funnel problem

State the volume floor. Per quantitative-evidence-floors.md: no "biggest leak" verdict below the floor. Under it, give a directional read and say so. Name the confounds — seasonality, attribution window, conversion lag — before crediting a cause.

Multi-branch: when causes split across branches, rank by recoverable volume × inverse fix-time, and say what you're not doing.


Phase 4 — Reporting + hand-off

Compose, don't build. Recurrence via /schedule; the weekly roll-up via /dashboard, which ships a pipeline-visualization template. No new cron infrastructure — that layer exists.

Hand off by branch: nurture gap → /email-nurture or /lifecycle · qualification gap → /funnel-strategy · plumbing/reporting → back to /revops. Append a [REVOPS] line to the client's history.md.


Anti-Hallucination Guardrails

  1. Never fabricate a leak number. Live CRM read or nothing. If the MCP is unavailable, say so and stop — per the financial-data.md posture, do not reconstruct pipeline data from memory or from a stale doc.
  2. Never invent a root cause. Quote or lower the confidence.
  3. Never skip Phase 0. The gate exists because the failure already happened on this client.
  4. Never write to the CRM. Read-only, always.
  5. Never crown a leak below the volume floor. Directional read + caveat instead.
  6. Never ship an unredacted end-client name. FCA-bound data.

Integration with other skills

SkillRelationship
/revopsThe audit half. It measures the plumbing; this decides. A HALT hands straight back to it.
/win-lossExplains closed-lost deals with transcripts. This explains silently-stalled leads. Different populations; its transcript adapters are reused here.
/lead-scoringProspective — should we pursue this account? This is retrospective — why did this one die?
/funnel-strategyDefines the stages and SLAs this measures stalls against. Hand-off target for Branch 1.
/email-nurture · /lifecycleHand-off targets for Branch 2.

Quality checks (pre-output)

Full gate → the premium reference. The load-bearing five:

  • Phase 0 emitted an explicit verdict before any leak claim. A HALT emitted no leak verdict at all.
  • Detection names actual leads. If the output is a percentage, it's an audit — start over.
  • Every root cause carries a verbatim quote + speaker, or is marked [INFERRED] / dropped.
  • The volume floor is stated; confounds and lag are named.
  • End-client PII masked. Nothing written to the CRM.

Final ship gate

Run /premortem --output before ship. See /premortem skill for the 5 execution domains and output template.

Then run /scope-guardian-reviewer — the client-deliverable ship gate: scope-creep check on proposals/SOWs (pm-loop.md). Live-CRM findings invite scope sprawl; this is the gate that catches "while we're in here…".

Trivial-case escape: ## Premortem\nNo failure modes — trivial change satisfies the contract for genuinely trivial outputs.


Attribution

The Detection → Investigation → Reporting shape, and specifically the per-lead granularity + recurrence that our cohort-level audit thinking wouldn't have produced, is adapted from Zapier's internal lead-leakage agent system as described in "Zapier's no lead left behind agent", Demand Collective, accessed 2026-07-16. Cite-only — concept port, zero code. Their browser-automation implementation is deliberately not ported (see Phase 2). See .claude/discovery/0726-zapier-lead-leakage-steal-analysis.md.


Signals

GitHub stars
36
Forks
14
Last commit
Jul 2026
Advanced
Catalog kind
skill
Gateway key
revops-incident-response
Source
github.com/matteotitta/genesys-skills