evals/evals.json
{
"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 }
]
}
SKILL.md
---
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.3"
---
# 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.