Field guide
Pipeline Debugging Scenarios: Ten Broken GTM Systems
Play it: the Pipeline Debugger game
Most GTM failures do not announce themselves. Every tool in the chain reports green, and the loss shows up weeks later as a missed number. Debugging a pipeline means starting from the symptom the team can actually see and walking the system backwards, one step at a time, until you reach the step whose behavior explains the whole symptom. The fix goes there.
Each scenario below has the same shape: the symptom, a diagram of the system with the broken step marked, the root cause and why it is the root cause, the fix and the named patterns it applies, why the tempting alternatives fail, and the leak written as a formula in variables. The first seven map to the seven revenue leaks; the last three cut across several of them.
The figures in each section are the labeled scenario inputs, fictional worked-model inputs shared with the free diagnostic. They are there so the formulas have something to point at, not as measurements of anyone. When you want to score a real system, use the teardown rubric self-check.
The ten scenarios
- The unanswered demo request (Slow lead response)
- The invisible visitor (Anonymous website traffic)
- The wrong list (Weak ICP targeting)
- The silent sequence (Low outbound reply rates)
- The dropped handoff (Leaky MQL-to-SQL handoff)
- The cold middle (Thin nurture)
- The same page for everyone (Undifferentiated conversion content)
- The forked record (Cross-cutting (spans several leaks))
- The alert nobody owns (Cross-cutting (spans several leaks))
- The sequence that emailed a customer (Cross-cutting (spans several leaks))
1. The unanswered demo request
Slow lead response
Symptom
Demo requests reach the CRM within seconds of the form submit, but the first human reply often lands the next business day. Reps say they never saw the lead, and every tool in the chain shows green.
- Round-robin router (broken): Assigns the lead to a shared queue, not a named rep, and starts no clock.
- Hourly email digest (broken): Batches new leads into a digest sent to a shared inbox nobody owns.
| Scenario input | Value |
|---|---|
| Inbound leads per month | 400 |
| Average contract value (ACV) | $25,000 |
| Opportunity win rate | 20% |
| Website visitors per month | 20,000 |
| Outbound SDR seats | 2 |
| MQLs never worked per month | 20 |
Root cause
The router parks the lead in a shared queue with no named owner and no clock, and the only alert is a batched digest, so nobody is accountable for the first touch.
A lead without an owner and a timer is everyone's and therefore no one's, which is exactly the gap between a fast CRM write and a slow human reply.
The fix
Assign a named owner of record when the lead is created and start an SLA timer that escalates to a backup rep, then a manager, if no first touch is logged.
Ownership makes one person accountable and the escalating timer catches the moment that person is busy, asleep or out.
Patterns applied: SLA Timer with Escalation and Owner-of-Record Routing.
Why the other answers are wrong
- Root cause, “The form asks too many questions, so buyers abandon it and the leads that do arrive are already cold.” The leads are arriving and being written to the CRM in seconds, so the delay sits after the form, not in it.
- Root cause, “Enrichment is slow and holds the record until every field is filled.” The record reaches the CRM within seconds, so enrichment is not what holds the reply for a day.
- Root cause, “The follow-up sequence copy is weak, so buyers ignore the first email.” Copy decides whether a buyer replies, but here the problem is that no human reaches out in time at all.
- Fix, “Send an instant auto-reply email and count it as the first response.” An auto-reply acknowledges the request but no human has engaged, so the leak is still open and the metric now hides it.
- Fix, “Hire another SDR so the queue gets worked faster.” A bigger team working a shared queue with no owner and no clock reproduces the same gap with more payroll.
- Fix, “Add qualifying fields to the form so reps can prioritize the queue.” Better context does not help when nobody is told the lead exists, and longer forms lose buyers.
The leak, as a formula
leads per month x months per year x change in lead-to-opportunity rate from a faster first human response x win rate x ACV
Put your own numbers into each variable; the arithmetic, and how to keep an estimate honest, is in the EVE revenue leak framework. Matching guide: read the guide for this failure.
2. The invisible visitor
Anonymous website traffic
Symptom
The pricing page is among the most visited pages on the site, yet almost none of those visits become a known account in the CRM. A visitor identification script was installed months ago, its dashboard shows company matches, and sales has stopped opening the alerts.
- Visitor ID script (broken): Loads outside the consent manager, so it is blocked on many sessions and not permitted on others.
- Single page-view trigger (broken): Any one matched page view fires an alert, with no fit, intent or repeat-visit check.
| Scenario input | Value |
|---|---|
| Inbound leads per month | 400 |
| Average contract value (ACV) | $25,000 |
| Opportunity win rate | 20% |
| Website visitors per month | 20,000 |
| Outbound SDR seats | 2 |
| MQLs never worked per month | 20 |
Root cause
The script runs outside the consent layer, so identification is blocked or not allowed on many sessions, and the matches it does make fire on a single page view, so sales learned the alerts are noise.
Both halves are needed to explain the symptom: too few lawful matches going in, and too little signal on each match coming out.
The fix
Load identification behind the consent manager with region rules, and alert only when a matched account stacks fit, a high-intent page and a repeat visit.
Consent gating makes each match usable, and stacking signals means the alert a rep receives is worth acting on.
Patterns applied: Consent-Gated Identification and Signal Stacking.
Why the other answers are wrong
- Root cause, “The visitor identification vendor is simply inaccurate and needs replacing.” Swapping vendors keeps the same consent placement and the same single-view trigger, so the new tool inherits both faults.
- Root cause, “The pricing page copy is weak, so visitors leave before they can be identified.” Identification happens on load, not on conversion, so page copy does not decide whether a visit is matched.
- Root cause, “The CRM sync is broken and matched accounts never arrive.” Alerts are being sent and ignored, which means records are flowing; the problem is what they are worth when they arrive.
- Fix, “Lower the match threshold and alert on every identified company so nothing is missed.” More unqualified alerts deepen the habit of ignoring them and do nothing about the sessions the consent layer blocks.
- Fix, “Put the pricing page behind a form so every visitor has to identify themselves.” Gating pricing trades anonymous visits for abandoned ones and hides the page buyers use to decide whether to talk to you.
- Fix, “Add a second identification script and merge the two match lists.” Two scripts outside the consent layer double the exposure and still feed the same single-view trigger.
The leak, as a formula
visitors per month x change in identification rate x share of identified accounts that fit the ICP x account-to-opportunity rate x win rate x ACV
Put your own numbers into each variable; the arithmetic, and how to keep an estimate honest, is in the EVE revenue leak framework. Matching guide: read the guide for this failure.
3. The wrong list
Weak ICP targeting
Symptom
Outbound books first meetings, but most of them stall after the first call. The account list is every company in a few industries above a headcount line, scored once on fit, and the SDRs work it from the top.
- Closed-won history: Never read when the list was built.
- Firmographic filter: Industry and headcount only.
- Fit-only account score (broken): Scores who an account is, never what is happening there now, so a company with no live problem scores the same as one with an open one.
| Scenario input | Value |
|---|---|
| Inbound leads per month | 400 |
| Average contract value (ACV) | $25,000 |
| Opportunity win rate | 20% |
| Website visitors per month | 20,000 |
| Outbound SDR seats | 2 |
| MQLs never worked per month | 20 |
Root cause
Accounts enter the list on fit alone, with no evidence of a current problem or a reason to act now, so meetings happen with companies that have nothing to buy for.
Meetings that stall after the first call are the signature of a fit-only list: the account looks right and has no live pain.
The fix
Require a stacked signal before an account enters the list: fit, plus at least one pain or timing signal such as a relevant hire, a new revenue leader or a stack change, checked against what closed-won accounts looked like before they bought.
The fault is who enters the list, and stacking a pain signal on top of fit changes who enters; capacity bands were the other candidate and come second, because they only ration a list once its score means something.
Patterns applied: Signal Stacking.
Why the other answers are wrong
- Root cause, “The SDRs are not qualifying hard enough on the first call.” Better qualification would end the stalled meetings sooner, but it cannot create demand that the list never selected for.
- Root cause, “The list is too small, so SDRs run out of good accounts.” The SDRs are booking meetings, so volume is not the constraint; the meetings themselves go nowhere.
- Root cause, “The sequence copy over-promises, so buyers feel misled on the call.” Copy can set the wrong expectation, but the pattern holds across sequences, which points upstream to who is on the list.
- Fix, “Re-tier the existing list into capacity-bound bands so the SDRs only work the top band.” Bands ration a list by what the team can work, but every account here was scored on fit alone, so the top band is still the wrong list.
- Fix, “Widen the filter to more industries so there are more accounts to work.” A wider fit-only filter adds more accounts with no live problem and makes the stall rate worse, not better.
- Fix, “Add more steps to the sequence so each account gets more attempts.” More touches on the wrong accounts produce more stalled meetings, not more pipeline.
The leak, as a formula
SDR seats x meetings per SDR per month x months per year x change in meeting-to-opportunity rate x win rate x ACV
Put your own numbers into each variable; the arithmetic, and how to keep an estimate honest, is in the EVE revenue leak framework. Matching guide: read the guide for this failure.
4. The silent sequence
Low outbound reply rates
Symptom
Reply rates on the main outbound sequence have slid quarter over quarter. Many sends open with an empty personalization line or a generic fallback, and a share of them bounce.
- Single-source enrichment (broken): One provider, no fallback and no validity check, so blanks and stale emails pass straight through.
- Outbound sequence (broken): Sends when a contact joins the list, with no hold for missing fields and no trigger beyond list membership.
| Scenario input | Value |
|---|---|
| Inbound leads per month | 400 |
| Average contract value (ACV) | $25,000 |
| Opportunity win rate | 20% |
| Website visitors per month | 20,000 |
| Outbound SDR seats | 2 |
| MQLs never worked per month | 20 |
Root cause
A single enrichment source returns blanks and stale emails, and the sequence sends anyway on list membership alone, so many messages are generic, mistimed or undeliverable.
Empty personalization lines and bounces trace to the data, and sending with no trigger explains why even the complete messages land at the wrong time.
The fix
Run enrichment as an ordered waterfall with a fallback provider and a validity check per field, hold any contact missing a required field, and trigger the send on a stacked signal instead of list membership.
The waterfall fills and verifies the fields the message depends on, and the stacked trigger sends the complete message at a moment it is relevant.
Patterns applied: Enrichment Waterfall with Fallback and Signal Stacking.
Why the other answers are wrong
- Root cause, “The subject lines are stale and need A/B testing.” Subject lines affect opens, but blank first lines and bounces are data faults no subject line can fix.
- Root cause, “The team is sending too much volume and mailbox reputation is the whole problem.” Reputation can add to bounces, but it does not explain the blank personalization fields on messages that do arrive.
- Root cause, “The market is saturated with outbound and buyers no longer reply to anyone.” A market-wide shift would not show up as empty personalization lines in your own sends.
- Fix, “Write a better generic fallback line for contacts with missing data.” A polished fallback is still a generic message, and it does nothing about the bounces.
- Fix, “Have an AI model rewrite every email from the company name alone.” A model writing from one field produces fluent generic copy and will invent specifics the data does not support.
- Fix, “Add more follow-up steps so each contact gets more chances to reply.” More steps multiply the generic and undeliverable sends that are causing the slide.
The leak, as a formula
SDR seats x emails sent per SDR per month x months per year x change in positive reply rate x meeting-to-opportunity rate x win rate x ACV
Put your own numbers into each variable; the arithmetic, and how to keep an estimate honest, is in the EVE revenue leak framework. Matching guide: read the guide for this failure.
5. The dropped handoff
Leaky MQL-to-SQL handoff
Symptom
Marketing reports MQLs up; sales reports pipeline flat. In the CRM, a share of each month's MQLs have no activity at all, and many of the ones that were worked were rejected with no reason recorded.
- MQL threshold (broken): Set by marketing alone; sales never agreed what it means, so reps do not trust it.
- Status change only (broken): The lead status flips to MQL but no owner changes and no task is created.
| Scenario input | Value |
|---|---|
| Inbound leads per month | 400 |
| Average contract value (ACV) | $25,000 |
| Opportunity win rate | 20% |
| Website visitors per month | 20,000 |
| Outbound SDR seats | 2 |
| MQLs never worked per month | 20 |
Root cause
There is no shared definition of a sales-ready lead, and crossing the threshold changes a status without assigning anyone, so some MQLs are never seen and others are rejected without a reason.
Unworked MQLs come from the missing owner, and silent rejections come from a threshold sales never agreed to.
The fix
Write one MQL definition that sales and marketing both sign, with accept and reject reason codes, and assign a named owner with a dated task whenever a lead crosses it.
The shared definition makes the threshold mean the same thing to both teams, and the owner and task make every MQL someone's job.
Patterns applied: Shared Handoff Definition and Owner-of-Record Routing.
Why the other answers are wrong
- Root cause, “Marketing is not generating enough MQLs.” MQL volume is up while pipeline is flat, so the loss is after the MQL, not before it.
- Root cause, “The SDRs are not doing their job.” Reps cannot work leads nobody assigned to them, and blaming people hides a system that never told them.
- Root cause, “The nurture track is broken, so recycled leads never come back.” Recycling only happens after a lead is worked or rejected, and the symptom is leads that were never worked at all.
- Fix, “Raise the MQL threshold so only the best leads reach sales.” A higher threshold nobody agreed to still produces leads nobody owns; it just produces fewer of them.
- Fix, “Hold a weekly sales and marketing meeting to review MQLs by hand.” A meeting can surface the problem once a week, but leads still sit unassigned for the days in between.
- Fix, “Auto-enroll every MQL into an email sequence so none are left untouched.” Automated emails make the activity column look full while no human has qualified anything.
The leak, as a formula
MQLs never worked per month x months per year x MQL-to-opportunity rate x win rate x ACV
Put your own numbers into each variable; the arithmetic, and how to keep an estimate honest, is in the EVE revenue leak framework. Matching guide: read the guide for this failure.
6. The cold middle
Thin nurture
Symptom
A large group of contacts carry high lead scores but have not engaged in months. Reps get hot-lead alerts on them, call, and find the interest long gone, while recently active accounts with lower lifetime scores sit untouched.
- Lifetime lead score (broken): Points only ever add up; nothing expires, so a burst of activity long ago outranks interest this week.
- Nurture track: Contacts never re-enter it, because their scores never fall.
| Scenario input | Value |
|---|---|
| Inbound leads per month | 400 |
| Average contract value (ACV) | $25,000 |
| Opportunity win rate | 20% |
| Website visitors per month | 20,000 |
| Outbound SDR seats | 2 |
| MQLs never worked per month | 20 |
Root cause
The score only accumulates and never decays, so it measures how much a contact ever did, not how interested they are now.
Stale contacts outranking active ones is exactly what a score with no decay produces over time.
The fix
Decay engagement points on a half-life so the score reflects recent behavior, and move contacts whose score falls below the line back into a nurture track that re-scores them on fresh intent.
Decay lets the score fall when interest does, which both clears stale alerts and gives nurture a clear entry and exit.
Patterns applied: Score Decay.
Why the other answers are wrong
- Root cause, “The webinars attract the wrong audience.” These contacts did engage and were real prospects once; the problem is that the score never noticed they stopped.
- Root cause, “Routing sends hot leads to the wrong reps.” The reps are reaching the right people; the people are no longer hot, which is a scoring fault.
- Root cause, “Nurture sends too few emails to keep contacts warm.” Send volume does not explain why active accounts are ranked below dormant ones.
- Fix, “Reset every score to zero once a year.” An annual reset is one big decay step: stale between resets, and it erases genuinely recent interest on reset day.
- Fix, “Raise the hot-lead threshold so fewer alerts fire.” A higher line on a score that never falls still ranks old activity above new, just with fewer alerts.
- Fix, “Tell reps to check last activity date before calling.” Pushing the check onto reps adds manual work to every alert and leaves routing ranking the wrong contacts.
The leak, as a formula
dormant ICP contacts x re-engagement-to-opportunity rate x win rate x ACV
Put your own numbers into each variable; the arithmetic, and how to keep an estimate honest, is in the EVE revenue leak framework. Matching guide: read the guide for this failure.
7. The same page for everyone
Undifferentiated conversion content
Symptom
Identified, in-market accounts from two very different segments land on the same pricing and demo pages, and one segment almost never books. The pages say what every competitor says, and the demo form asks everyone the same questions.
- Segment and stack data: Known, but never used by the page.
- One pricing and proof page (broken): One proof block, one comparison and one next step for every segment.
| Scenario input | Value |
|---|---|
| Inbound leads per month | 400 |
| Average contract value (ACV) | $25,000 |
| Opportunity win rate | 20% |
| Website visitors per month | 20,000 |
| Outbound SDR seats | 2 |
| MQLs never worked per month | 20 |
Root cause
The decision-stage page answers one segment's questions and not the other's, and the signals that say which segment a buyer is in never reach the page.
Identified, in-market buyers who still do not book are telling you the page did not answer their decision question.
The fix
Stack the signals you already hold (segment, pages read, the alternative being evaluated) to choose which proof block, comparison and next step the page shows, and write a real answer for each segment's decision question.
The stacked signals pick the right answer and the rewritten blocks make sure there is a right answer to pick.
Patterns applied: Signal Stacking.
Why the other answers are wrong
- Root cause, “The second segment is low-intent traffic and should be ignored.” These accounts are identified and in-market, so intent is present; the page is what fails them.
- Root cause, “The price is too high for the second segment.” Price may matter, but a page that never states why you over the alternative for that segment loses before price is weighed.
- Root cause, “The demo form is broken on some browsers.” A technical fault would hit both segments, and only one of them is failing to book.
- Fix, “Rewrite the headline to be bolder and more benefit-led.” A bolder headline that is the same for everyone still leaves the second segment's question unanswered.
- Fix, “Add a chatbot to the page to answer questions.” A chatbot moves the work onto the buyer, who has to know to ask, and it has nothing better to say than the page does.
- Fix, “Offer the second segment a discount.” Discounting treats a missing reason to buy as a price problem and trains the segment to wait for offers.
The leak, as a formula
identified in-market accounts per month x months per year x change in page-to-opportunity rate x win rate x ACV
Put your own numbers into each variable; the arithmetic, and how to keep an estimate honest, is in the EVE revenue leak framework. Matching guide: read the guide for this failure.
8. The forked record
Cross-cutting (spans several leaks)
Symptom
One buyer submitted the demo form once and now exists as several leads in the CRM, each with a different owner, and two of them were enrolled in the same sequence. Reporting counts the demo request more than once.
- Demo form webhook: Retries on any slow response.
- Visitor ID sync: Writes the same person from a second source.
- Lead create step (broken): Inserts a new record on every event, with no idempotency key and no match on an existing record.
| Scenario input | Value |
|---|---|
| Inbound leads per month | 400 |
| Average contract value (ACV) | $25,000 |
| Opportunity win rate | 20% |
| Website visitors per month | 20,000 |
| Outbound SDR seats | 2 |
| MQLs never worked per month | 20 |
Root cause
The create step inserts on every event it receives, so webhook retries and the second source each create a new lead instead of updating the one that exists.
Several records with different owners from one submission is the signature of a non-idempotent write.
The fix
Give every inbound event a stable idempotency key, such as source plus event id, upsert on that key and on a normalized match to the existing person, and make retries no-ops.
An idempotent write means the same event can arrive any number of times and still produce one record and one owner.
Patterns applied: Idempotent Event Ingestion.
Why the other answers are wrong
- Root cause, “The buyer submitted the form several times.” The form log shows one submission, and the duplicates also arrive from the visitor sync, which a person cannot double-submit.
- Root cause, “Round-robin assignment is randomizing owners.” Round-robin did its job on each record it was given; the fault is that it was given several.
- Root cause, “The weekly dedupe job did not run.” A cleanup job runs after the damage, when owners have already been assigned and sequences have already sent.
- Fix, “Schedule a nightly merge job to combine duplicates.” A nightly merge cleans up after the duplicate owners and double enrollments have already happened.
- Fix, “Turn off webhook retries.” Without retries a real network failure loses the lead entirely, and the second source still duplicates.
- Fix, “Disconnect the visitor ID sync so only the form writes leads.” Dropping a source removes signal and leaves the retry duplicates untouched.
The leak, as a formula
duplicate records per month x months per year x share that cause a missed or doubled first touch x lead-to-opportunity rate x win rate x ACV
Put your own numbers into each variable; the arithmetic, and how to keep an estimate honest, is in the EVE revenue leak framework. Matching guide: read the guide for this failure.
9. The alert nobody owns
Cross-cutting (spans several leaks)
Symptom
The hot-lead channel posts dozens of alerts a day, many of them repeats for the same account, and the reps have muted it. When leadership asks how fast hot leads are worked, nobody can answer, because the CRM only stores when each lead was created.
- Owner lookup: Knows the owner but the alert ignores it.
- Channel alert (broken): Fires on every qualifying event to a shared channel, with no dedup, no named owner and no clock.
- CRM lead record (broken): Stores created time only; no alerted, claimed or first-touch time.
| Scenario input | Value |
|---|---|
| Inbound leads per month | 400 |
| Average contract value (ACV) | $25,000 |
| Opportunity win rate | 20% |
| Website visitors per month | 20,000 |
| Outbound SDR seats | 2 |
| MQLs never worked per month | 20 |
Root cause
Repeat events each fire their own alert into a shared channel with no owner and no timer, and nothing writes back when an alert was claimed or worked, so the channel is noise and the response time is unmeasurable.
Muted reps come from noise and no owner, and the unanswerable question comes from timestamps that were never written.
The fix
Collapse repeat alerts for the same account inside a dedup window, address each alert to the owner of record with an SLA timer that escalates when unclaimed, and write four timestamps back to the record: created, alerted, claimed and first touch.
Dedup restores trust in the channel, the timer makes each alert someone's job, and the timestamps make speed measurable.
Patterns applied: Alert Dedup Window, SLA Timer with Escalation and Four-Timestamp Write-Back.
Why the other answers are wrong
- Root cause, “The reps are ignoring alerts and need to be managed harder.” Muting a channel that repeats itself all day is a rational response to a system fault, not a discipline problem.
- Root cause, “The hot score threshold is too low.” A higher threshold reduces volume, but repeats still fire per event and the CRM still cannot say how fast anything was worked.
- Root cause, “Slack is the wrong place for alerts; they should be emails.” Moving the same repeated, unowned alerts to email moves the noise without fixing it.
- Fix, “Replace live alerts with one daily digest of hot leads.” A digest removes the noise by removing the speed, which is the reason the alert existed.
- Fix, “Split the channel into one per region.” Smaller channels still repeat per event, still have no owner per alert and still write no timestamps.
- Fix, “Build a response-time dashboard from created time and close date.” Created time and close date cannot show response speed; the timestamps in between were never recorded.
The leak, as a formula
hot leads per month x months per year x change in lead-to-opportunity rate from a faster claimed response x win rate x ACV
Put your own numbers into each variable; the arithmetic, and how to keep an estimate honest, is in the EVE revenue leak framework. Matching guide: read the guide for this failure.
10. The sequence that emailed a customer
Cross-cutting (spans several leaks)
Symptom
A cold outbound sequence emailed the champion at a current customer, and another step went to a contact at an open opportunity owned by a different rep. The list came from a signal tool and went straight into the sequencer.
- Unsubscribe check (broken): Checks the unsubscribe list only, once, at import.
- Customers and open deals: Holds the truth about who must not get cold outreach, but is never consulted at send time.
| Scenario input | Value |
|---|---|
| Inbound leads per month | 400 |
| Average contract value (ACV) | $25,000 |
| Opportunity win rate | 20% |
| Website visitors per month | 20,000 |
| Outbound SDR seats | 2 |
| MQLs never worked per month | 20 |
Root cause
Suppression checks only unsubscribes, once, at import, and never checks the CRM for customers, open opportunities or other owners at send time.
Both bad sends were to people the CRM knew about, which means the one place that knew was never asked.
The fix
Put a suppression ring in front of every send: current customers, open opportunities, contacts owned by another rep, partners, unsubscribes and do-not-contact flags, checked live against the CRM at enrollment and again before each step.
A ring checked at enrollment and before each step catches both the contact who was a customer at import and the one who became an opportunity mid-sequence.
Patterns applied: Suppression Ring.
Why the other answers are wrong
- Root cause, “The signal tool returned bad data.” The contacts were real and correctly matched; the fault is that nobody checked who they already were to you.
- Root cause, “The rep who built the list should have checked it by hand.” Hand checks fail at volume and on the day someone is busy, which is why suppression belongs in the system.
- Root cause, “The sequence copy was too aggressive for a customer.” No cold copy is right for a current customer; the message should never have been sent.
- Fix, “Export the customer list monthly and upload it to the sequencer as a block list.” A monthly export is stale for every deal opened since, and it misses open opportunities and other owners entirely.
- Fix, “Require a manager to approve every list before it is enrolled.” Approval adds a human bottleneck and still checks once, before the contacts who change status mid-sequence.
- Fix, “Stop using signal tools for outbound lists.” Any list source, including your own, can contain customers; the missing piece is the check, not the source.
The leak, as a formula
wrongly enrolled contacts per month x months per year x share that damage an open deal or a renewal x win rate x ACV
Put your own numbers into each variable; the arithmetic, and how to keep an estimate honest, is in the EVE revenue leak framework. Matching guide: read the guide for this failure.
How to use these scenarios
Read the symptom first and stop before the diagram. Write down which step you would inspect and what you expect to find. Then compare. The habit worth building is not memorizing ten answers; it is refusing to fix a symptom until one cause explains all of it, and asking of every proposed fix whether it changes the broken step or only the number on the report.
Play it: the Pipeline Debugger game
Frequently asked questions
What is pipeline debugging?
How were these ten scenarios chosen?
Are the numbers in the scenarios real?
How does scoring work in the Pipeline Debugger game?
How do I cite a scenario?
Done for you
Want this built inside your stack?
Artemis GTM is a GTM engineering consulting firm that builds and runs outbound and inbound GTM systems for seed to Series C B2B startups, hands-on, in three to six months, then hands them over. One evaluation call, a written scoping note, a custom quote.
Book an evaluationNot an engagement yet? Install the free AI GTM Engineer