The Pipeline Leak Audit
Find out where opportunities actually disappear between a lead and a customer, name why, and decide what changes. This is the complete system in one place: the checklist, the worksheets, the finding format, and the exact prompts, so you can run it on a real pipeline this week. One example runs through the whole page, a 14-person B2B services firm on HubSpot, so every blank has a filled-in version next to it.
You need one pipeline, a stage-history or activity export from whatever CRM you run on, and the willingness to look at what the record actually supports rather than what the funnel report implies. Nobody’s number is the finding. How the pipeline is run is.
- Name the pipeline
- Gather the evidence
- Run the prompt
One pipeline, one segment if you run more than one motion, one clear period. Everything below runs on that and nothing else.
If self-serve, mid-market, and enterprise deals all live in the same pipeline, don’t average across them. Their normal stage durations are different by design, and a threshold built from the blend will flag the wrong deals in both directions.
What business data to gather
Gather it before you interpret any of it. A stage-history export read while you’re forming an opinion becomes the opinion.
From the CRM
- Every deal in the period, with stage-entry and stage-exit timestamps where your CRM exposes them — closed-won ones included, since that is where your normal stage times come from
- Time-in-stage or stage-duration reports, and re-entry history where available
- Closed-lost reason field, plus any free-text note
- Activity history: calls, emails, meetings, tasks — logged and associated to the deal
- Next scheduled activity, where the field exists
- Contact roles on each deal, if your CRM tracks economic buyer or decision-maker
From the people running it
- A walkthrough from the rep or manager who owns the pipeline, in their own words
- What they log outside the CRM: mobile calls, personal inbox, texts, LinkedIn messages
- What “stalled” actually looks like to them, before you show them your own threshold
- Their honest read on which stalled deals are worth saving and which are dead
- Whatever they’d change first about the pipeline if it were entirely up to them
Stuck on the evidence?How to tell the sales team, what the CRM history will not show, and how to get the export into an assistant.
Getting the files out
- Most systems have an Export or Download button. Your CRM will have a stage-history, deal, or property-history export, usually under Reports or Data Export.
- Email: copy the thread, or forward it to yourself.
- Can’t export it? Screenshot it — these assistants read images.
- Nothing exports? Write down dates, counts, amounts, who did what.
Which assistant, how many chats
- ChatGPT, Claude, Gemini, or Copilot — pick one that can run code on a spreadsheet, so every count is computed rather than guessed. The paid tiers of ChatGPT and Claude both can.
- One conversation per process. Upload the evidence first, then the prompts, in order.
- New process, month, or account? Start a fresh chat.
- Upload failing or replies drifting? Send less at a time.
Paste this into the same assistant, with your own tool and the records you’re after filled in. It walks you to the right screen rather than sending you to documentation.
You don’t need exports to start. Copy the interview version instead: paste it into ChatGPT, Claude, or whatever you use, and it asks you for whatever evidence it needs and works from what you can describe when a file isn’t there.
Paste this into any AI assistant along with your stage-history export and your own walkthrough notes. It runs the whole method in order and will not hand you a borrowed benchmark.
I want you to help me find where deals actually disappear in "a pipeline I have not named yet (ask me first)." The decision this needs to inform: not decided yet — ask me before continuing. Your job is not to predict my close rate or quote industry conversion benchmarks. Your job is to work out which deals in my CRM export are genuinely stalled, why, and what should happen to each one, being exact about what the data can and can't support. I will give you a stage-history or activity export from my CRM, and a walkthrough of how the pipeline actually runs. Work through these stages, in order, as your working: 1. SET THE FRAME AND INVENTORY THE EVIDENCE Read back the pipeline or segment, the period, and the decision this is for. If I haven't told you one of these, ask. Then list what I gave you: each file, its columns, its row count and date range, and anything the stages below need that isn't there. Do not proceed as though a missing field is a zero. 2. BUILD THE LEDGER One row per deal: current stage, every transition with its timestamp, re-entry count, days from creation to the first logged activity, last and next activity dates, and loss reason if closed. Flag anything the data can't confirm as its own list: a skipped stage, a transition after a gap of more than twice that stage's normal time with no logged activity, a blank or generic loss reason. 3. SET THE THRESHOLD Compute the normal time in each stage for this segment from the closed-won deals in my export: the median days per stage, and the longest gap between two logged activities on any deal that still closed. If there are fewer than ten closed-won deals in the segment, stop and ask me for a normal instead. Do not assume a companywide number. A deal is stalled if it is open, has no future task, has no logged activity inside that longest gap, and its stage age is past the segment's median. 4. NAME THE CAUSE For each stalled deal, check for a missing next step first. If one exists, classify it as one of: no dated next step, budget or authority unconfirmed, indecision, champion turnover, or competitor selected. Require evidence for each classification: a named competitor, a confirmed sign-off contact, a bounced email, not an inference from silence. Where the evidence doesn't support a classification, list it as open rather than guessing. Where the walkthrough says a rep's activity goes unlogged, silence on that rep's deals is not evidence: list them as open and say what the rep needs to log. 5. TEST IT For deals with a complex or multi-stakeholder sale, apply MEDDIC. For simpler or shorter-cycle deals, apply BANT. Name the criterion that is failing for each stalled deal. 6. DECIDE, PER DEAL One action per stalled deal: book a next step, multi-thread, requalify, disqualify and reclaim the rep's time, or escalate. Disqualify only where the sole evidence is silence for more than twice the Proposal-stage median after a logged outreach that asked for an answer, and nothing in the walkthrough suggests the contact went unlogged. Justify any escalation; it should be rare. 7. FIND THE PATTERN Where the same cause recurs across deals, reps, or months, treat it as one process finding rather than several deal findings. Include slow first contact if the ledger shows it. 8. DECIDE THE PROCESS FIX For any pattern, the cheapest fix that would remove it: fixing the stage definition, adding a required field or gate, naming an owner for the stalled-deal queue, or changing what reps are measured on. Only recommend automation if you can say why the other four would not work. 9. SIZE IT Three numbers, kept separate: pipeline value at risk (every stalled deal you did not disqualify), the value of the deals you did disqualify, and rep hours reclaimed by disqualification. Where the hours come from someone's own estimate in the walkthrough, label them as that. One deal gets one cause: do not build totals by stacking multiple causes onto the same deal. HOW TO REPLY Do the stages above as your working. Do not show me the working. If a stage needs an answer from me, ask that one question and stop. Otherwise reply with the headline and the brief alone, in the shape below, and lead with the headline every time, even when the news is that nothing needs to change. Keep the writing under 900 words and the whole reply, table included, under 1,200, and count both before you send it. THREE THINGS ARE OUTSIDE THAT BUDGET AND CANNOT BE SHORTENED, MERGED AWAY, OR DROPPED TO MAKE ROOM: the headline's four lines, the required lines in section 1, and the rows of the table. Write those first, then spend what is left of the budget on the prose. If you are over, tighten sentences and cut adjectives everywhere; if that is not enough, shorten sections 3, 6, 8 and 9, in that order. Never buy words by dropping a finding, a row, a number, or a required line. Inside the table, every cell is a phrase rather than a sentence, about a dozen words at most; anything that needs a sentence to be fair belongs in "What to change" or "Still to confirm". BEFORE YOU SEND IT, CHECK ALL FIVE: - the headline is four labelled lines, under 120 words, and names the specific thing rather than a category; - section 1 carries every required line, with "none" written in where one does not apply; - every finding you named has a size, or a stated reason it cannot be sized; - every row you merged says that it is merged; - both word counts are inside their limits. If any of these fails, fix it and take the words from the prose. If I say "show your working", show the ledger and every rule you applied. THE HEADLINE Open with this. Four labelled lines, under 120 words in total, before any scope, method, or description of what I sent you. Someone who reads only these four lines has the answer. - The finding. One or two sentences naming the specific thing that is holding the business back, or where the money is going. Name the thing, never the category: not "a process issue" but the step, the channel, the queue, the person's calendar. Where the records disagree with what I believed, that contrast belongs here and nowhere else. - What it costs. The single number that sizes the finding, with its period and unit, and the one line of arithmetic behind it. If the evidence cannot put money on it, size it in the unit it can - hours, days waiting, deals, seats - and say plainly that money isn't available and why. - Do this first. The cheapest fix, what it costs, and who does it. Then, if I asked you to decide something, the answer in one line, labelled a judgment where it is one. - How sure. "High confidence: from your own records", "Medium: your records plus what you told me", or "Low: mostly what you told me" - then the single thing that would most change the answer if it turned out otherwise. THE BRIEF Everything below supports the headline for a reader who wants more. Expand it; do not restate it in the same words. 1. What this ran on. Labelled lines, not prose. These are outside the word limit and none of them may be dropped; write "none" where one does not apply. - Scope and period. - The decision this is for. - Scored: what you included, and how many. - Excluded: how many, why, and what they were worth. - Evidence pulled: the date the records were pulled. - Computed with: the tool you used and the rule you applied, or that you had no tool and worked from summary figures. 2. What the evidence covered. Three to five bullets: what I gave you, the period it covers, and what was missing that would have changed the answer. 3. What we found. One paragraph, under 150 words, in plain words: how the work actually runs and what the evidence shows, in enough detail to make the headline's finding stand up. 4. The numbers. Pipeline value at risk, the value disqualified, and rep hours reclaimed, kept separate. For each: how it was computed and which rows it rests on. 5. The ledger. One table, one row per stalled deal: stage and age, cause with its evidence, the failing criterion, and the decision. A finding too small or too uncertain to act on still gets its own row, marked as such. Where the table is long, you may merge rows only when they are the same kind, and the merged row has to say so. Never drop one. 6. What to change. Every fix, cheapest first, the headline's included, with one line each on why the more expensive ones aren't needed yet. 7. How you'd know it worked. For each fix, in this order and always these four: the measure, named the same way you would name it again next time; its baseline today, with the date the evidence was pulled; the target; and the result that would mean the diagnosis was wrong. Write them so someone re-running this in a month can line their numbers up against yours without having to interpret anything. 8. Still to confirm. Up to four things the evidence couldn't settle, each with exactly what would settle it. 9. Not claiming. Up to five claims you are refusing to make, one line each. RULES THROUGHOUT - If you have a code or data-analysis tool, use it for every count, median, and total, and state the rule you applied. If you don't, say so and ask me for summary tables instead of raw exports. - Never invent a number that is not in my evidence. Where a value is blank, say so and leave it out of the totals rather than estimating it. - Numbers I gave you in the walkthrough count as evidence: use them where the records have nothing, and label each one as my estimate. - Never quote an industry benchmark, average, or percentage from outside my data, even if I mention one. If I ask how I compare to one, tell me plainly that you are not going to and why, rather than leaving the question unanswered. - My exports often cut the same figures more than one way. Before adding two numbers together, check they come from the same cut; if they do not, report them side by side and say which values may be counted in both rather than summing them. - Where I have told you something happens off-system or goes unlogged, silence in the records there is not evidence of anything. Say what would need to be logged. - Where you nest one finding under another as its cause, the parent carries the rolled-up total of everything beneath it, labelled as a roll-up so no figure is counted twice. Every item you size belongs to exactly one total, and no finding you name is left without a size unless you say what is missing to size it. - Keep observed facts, inferences, and unknowns separate. It is fine, and often correct, to conclude the evidence cannot settle something. - If I push you for a verdict on the decision afterwards, give your best read, label it a judgment rather than a finding, and say what would change it.
The refusals matter as much as the findings. An assistant asked to audit a pipeline will happily produce a confident list of causes, because that is what the request sounds like it wants. Most of the stages above exist to make it say which conclusions the evidence can’t actually support, which is the part you’d otherwise have to catch yourself.
What you’re looking for
A CRM records when somebody edited a record. It doesn’t automatically record when a buyer moved. Before this audit can say anything about why deals stall, it has to separate the two.
The output is a short list of findings, each one a deal or a pattern, carrying the evidence that supports it and the decision that follows. It is not a close-rate percentage, and a business case resting on a stage-conversion benchmark borrowed from a vendor’s blog post is the easiest thing in the room to argue with — those figures vary by a factor of five depending on who’s publishing them, because “lead,” “qualified,” and “opportunity” mean something different at every company that uses them.
Build the deal ledger
One row per deal, at the transition grain. This is where the audit is usually lost, because a summary funnel report is sitting right there and looks like it should be enough. Full method in System 01.
| Deal | Stage | Last activity | Next step | Loss reason | Flag |
|---|---|---|---|---|---|
| Meridian Co | Proposal Sent | 23 days ago | None | — | No next step |
| Harlan Group | Proposal Sent | 4 days ago | None | — | Single contact only |
| Voss & Kerr | Closed Lost | — | — | Other | No note on file |
Set the stall threshold by segment
Full method in System 01. A single companywide threshold will flag the wrong deals in both directions.
For the mid-market segment in the worked example: a 9-day median in Proposal Sent, so anything past roughly three weeks with no future task gets flagged. That threshold caught 14 of 61 deals.
Name why each stalled deal stalled
Full lists and the seven-question review in System 02. Check for a missing next step first, before spending time on anything else.
The one that’s on you
- No dated next step. Recent activity, nothing on the calendar. Check this before anything below — it’s usually the largest bucket and the cheapest to fix.
The four that sit with the buyer
- Budget or authority unconfirmed. No sign-off contact engaged, no procurement path named.
- Indecision. Activity taper, repeated close-date slips, no new objection each time.
- Champion turnover. Single contact, engagement stops all at once.
- Competitor selected. Only when there’s a named tool or evaluation criterion to point to — not a rep’s guess.
Use BANT for shorter, lower-complexity deals and MEDDIC for multi-stakeholder ones, and run the seven-question review from System 02 against anything past its threshold. If the deal has no next step, no economic buyer confirmed, or no agreed decision process, treat it as at-risk regardless of the stage it’s sitting in.
Decide what happens to each one
Each deal gets one action. Full method, including the five process fixes, in System 03.
Then look across the decisions for a pattern: the same cause on several deals, several reps, or several months is no longer a rep-level finding. Fix the definition, the gate, the ownership, or the incentive that lets the pattern keep happening — and reach for automation only once those four have been tried and the pattern survives them.
Add it up without lying to yourself
This is the document people argue with, so keep the arithmetic honest about what kind of number each total is.
What the finished brief contains
If it’s missing any of these, it isn’t finished.
In it
- The pipeline, the segment, and the decision this was run to inform
- The stall threshold used, and why, per segment
- Every stalled deal, its cause, and the decision made
- Any pattern that recurred across deals, reps, or months, with its process fix
- Pipeline value at risk and rep hours reclaimed, reported separately
- The deals you couldn’t classify, and what evidence would settle them
Not in it
- A stage-conversion percentage borrowed from a vendor benchmark
- A close-rate trend presented without the segment and cohort behind it
- Pipeline value at risk reported as revenue already lost
- A named rep singled out for a finding that turned out to be a process gap
- A loss reason treated as fact when the evidence was only a rep’s impression
- A recommendation to buy anything, arrived at before the four cheaper fixes were tried
How often to run it again
Run it on one pipeline and you’ll have a ledger, a decision for every stalled deal, and at most one or two process fixes worth making. Run it again next quarter and you’ll be checking whether those fixes held, which is a different and shorter exercise than the first pass.
