revenue-leakage

{
  "skill_name": "revenue-leakage",
  "evals": [
    {
      "id": 1,
      "prompt": "I run RevOps at Brightloom Systems, we sell warehouse scheduling software to mid-market logistics companies. Marketing swears they handed sales 400 qualified leads in Q2, sales insists they only ever got 250. I pulled the Q2 cohort out of the CRM myself: 250 accepted, 60 rejected with a reason code from the dropdown, 30 marked disqualified as bad fit, 10 still sitting inside our 5-day acceptance window. That leaves 50 I genuinely cannot account for. Average deal is $18k and historically 22% of accepted leads close. Our CFO wants a single number for 'revenue we lost in Q2' to put in the board deck Thursday. What do I tell her? One thing worth knowing: about half the team passes leads back and forth in a Slack channel instead of moving them in the CRM.",
      "expected_output": "A per-transition reconciliation of the 400-lead Q2 cohort isolating a 50-record residual, the residual split by the three-way classification into real leak / healthy disqualification / data-capture gap, a recoverable (not gross) dollar figure with a confidence tag for the real-leak portion only, and an instrumentation fix with no dollar figure for the Slack handoff.",
      "files": [],
      "expectations": [
        "Builds a per-transition reconciliation in the form entered = advanced + lost(reason) + disqualified(reason) + still-open-in-window + residual",
        "Identifies the unexplained residual as 50 records, equal to 12.5% of the 400 entering the transition",
        "Excludes the 60 rejected-with-reason and the 30 disqualified records from the leakage finding, naming them legitimate recorded exits rather than lost revenue",
        "States that disqualification volume is a sign of a filtered funnel, or that a funnel with zero disqualification is unfiltered rather than healthy",
        "Refuses to report the gross pipeline value of the unaccounted records as the revenue lost figure for the board deck",
        "Sizes recoverable revenue as leaked record count multiplied by average value per record multiplied by the onward conversion rate from the leak point, using the 22% figure as the onward conversion input",
        "Runs the three-way classification on the 50-record residual before any part of it is sized as a leak",
        "Requires evidence per record group (timestamps, owner history, reason codes, or the absence of them) before assigning a classification",
        "Names the Slack-based lead passing as a suspected data-capture gap or untracked step rather than a funnel drop",
        "Assigns the Slack handoff an instrumentation fix and no dollar figure",
        "Follows the Q2 entry cohort forward rather than analyzing a point-in-time snapshot of the pipeline",
        "Attaches a confidence tag (measured, estimated, or assumed) to the recoverable figure"
      ]
    },
    {
      "id": 2,
      "prompt": "Quilo is a self-serve time-tracking SaaS, average subscription $95/month, no sales team involved below enterprise. Last month we attempted 900 renewal charges: 810 went through, 18 failed and then recovered on their own, 9 customers cancelled after a failure, 12 are still in retry inside our 14-day window. 51 just ended. Our growth lead is convinced this is a product problem and wants to run a cancellation survey. For context, our own data shows a payer who recovers sticks around roughly 6 more months. Give me the real picture and tell me what to do first. Engineering has capacity this sprint and the billing config is ours to change.",
      "expected_output": "A charge-to-renewal reconciliation isolating 51 unexplained records, classified as involuntary churn with no recovery path wired to the payment-failure event, sized with an achievable-minus-current recovery rate derived from Quilo's own data, and a recovery-sequence fix promoted on the stated engineering capacity with its compliance review named.",
      "files": [],
      "expectations": [
        "Reconciles the charge-to-renewed transition and identifies 51 unexplained records, equal to 5.7% of the 900 charges attempted",
        "Classifies the 51 as a real leak caused by payment failure with no retry or recovery sequence wired to the failure event",
        "States that the mechanism here is technical rather than human and that no rep owns these records, which is why the leak was invisible",
        "Rejects or deprioritizes the cancellation-survey framing on the grounds that these subscriptions ended on payment failure rather than on a customer decision",
        "Sizes recoverable revenue using the difference between an achievable recovery rate and the current recovery rate applied to failed-payment revenue, not the full 51 subscriptions as if all were recoverable",
        "Uses the user's own 6-month post-recovery retention figure rather than an invented subscription lifetime",
        "Derives the achievable recovery rate from the user's own recovery history, such as the 18 organic recoveries or processor retry data, rather than from a vendor benchmark",
        "Labels any involuntary-churn share benchmark it quotes as a vendor-sourced figure rather than presenting it as an industry constant",
        "Recommends a recovery or dunning sequence wired to the payment-failure event as the fix, and names it as the recovery-sequence fix class",
        "Promotes the recovery-sequence fix on the strength of the stated engineering capacity and says that this constraint is what moved it",
        "Notes that a retry or dunning change requires a payment-rules and subscriber-notification review before shipping",
        "States that the reconciliation arithmetic, the classification step, and the recoverable-dollar sizing rule are identical to a sales-led funnel, and that only the leak site and evidence type change"
      ]
    },
    {
      "id": 3,
      "prompt": "Northgate Analytics, we sell BI tooling to insurance carriers. Our VP Sales read that responding to an inbound lead within 5 minutes makes you 100x more likely to connect and 21x more likely to qualify it, and that the average B2B response time is 42 hours. Our median first response is 19 hours across the 1,200 inbound demo requests we got last quarter, so he is convinced we are bleeding millions and wants a hard 5-minute SLA plus a dollar figure to justify hiring two more SDRs. Can you size what slow response is costing us and write up the case?",
      "expected_output": "A refusal to build the sizing on the quoted multipliers, with the multipliers named as unsourced, the real HBR study cited separately as evidence that latency matters, and a method for deriving Northgate's own latency threshold and leak size from its own response-time-versus-conversion data.",
      "files": [],
      "expectations": [
        "Declines to use the 100x, 21x, and 42-hour figures as the basis for any sizing, stating that they are unsourced or unverifiable",
        "Produces no dollar figure derived from the quoted multipliers",
        "Names the 2011 Harvard Business Review study 'The Short Life of Online Sales Leads' by Oldroyd, McElheran, and Elkington as real and citable evidence that response latency matters",
        "Separates that study from the specific multipliers commonly attached to it rather than treating the multipliers as its findings",
        "Instructs measuring Northgate's own response-time-versus-conversion curve and deriving the latency threshold from that curve",
        "Does not endorse a 5-minute SLA as an industry standard or published constant",
        "Labels every numeric threshold it proposes with its provenance: published practice, practitioner consensus, or derived from the user's own data",
        "Asks whether first-response timestamps exist per record before treating slow response as a measurable leak",
        "Requires the slow-response or unworked-lead residual to pass the three-way classification before any part of it is sized",
        "Attributes the residual to a process defect such as a missing SLA or escalation rather than to individual reps, unless owner history proves otherwise"
      ]
    },
    {
      "id": 4,
      "prompt": "Meridian Freight Software. Deals keep dying between verbal yes and signature. Last quarter 88 opportunities hit verbal commit at an average of $41k each, and 61 came back signed. Nobody can tell me what happened to the other 27. Contracting runs through our legal team's shared inbox plus a signature tool that does not write anything back to the CRM, so there are no dates on any of it. My board meeting is in 10 days and I need a leakage number for that gap. Just give me your best estimate, I understand it will not be perfect.",
      "expected_output": "A refusal to estimate a dollar figure for a step that emits no records, the gap named as the late-stage paper-process leak and recorded as an instrumentation gap with a scheduled re-run, and a register for this round that drops process redesign on the 10-day deadline and leads with rework and alerts.",
      "files": [],
      "expectations": [
        "Refuses to produce an estimated dollar figure for the contracting step while it emits no timestamped records, despite the user explicitly authorizing a best guess",
        "States that guessing a number for an untracked step would fabricate a figure that anchors the whole ranking",
        "Names the gap as an instrumentation or data-capture gap to be instrumented before it can be measured",
        "Identifies the verbal-yes-to-signature gap as the late-stage paper-process leak named by MEDDPICC",
        "Places the contracting gap in a capture-gaps section carrying an instrumentation fix and no dollar figure",
        "Schedules a re-run after instrumentation and presents that as a passing outcome rather than a failure to deliver",
        "Reconciles the 88 verbal-commit exits against the 61 signed contracts and names 27 as the unexplained residual",
        "Does not classify the 27 records as a confirmed real leak without evidence from timestamps, owner history, or reason codes",
        "Deletes process redesign from this round's register on the strength of the 10-day deadline and names that deadline as the constraint that deleted it",
        "Leads this round with alerts, routing fallbacks, or one-off rework of the records that already leaked",
        "Proposes instrumenting the signature tool or legal inbox handoff so the contracting step writes a timestamped record"
      ]
    },
    {
      "id": 5,
      "prompt": "Follow-up on Arbordale Software. We have confirmed and sized four leaks in the SMB self-serve funnel for the March cohort: (a) failed payments never retried, $210k recoverable; (b) leads assigned to a territory owner who left in January and nobody picked them up, $38k; (c) usage over entitlement never triggering an expansion motion, $96k; (d) the trial-to-paid handoff is entirely manual and would need rebuilding across product, billing and CS, $340k. Constraints: finance has frozen the billing system until the new fiscal year, I have one analyst and zero engineering time, and our CRO wants results by end of quarter. Put these in order and tell me what we are actually doing.",
      "expected_output": "A leak register ranked by recoverable dollars per unit of fix effort with the ranking basis stated above it, the billing-frozen recovery-sequence fix deleted with its constraint named while the leak stays marked blocked, process redesign deleted on the deadline, one-off rework leading on the analyst-only ceiling, and a fix class plus process owner on every row.",
      "files": [],
      "expectations": [
        "Ranks the register by recoverable dollars per unit of fix effort rather than by recoverable dollars alone, and states the ranking basis above the register",
        "Does not place the $340,000 trial-to-paid redesign first on the strength of its dollar figure",
        "Deletes the $210,000 failed-payment recovery-sequence fix rather than demoting it, because the billing system is frozen",
        "Names the billing freeze as the specific constraint that deleted that fix class",
        "Keeps the failed-payment leak itself in the register, marked blocked with no fix owner, rather than removing the leak along with its fix",
        "Deletes process redesign from this round on the strength of the end-of-quarter deadline",
        "Leads with one-off rework of the records that already leaked, given the analyst-only effort ceiling",
        "States that the analyst-only effort ceiling rules out instrumentation and redesign fixes",
        "Assigns every entry a fix class drawn from alert/escalation, routing fallback, recovery sequence, one-off rework, or process redesign",
        "Classifies the departed-territory-owner leak as an ownership vacuum whose fix is a routing fallback plus an escalation alert on unassigned records",
        "Names one process or system owner per register entry rather than blaming an individual",
        "Names process redesign as the fix class this efficiency ordering starves, and states the condition that would promote it into its own dated workstream"
      ]
    },
    {
      "id": 6,
      "prompt": "Here is a pull from the CRM at Caldera Networks: everything currently open or closed in the pipeline, every vintage, 1,430 records total. 312 have had no stage change in 30+ days, 88 are missing an amount, 140 have had their close date pushed three or more times, and 44 records appear on both my 'stalled at proposal' list and my 'closed-won but never invoiced' list. Total open value on the stalled ones is $2.1M. Write me the revenue leakage report.",
      "expected_output": "A rejection of the all-vintage snapshot as a reconciliation base with a request for one funnel, period and entry cohort, the hygiene counts reframed as input signals rather than findings, the 44 double-listed records counted once at first unexplained exit, and a refusal to present the $2.1M open value as leaked revenue.",
      "files": [],
      "expectations": [
        "Rejects the all-vintage snapshot as a basis for reconciliation and requires one entry cohort followed forward",
        "States that mixing snapshot counts with cohort flows makes the residuals arithmetic noise, inventing or hiding leaks",
        "Treats the stale-deal count, missing amounts, and push counts as input signals for locating leaks rather than as the findings themselves",
        "Does not deliver the output as a hygiene checklist or an exception list with a disposition per flagged deal",
        "States that field-hygiene remediation is a different job and routes it elsewhere rather than absorbing it into this deliverable",
        "Counts each of the 44 records appearing on both lists once, at its first unexplained exit",
        "Warns that double-counting a record across two leak sites inflates the recoverable total beyond reality",
        "Refuses to report the $2.1M open value of the stalled deals as leaked or recoverable revenue",
        "States that every finding must carry records affected plus either recoverable dollars or an instrumentation fix",
        "Asks which single funnel instance, which period, and which entry cohort the analysis should cover",
        "Treats repeated close-date pushes with no accompanying activity as evidence of probable dead records inflating open-in-window counts rather than as the leak itself"
      ]
    },
    {
      "id": 7,
      "prompt": "I am head of RevOps at Tessellate Labs. The board asked where pipeline is vanishing. I want you to look across our EMEA, NAMER and APAC funnels for the last three quarters and find the leaks. And while you are in there: our stage definitions are a mess, half of them are things like 'rep sent a proposal', and our round-robin keeps dumping enterprise leads on SMB reps. Fix all of that as part of the same deliverable please.",
      "expected_output": "A narrowed scope to one funnel instance, one period and one entry cohort, an explicit trace-not-redesign boundary that routes the stage-definition and routing problems to the matching sibling skills in one line each, and an interview run one question at a time before any analysis.",
      "files": [],
      "expectations": [
        "Narrows the analysis to exactly one funnel instance, one period, and one entry cohort",
        "States that comparing across the three regions and three quarters is program-level work and out of scope here",
        "Declines to rebuild the stage definitions as part of this deliverable",
        "Names the stage-definition defect in roughly one line and routes it to the pipeline stage definition audit skill",
        "Declines to redesign the routing logic as part of this deliverable",
        "Routes the routing defect to the lead-routing skill while retaining misassignment as a leak site to probe in this analysis",
        "States the scope boundary as trace rather than redesign, treating the stage set and the routing rules as given inputs",
        "Runs an interview before analyzing, asking one question per message",
        "Asks what unexplained residual per transition the user is willing to sign off on, and frames that tolerance as the user's number rather than the skill's",
        "Labels any residual tolerance placeholder it offers, such as 5% of entering records per transition, as a practitioner working bar rather than a published standard"
      ]
    },
    {
      "id": 8,
      "prompt": "Vantage Kilns, we sell scheduling and maintenance software to industrial kiln operators. We have isolated 62 records that leaked out of our 'pilot agreed' step in the Q1 cohort. They were viable, nobody ever touched them again, and the rep who owned them left the company. We are 8 months on from that cohort now. Average deal value for that cohort is $27k, though company-wide our average is $34k. We only started tracking stage history five months ago so I do not have clean conversion data from that step. What are these 62 worth?",
      "expected_output": "A recoverable figure built from the cohort's own average value, an onward conversion rate obtained by falling back down the evidence-strength chain now that funnel history is unavailable, an age haircut for the 8-month-old cohort stated as an assumption, and an estimated or assumed confidence tag with its ranking consequence.",
      "files": [],
      "expectations": [
        "Uses the cohort's own $27,000 average deal value rather than the $34,000 company-wide average",
        "Applies an onward conversion rate from the pilot-agreed point rather than treating all 62 records as closeable",
        "Notes that the funnel's own history is the strongest basis for onward conversion and that it is unavailable here, then falls back to chaining the user's step-to-step rates from the leak point forward",
        "Treats the onward-conversion estimation methods as a fallback chain ordered by evidence strength, not as a menu of options ranked by effort or efficiency",
        "Applies an age haircut to account for the cohort being 8 months old",
        "Derives the haircut from the user's own reactivation or re-engagement outcomes, or states it explicitly as an assumption when none exist",
        "Does not import a published response-decay or speed-to-lead multiplier as the age haircut",
        "Tags the resulting figure 'estimated' or 'assumed' rather than 'measured'",
        "States that an assumed figure must not drive the ranking on its own and needs upgrading or an instrumentation flag",
        "Does not present 62 multiplied by $27,000 as the recoverable figure"
      ]
    }
  ],
  "trigger_queries": [
    { "query": "where are we losing deals between marketing and sales", "should_trigger": true },
    { "query": "our funnel is leaky and I want to know where", "should_trigger": true },
    { "query": "run a revenue leakage audit on our SMB funnel", "should_trigger": true },
    { "query": "marketing says they sent 500 leads, sales says they got 300, what happened to the rest", "should_trigger": true },
    { "query": "deals keep disappearing between verbal commit and signed contract", "should_trigger": true },
    { "query": "trial signups are flat but paid conversions dropped 20% and nobody can say where it happens", "should_trigger": true },
    { "query": "how much revenue are we losing to failed payments that never get retried", "should_trigger": true },
    { "query": "we have renewals that just lapsed and nobody noticed until the quarter closed", "should_trigger": true },
    { "query": "quantify what our unworked leads are actually costing us", "should_trigger": true },
    { "query": "why did pipeline vanish this quarter", "should_trigger": true },
    { "query": "I want to know what is actually recoverable, not what was lost on paper", "should_trigger": true },
    { "query": "there is a gap between our closed-won deals and what we actually invoiced", "should_trigger": true },
    { "query": "find the drop-off in our self-serve checkout funnel and put a number on it", "should_trigger": true },
    { "query": "some of our leads never get contacted at all, what is that worth", "should_trigger": true },
    { "query": "our SDR to AE handoff happens in Slack and I think things fall through", "should_trigger": true },
    { "query": "audit where records exit our funnel without an accounted-for reason", "should_trigger": true },
    { "query": "reconcile leads passed versus leads accepted and tell me what the gap is worth", "should_trigger": true },
    { "query": "we are leaving money on the table somewhere in the funnel, find it", "should_trigger": true },
    { "query": "accounts blow past their seat limits and nobody ever triggers an upsell", "should_trigger": true },
    { "query": "how much are we losing to dunning gaps and involuntary churn", "should_trigger": true },
    { "query": "size the revenue we could get back if we fixed our qualification handoff", "should_trigger": true },
    { "query": "the board wants to know where money is going missing in our GTM motion", "should_trigger": true },
    { "query": "what is the dollar value of deals that stall and never close or get closed out", "should_trigger": true },
    { "query": "I need a leak register for our enterprise funnel this quarter", "should_trigger": true },
    { "query": "put a number on what our manual quoting process is costing us", "should_trigger": true },
    { "query": "we lose deals in procurement and legal review, help me measure it", "should_trigger": true },
    { "query": "conversion between two stages dropped and I cannot explain the difference", "should_trigger": true },
    { "query": "half our inbound demo requests never make it into the CRM at all", "should_trigger": true },
    { "query": "where does revenue exit our funnel silently", "should_trigger": true },
    { "query": "which of our funnel gaps should we fix first if all I have is one analyst", "should_trigger": true },
    { "query": "how do I separate deals we legitimately disqualified from deals we lost by accident", "should_trigger": true },
    { "query": "our numbers do not reconcile between the marketing tool and the CRM for last quarter's cohort", "should_trigger": true },
    { "query": "how much of our churn is cards failing rather than customers actually leaving", "should_trigger": true },
    { "query": "figure out what is recoverable from the deals that went quiet last quarter", "should_trigger": true },
    { "query": "usage is going unbilled on some accounts and I want to know the scale of it", "should_trigger": true },
    { "query": "trace every place a record can fall out of our revenue process", "should_trigger": true },
    { "query": "we found 200 leads assigned to a rep who left six months ago", "should_trigger": true },
    { "query": "nobody owns the space between sales and billing and I think we are bleeding there", "should_trigger": true },
    { "query": "help me prove to finance how much a routing fallback would actually recover", "should_trigger": true },
    { "query": "audit our pipeline stage definitions against buyer-verifiable milestones", "should_trigger": false },
    { "query": "our stage exit criteria are all rep activity, rewrite them properly", "should_trigger": false },
    { "query": "run a hygiene audit on our open pipeline and flag the stale deals", "should_trigger": false },
    { "query": "give me an exception list of deals missing a close date or an amount", "should_trigger": false },
    { "query": "why is our sales forecast always wrong", "should_trigger": false },
    { "query": "our reps sandbag every quarter, how do I fix the forecast roll-up", "should_trigger": false },
    { "query": "design our revenue funnel stage model from scratch", "should_trigger": false },
    { "query": "should our funnel unit of analysis be leads or buying groups", "should_trigger": false },
    { "query": "build the routing rules that assign inbound leads to reps", "should_trigger": false },
    { "query": "set up weighted round robin with per-rep capacity limits", "should_trigger": false },
    { "query": "recalibrate our lead scoring model against closed-won outcomes", "should_trigger": false },
    { "query": "where should we set the MQL threshold this year", "should_trigger": false },
    { "query": "which product usage signals actually predict churn", "should_trigger": false },
    { "query": "build a composite customer health score with weighted, decayed signals", "should_trigger": false },
    { "query": "design a tiered discount approval matrix for non-standard deals", "should_trigger": false },
    { "query": "what should our margin floor policy be on services concessions", "should_trigger": false },
    { "query": "who owns each field in our CRM and how often must it be refreshed", "should_trigger": false },
    { "query": "decide which system is source of truth for the account object", "should_trigger": false },
    { "query": "build a revenue metric tree from board level down to IC", "should_trigger": false },
    { "query": "structure the narrative for our monthly board revenue report", "should_trigger": false },
    { "query": "we have four tools doing the same job, what do we cut at renewal", "should_trigger": false },
    { "query": "design the packet that transfers from sales to CS at closed-won", "should_trigger": false },
    { "query": "am I ready for a senior revops role, review my resume", "should_trigger": false },
    { "query": "write the interview loop and scorecard for a sales ops hire", "should_trigger": false },
    { "query": "which revops newsletters and podcasts should I be following", "should_trigger": false },
    { "query": "which skill in this collection should I use for my task", "should_trigger": false },
    { "query": "our Node service memory keeps growing until it OOMs, find the leak", "should_trigger": false },
    { "query": "profile this Go binary for a goroutine leak", "should_trigger": false },
    { "query": "we had a data leak and customer emails got exposed, write the incident response", "should_trigger": false },
    { "query": "check whether any API keys leaked into our git history", "should_trigger": false },
    { "query": "there is a file descriptor leak in our worker pool", "should_trigger": false },
    { "query": "our chatbot is leaking its system prompt, how do I stop it", "should_trigger": false },
    { "query": "audit our SaaS licenses, we are paying for seats nobody uses", "should_trigger": false },
    { "query": "run a win-loss interview program on the deals we lost last quarter", "should_trigger": false },
    { "query": "survey churned customers to learn why they cancelled", "should_trigger": false },
    { "query": "our attribution model is undercounting paid social conversions", "should_trigger": false },
    { "query": "write a dunning email sequence that wins back failed payments", "should_trigger": false },
    { "query": "reduce cart abandonment on our checkout page with better UX", "should_trigger": false },
    { "query": "our comp plan pays commission on deals that later get clawed back, redesign it", "should_trigger": false }
  ]
}

# Leak Site Inventory

Probe every site below when mapping the funnel; skipping one is how a report misses the biggest leak. For each site: the mechanism, the detection signal, and the evidence to pull.

Markers:

- **[B2B]** - assumes a rep-owned pipeline.
- **[self-serve]** - assumes a product/billing funnel.
- unmarked - occurs in both.

This is a coverage checklist, not a menu to rank - the sites do not compete for the same slot, and ranking them by likely yield before the reconciliation has run would be guessing which one leaks in this funnel. Ranking happens once, downstream, on the sized register at workflow step 6. Skip a site only when the funnel structurally has no such step, and record that it was skipped for that reason.

## Entry and capture

- **Records never created.** Inbound paths that reach no system: a demo request answered from a personal inbox, a partner referral passed verbally, a chat conversation never logged. Detection: enumerate every inbound path with the user, then check each one produces a record with a timestamp. Evidence: compare source-system volume (form submissions, chat sessions, referral emails) against records created in the same window.
- **Records created but ownerless at birth.** No fallback owner in the assignment logic, so unmatched records land in a queue nobody watches. Detection: count records with no owner or a queue owner N days after creation - derive N from the funnel's own median time-to-assignment. Evidence: owner history showing assignment never happened.

## Assignment and first response

- **Unworked leads.** [B2B] Assigned but never contacted. Detection: records with an owner and zero outbound activity inside the expected window. Evidence: activity history per record; segment by owner to separate a capacity problem from an individual one - attribute to the process (no SLA, no escalation) unless owner history proves otherwise.
- **Misassignment.** [B2B] Routed to the wrong territory, segment, or a departed owner; the record sits because nobody believes it is theirs. Detection: residuals concentrated on a few owners or on records reassigned more than once. Fix design belongs to the lead-routing skill; here it is only a leak site.
- **First-response latency.** Response so slow the record is dead on contact. Measure the funnel's own response-time-vs-conversion curve and locate the decay point in that data; do not import the circulating 5-minute/21x/100x multipliers (unsourced - see SKILL.md Ground Rules).

## Qualification handoff

- **Passed but never accepted.** [B2B] The qualifying team marks a record ready; the receiving team never accepts or rejects it. Detection: reconcile passed vs accepted-or-rejected counts per period; the residual is the leak. Evidence: handoff timestamps on both sides. A missing shared definition of "accepted" shows up as high rejection plus high residual together.
- **Handoff living in chat or email.** The pass happens as a message, not a record transition - no timestamp, no reconciliation possible. Classify as a data-capture gap and instrument before measuring.

## Mid-funnel

- **Silent stalls.** Records open far past the step's expected dwell time with no recorded reason. Stale-deal data is the input signal; the leakage question is whether the record exited economically (dead but never closed) - not whether the field hygiene is good.
- **Silent close-date or renewal-date pushes.** Dates moved repeatedly with no reason code. Detection: date-change history per record; repeated pushes without activity mark a probable dead record inflating open-in-window counts.
- **No-decision losses recorded as nothing.** Deals that ended with no decision and were never closed out. These sit permanently in "open", corrupting the reconciliation. Evidence: open records whose last buyer-side activity is older than the funnel's full cycle length.

## Late stage - paper process

- **Verbal yes to signature.** [B2B] Procurement, legal review, security review, signature routing - the leak MEDDPICC names "Paper Process". Detection: reconcile verbal-commit or proposal-stage exits against signed contracts; pull time-in-contracting per record. Often untracked because contracting happens in a signature tool or email thread that never writes back to the record - then it is a capture gap first.

## Quote-to-cash

- **Quote-to-order-to-billing mismatches.** Discounts beyond policy, negotiated terms never reflected in the invoice, usage never metered or billed, invoices drafted but never finalized. Detection: three-way match on a sample - quote terms vs order vs invoiced amount. Evidence: billing-system records against closed-won records.

## Post-sale

- **Renewal misses.** Renewals that lapse because no one owned the motion, or auto-renew terms that existed on paper but were never triggered in the billing system. Detection: reconcile contracts due for renewal in the period against renewed/churned/still-pending outcomes; the residual is the leak.
- **Expansion never asked for.** Accounts consistently over plan limits or adding seats with no expansion motion triggered. Detection: usage-over-entitlement events with no follow-up record.
- **Involuntary churn.** [self-serve, also B2B] Subscriptions ending on payment failure with no retry schedule or recovery sequence wired to the failure event. Detection: reconcile payment-failure events against recovered / retried / cancelled outcomes; a failure event whose subscription silently ends with no recovery attempt is a pure leak. Scale anchor: 20-40% of total subscription churn is involuntary (Baremetrics, citing Paddle research); 2-5% for B2B SaaS (Baremetrics platform data).

## Self-serve funnel steps

- **Trial and checkout drops.** [self-serve] Step-level drop-off inside signup, activation, and checkout. The conservation test applies unchanged: events in vs events out per step. A step with no event instrumentation is a capture gap, not a zero.

## Untracked-step probe (run at every boundary)

For each adjacent pair of systems or owners, ask:

1. What happens between these two, exactly, and who does it?
2. Does that step write a timestamped record anywhere?
3. If the person doing it went on leave tomorrow, would records queue up invisibly?

Any "a human does it by hand in an inbox/spreadsheet/chat" answer marks a suspected leak site with no measurable drop-off until instrumented.

# Sizing Recoverable Revenue

Size only confirmed real leaks - never healthy disqualifications, never data-capture gaps (those get an instrumentation fix, not a dollar figure).

## The formula

```
recoverable $ = leaked record count
              x average value per record
              x onward conversion rate from the leak point
```

- **Leaked record count** - from the reconciliation residual, after classification, each record counted once at its first unexplained exit.
- **Average value per record** - deal value for pipeline leaks; subscription value (per period, times the periods realistically recoverable) for billing/renewal/churn leaks. Use the cohort's own average, not the company-wide one - leaked records often skew smaller or larger than the mean.
- **Onward conversion rate** - the probability a record at that funnel point would still have converted had it not leaked. This is what separates recoverable from gross; omitting it is the classic credibility failure.

## Estimating onward conversion

These four are a fallback chain, not a menu to rank by efficiency: each rung fires only when the rung above it has no data, and the ordering axis is evidence strength. Ranking them by effort would be false precision - a weaker method is never the efficient choice, only the available one.

1. Best: compute it from the funnel's own history - the conversion-to-close rate of records that passed the same point in a prior healthy cohort.
2. If history is thin, chain the step-to-step rates the user provided in the Interview from the leak point forward.
3. Apply an age haircut: a record that leaked months ago converts worse than a fresh one at the same point. Derive the decay from the user's own reactivation or re-engagement outcomes when any exist; otherwise state the haircut as an assumption and tag confidence accordingly. Do not import a published response-decay multiplier as the haircut (see the warn-off in SKILL.md Ground Rules).
4. Involuntary-churn leaks: recoverable = failed-payment revenue x (achievable recovery rate - current recovery rate). Derive the achievable rate from the user's own recovery history where it exists; a vendor benchmark may be quoted only as a labeled vendor figure, never as the assumption driving the number.

## Confidence tags

These are a data-quality gate, not a menu of options - they qualify a figure, they do not compete for the same job, so no efficiency ordering applies to them.

Tag every recoverable figure:

- **measured** - all three factors from the funnel's own data.
- **estimated** - count and value measured; onward conversion chained or haircut from stated assumptions.
- **assumed** - any factor guessed. An "assumed" figure may appear in the register but must never drive the ranking on its own; upgrade it or flag the leak as needing instrumentation.

Report the recoverable total by confidence band, not as one blended number.

## Ranking the register

Rank by recoverable dollars per unit of fix effort, never by recoverable dollars alone: a mid-sized leak fixed by wiring one alert outranks a larger one needing a process redesign. State the adjustment on every entry it moved; never silently reorder.

Recoverable dollars are the value axis and stay in dollars. Effort never is - it is analyst hours, engineering work, cross-team coordination, and how hard the fix is to reverse.

Fix classes, in default order:

```
efficiency (recoverable $ per unit of effort, highest first)
  alert/escalation == routing fallback > recovery sequence > one-off rework > process redesign

value (recoverable $ unlocked, largest first)
  process redesign > recovery sequence > alert/escalation == routing fallback > one-off rework

effort (heaviest first)
  process redesign > recovery sequence > one-off rework > alert/escalation == routing fallback

compliance cost (review triggered, heaviest first)
  recovery sequence > rework of invoiced or recognized revenue
```

- **alert/escalation** - a threshold alert or escalation on an event the funnel already emits (unaccepted past the handoff window, stalled past dwell time). Near-zero effort, one config change, switched off to reverse; the value recurs every cycle.
- **routing fallback** - a fallback owner or reassignment rule closing an ownership vacuum. An hour, same system, same reversibility.
- **recovery sequence** - a retry or dunning path wired to an existing failure event. A day of billing configuration; in self-serve funnels this is usually the single largest recurring recoverable number.
- **one-off rework** - working the records that already leaked. An hour of analyst or rep time and no system touched, but the value is bounded by that record set and never recurs.
- **process redesign** - rebuilding the handoff, contracting, or renewal motion itself. A quarter, cross-team, and hard to reverse once teams have re-learned it.

Ties: alert/escalation `==` routing fallback on all three dollar axes, because both are one configuration change in a system that already holds the data. Both recur every cycle, and which of the two recovers more depends on which site leaks more in this funnel, not on the class.

Compliance cost is the review a fix triggers and the reversibility it costs:

- Retry and dunning changes need a payment-rules and subscriber-notification review before shipping.
- Re-issuing or backdating an invoice needs revenue-recognition sign-off from finance and is not silently reversible.
- Alerts, routing fallbacks, and a sales-handoff redesign trigger none, so they carry no compliance cost at all.

**What this order starves: process redesign.** It carries the biggest recoverable number and the worst ratio, so it loses every round and never gets done when the register is only ever read top-down.

Promote it out of the register into its own dated workstream with its own owner as soon as any of these holds:

- the same structural leak returns in consecutive re-runs after the cheap fixes were applied
- its recoverable figure exceeds the rest of the register combined
- no cheap fix is even possible because the step emits no event to alert on

Instrumentation is deliberately absent from these lines. A capture gap carries no dollar figure by rule, so a dollar ratio would rank it last by construction. It ranks in its own section instead, by which instrumentation unlocks the most currently-unmeasurable funnel volume.

This order is a default, not a law - it shifts with the funnel and with who executes the fix. Re-rank it against what the Interview already established about this user before presenting the register:

- Engineering capacity available -> promote recovery sequence, and promote instrumentation inside its own section.
- An analyst who owns the data and nothing else -> promote one-off rework; alerts and routing fallbacks hold their lead only where they are configuration rather than code.
- A billing system nobody will touch this quarter -> delete the recovery-sequence and invoice-rework fixes and name the constraint that deleted them. The leak itself stays in the register, marked blocked with no fix owner. A ruled-out fix demoted to the bottom instead of deleted silently reappears as scope next quarter.
- A hard date from the Interview -> delete process redesign from this round and lead with rework of the records that already leaked.

Then, whatever the resulting order:

1. Every entry names one owner for the fix - a process or system owner, not a blamed individual.
2. Every entry carries its fix class, so the trade-off behind its rank is readable in the row itself.
3. Cap the register at the leaks that together cover the large majority of the sized total; a 30-row register buries the three that matter.

## What never to do

- Never sum gross pipeline value of stalled deals and present it as recoverable.
- Never double-count a record across two leak sites - first unexplained exit wins.
- Never size an untracked step. No records, no number; instrument first.
- Never blend measured and assumed figures into a single headline total.

# Worked Examples

Three examples: a B2B sales-led reconciliation, a self-serve/PLG reconciliation, and a report done wrong. Numbers are illustrative shapes, not benchmarks - every real report derives its rates from the user's own data.

## Example 1 - B2B sales-led: the qualification handoff

Mid-market funnel, one quarter's entry cohort of 400 qualified-marked leads, average deal value $18,000, historical accepted-to-close conversion 22%.

Reconciliation at the qualified -> accepted transition:

```
entered:                     400
advanced (accepted):         250
rejected with reason code:    60
disqualified (bad fit):       30
still open, in 5-day window:  10
residual (unexplained):       50   = 12.5% of entered
```

Classification of the 50-record residual, from owner and activity history:

- 20 records: passed while the receiving owner's territory was vacant. No fallback owner existed. Zero activity ever occurred. **Real leak** (ownership vacuum).
- 18 records: the pass happened as a chat message; the receiving team worked them, 6 closed, but the system never recorded acceptance. **Data-capture gap** - the funnel worked, the data did not. Instrumentation fix, no dollar figure.
- 12 records: rejected verbally in a pipeline meeting, never coded. **Data-capture gap** on the rejection path (a missing reason code, not a lost deal).

Sizing the real leak: 20 records x $18,000 x 22% onward conversion x 0.7 age haircut (cohort is a quarter old; haircut stated as an assumption from the team's own re-engagement outcomes) = **$55,440 recoverable, tagged "estimated"**. The gross figure ($360,000 of "lost pipeline") never appears.

Register entry:

```
rank 1 | qualification handoff - ownership vacuum | 20 records, owner history:
territory vacant, no fallback | real leak | $55,440 (estimated) |
owner: revenue operations | fix: fallback owner + escalation on unaccepted
records past 5 days | fix class: routing fallback + alert/escalation
```

It ranks first on effort-adjusted dollars, not on dollars alone: both fix classes are one configuration change in the system that already holds the records, so a larger leak needing a handoff redesign would still sit below it. Say that adjustment out loud above the register rather than leaving the reader to infer it from the row order.

## Example 2 - self-serve/PLG: payment failure

Subscription product, one month's cohort of 900 renewal charges, average subscription $95/month.

Reconciliation at the charge -> renewed transition:

```
entered (charges attempted):  900
succeeded:                    810
failed -> recovered:           18
failed -> cancelled by user:    9
failed -> in retry, in window: 12
residual (unexplained):        51   = 5.7% of entered
```

Classification: billing-system event history shows all 51 were payment failures whose subscriptions ended with no retry and no recovery message - the failure event was never wired to any recovery sequence. **Real leak** (involuntary churn with no dunning path). The mechanism is technical, not human - no rep owns these records, which is exactly why the leak was invisible.

Sizing: 51 subscriptions x $95 x 6 recoverable months (user's own reactivation data shows recovered payers retain ~6 months) x 55% achievable recovery (derived from the 18 recovered organically plus the user's processor retry data; tagged "estimated") = **$15,988 recoverable/cohort-month, tagged "estimated"**.

Note what is identical to Example 1: the reconciliation arithmetic, the classification step, and the recoverable (not gross) sizing. Only the leak site and the evidence type changed.

## Example 3 - the report done wrong (negative example)

A leakage report for the same B2B funnel that would fail this skill's Pass Threshold:

> "Analysis of the pipeline snapshot found 130 leads that did not convert: 60 rejected, 30 disqualified, and 40 stalled deals worth $720,000 in lost pipeline. Additionally, 85 open deals are stale (>30 days). Recommendation: sales must follow up faster. Total revenue leakage: $720,000+."

Every defect, named:

- **Counts disqualification as leakage.** The 60 rejected-with-reason and 30 disqualified records left legitimately and were recorded; including them inflates the finding and burns trust with sales.
- **Sizes gross, not recoverable.** $720,000 is the face value of stalled deals, not what a fix would recapture; finance will discount the entire report.
- **Snapshot, not cohort.** "130 leads that did not convert" mixes vintages; the residual is arithmetic noise.
- **No classification.** The 40 stalled deals were never checked against activity history - some progressed unrecorded (capture gap), some were dead-but-open (no-decision), some genuinely leaked. One number hides three different fixes.
- **Hygiene drift.** The stale-deal count is an input signal presented as a finding, with no records-to-dollars link.
- **No ranking anyone can act on.** One blended total, no fix class, no effort axis. The reader's question is never "what did we lose" but "which of these do I do first with the hours I have", and a single gross figure answers neither.
- **Blames people, not the process.** "Sales must follow up faster" names no owner, no system defect, no fix - and the owner history was never pulled to justify the blame.

---
name: revenue-leakage
description: Trace where deals and revenue silently exit one specific funnel and size the loss in recoverable (never gross) dollars - untracked steps, unworked leads, manual handoffs, mid-funnel stalls, paper-process drops, billing and renewal misses - separating real leaks from healthy disqualification and data-capture gaps. Use whenever the user mentions revenue leakage, funnel drop-off, a leaky funnel, deals disappearing, unworked leads, handoff gaps, "where are we losing deals", or "why did pipeline vanish" - even if they never say "leakage". Covers B2B sales-led and B2C/self-serve/PLG, one funnel instance at a time. Takes stage definitions as given - to audit those, use mbfinotti/revops-skills@pipeline-stage-definition-audit instead.
license: MIT
metadata:
  author: Maya-Beth Finotti
  version: "1.4.2"
---

# Revenue Leakage

Trace where records and dollars silently exit one specific funnel instance, prove each loss is real, size the recoverable amount, and rank the fixes by owner.

- **Lifecycle lens:** Winning by Design's Bowtie (winningbydesign.com/bowtie). Leakage spans acquisition through onboarding, renewal, and expansion, not just the sales stages - most teams over-inspect the top and never reconcile the back half.
- **Late-stage leak:** MEDDPICC's "Paper Process" element (meddicc.com/meddpicc) names the classic late-stage leak - deals that die between verbal yes and signature.
- **Working method:** process mining applied to the funnel's own event log, the approach Celonis popularized. Reconstruct the process from timestamps as it actually ran, never from the documented flowchart.

## Ground Rules

- Trace, never redesign. The stage set, routing rules, scoring model, and handoff processes are inputs. If one of them is the defect, say so in one line and route to the matching skill in Reference - do not rebuild it here.
- The deliverable is a leak register, never a hygiene checklist. Stale-deal counts, missing fields, and push counts are input signals for locating leaks; reporting them as the finding is a different skill's job (`mbfinotti/revops-skills@sales-pipeline-hygiene`). Leakage asks where records and dollars exited without an accounted-for reason, and what that is worth.
- Nothing is a leak until it passes the three-way classification below. Counting healthy disqualification as leakage is the most common false finding in this genre. Mistaking a data-capture gap for a funnel drop is the second most common.
- Size the recoverable amount, never the gross. Presenting the gross pipeline value of stalled deals as "leaked revenue" is the standard way these reports lose credibility with finance.
- Stay on one funnel instance for one period and one entry cohort. Program-level patterns across teams, funnels, or quarters are out of scope.
- Label every numeric threshold with its provenance: published practice, practitioner consensus, or derived from the user's own data. Never present a vendor heuristic as an industry constant.
- Warn off the circulating speed-to-lead statistics below - the vendor pages carrying them cite nothing:
  - "respond in 5 minutes = 100x more likely"
  - "21x more likely to qualify"
  - "average B2B response time is 42 hours"
  - "38% of leads never reply"
  - the "391% / 60-second rule"

  The HBR 2011 paper "The Short Life of Online Sales Leads" (Oldroyd, McElheran, Elkington) is real and citable as evidence that response latency matters, but the specific multipliers commonly attached to it were not verifiable. Measure the user's own response-time-vs-conversion curve and derive the threshold from that.

## The Conservation Test

Every record that enters a funnel step must leave it through exactly one countable outcome:

- **advanced**
- **closed-lost with a recorded reason**
- **disqualified/recycled with a recorded reason**
- **still open inside that step's expected dwell window**

Build the reconciliation per transition:

```
entered  =  advanced + lost(reason) + disqualified(reason) + still-open(in window)  +  residual
```

Every non-zero residual demands an explanation. Before anything is called a leak, run the three-way classification on it:

1. **Real leak** - the record was viable and stopped moving for a process, system, or ownership reason (never contacted, never accepted, stalled past window, never invoiced). Only these get sized and ranked.
2. **Healthy disqualification** - the record left for a legitimate reason and the exit was recorded. Not a leak. A funnel with zero disqualification is not healthy; it is unfiltered.
3. **Data-capture gap** - the record actually progressed but the system never recorded it: an untracked step, work living in an inbox or spreadsheet, a missing timestamp, a conversion completing in a system that never writes back. The drop is in the data, not the funnel; the fix is instrumentation, and "fixing the funnel" here fixes nothing.

**Untracked-step detection is the signature move.** For every pair of adjacent systems or owners, ask what happens in between and whether a human does it by hand. Any step performed in an inbox, spreadsheet, or chat thread has no timestamp and therefore no measurable drop-off - treat every such step as a suspected leak site until instrumented or proven pass-through. A step that produces no records carries no measurable leak; name it as an instrumentation gap instead of guessing a number.

## B2B and B2C / Self-Serve

- **B2B sales-led:** leak sites are human action points - respond, route, accept, advance, chase signature. A rep-owned pipeline exists, so residuals attach to owners.
- **B2C / self-serve / PLG:** most of the funnel has no rep-owned pipeline; the mechanism is technical rather than human - trial and checkout step drops, payment failure and dunning gaps, involuntary churn, auto-renewal misses. Involuntary churn runs 20-40% of total subscription churn (Baremetrics, citing Paddle research), and 2-5% for B2B SaaS specifically (Baremetrics' own platform data - vendor-aggregated, not an independent study).
- **Identical across both, apply without modification:** the conservation reconciliation itself, the three-way classification, the recoverable-dollar sizing rule, and the rule that an untracked step cannot be measured until instrumented. Only the leak-site catalog and the evidence types differ.

## Interview

Ask before analyzing. One question per message; multiple-choice where possible; skip anything already answered.

- Which funnel and motion: B2B sales-led, sales-assisted PLG, pure self-serve/B2C? One funnel instance only - which one?
- What triggered this investigation: a number that dropped, a board question, deals that vanished, a gut feeling?
- What are the funnel's steps as actually operated (not the official diagram), and which system holds each segment of the record trail - marketing tool, sales system, billing system, spreadsheets?
- What can actually be exported or queried: stage-change history with timestamps, owner history, closed-lost and disqualification reason codes, billing/invoice records, payment-failure events?
- Where do manual steps live today - which handoffs happen through an inbox, a spreadsheet, or a chat message?
- Who owns each funnel segment, and who owns the spaces between segments?
- Which period and entry cohort should the analysis cover? (One cohort, followed forward - never a mixed-vintage snapshot.)
- Average deal or subscription value, and the historical step-to-step conversion rates if known?
- What unexplained residual per transition are you willing to sign off on? The Pass Threshold gates on this number and it has to be yours, not this skill's. A common working bar is 5% of entering records per transition - a practitioner figure, not a published standard. Take 5% only as a placeholder when no better basis exists, and tighten it from the funnel's own reconciliation history as soon as one run produces that history.
- By what date must the recovered revenue actually land - this quarter's close, a board date, no fixed deadline? (A hard date deletes process redesign from this round's register and leads with alerts, routing fallbacks, and rework of the records already leaked.)
- Do you want a one-off recovery of the records that already leaked, or a fix that stops the leak recurring? (One-off promotes rework; compounding promotes alerts, routing fallbacks, and recovery sequences.)
- What is the effort ceiling - analyst hours only, engineering capacity available, or a cross-team process change on the table?
  - Analyst-only deletes instrumentation and redesign fixes.
  - Engineering capacity promotes recovery sequences and instrumentation.
  - A cross-team mandate is what makes process redesign rankable at all.

## Workflow

1. Run the Interview; fix the funnel, period, and entry cohort; confirm the scope boundary (trace, not redesign).
2. Map the funnel as actually operated: every step, system, owner, and handoff - including the manual ones. Mark every untracked or hand-performed step as a suspected leak site. Use [references/leak-site-inventory.md](references/leak-site-inventory.md) as the checklist of sites to probe so none is skipped.
3. If you can query the funnel's systems directly, build the conservation reconciliation per transition from the event history; otherwise derive it from exports and record samples the user provides, and mark every transition you could not reconcile as unmeasured rather than assuming it is clean.
4. Classify every non-zero residual with the three-way test, attaching evidence per record group: timestamps, owner history, reason codes, or their absence. An unclassifiable residual stays labeled "unexplained" - never promote it straight to "leak".
5. Size each confirmed real leak in recoverable dollars per [references/sizing-recoverable-revenue.md](references/sizing-recoverable-revenue.md), with a confidence tag on every figure.
6. Build the leak register (schema in Output Shape), ranked by recoverable dollars per unit of fix effort - never by dollars alone - using the fix-class ordering in [references/sizing-recoverable-revenue.md](references/sizing-recoverable-revenue.md), re-ranked against the deadline, one-off-vs-compounding, and effort-ceiling answers from the Interview. Delete a fix class the user's constraints rule out rather than demoting it, and say which constraint deleted it. Data-capture gaps get their own section with an instrumentation fix, not a dollar figure.
7. Emit the report one section at a time for user validation, grounded in the matching example from [references/worked-examples.md](references/worked-examples.md).
8. Check the Pass Threshold; iterate until it holds or every remaining gap is explicitly named as uninstrumented with a scheduled fix.
9. If the harness has persistent memory, store the funnel map, the instrumentation gaps, and the agreed residual baselines so the re-check starts from them; otherwise put all three in the report's final section so the user can paste them into the next run.

## Output Shape

Every threshold and dollar figure carries a provenance or confidence tag.

```
REVENUE LEAKAGE REPORT - <funnel>, <cohort/period>, <date>
Funnel map       : steps -> systems -> owners; manual/untracked steps flagged
Reconciliation   : per transition - entered / advanced / lost(reason) /
                   disqualified(reason) / open-in-window / residual (% of entered)
Leak register    : rank | site | evidence | classification | records affected |
                   recoverable $ (confidence) | owner | fix | fix class
                   (fix class carries the effort behind the rank; ranking basis
                   and any deleted fix class stated above the register)
Disqualification : volume left for recorded, legitimate reasons (not leakage)
Capture gaps     : untracked steps + records that progressed unrecorded;
                   instrumentation fix per gap, no dollar figure
Recoverable total: sum of register, by confidence band; never a gross figure
Re-check         : residual baselines agreed, re-run date, gaps scheduled
```

## Pass Threshold

- The unexplained residual at every reconciled transition is below the tolerance agreed with the user upfront - a common working bar is 5% of entering records per transition (practitioner working bar, not a published standard; derive a tighter one from the funnel's own history).
- Every leak register entry carries evidence, a classification, a recoverable figure with confidence tag, an owner, a fix, and that fix's class.
- Every unreconciled transition and untracked step is explicitly named as uninstrumented with a scheduled instrumentation fix - never silently omitted.
- The analysis covers exactly one entry cohort followed forward; no snapshot counts mixed with cohort flows.

Iterate until all four hold. Where instrumentation must be built before a transition can be reconciled, the report says so and schedules the re-run - that is a passing outcome; a guessed number is not.

## Common Failure Modes

| Defect                                                   | Consequence                                                                   | Fix                                                                                               |
| -------------------------------------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| Mixing cohort vintages (snapshot counts vs cohort flows) | Residuals are arithmetic noise; leaks invented or hidden                      | One entry cohort followed forward; compare like periods only                                      |
| Counting healthy disqualification as leakage             | Inflated findings; sales stops trusting the report                            | Three-way classification before anything is called a leak                                         |
| Mistaking a capture gap for a funnel drop                | "Fix" targets a funnel that isn't broken; nothing improves                    | Check for progression evidence in adjacent systems first                                          |
| Double-counting a record that leaks twice                | Recoverable total exceeds reality; credibility lost                           | Each record counts once, at its first unexplained exit                                            |
| Sizing gross pipeline value as recoverable               | Finance discounts the whole report                                            | Recoverable = records x value x onward conversion from that point                                 |
| Blaming reps for a systems defect                        | Political fight, no fix; the leak persists                                    | Attach residuals to process/system owners, not individuals, unless owner history proves otherwise |
| Guessing a number for an untracked step                  | A fabricated figure anchors the whole ranking                                 | Name it uninstrumented; instrument first, measure next run                                        |
| Deliverable drifts into a hygiene checklist              | Duplicates the hygiene skill; the "what is it worth" question goes unanswered | Every finding must state records affected and recoverable dollars or an instrumentation fix       |

## KPIs

- Track per re-run:
  - unexplained residual share per transition (trending to the agreed tolerance)
  - recovered dollars against the sized recoverable figure per fixed leak
  - share of funnel steps with timestamps (instrumentation coverage)
  - time from leak confirmation to fix ownership
- Recovered-vs-sized is the honesty check on the sizing method itself: if actual recovery consistently lands far under the sized figure, tighten the onward-conversion assumptions before the next report.
- Never report "leaks found" as the success metric - it rewards inflating the register.

## Invocation Examples

- "Our marketing team swears they sent sales 400 qualified leads last quarter and sales says they got 250. Where are we losing deals and what is it costing us?"
- "Trial signups are steady but paid conversions dropped 20% and nobody can say where in the funnel it happens. Trace the leak."
- "Deals keep disappearing between verbal commit and signed contract, and renewals seem to just lapse. Find the leakage and tell me what's actually recoverable."

## Reference

- Read [references/leak-site-inventory.md](references/leak-site-inventory.md) when mapping the funnel - the catalog of leak sites from entry to involuntary churn, with detection signals and evidence to pull per site.
- Read [references/sizing-recoverable-revenue.md](references/sizing-recoverable-revenue.md) when sizing and ranking - the recoverable-dollar formula, onward-conversion estimation, confidence tags, and ranking rules.
- Read [references/worked-examples.md](references/worked-examples.md) when shaping the deliverable - one B2B reconciliation, one self-serve/PLG reconciliation, and one report done wrong.
- See `mbfinotti/revops-skills@sales-forecast-diagnostic` when the presenting symptom is a wrong forecast number rather than vanished records.
- See `mbfinotti/revops-skills@lead-routing` when a leak site turns out to need the assignment logic redesigned.
- See `mbfinotti/revops-skills@lead-scoring` when a leak site turns out to need the score redesigned.
- See `mbfinotti/revops-skills@sales-to-cs-handoff` when the fix for a handoff leak is designing the sales-to-CS handoff itself.