Complete systemBuilt to be run. Everything below is yours to use, with or without us. Run it with AI gives you the evidence to pull and a prompt that already knows your scope; Understand it is the same method in reading order.

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.

  1. Name the pipeline
  2. Gather the evidence
  3. 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.

Example
The pipeline: new-business deals, mid-market segment, last two quarters
The decision this is for: whether the drop in close rate is a market problem or a pipeline-hygiene problem
Write these two lines before anything else
An audit with no decision attached is an inspection, and inspections get filed. Name what you're actually trying to decide before you pull a single export. They also feed the prompt below.

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.
How to tell the sales team
A pipeline review that arrives unannounced reads as a performance audit, and people who think they’re being graded respond by defending the number instead of describing it honestly. Say this, or something like it, before you pull a single export.
Say: “I want to look at where deals in this pipeline actually get stuck, using the CRM history rather than the summary reports. I’m not scoring anyone’s close rate. Most of what I expect to find is deals with no next step booked and a loss-reason field that isn’t telling us anything — that’s a gap in how the pipeline is run, not in how hard anyone’s working. I’ll walk the stalled list with you before anything changes, and the first thing I want is your own read on which of them are actually worth saving.”
Then do this: review the stalled list with the rep before it goes anywhere else, and let a genuine disagreement about a deal’s status stand as an open question rather than overruling it from the data alone. The CRM shows what was recorded. The rep sometimes knows something that never got typed in.
The findings are about the pipeline’s definitions, gates, and ownership. If one turns out to be about a specific rep’s performance, that’s a management conversation, and it doesn’t go in the brief.
Know what the evidence will not show you
Real buyer intent: a stage timestamp records a CRM edit, not a decision made in the buyer’s building. Corroborate with logged activity before treating a stage change as fact.
Work done off-system: the mobile call, the personal-inbox thread, the text message. “No activity” in the CRM can mean no activity happened, or it can mean nobody logged it.
The real reason a deal went cold: loss-reason fields are frequently blank, generic, or picked for speed rather than accuracy. Treat an unverified “lost to competitor” as a hypothesis, not a fact.
Whether a deal was ever real: some fraction of any pipeline is a rep being optimistic, or a prospect being polite. Nothing in the CRM distinguishes that from a genuine opportunity until you ask.
These gaps are the reason the walkthrough exists. A finding sourced only from a CRM export is worth less than one somebody who runs the pipeline confirmed out loud.

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.
Before any of it leaves your building
Check first: client material may be covered by your engagement terms or privacy law. Sending it to a third-party assistant is your call, with your lawyer if you have one.
You probably don’t need the names: dates, counts, and who did what are usually enough. Swap in Client A, Client B before you upload.
Check the setting once: consumer tiers may train on what you send; business tiers usually don’t. Worth checking before you start.
None of this is a reason to skip the exercise. It’s the reason to spend ten minutes on the first upload deciding what needs to be in it.
Can’t find the export button?

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.

Don’t have any of this together yet?

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.

Your prompt

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.

01

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.

1
Reconstruct. Build a deal-by-deal ledger from the CRM export, flagging what the record can and can’t support.
2
Flag what’s stalled. By segment, not by one companywide number — a pause that’s normal for an enterprise deal is a warning sign for a ten-day sales cycle.
3
Name the cause. One of five: no dated next step, budget or authority unconfirmed, indecision, champion turnover, or competitor selected — with evidence, not a rep’s impression.
4
Decide, per deal. Book a step, multi-thread, requalify, disqualify, or escalate.
5
Decide, per pattern. When the same cause recurs across deals, reps, or months, fix the process rather than coaching each rep separately.

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.

02

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.

The minimum ledger
Deal: id, account, owner, source, stated size
Transitions: from stage, to stage, timestamp, re-entry count
Current state: status, close date if closed, normalized loss reason, free-text note
Activity: last CRM activity, last customer-facing activity if distinguishable, next scheduled activity
People: contacts engaged, economic buyer confirmed yes/no, champion’s last-engaged date
Flag, don’t discard, anything the export can’t confirm: a skipped stage, a transition right after a long silence, a blank loss reason. Those flags are findings in their own right, before you’ve looked at a single deal’s content.
Example — three of 61 rows in the ledger
DealStageLast activityNext stepLoss reasonFlag
Meridian CoProposal Sent23 days agoNoneNo next step
Harlan GroupProposal Sent4 days agoNoneSingle contact only
Voss & KerrClosed LostOtherNo note on file
Scroll sideways for the rest of each row.
Meridian and Harlan look identical on a stage report: both “stalled in Proposal.” The ledger already shows they need different things — Meridian a booked call, Harlan a second contact.
03

Set the stall threshold by segment

Full method in System 01. A single companywide threshold will flag the wrong deals in both directions.

Write this before you run the flag
Segment: ______
Normal time in this stage, from your own closed-won history: ______
Stalled means: open, no future task, no qualifying activity inside the segment’s normal gap, and stage age past the segment’s median

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.

04

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.

05

Decide what happens to each one

Each deal gets one action. Full method, including the five process fixes, in System 03.

1
Book the next step
2
Multi-thread
3
Requalify
4
Disqualify, and reclaim the time
5
Escalate, rarely

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.

The shape of a decision
Finding: the deal or pattern, and its cause
Decision: book / multi-thread / requalify / disqualify / escalate, or a process fix
Change: what’s different by name, and who owns it
Expected: what should be different, measured how, by when
Reversal: what result would say the diagnosis was wrong
06

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.

Three rules that keep the total honest
One deal, one cause. Give a stalled deal a single primary reason. Where two candidates are plausible, write both and say which decided it.
Pipeline value is at risk, not lost. The dollar value of stalled deals is what could still close if the decisions above work. Report it as exposure.
Reclaimed rep time is the other number. Disqualifying a dead deal doesn’t recover pipeline value — it recovers hours a rep was spending on something that was never going to close. Report the two separately; they answer different questions and get added to different totals.
07

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
Example — the pipeline brief, on one page
Pipeline, decision: mid-market new business, last two quarters; whether the close-rate drop is a market problem or a hygiene problem.
Threshold: Proposal Sent, mid-market: stalled past 21 days with no future task, against a 9-day median.
Stalled deals, by cause: 6 no next step (booked this week) · 5 budget/authority unconfirmed (multi-threading push) · 1 indecision (requalified) · 1 competitor selected, evidence-backed (disqualified) · 1 champion turnover (30-day watch).
Pattern found: 22 of 31 closed-lost deals this period carry “Other” with no note — not five reps forgetting, but a field with no required options.
Process fix: a short controlled loss-reason list, required before a deal can close lost, with an optional note above a size threshold. No new software.
Reversal: if “Other” is still above one in five closed-lost deals a quarter after the field is required, the next place to look is the incentive for closing quickly over closing accurately.
One page, no borrowed benchmark. The close-rate drop turns out to be mostly hygiene: real pipeline value sitting unattended rather than a shift in the market.

How often to run it again

Recommended cadence
Weekly. Deals move daily. A stall caught in week one is still recoverable; the same stall at day sixty usually isn’t.
The first run is the one that surprises you. Every run after it is doing a different job: checking whether the fixes moved the measures this brief set, and catching what is new. That is a shorter exercise than the first pass, and it is the point at which this stops being a one-off and starts being a habit. How to put it on a schedule →

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.