mbfinotti/revops-skillsCheck passed
SKILL DETAIL
sales-pipeline-hygiene
mbfinotti/revops-skills/sales-pipeline-hygiene
Run a periodic, checklist-based hygiene audit over an active pipeline snapshot - stale deals (no stage, close date, or amount change, not logged touches) flagged against segment-specific stage medians, close-date push-count anomalies, and missing forecast-critical fields - producing an exception list with a disposition per flagged deal, a remediation plan, and a pass threshold. Use whenever the user mentions pipeline hygiene, a stale deal audit, pipeline cleanup before a QBR, deals that keep pushing, a close date that keeps slipping, missing fields on deals, or "our pipeline is full of junk" - even if they never say "hygiene". Covers B2B and B2C/high-velocity/PLG. Do NOT use for rewriting stage definitions - use mbfinotti/revops-skills@pipeline-stage-definition-audit instead.
Installs · 172View source
Installation
npx skills add https://github.com/mbfinotti/revops-skills --skill sales-pipeline-hygiene
Skill files
SKILL.md
Last synced · Sep 15, 2026
evals/evals.json›
{
"skill_name": "sales-pipeline-hygiene",
"evals": [
{
"id": 1,
"prompt": "I run sales ops at Harlowe Systems - mid-market B2B security software, roughly 95-day average cycle. Board QBR is in three weeks and our pipeline is full of junk. We have 312 open opportunities worth $11.4M. Our current rule is: if a rep hasn't logged a call or an email on a deal in 30 days, it's stale. By that rule only 22 deals are stale, which literally nobody in the room believes. So I pulled average days-in-stage across all 312 open deals, got 41 days, and I was going to flag anything sitting past 41 days in a stage. Reported coverage is 4.1x. Give me the audit.",
"expected_output": "A pipeline hygiene audit that first replaces the logged-touch staleness definition with a field-change definition, rebuilds the baselines from closed-deal history with the dead tail excluded, sets segment-specific thresholds, sizes the stale layer into four buckets, restates coverage honestly, and recommends an amnesty before any enforcement.",
"files": [],
"expectations": [
"Redefines stale so the primary trigger is a change to Stage, Close Date, or Amount, not a logged call or email",
"Keeps last-activity age as a second, independent trigger rather than discarding it or substituting it for the field-change rule",
"States explicitly that a rule keyed on logged touches can be satisfied without the deal progressing at all",
"Rejects deriving the baseline from the 312 open deals and directs using 12-18 months of closed (won and lost) deal history instead",
"Uses median days-in-stage rather than the 41-day average, and says why a mean is dragged by long-sitting deals",
"Excludes the stale layer from the history before computing medians, stating that a dead tail flattens the close curve",
"Sets thresholds per segment as a multiple of that segment's own median - roughly 1.5x for high-velocity up to 2.0x for enterprise - not one flat day count across the whole book",
"Buckets stale pipeline value into four bands: under 90, 90-180, 180-365, and over 365 days since last meaningful change",
"Recomputes coverage excluding the over-365-day bucket and reports it beside the 4.1x headline figure",
"Recommends running a pipeline amnesty before any enforcement if stale value exceeds roughly 20-30% of pipeline value",
"Does not propose auto-closing or deleting the flagged deals",
"Produces an exception list carrying, per flagged deal, a proposed disposition, a named owner, and a recorded reason",
"Flags deals whose next step is dated in the past or which have no scheduled future meeting"
]
},
{
"id": 2,
"prompt": "Cedarloop, B2B SaaS, about 60 reps. Our opportunity records are a mess: only 44% of open deals have a next step, close date is blank on 9%, and loss reason is filled on 31% of closed-lost. My plan is to make 14 fields required on the opportunity object so nothing can be saved without them, and to run a quarterly $500 spiff for the rep with the highest field-completion score. Sales leadership already green-lit the spiff. What completeness targets should I set and how do I roll this out?",
"expected_output": "A completeness plan that rejects both the 14 required fields and the completion spiff, scopes the check to forecast-critical fields, sets 90-95% targets with an 80% floor, and remediates in the stated efficiency order led by a stage-gated validation rule.",
"files": [],
"expectations": [
"Rejects adding 14 required fields and states that heavy requirement produces fabricated placeholder values at scale",
"Recommends holding required fields to a cap of roughly 5-7 per object",
"Ranks a stage-gated validation rule first, ahead of an owner nudge, ahead of auto-capture",
"States that ordering out loud rather than leaving three remedies as an unranked list",
"Distinguishes a required field (checks that something was entered) from a validation rule (checks that what was entered makes sense)",
"Rejects the completion-based spiff and states that comp tied to field completion produces fast, complete, low-quality data",
"If comp touches hygiene at all, ties it to forecast accuracy as an outcome rather than to field completion as an input",
"Scopes the completeness check to forecast-critical fields only, not the whole schema",
"Names amount, stage, and close date as the highest-value targets because they are the meaningful-activity fields themselves",
"Sets a completeness target of 90-95% on forecast-critical fields with 80% as the minimum floor",
"Directs checking populated fields for fabricated placeholders - sentinel values, identical boilerplate next steps, next-step dates always exactly N days out, amounts stuck on a round default - and counting them as empty",
"Reports each field's completeness next to the decision it feeds rather than as a bare percentage"
]
},
{
"id": 3,
"prompt": "Meridian Fabrics, enterprise B2B, average deal $180K, six-to-nine month cycles. Of 140 open deals, 34 have moved their close date at least once this year, 11 have moved it twice, and 4 have moved it three or more times. Two of the three-movers have been sitting in the customer's legal review for seven weeks. My VP wants to close-lost everything that has pushed more than once and be done with it. Build me the push report and tell me what to do with these.",
"expected_output": "A push-count report that escalates rather than closes, separates slipping from dead using stacked buyer-side evidence, exempts legal and procurement stalls, and leaves disposition with the manager and rep.",
"files": [],
"expectations": [
"Rejects the VP's plan to close-lost every deal that has pushed more than once",
"Names the second push as the escalation trigger that moves a deal to manager inspection, not to closure",
"Treats three or more slips as disqualification-warranting rather than as automatic closure",
"Exempts the deals sitting in legal or procurement review from stale or dead treatment",
"Requires a stated reason on any close-date change that crosses a period boundary, and separates those pushes from in-quarter nudges",
"Applies an evidence test - what has to happen before this date becomes realistic - instead of reading the close-date field alone",
"Stacks named buyer-side signals: mutual-action-plan progress with dated owners, multi-threading depth, economic-buyer engagement, entry into procurement or legal, and champion responsiveness",
"States that a delayed next step on its own may be harmless and only becomes actionable when combined with other negative signals",
"Once a slip is confirmed, updates the CRM close date immediately with a note on the evidence rather than leaving the forecast untouched",
"Directs tracking push count as a field derived from close-date field history rather than from memory",
"Sorts the exception list so second-push and multi-flag deals sit at the top, with pipeline value attached",
"Leaves the final disposition to the front-line manager working with the rep, not to RevOps and not to automation",
"Reports the push-count distribution as the share of deals at 0, 1, and 2+ pushes"
]
},
{
"id": 4,
"prompt": "Quicksend - inside sales, median cycle 11 days, about 2,100 open opportunities, 5 AEs plus an SDR pod. Deal sizes run $400 to $6,000. We obviously can't do deal-by-deal review on 2,100 records. Last quarter I set a job to auto-close anything untouched for 30 days across the whole pipeline and the reps went nuclear. How should the hygiene audit work at this volume?",
"expected_output": "A high-velocity audit design built on aggregate exception rules, SLA age caps that auto-tag rather than auto-close, tightly fenced auto-close conditions, and a bulk-versus-conversation split derived from the pipeline's own value distribution.",
"files": [],
"expectations": [
"Replaces deal-by-deal review with aggregate, exception-based rules for this volume and cycle length",
"Keeps the meaningful-activity definition (stage, close date, or amount change) identical to the B2B case rather than switching it for the high-velocity motion",
"Derives stale thresholds at roughly 1.5x the segment's stage medians for this motion",
"Sets an inactivity flag in the 14-21 day range rather than the blanket 30 days the user used",
"Restricts any scheduled auto-close to pre-qualified early stages only, never the whole pipeline",
"Requires any scheduled auto-close to reference last-activity date so it does not fire on false positives",
"Requires explicit sales-leadership buy-in before any scheduled auto-close",
"Sets a maximum allowable age per stage proportional to baseline cycle length, and on SLA breach auto-tags for manager review instead of auto-closing",
"Proposes a bulk disposition path with a stated manager override window rather than per-deal conversations across all 2,100 records",
"Splits bulk versus conversation at a value threshold derived from this pipeline's own value distribution rather than at a fixed dollar amount",
"Uses a no-fault audit-cleanup reason code for bulk closures so rep win rates and loss analysis stay clean",
"Keeps classify-don't-delete: no records are deleted"
]
},
{
"id": 5,
"prompt": "Orbitpad is fully self-serve - 14,000 free workspaces, about 900 paying teams, all credit card, no reps and no AEs at all. Our CRM auto-creates an 'opportunity' for every workspace that crosses 5 seats, and we now have 3,800 of them sitting in a 'Trial' stage with no owner and no close date. Our new head of growth wants a monthly pipeline hygiene audit on these. Run it.",
"expected_output": "A refusal to force a rep-facing hygiene audit onto a pure self-serve motion, with the reason, a redirect toward product-signal quality and PQL routing, and the conditions that would make the audit warranted.",
"files": [],
"expectations": [
"States that a traditional deals pipeline, and therefore a rep-facing hygiene audit, may not be warranted at all for a purely self-serve motion",
"Explains that in pure PLG prospects qualify themselves through product usage and self-serve deals convert in-product",
"Redirects hygiene toward product-signal quality and product-qualified-lead routing instead of deal-record cleanup",
"Asks whether any sales-assisted or expansion motion exists alongside the self-serve one before ruling the audit in or out",
"Does not invent per-segment days-in-stage medians for a motion with no rep-worked stages",
"Does not recommend deleting the 3,800 auto-created records",
"Identifies the auto-creation rule itself as the upstream cause rather than treating the 3,800 records as a hygiene backlog to work down",
"Avoids proposing rep-facing nudges, validation rules, or manager coaching conversations where there are no reps",
"Does not produce push-count or close-date-slip rules for records that carry no close date",
"Names what would change the answer - a sales-assisted segment, named-account expansion deals, or reps working upgrades - as the condition under which the audit becomes warranted"
]
},
{
"id": 6,
"prompt": "Two-year-old startup, Novaquill. 68 open deals, 41 closed-won ever. We switched CRM five months ago and field history tracking was never switched on, so I have no record of what any close date used to be. My CEO wants the push-count report and per-stage benchmarks for the board on Friday. Can you build both?",
"expected_output": "An honest answer that push counts are unreconstructable and must be reported as collecting, that 41 closed-won sits below the modelling volume floor so baselines must be internal and labelled low-confidence, plus the subset of rules that run without history.",
"files": [],
"expectations": [
"States that push counts cannot be reconstructed without field history and refuses to estimate a historical push count",
"Recommends adding a push-counter field incremented on every close-date change from now on",
"Reports the push metric as collecting, first readable at the next audit, rather than producing a number for Friday",
"Notes that field history tracking must be enabled per field before push counts become reconstructable at all",
"Flags that 41 closed-won deals sits below the volume floor for reliable modelling, on the order of 400+ created opportunities and 150+ closed-won across at least four quarters",
"Directs using internal top-quartile medians rather than external benchmarks at this volume",
"Labels the resulting baselines low-confidence rather than presenting them as benchmarks",
"Where no stage history exists, approximates per-stage priors by splitting the known full-cycle length across stages and marks them as low-confidence priors",
"Schedules replacement of those priors after one full cycle of real data",
"Still runs the rules that need no history: past-due close dates, missing next step, and missing forecast-critical fields",
"Does not present a fabricated per-stage benchmark table as if it were derived from this company's own data"
]
},
{
"id": 7,
"prompt": "Brightmoor Analytics. After the audit we have 407 dead records. My plan is to hard-delete them so the reporting is clean. Separately, 23 accounts we lost 8 to 14 months ago have come back asking for new quotes - I want to reopen those closed-lost opportunities and drop them back into the pipeline at Negotiation so the reps get credit. We're on Salesforce. Sanity-check both.",
"expected_output": "A rejection of the hard delete in favour of classification with real reason codes, and a default to a linked new record over reopening, with the two conditions that would flip that default named.",
"files": [],
"expectations": [
"Rejects hard-deleting the 407 records and directs classifying them instead",
"States that deletion destroys the record the next audit would learn from and corrupts conversion baselines and rep metrics",
"Notes that recycle-bin retention on this platform is short, on the order of 15 days, so deletion is irreversible in practice",
"Assigns each of the 407 a disposition from a named taxonomy - close lost with a real reason code, move to nurture, re-stage backwards, re-date with evidence, or keep with a named next step - rather than one blanket outcome",
"Defaults the 23 returning buyers to a new opportunity record linked back to the closed-lost one rather than reopening the original",
"Explains that reopening rewrites cycle length and loss reason in place, so no later report can separate a reopened deal from an original one",
"Names the two conditions that flip that default: attribution or comp crediting the original opportunity's owner, and reporting that cannot join a new record to its predecessor",
"Rejects dropping the returning deals straight into Negotiation without buyer-side evidence supporting that stage",
"Treats the claim that reopening recovers 10-20% of lost pipeline as contested, and attributes the recovery to working the returning buyer rather than to the reopen mechanic",
"Recommends restricting casual stage movement out of Closed-Lost so reps cannot reset stale counters by reopening",
"Does not bulk-set a single loss reason across the 407 records",
"Includes a no-fault reason code such as never a real opportunity or audit cleanup so bulk closures stay out of competitive-loss analysis"
]
},
{
"id": 8,
"prompt": "Kesterline Group. We're doing the pipeline hygiene audit, but while you're in there I also want: (a) our stage exit criteria rewritten, because 'Demo Scheduled' and 'Proposal Sent' clearly aren't working, (b) the Slack alert system designed - which channel, how often reps get pinged, how we avoid alert fatigue, (c) a fix for our forecast, we've missed three quarters running, and (d) a decision on who owns the Account Industry field, because marketing keeps overwriting it. Go.",
"expected_output": "The hygiene audit delivered, with each of the four out-of-scope requests declined and routed to the adjacent piece of work by name, while still describing the handoff shape of the prevention layer.",
"files": [],
"expectations": [
"Runs the hygiene audit and declines the stage-definition rewrite, routing it to a stage-definition audit by name",
"Declines to design the alert timing, the channels, or the notification-fatigue policy",
"Still describes the handoff shape of the prevention layer: message the owner on a past-due close date, increment a reminder counter, add the manager at the third reminder",
"Declines to diagnose forecast reliability and routes it to a sales forecast diagnostic by name",
"Declines to set field ownership or source-of-truth policy and routes it to CRM data governance by name",
"States that hygiene takes the existing stage set as given and inspects the deals inside it",
"States that hygiene feeds the forecast clean data rather than fixing the forecast method",
"Checks completeness of the fields that already exist rather than ruling on who owns them",
"States the scope boundaries inside the deliverable itself, not only in passing conversation",
"Does not silently absorb any of the four out-of-scope requests into the audit deliverable",
"Recommends the recurring hygiene audit ride an existing ritual rather than adding a new meeting"
]
},
{
"id": 9,
"prompt": "Ashford Tech, 45 reps across four teams. The exception list is built - 118 flagged deals. My plan for Thursday: I present the list live on the all-hands pipeline call with the CRO and both VPs on the line, we go deal by deal, and my ops team closes whatever the reps can't defend on the spot. I'm also putting a hygiene leaderboard in the #sales channel so people can see where they stand. Tell me if this works.",
"expected_output": "A rewritten rollout: rules announced before the first flag, exception list published at least 12 hours ahead, executives out of the rep-level session, manager-and-rep disposition instead of ops closing deals, the leaderboard dropped, and an outcome publication plus cadence.",
"files": [],
"expectations": [
"Rejects presenting the list live and requires publishing the exception list at least 12 hours before the meeting that works it",
"States that a meeting which starts by pulling a report has already failed",
"Rejects the ops team closing deals unilaterally; the front-line manager and the rep decide each disposition",
"Splits ownership three ways: RevOps owns the definitions, snapshot, automation, and pre-published data package; the manager owns disposition and coaching; the rep owns the update and the evidence",
"Keeps the CRO and the VPs out of the rep-level pipeline review, because executive presence makes reps defend pipeline instead of exposing risk in it",
"Rejects the public hygiene leaderboard and keeps score comparisons inside 1:1s and pipeline reviews",
"Requires announcing the rules - the meaningful-activity definition, the thresholds and what they are derived from, and what a flag means - before the first flag lands",
"States that a flag opens a coaching conversation, never an automatic closure",
"Runs the review inside an existing ritual rather than adding a new meeting",
"Batches proposals with a stated manager override window and treats silence after the window as consent to the disposition the rep already saw",
"Publishes the outcome afterwards: deals reviewed, dispositions by type, pipeline-value delta, and KPI movement",
"Announces the recurring cadence and the escalation path so the pass does not read as a one-off purge",
"States that exceptions aging past thirty days signal a rule that belongs in the system rather than another meeting"
]
},
{
"id": 10,
"prompt": "Writing the board slide for the Verity Loop pipeline audit. I want to lead with 'Gartner says 40-60% of B2B pipeline is stale' to justify the project, then show our target of 80% of pipeline value carrying a next step, then close with '496 hygiene issues resolved in 3 days' as the headline result. I also read somewhere that clean pipeline makes forecasts 23% more accurate - worth including? Draft the slide.",
"expected_output": "A slide draft that strips the misattributed and secondhand figures, replaces the borrowed 80% target with an internally derived one, and replaces clearance speed with forecast-linked KPI movement against a stated baseline and pass threshold.",
"files": [],
"expectations": [
"Refuses to attribute the 40-60% stale figure to Gartner and flags it as secondhand, reaching the user only through an intermediary",
"Flags that much of the published numeric detail in this field originates from vendors selling forecasting or hygiene tooling",
"Rejects the 80% next-step figure as a cross-company benchmark and sets the future-dated next-step target from the team's own baseline",
"Treats the 23%-more-accurate forecast claim as unverified and refuses to present it as research",
"Rejects 496 issues resolved in 3 days as the success measure, because clearance speed is not a KPI",
"Replaces it with forecast-linked KPI movement measured against the pre-audit baseline",
"Names concrete KPIs: stale value as a share of open pipeline, the honest-coverage gap, slipped-deal rate, completeness on forecast-critical fields, share of deals with a future-dated next step, and close-date accuracy",
"States the healthy stale-value band - below roughly 20-30% of open pipeline, with late-stage stale below 15%",
"States the slipped-deal rate target of below 20%, with consistently above 30% signalling systemic qualification or discipline problems",
"Refuses to promise a win-rate lift from auditing and measures any lift against the team's own pre-audit baseline instead",
"States the pass threshold in checkable terms: every flagged deal carries a decided disposition with an owner and reason, zero open deals with a past-due close date, and zero second-push or quarter-boundary-push deals lacking a documented evidence answer",
"Treats the first audit as the baseline and derives targets from it rather than from published numbers"
]
},
{
"id": 11,
"prompt": "Two things out of the Halvorsen Media pipeline pull. First: one rep, D.K., has 52 open deals all sitting in 'Identified' since the day he created them - no contact attached, no next step ever set, the same three-word description on every one. He says he's 'working' the accounts. Second: a different rep closed 46% of her annual number in the final nine days of Q3, and did roughly the same thing in Q2. What do I do with each?",
"expected_output": "The 52 records identified as claim-only dibs deals and routed to an ownership decision before closure; the end-of-quarter concentration treated as a sandbagging watch metric that opens a comp-design conversation rather than an enforcement action.",
"files": [],
"expectations": [
"Identifies D.K.'s 52 records as claim-only dibs deals using the combination of entry-stage-since-creation, no meaningful change since creation, no contact or next step, and one owner holding a cluster of similar records",
"Routes them to their own disposition path, treating the question as account ownership rather than deal quality",
"Settles ownership first - territory rules, a named-account list, or release to marketing - before closing the placeholder records",
"States that closing them without settling ownership just makes the rep open new ones",
"Names the downstream cost of claim-only records: they block marketing from targeting the account and create friction in territory moves",
"Does not delete the 52 records",
"Treats the 46%-in-nine-days pattern as a sandbagging watch signal rather than a hygiene violation",
"Gives the healthy end-of-quarter close concentration band of roughly 20-25%, and the sustained per-rep level above roughly 35% that warrants attention",
"Opens a comp-design conversation about the second rep rather than a compliance or enforcement action",
"Tracks end-of-quarter close concentration per rep as a standing watch metric across audits"
]
},
{
"id": 12,
"prompt": "New RevOps hire at Talloway Group, week two. My manager just walked past my desk and said 'run a pipeline hygiene audit, have it for me tomorrow.' I have admin access to the CRM. That is genuinely all I have. Where do I start?",
"expected_output": "An interview run one question at a time before any auditing, followed by a frozen as-of snapshot and a clean-and-standardize pass before any measurement, with the stale layer sized ahead of baseline derivation.",
"files": [],
"expectations": [
"Runs an interview before auditing, asking one question per message rather than delivering an audit on the stated facts",
"Asks what can be exported or queried: open deals with stage, amount, close date, owner, last activity date, created date and next step, plus stage-change and close-date-change history",
"Asks which motions and segments feed the pipeline, and the typical cycle length and deal size per segment",
"Asks which recurring rituals already exist - forecast call, pipeline review, QBR, deal desk - so the audit rides one instead of adding a meeting",
"Asks which fields forecasting and pipeline decisions actually read, since completeness is checked against those rather than the whole schema",
"Asks the date the result must land by, and whether this is a one-off cleanup or the start of a recurring cadence",
"Asks about the effort ceiling: friction per deal reps will absorb, admin configuration time available, and manager review time per week",
"Asks whether any compensation is currently tied to CRM hygiene, field completion, or forecast accuracy",
"Fixes a stated as-of date and freezes that snapshot, so dispositions are decided against it rather than against a moving book",
"Cleans and standardizes before measuring anything: maps custom stages to a canonical order, removes test records, backfills missing stage-entry dates, and normalizes currency and timezone",
"Sizes the stale layer before deriving baselines, rather than opening with threshold-setting"
]
}
],
"trigger_queries": [
{ "query": "run a pipeline hygiene audit on our open opportunities", "should_trigger": true },
{ "query": "our pipeline is full of junk and the QBR is in two weeks", "should_trigger": true },
{ "query": "half these deals haven't moved in months, what do I do with them", "should_trigger": true },
{ "query": "how should I define a stale deal", "should_trigger": true },
{ "query": "flag every deal that keeps pushing its close date", "should_trigger": true },
{ "query": "three deals in my commit have pushed twice each, build me an exception list", "should_trigger": true },
{ "query": "our reps log a call every week on deals that are obviously dead and the report says they're fine", "should_trigger": true },
{ "query": "I need to clean up the pipeline before the board meeting", "should_trigger": true },
{ "query": "what share of open pipeline being stale is actually normal", "should_trigger": true },
{ "query": "58% of our deals have no next step, how do I fix that", "should_trigger": true },
{ "query": "should I make more fields required on the opportunity object", "should_trigger": true },
{ "query": "we have about 400 zombie opportunities, delete them or keep them", "should_trigger": true },
{ "query": "the same deals slip their close date every single quarter", "should_trigger": true },
{ "query": "give my managers a list of deals to work through with their reps this week", "should_trigger": true },
{ "query": "how long should a deal sit in Proposal before I flag it", "should_trigger": true },
{ "query": "set up a stale deal audit for our enterprise segment", "should_trigger": true },
{ "query": "my CRM says 4x coverage and I don't believe a word of it", "should_trigger": true },
{ "query": "what should I do with deals nobody has touched in over a year", "should_trigger": true },
{ "query": "audit our open deals for missing forecast fields", "should_trigger": true },
{ "query": "pipeline cleanup plan for next quarter", "should_trigger": true },
{ "query": "is it ok to auto close deals that go quiet", "should_trigger": true },
{ "query": "my ops team wants to mass close 300 old opportunities, is that a good idea", "should_trigger": true },
{ "query": "how do I stop reps from stuffing close dates at quarter end", "should_trigger": true },
{ "query": "one of my reps opens deals just to claim accounts", "should_trigger": true },
{ "query": "deal review prep - which records should managers actually challenge", "should_trigger": true },
{ "query": "what's a reasonable days-in-stage threshold by segment", "should_trigger": true },
{ "query": "we have 2000 open deals and 5 reps, we can't review them one by one", "should_trigger": true },
{ "query": "should I give a bonus for CRM data quality", "should_trigger": true },
{ "query": "our loss reasons are all 'Price' and I don't trust a single one", "should_trigger": true },
{ "query": "we lost a deal ten months ago and they came back, reopen it or make a new one", "should_trigger": true },
{ "query": "how often should we scrub the pipeline", "should_trigger": true },
{ "query": "I want a monthly cleanup ritual that doesn't add another meeting", "should_trigger": true },
{ "query": "our pipeline review runs 90 minutes and nothing ever changes", "should_trigger": true },
{ "query": "which deals in my book are actually real", "should_trigger": true },
{ "query": "how do I tell a slipping deal from a dead one", "should_trigger": true },
{ "query": "the same 40 deals get discussed every week and never close", "should_trigger": true },
{ "query": "pre-QBR pipeline scrub", "should_trigger": true },
{ "query": "what KPIs prove our pipeline cleanup actually worked", "should_trigger": true },
{ "query": "we're rolling out new CRM rules for deals, how do I tell the reps", "should_trigger": true },
{ "query": "reps are going to hate this cleanup, how do I run it without a revolt", "should_trigger": true },
{ "query": "pipeline amnesty - is that a real thing and should we run one", "should_trigger": true },
{ "query": "what dispositions should I offer for flagged deals", "should_trigger": true },
{ "query": "half my open opps have a close date in the past", "should_trigger": true },
{ "query": "our open pipeline number is fiction and I need to prove it to the CRO", "should_trigger": true },
{ "query": "how do I measure whether our deal records are trustworthy", "should_trigger": true },
{ "query": "set thresholds for flagging deals that haven't progressed", "should_trigger": true },
{ "query": "checklist for auditing open opportunities", "should_trigger": true },
{ "query": "what do I do with a deal that has been in the customer's legal review for two months", "should_trigger": true },
{ "query": "quarterly territory scrub before period end", "should_trigger": true },
{ "query": "our inside sales pipeline has thousands of tiny deals that never get closed out", "should_trigger": true },
{ "query": "identify the deals that are inflating our coverage number", "should_trigger": true },
{ "query": "the next step field is empty on most deals, does that actually matter", "should_trigger": true },
{ "query": "how many times can a rep move a close date before I escalate", "should_trigger": true },
{ "query": "clean up opportunity records without wrecking our historical reporting", "should_trigger": true },
{ "query": "my VP wants to close-lost everything that pushed twice", "should_trigger": true },
{ "query": "we switched CRM and lost all the field history, can I still audit pushes", "should_trigger": true },
{ "query": "build the exception list for the biweekly pipeline review", "should_trigger": true },
{ "query": "what counts as a deal actually moving", "should_trigger": true },
{ "query": "our forecast is built on deals that haven't changed since February", "should_trigger": true },
{ "query": "should stale thresholds be the same for SMB and enterprise", "should_trigger": true },
{ "query": "I inherited a book of 200 deals and have no idea which ones are alive", "should_trigger": true },
{ "query": "set up a recurring check that keeps the deal records honest", "should_trigger": true },
{ "query": "the sales team keeps dead deals alive so their coverage looks good", "should_trigger": true },
{ "query": "we need to size how much of our pipeline is garbage", "should_trigger": true },
{ "query": "audit deal records before the forecast call on Monday", "should_trigger": true },
{ "query": "validation rule or nudge for empty close dates", "should_trigger": true },
{ "query": "rewrite our stage exit criteria so each one names something the buyer did", "should_trigger": false },
{ "query": "our stages are called 'Demo Scheduled' and 'Proposal Sent' and they don't mean anything", "should_trigger": false },
{ "query": "audit our pipeline stage definitions", "should_trigger": false },
{ "query": "how many stages should our sales process have", "should_trigger": false },
{ "query": "why is everything stuck in one stage", "should_trigger": false },
{ "query": "diagnose why we missed the number three quarters in a row", "should_trigger": false },
{ "query": "our commit never lands, what is wrong with our forecasting method", "should_trigger": false },
{ "query": "should we use weighted pipeline or category-based forecasting", "should_trigger": false },
{ "query": "build a forecast model for next year's revenue plan", "should_trigger": false },
{ "query": "who owns the Account Industry field, marketing keeps overwriting it", "should_trigger": false },
{ "query": "we need a data dictionary for our CRM fields", "should_trigger": false },
{ "query": "custom field sprawl, we have 340 fields on the contact object", "should_trigger": false },
{ "query": "which system is the source of truth for account records", "should_trigger": false },
{ "query": "finance and sales report two different ARR numbers", "should_trigger": false },
{ "query": "set up data contracts between our GTM teams", "should_trigger": false },
{ "query": "where are we losing deals in the funnel", "should_trigger": false },
{ "query": "size how much revenue we lose to unworked inbound leads", "should_trigger": false },
{ "query": "our billing misses renewals, how much is that costing us", "should_trigger": false },
{ "query": "design our funnel stages from lead through closed won", "should_trigger": false },
{ "query": "should we model the funnel on leads or on buying groups", "should_trigger": false },
{ "query": "build a bowtie funnel model for the plan", "should_trigger": false },
{ "query": "define MQL and SQL so marketing and sales stop arguing", "should_trigger": false },
{ "query": "who should get this inbound lead", "should_trigger": false },
{ "query": "our round robin is giving one rep twice as many leads", "should_trigger": false },
{ "query": "leads are sitting unworked in a queue for days", "should_trigger": false },
{ "query": "set a territory assignment waterfall with named account overrides", "should_trigger": false },
{ "query": "sales rejects most of our MQLs", "should_trigger": false },
{ "query": "recalibrate the weights in our lead scoring model", "should_trigger": false },
{ "query": "add score decay to our scoring model", "should_trigger": false },
{ "query": "build a discount approval matrix", "should_trigger": false },
{ "query": "who signs off on a 40% discount", "should_trigger": false },
{ "query": "design the deal desk intake and exception process", "should_trigger": false },
{ "query": "our green accounts keep churning", "should_trigger": false },
{ "query": "weight the signals in our account health score", "should_trigger": false },
{ "query": "the champion left the account, is that a churn signal", "should_trigger": false },
{ "query": "build an early warning system for at-risk customers", "should_trigger": false },
{ "query": "our CSMs start from zero after a deal closes", "should_trigger": false },
{ "query": "what data should transfer from sales to CS at closed won", "should_trigger": false },
{ "query": "our board deck reads like a data dump", "should_trigger": false },
{ "query": "which metrics belong in the monthly revenue review", "should_trigger": false },
{ "query": "build a KPI tree from board level down to IC", "should_trigger": false },
{ "query": "what should our North Star metric be", "should_trigger": false },
{ "query": "we pay for too many GTM tools, which ones do we cut", "should_trigger": false },
{ "query": "consolidate our sales engagement and dialer tools", "should_trigger": false },
{ "query": "how do I break into RevOps", "should_trigger": false },
{ "query": "prep me for a RevOps manager interview loop", "should_trigger": false },
{ "query": "write a scorecard for our first sales ops hire", "should_trigger": false },
{ "query": "30-60-90 plan for a new RevOps analyst", "should_trigger": false },
{ "query": "which RevOps newsletters should I subscribe to", "should_trigger": false },
{ "query": "who should I follow in revenue operations", "should_trigger": false },
{ "query": "starting a brand new RevOps project, where do I begin", "should_trigger": false },
{ "query": "our data pipeline keeps failing overnight, audit the DAG", "should_trigger": false },
{ "query": "audit our BigQuery pipeline for cost and freshness", "should_trigger": false },
{ "query": "design a deployment pipeline with staging and canary steps", "should_trigger": false },
{ "query": "clean up stale branches and dead code in our repo", "should_trigger": false },
{ "query": "our Azure Pipelines build takes 40 minutes, speed it up", "should_trigger": false },
{ "query": "our recruiting pipeline is full of candidates nobody has contacted in months", "should_trigger": false },
{ "query": "candidates are stuck at the onsite stage in our ATS, clean it up", "should_trigger": false },
{ "query": "set up CRM automation so emails get logged without rep input", "should_trigger": false },
{ "query": "the ETL job is writing duplicate rows into the warehouse, how do I dedupe", "should_trigger": false },
{ "query": "code hygiene rules for our TypeScript monorepo", "should_trigger": false },
{ "query": "our ML training pipeline is running on stale feature data", "should_trigger": false },
{ "query": "audit our docs pipeline for broken links", "should_trigger": false },
{ "query": "sprint hygiene - our Jira board is full of tickets nobody has touched in six months", "should_trigger": false },
{ "query": "clean up our email list, tons of contacts never open anything", "should_trigger": false },
{ "query": "our support queue has hundreds of stale tickets, what's the cleanup process", "should_trigger": false }
]
}
references/audit-report-examples.md›
# Worked Examples
Three condensed examples: a B2B audit, a high-velocity audit, and an audit done wrong. Company names and numbers are illustrative, invented for these examples - not sourced benchmarks.
## Example 1 - B2B Mid-Market Audit
Context: sales-led pipeline, ~90-day cycle, 240 open deals, monthly audit being introduced before a QBR, ridden on the existing biweekly pipeline review.
```
PIPELINE HYGIENE AUDIT - Mid-market pipeline, as-of 2026-03-31
Definitions : meaningful activity = stage/close date/amount change
(ORM definition; last-activity as second trigger);
stale multiplier 1.5-2.0x mid-market medians; inactivity
flag 30-45d (DealHub range); legal/procurement exempt
Stale layer : $8.1M open pipeline -> <90d: $5.2M / 90-180d: $1.6M /
180-365d: $0.9M / >365d: $0.4M; headline coverage 3.8x ->
3.6x excluding >365 bucket; stale value 36% of pipeline ->
amnesty day scheduled BEFORE enforcement (over the
20-30% line)
Summary : 240 deals audited; 61 flagged (25%)
Exception list (excerpt):
Deal Owner Flags Evidence Decided disposition Disp. owner Reason
Northwind ERP J.R. stale(51d in Eval, no stacked signal moves Close lost: "dropped J.R. no answer to "what has
median 24d), 2nd push since Feb 9; single- follow-up" to happen"; single-thread
threaded
Contoso Add-on M.K. 2nd push (crossed in legal since Mar 20; Re-date 2026-04-18, date M.K. evidence moving; stated
quarter boundary) champion responsive updated in CRM same day reason logged on push
Fabrikam Pilot M.K. missing next step deal active, field Keep + next step "pilot M.K. data gap, not deal decay
blank review call Apr 7"
8 early-stage T.S. dibs pattern (no created w/ no contact Ownership to territory Sales mgr claim-only records
records meaningful change since or next step rules; records closed
creation) "never a real opp (audit)"
Field gaps : next step 58% populated vs 90-95% target (feeds Monday
prioritization); amount 92%; loss reason 41% (feeds
win/loss) -> fix: 2 fields un-required (cap 5-7),
stage-gated validation rule on close date + amount
Push report : 0 pushes 71% / 1 push 17% / 2+ 12%; all second-push deals
reviewed by manager with stacked-signal evidence; 3
quarter-boundary pushes, all with stated reasons
Remediation : push-counter field added; loss-reason list rebuilt to 7
codes w/ definitions; amnesty day Apr 3
Communication : rules memo sent Apr 2 (before first flag); exception list
published 12h before Apr 6 pipeline review; execs excluded
from rep sessions; outcome summary to sales org Apr 10
KPIs : stale value 36% -> target <25% next audit; next-step 58% ->
75% (own baseline, self-set); slipped-deal
rate 24% -> <20%; pass: 3 of 4 criteria met; re-audit Apr 30
```
## Example 2 - High-Velocity / B2C-Adjacent Audit
Context: inside-sales transactional pipeline, 9-day median cycle, ~1,800 open deals, weekly aggregate audit - deal-by-deal review replaced by rules, per the high-velocity pattern.
```
PIPELINE HYGIENE AUDIT - Velocity pipeline, as-of week 14
Definitions : meaningful activity = field change (identical to B2B - this
does not vary by motion); ~1.5x stage medians of 1-3d
(derived, 8 weeks history); inactivity flag 14d;
push tolerance: any second date = escalation (9-day cycle
makes a second push a cycle restart)
Method : aggregate rules, exception-based; SLA age caps per stage
proportional to cycle length; SLA breach -> auto-tag for
manager review (never auto-close); scheduled auto-close
only on the pre-qualified entry stage, referencing
last-activity date, approved by sales leadership
Summary : 1,812 deals; 496 tagged; bulk dispositions below $2K value
threshold, conversations above it; 48h manager override
window on every deal
Dispositions : 371 bulk close-lost "aged out (audit cleanup)" (9 pulled
back by managers in the window); 74 re-dated with evidence;
51 kept with next step
Field gaps : phone-validated flag 71% vs 90% target - the only
completeness field this team's routing actually reads
KPIs : freshness 66% -> 84% post-audit; 88% zero-push; stale value
12% (under the 20-30% line - no amnesty needed); weekly
cadence confirmed; pass threshold met
```
Note what did _not_ change from Example 1:
- The meaningful-activity definition.
- Classify-don't-delete.
- Validation-rules-over-required-fields.
- The override window.
- The coaching posture.
What changed:
- The unit of analysis (aggregate rules, not deal-by-deal).
- The automation degree (auto-tag plus limited pre-qualified auto-close).
- The thresholds' absolute size.
## Negative Example - The Audit Done Wrong
Context: same mid-market pipeline as Example 1, run by a new ops hire the quarter before.
What happened:
- Defined stale by logged activity: any deal with a call or email in the last 30 days passed. Reps kept dead deals "fresh" with a weekly logged voicemail; the stale layer survived the audit untouched while genuinely worked-but-slow enterprise deals got flagged.
- One flat 30-day stage threshold across segments - it flagged half of Evaluation (median 24d, so 30d is normal there) and almost nothing in the SMB motion (median 6d, where 30 days is four cycles).
- Computed "average days-in-stage" on the whole book, dead tail included, so the resulting thresholds were flattened by zombies and flagged almost nothing.
- No announcement, no amnesty despite ~40% of value being stale. Reps discovered the rules when 130 deals were mass-closed overnight, loss reason bulk-set to "Price" (first dropdown option).
- 40 records were deleted outright "to keep reporting clean". They aged out of the recycle bin; conversion baselines and two reps' win rates were permanently corrupted.
- Tied a spiff to field completion. Completeness hit 97% in two weeks - next steps read "n/a", amounts defaulted to $10,000, and every close date landed on the last day of the quarter. At quarter end, reps mass-pushed dates with no reason required, and the forecast rolled over intact.
- Success was reported as "496 hygiene issues resolved in 3 days" - clearance speed, no KPI baseline, no follow-up audit scheduled.
What it caused: reps kept real deal notes in a private spreadsheet and updated the CRM only under pressure - the audit made the data _worse_. Loss analysis showed a fictional pricing crisis. The next quarter's forecast used corrupted baselines and quarter-stuffed close dates.
Each mistake maps to a rule in this skill:
- Define meaningful activity on field changes, not logged touches.
- Segment the thresholds.
- Exclude the stale layer before computing baselines.
- Amnesty before enforcement when the stale share is high.
- Communicate before enforcing.
- Classify with honest codes, never delete, never bulk-set a reason.
- Never tie comp to field completion.
- Require stated reasons on period-boundary pushes.
- Grade on KPI movement, not clearance speed.
references/detection-rules.md›
# Detection Rules - Computation and Fallbacks
How to derive the baselines and run each rule family. Label every output number with its provenance:
- Derived from the user's own data.
- A named practitioner source.
- A convergent practitioner range.
## Meaningful Activity - Define Before Anything Else
- **Field-change definition (default)**: a deal showed meaningful activity when its Stage, Close Date, or Amount changed. Logged calls and emails are activity in the CRM sense but do not indicate the deal moved - a staleness rule built on them can be satisfied without any progression, which is how stale pipeline survives review after review (ORM).
- **Last-activity definition (secondary)**: days since the last logged touch. Many hygiene programs and vendor tools key on this; it is a genuine practitioner disagreement, not a settled question.
- Run both as independent triggers: field-change age catches the deal that is "worked" but never moves; last-activity age catches the deal nobody has touched at all. A deal tripping both is the strongest stale signal.
## Deriving Per-Segment Baselines
1. Pull stage-change history for deals closed (won and lost) over the last 12-18 months. Open deals bias time-in-stage downward - a deal still sitting in a stage hasn't finished sitting there.
2. **Exclude the stale layer before computing anything** - a deal group carrying a large dead tail produces a longer, flatter close curve than its live deals actually have (ORM). First bucket the book by days since last meaningful change (<90 / 90-180 / 180-365 / >365), then compute medians on the live layer.
3. Per stage per segment (SMB / mid-market / enterprise at minimum; add region, source, or deal type where velocity genuinely differs), compute the median days from entry to exit. Median, not mean: a few zombies drag the mean until the threshold flags nothing. Company-wide averages mask the velocity difference between an SMB and an enterprise motion (Umbrex, Outreach).
4. Volume floor: Gong's guidance for reliable modeling is 400+ created opportunities including 150+ closed-won across at least four quarters. Below that, use internal top-quartile medians rather than external benchmarks, and label the baseline low-confidence.
5. Also compute the typical activity interval on closed-won deals (calibrates the last-activity window) and historical close-date accuracy within the chosen tolerance.
**When no history exists**:
- Approximate a per-stage prior by splitting the known full-cycle length across stages weighted by the team's judgment.
- Mark every baseline "low-confidence prior".
- Schedule replacement after one full cycle of real data.
## Stale-Deal Rules
Multiplier and window are segment-dependent - convergent across Umbrex, Outreach, and DealHub, so likely real operating numbers rather than one vendor's marketing:
| Segment | Discovery/Qualified median | Evaluation/POC median | Proposal/Negotiation median | Stale multiplier | Inactivity flag |
| -------------------- | -------------------------- | --------------------- | --------------------------- | ---------------- | --------------- |
| SMB / high-velocity | 5-10 days | short | 3-10 days | ~1.5x median | 14-21 days |
| Mid-market | 7-14 days | 14-30 days | 7-14 days | 1.5-2.0x | 30-45 days |
| Enterprise / complex | 14-30 days | 30-90 days | 14-30+ days | 2.0x median | 60-90 days |
Medians: Umbrex. Inactivity rule of thumb: DealHub - with **legal and procurement reviews explicitly exempt** from stale flags. Worked example (Umbrex, Outreach state the identical rule): Proposal median 12 days → stale at 18-24 days.
Additional triggers, all VERIFIED practitioner rules:
- No activity in 14 days on mid/late-stage deals (Umbrex, Outreach).
- Next step dated in the past, or no scheduled future meeting at all.
- **12-month rule** (ORM): no meaningful change in 12 months marks the truly dead layer - close curves rarely carry meaningful expectation past 52 weeks. ORM's customer aggregate: more than 10% of open pipeline typically sits untouched past 12 months.
Distinguish _stale_ (no recorded motion - a data question this audit answers) from _dead_ (buyer evidence says it's over - a judgment the review conversation makes).
## Push-Count Rules
Track pushes as a field, not a memory (ORM): count close-date changes per deal from field history, snapshot deltas, or a dedicated counter field, and sort late-stage pipeline by that count - the deals at the top are the forecast risk.
| Trigger | Action | Provenance |
| -------------------------------- | --------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Second push** | Escalate to manager deal inspection | ORM - the best single predictor of slippage; a quarter-to-quarter slip lowers close odds even in commit. Umbrex flags "repeat pushers" at >= 2 moves |
| Push crossing a quarter boundary | Worse than an in-quarter nudge; require a stated reason on the change | ORM structural fix for close-date stuffing |
| 3+ slips | Disqualification-warranting | SalesOpsClub |
| Close date already past | Automatic flag | Common practice, uncontroversial |
**Slipping vs dead - stacked evidence, not the date field.** Open with "what has to happen before this date becomes realistic?", then stack the signals:
- Mutual-action-plan progress with dated owners.
- Multi-threading depth.
- Economic-buyer engagement.
- Entry into procurement/legal.
- Champion responsiveness.
A delayed next step alone may be harmless; combined with a pushed close date, single-threading, and budget hesitation it becomes a stronger, explainable case for intervention (AskElephant). Context on why multi-threading is a real signal: Ebsta x Pavilion's 2024 benchmarks (4.2M+ opportunities) found multi-threading lifts win rates 130% on deals over $50k.
Once a slip is confirmed, update the CRM close date immediately with a note on the evidence and the revised plan - the worst outcome is intervening on the deal but leaving the forecast untouched.
**When the CRM retains no field history**: push counts cannot be reconstructed.
- Add a push-counter field incremented on every close-date change starting now.
- Report the metric as "collecting - first readable next audit".
- Never estimate a historical push count.
## Field-Completeness Rules
1. Start from the forecast-critical set, not the whole schema:
- Next step and next-step date, close date, amount, stage, forecast category, loss reason on closed-lost.
- The qualification fields the forecast actually reads (champion, economic buyer, paper process in enterprise motions).
Amount, stage, and close date are the highest-value validation targets - they are the meaningful-activity fields themselves (ORM).
2. Report completeness per field as % of open deals populated against the 90-95% target (80% floor - Saber; Komo/DAMA), next to the decision that field feeds.
- **Do**: "37% of deals have no next step, so Monday prioritization runs blind."
- **Don't**: "field X is 63% complete."
3. Remediate in efficiency order - **stage-gated validation rule > owner nudge > auto-capture** - reading the axes below before deviating from it. The distinction underneath the order: a required field checks that something was entered; a validation rule checks that what was entered makes sense (ORM).
- effort: auto-capture > owner nudge > stage-gated validation rule. Auto-capture is an integration project - a quarter of work, and hard to unwind once email and calendar data is flowing. A nudge takes an hour to configure and then levies a standing tax on every rep who receives it. A validation rule takes about the same hour, then costs seconds and only on advancement to a late stage; switching it off reverses it completely.
- value: auto-capture > stage-gated validation rule > owner nudge. Auto-capture fills the fields whether anyone cooperates or not; the validation rule protects exactly the fields the forecast reads, at the moment they start mattering; a nudge only improves the odds someone acts.
- compliance cost: auto-capture > stage-gated validation rule == nudge. Capturing email and calendar content triggers a consent and data-processing review in several jurisdictions, and ingested history cannot be put back. The tie is a genuine nil on both sides - neither a rule nor a nudge reads anything from outside the CRM - so this axis exists only to separate auto-capture from the other two.
More required fields is deleted from this menu rather than ranked last: heavy requirement breeds the fabricated placeholders of step 4, so the skill's own constraint rules it out. Hold the cap at 5-7 required fields per object (AskElephant).
What this order starves is auto-capture: highest value and highest effort, so a ratio never selects it. Promote it anyway when an activity-capture tool is already deployed (the integration cost is already paid, leaving configuration), or when reps sit at their friction limit and every cheaper option spends friction the team does not have.
Treat the order as a default that shifts with context and with who executes it. Re-rank it against the Interview answers:
- A result due this week leaves auto-capture unbuilt.
- A recurring mandate is what pays for it.
- A manager who already runs a weekly pipeline review can carry a nudge's follow-up as review time instead of rep friction.
4. Check populated fields for **fabricated placeholders**, which heavy requirement breeds:
- Sentinel values ("TBD", ".", "123", "n/a n/a n/a", "999999").
- Identical boilerplate next steps across many deals.
- Next-step dates always exactly N days out.
- Amounts that never vary off a round default.
Count fabricated as empty. If placeholders cluster on required fields, the remediation is fewer requirements plus validation rules, not policing harder.
## Dibs-Deal Detection
Claim-only deals - opened to reserve an account, never worked - hide from single rules because they are "new". Flag the combination:
- Early-stage, at or near the entry stage since creation;
- No meaningful change and no activity logged since the week of creation;
- No contact attached, or no next step ever set;
- The same owner holds a cluster of similar records.
Route these to their own disposition path: the question is account ownership (a territory and routing decision), not deal quality. Closing them without settling ownership just makes the rep open new ones. Provenance: named failure mode from RevOps Co-op - claim-only records rot, block marketing from targeting the account, and create friction in territory moves.
references/disposition-and-communication.md›
# Dispositions and the Communication Plan
## The Evidence Test per Disposition
Decide each flagged deal by what the buyer-side evidence supports, not by what cleans the dashboard fastest. For the stale working list, only two answers are acceptable: revive it with a real next step and a validated close date, or close it out (ORM).
| Disposition | Evidence that supports it | Trap to avoid |
| ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| Close lost, real reason code | Stacked signals all negative: no buyer response past the silence window, champion unresponsive, no economic-buyer engagement, "what has to happen" has no answer | Closing a merely quiet deal - a legal or procurement stall is exempt, not dead |
| Move to nurture | Buyer said "not now" with a plausible future trigger (renewal date, next fiscal year) | Nurture as a euphemism for lost - nurture needs a re-entry trigger and date, or it's a graveyard |
| Re-stage backwards | Deal is alive but the stage claims buyer commitment the record can't show | Punitive demotion of every flagged deal - restage only where the stage genuinely overstates position |
| Re-date with evidence | A concrete buyer-side answer plus at least one moving stacked signal (MAP progress, legal entry, champion responsive) | Accepting a seller-side answer ("I'll follow up") as evidence; updating the deal plan but not the CRM date |
| Keep, with named next step and date | Deal is healthy; the flag was a missing or stale field | "Keep" without writing the next step - that re-flags the same deal next audit |
The manager decides, never the rep alone - do not let the seller grade their own homework (LeanLayer) - and never automation alone: flag automatically, but let managers make the final call on removal; automated deletion creates distrust (ORM). Non-standard re-stages and deal splits route through the deal desk. Every decided disposition records the decision, a named owner, and the reason.
## Reason Codes
A generic dropdown makes loss data garbage: a rep who dropped the ball still clicks "Price" to save face. Design the closed-lost list so honesty is possible:
- A clear, finite list with written definitions, plus optional sub-reasons (SalesHive):
- No decision.
- Lost to competitor.
- Product fit.
- Budget.
- Timing.
- Wrong persona.
- Require a one-sentence context note, ideally in the prospect's own words.
- Include no-fault codes: "we stopped pursuing / dropped follow-up", "never a real opportunity (audit cleanup)". The audit-cleanup code keeps bulk hygiene closures out of genuine competitive-loss analysis.
- Review the code distribution each audit; a code taking >40% of volume is hiding several truths.
## Reopen vs New Record
Both camps argue about where a returning buyer's record lives, so put them on one yardstick: what each buys, against what each costs in configuration, standing manager gates, and reversibility.
- **New record, linked back to the closed-lost one** (reporting-integrity camp - Varicent; HubSpot community): once closed-lost, a deal stays closed-lost; the returning buyer gets a fresh opportunity related to the old one. Costs near-zero - a written policy and a relate-records step - and stays reversible, since a policy changed next quarter rewrites nothing already recorded. Cycle-length and loss-reason series survive intact.
- **Reopen the closed-lost record** (pipeline-recovery camp - Letterdrop): reopening done correctly can recover 10-20% of lost pipeline, but only when the buying motion has genuinely resumed and with the close date reset. Costs about an hour of configuration (a gated reopen path, a "reopened" flag) plus a standing manager gate on every reopen, and it is the irreversible option: cycle length and loss reason are rewritten in place, and no later report can separate a reopened deal from an original one.
- value: reopen == new record - the 10-20% recovery is bought by working the returning buyer again, not by which record holds them, and a linked new record captures the same revenue with the same effort from the rep
- effort: reopen > new record - a gated path and a standing gate against a one-line policy, and the damage to the reporting series cannot be undone once records exist under the rule
Default to the linked new record. Two conditions genuinely flip that, and where either holds there is no honest ranking - only a choice about which failure the org would rather live with, distorted cycle and loss reporting or recovery it cannot credit:
- Attribution or comp credits the original opportunity's owner, so splitting one buyer across two records mis-pays someone.
- Reporting cannot join a new record to its predecessor, which quietly costs the linked-record option the recovery history it exists to preserve.
Either way, restrict casual stage movement out of Closed-Lost so reps cannot reset stale counters by reopening.
## The Pipeline Amnesty - Run Before Enforcement
Named practice (ORM): give reps one day per month to clean their pipeline with **no penalties** for removing deals. Frame it as a fresh start, not an audit, and exclude amnesty-removed deals from win-rate calculations. This is the antidote to the honesty problem - reps hide dead deals because closing them hurts coverage and win-rate math; the amnesty removes the punishment for telling the truth.
Run an amnesty _before_ the first enforcement pass whenever the sizing step finds more than 20-30% of pipeline value stale: enforcing rules against a book that is one-third dead punishes the honest and rewards whoever games first.
## The Communication Plan - Before Enforcement, Not After
The posture throughout is coaching, not compliance - governance should feel like guardrails, not a cage, and a stale flag is the start of a coaching conversation, not a write-off. Communicate whatever gets automated; otherwise, to the sales team, it didn't happen (RevOps Co-op). Sequence:
1. **Announce the rules before the first flag**:
- The meaningful-activity definition.
- The per-segment thresholds, and what they're derived from.
- What a flag means (a review conversation, never automatic closure).
A rep who first meets a rule by being flagged experiences an ambush.
2. **Publish the exception list at least 12 hours before the meeting that works it** (ORM: any meeting that starts by pulling a report has already failed). Managers arrive with records that failed rules, not opinions about effort.
3. **Run the review inside existing rituals as coaching.** Per deal, walk: here is the flag, here is the evidence, what do you know that the record doesn't?
- Keep executives out of the rep-level session.
- Keep hygiene-score comparisons inside 1:1s and pipeline reviews - a company-wide leaderboard invites gaming.
4. **Publish the outcome**:
- Deals reviewed.
- Dispositions by type.
- Pipeline-value delta.
- KPI movement.
Showing that most flags ended in "keep, with next step" or "re-date with evidence" - not mass closure - is what buys trust for the next cycle.
5. **Announce the cadence and the escalation path.** A one-off purge trains reps to wait it out. Exceptions that clear within a week are a functioning process; exceptions that age past thirty days signal a rule that needs to exist in the system rather than in a conversation (ORM).
**Compensation warning**: never tie comp to field completion - it produces fast, complete, low-quality data (ORM). If any variable comp touches hygiene, tie it to forecast accuracy (an outcome), not field completion (an input that invites junk entry).
## Mass-Cleanup Change Management
Manager attention is the scarce input in a mass cleanup, so spend it by pipeline value recovered per minute of review: **bulk proposal with an override window > per-deal conversation**.
- value: per-deal conversation > bulk proposal - a conversation recovers the deals a rule would have wrongly closed, which is only worth doing on deals carrying real pipeline value
- effort: per-deal conversation > bulk proposal - minutes of manager review per record against one pass over a list
Split the two at a value threshold derived from the pipeline's own value distribution, never at a fixed amount: below it bulk-apply, above it converse. The split moves with who executes it - a manager already running a weekly pipeline review absorbs more conversations than one who reviews monthly, so lower the threshold for them.
- Never let RevOps close deals unilaterally, and never auto-close on a rule.
- On SLA breach, auto-tag for manager review.
- Batch proposals, give managers a stated override window, then apply. Silence after the window is consent to the _proposed_ disposition the rep already saw, not to a surprise.
- The override window applies on both sides of the threshold.
- Use the "never a real opportunity (audit cleanup)" code for bulk closures so rep win-rate and loss analysis stay clean; amnesty removals are likewise excluded from win-rate math.
- Scheduled auto-close is acceptable only when all of the following hold:
- High-velocity pipelines.
- Pre-qualified early stages.
- Referencing last-activity date.
- Sales-leadership buy-in.
- Handle dibs deals as an ownership decision: settle who holds the account (territory rules, a named-account list, or release to marketing), then close the placeholder record. Closing without settling ownership regenerates the problem within a quarter.
references/evidence-and-benchmarks.md›
# Evidence and Benchmarks - Credibility Flags
Check this table before quoting any number to stakeholders.
- **VERIFIED**: traceable to a named source, cross-corroborated where stated.
- **SECONDHAND**: attributed to a big-name source only through an intermediary, do not cite the big name.
- **BASELINE ONLY**: do not quote a cross-company figure for this one, derive the target from internal baselines.
Overall caveat first: much of the published numeric detail in this field originates from vendors selling forecasting or hygiene tooling. ORM is the richest practitioner-voice source but sells forecast models; its numbers are its own customer aggregates - internally consistent and cross-corroborated by Umbrex and Outreach, but not independent research. Say so when citing.
## Thresholds and Named Practices Used by This Skill
| Figure / practice | Source | Flag | Use as |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| Meaningful activity = stage/close date/amount change, not logged touches | ORM | VERIFIED (as one side of a live disagreement) | Default definition; last-activity as second trigger |
| Stale at 1.5x (SMB) to 2.0x (enterprise) segment median days-in-stage | Umbrex, Outreach, DealHub - independent convergence | VERIFIED | Segment-dependent multiplier, not competing opinions |
| Inactivity flags: SMB 14-21d, mid-market 30-45d, enterprise 60-90d; legal/procurement exempt | DealHub | VERIFIED | Rule-of-thumb windows |
| 14-day no-activity flag, mid/late stages | Umbrex, Outreach | VERIFIED | Freshness trigger |
| Four staleness buckets (<90/90-180/180-365/>365d); 12-month dead-pipeline rule; >10% of pipeline typically untouched at 12 months | ORM (own customer aggregate) | VERIFIED as vendor aggregate | Bucket sizing; honest-coverage computation |
| Healthy stale value <20-30% of open pipeline; late-stage stale <15% | Umbrex | VERIFIED | Stale-layer health targets |
| Second push = escalation trigger; repeat pushers at >=2 moves | ORM; Umbrex | VERIFIED | Manager-inspection trigger |
| 3+ close-date slips = disqualification-warranting | SalesOpsClub | VERIFIED | Disqualification trigger |
| Stated reason required on pushes crossing a period boundary | ORM | VERIFIED | Anti-stuffing structural fix |
| Slipped-deal rate target <20%; >30% = systemic problems | Revenue.io | VERIFIED | KPI target (note: ORM's "~20% of day-one in-quarter dates close in-quarter" measures a different cohort - do not conflate) |
| Field completeness 90-95% on forecast-critical fields; 80% floor | Saber; Komo/DAMA | VERIFIED | Completeness targets |
| Cap required fields at 5-7 per object | AskElephant | VERIFIED | Requirement ceiling |
| Required-field vs validation-rule distinction; "n/a n/a n/a at scale" | ORM; AskElephant | VERIFIED | Remediation design |
| Close-date accuracy within 14 days as a KPI | ORM | VERIFIED | KPI tolerance starting point |
| EOQ close concentration 20-25% healthy; sustained >35% per rep = comp-design conversation | Avoma | VERIFIED | Sandbagging watch metric |
| Multi-threading lifts win rates 130% on deals >$50k; winning stakeholder groups 67% larger | Ebsta x Pavilion 2024 (4.2M+ opportunities) | VERIFIED | Why multi-threading depth is a stacked signal |
| Volume floor for reliable modeling: 400+ created opps, 150+ closed-won, 4+ quarters | Gong (help.gong.io) | VERIFIED | When to use internal top-quartile medians instead |
| Pipeline amnesty: monthly no-penalty cleanup day, removals excluded from win-rate math | ORM (named practice) | VERIFIED | Pre-enforcement honesty fix |
| Hygiene-score rollup; 85% threshold explicitly illustrative; nudge counter escalating to manager at third reminder | Jeff Ignacio (RevOps Impact) | VERIFIED (the point-by-point weighting stays paywalled; a separate free companion post confirms the score rolls up activity, pipeline health, deal execution, and outcomes into one accountability score, with no published point values) | Handoff shape for the standing nudge system |
| Ritual cadence: weekly forecast call / biweekly pipeline review (weekly in quarter's last month) / quarterly scrub 2 weeks pre-period-end; exception list published >=12h ahead; executives off rep-level reviews | ORM | VERIFIED | Cadence design |
| 76% say less than half their CRM data is accurate and complete; 37% report revenue loss from poor data | Validity, State of CRM Data Management 2025 (602 users) | VERIFIED | Context on general CRM quality - not hygiene-audit outcomes |
| Coverage: discount deals aged past 2x average cycle; 4x with 30% stale = 2.8x qualified | Clari | VERIFIED | Qualified-coverage computation |
## Handle with Care
| Figure | Attribution | Flag | Guidance |
| -------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| "40-60% of B2B CRM pipeline is stale" | "Gartner 2024" via ORM glossary; primary unreachable | SECONDHAND | Never cite as Gartner |
| "85-90% forecast accuracy at 30 days with hygiene vs 60-70% without" | resources.rework.com (vendor glossary) | SECONDHAND | Directional only |
| "Clean pipeline forecasts 23% more accurate" | "InsightSquared 2023" via ORM glossary; primary unverified | SECONDHAND | Do not quote as research |
| "80% of pipeline value should have a next step" | Circulating listicles and vendor blogs (e.g. Weflow, pipeline-visibility tooling, which defines it as a next step dated within 14 days) | BASELINE ONLY | Set the future-dated next-step target from the team's own baseline; never quote the 80% |
| Win rate on audited vs unaudited pipeline | - | BASELINE ONLY | Never promise a win-rate lift from auditing; measure it against the team's own pre-audit baseline |
| "Reopening recovers 10-20% of lost pipeline" | Letterdrop (one camp of a contested debate) | VERIFIED as a claim, contested as practice | Quote as the recovery available from working a returning buyer, not as an argument for the reopen mechanic - a linked new record earns the same figure |
## Open Debates - State Rather than Paper Over
- **Next-step coverage and audit lift are internal-baseline metrics.** Set both the target % of pipeline with a future-dated next step and any win-rate lift attributed to auditing from the team's own history; neither travels as a cross-company benchmark.
- **Reopen-vs-new-record** stays unresolved among practitioners only under two conditions:
- Attribution or comp credits the original opportunity's owner, so splitting one buyer across two records mis-pays someone.
- Reporting cannot join a new record to its predecessor, which costs the linked-record option the recovery history it exists to preserve.
Elsewhere the linked new record wins on both axes.
- **Public-leaderboard-vs-private-coaching** is genuinely unresolved - present both sides.
- Short recycle-bin retention (e.g. 15 days on one major CRM) circulates in CRM-hygiene guides without a single canonical citation; verify against the user's own platform documentation before quoting a number.
SKILL.md›
---
name: sales-pipeline-hygiene
description: Run a periodic, checklist-based hygiene audit over an active pipeline snapshot - stale deals (no stage, close date, or amount change, not logged touches) flagged against segment-specific stage medians, close-date push-count anomalies, and missing forecast-critical fields - producing an exception list with a disposition per flagged deal, a remediation plan, and a pass threshold. Use whenever the user mentions pipeline hygiene, a stale deal audit, pipeline cleanup before a QBR, deals that keep pushing, a close date that keeps slipping, missing fields on deals, or "our pipeline is full of junk" - even if they never say "hygiene". Covers B2B and B2C/high-velocity/PLG. Do NOT use for rewriting stage definitions - use mbfinotti/revops-skills@pipeline-stage-definition-audit instead.
license: MIT
metadata:
author: Maya-Beth Finotti
version: "1.2.4"
---
# Pipeline Hygiene
Audit the deals sitting in the active pipeline right now - stale deals, close-date push anomalies, missing forecast-critical fields - and turn the findings into an exception list with one disposition decision per flagged deal, a remediation and communication plan, and a measurable pass threshold. Ownership is split three ways, not shared (ORM):
- RevOps owns the definitions, the snapshot, the automation, and the pre-published data package.
- The front-line manager owns the per-deal disposition and the coaching conversation.
- The rep owns the update and the evidence.
The split is what removes the argument - the manager arrives holding specific records that failed specific rules, not a general complaint. Splitting it the other way produces meetings that run on time and change nothing.
The audit's load-bearing definitional choice comes first: **meaningful activity means a change to Stage, Close Date, or Amount - not logged calls or emails** (ORM). Logged touches are activity in the CRM sense, but they do not indicate the deal moved, so a rule built on them can be satisfied without any progression - which is exactly how stale pipeline survives review after review. This is a live practitioner disagreement (many tools key on last-activity date); default to the field-change definition and use last-activity as a second, independent trigger - together, never interchangeably.
## Scope Boundaries
State these in the deliverable so the audit does not drift:
- This is a periodic audit of the deals in the pipeline today. Designing the standing automated reminder/nudge system that prevents staleness is a different job: the audit may recommend automating a recurring check and describe what it hands off to, but must not design alert timing, channels, or notification-fatigue policy.
- It does not audit or rewrite stage definitions or exit criteria - that is `mbfinotti/revops-skills@pipeline-stage-definition-audit`. Hygiene takes the existing stage set as given and inspects the deals inside it.
- It does not diagnose overall forecast reliability - that is `mbfinotti/revops-skills@sales-forecast-diagnostic`. Hygiene feeds it clean data; it does not fix the forecast method.
- It does not set org-wide field ownership or source-of-truth policy - that is `mbfinotti/revops-skills@crm-data-governance`. Hygiene checks completeness of the fields that already exist.
- It does not trace funnel revenue leakage - that is `mbfinotti/revops-skills@revenue-leakage`.
## Interview
Ask before auditing. One question per message; multiple-choice where possible; skip anything already answered.
- What can you export or query from the system of record: open deals with stage, amount, close date, owner, last activity date, created date, next step? Stage-change history? Close-date change history? As-of snapshots?
- Which motion and segments feed this pipeline: SMB/high-velocity, mid-market, enterprise, B2C/transactional, PLG sales-assisted, mixed? Typical cycle length and deal size per segment?
- Which recurring rituals already exist - weekly forecast call, pipeline review, QBR, deal desk? The audit rides on these; it must not add a meeting.
- Which fields do forecasting and pipeline decisions actually read? (These, not all fields, are what completeness is checked against.)
- Does a written definition of "stale" or any hygiene rule already exist? Is it enforced, and by whom?
- By what date must the result land - a QBR, a forecast call, a board number? A date inside the week promotes the remediations that ship the same day (validation rules, nudges) and demotes anything needing an integration.
- Is this a one-off cleanup (pre-QBR, pre-forecast, new leader) or the start of a recurring cadence? A recurring mandate is what makes auto-capture worth its cost; a one-off run leaves it unbuilt and re-runs the same manual pass next quarter.
- What is the effort ceiling: how much added friction per deal reps will absorb, how much admin configuration time exists, and how much manager review time exists per week? A team already at its friction limit rules nudges out whatever the completeness gap says, and a thin review budget pushes the bulk/conversation split (see [references/disposition-and-communication.md](references/disposition-and-communication.md)) toward bulk.
- Who is the manager who will work the exception list with reps, and who owns closing out dispositions?
- Any history of mass cleanups, and how did reps react? Are there known claim-only "dibs" deals - early-stage records opened just to hold an account?
- Is any compensation currently tied to CRM hygiene, field completion, or forecast accuracy?
## Workflow
1. Run the Interview. Fix the audit scope: all open deals as of a stated as-of date. Freeze that snapshot - dispositions are decided against it, not a moving book.
2. Extract the data. If you can query the pipeline data directly, pull open deals plus stage-change history, close-date change history, and activity records; otherwise request an export with those named columns. Then clean and standardize before measuring anything (Umbrex's audit order):
- Map custom stages to canonical order.
- Remove test records.
- Backfill missing stage-entry dates.
- Normalize currency and timezone.
3. Size the stale layer first, using the four staleness buckets - under 90 / 90-180 / 180-365 / over 365 days since last meaningful change (ORM). Recompute coverage excluding the over-365 bucket: the gap between that and headline coverage is the honest measure of how much reporting has been overstating the quarter. If more than 20-30% of pipeline value is stale, schedule a pipeline amnesty before any enforcement (see [references/disposition-and-communication.md](references/disposition-and-communication.md)).
4. Derive per-segment baselines from 12-18 months of closed-won history **with the stale layer excluded** - clean before measuring: a deal group carrying a large dead tail produces a longer, flatter close curve than its live deals actually have (ORM), corrupting the very medians the audit runs on. Compute median days-in-stage per stage per segment (median, not mean).
5. Set thresholds per segment - roughly 1.5x median for SMB/high-velocity up to 2.0x for enterprise - plus freshness windows and push triggers (Detection Rules below; derivations and fallbacks in [references/detection-rules.md](references/detection-rules.md)).
6. Run the three rule families over the snapshot. Output one row per deal per tripped rule, with the evidence that tripped it.
7. Merge flags into a per-deal exception list with pipeline value attached; second-push deals and multi-flag deals go to the top.
8. Propose a disposition per flagged deal from the taxonomy below. RevOps proposes; the manager and rep decide - flagging must never be auto-deletion, and the rep never grades their own homework. Every decided disposition gets a named owner and a recorded reason.
9. Draft the communication plan before anything is enforced or automated, and publish the exception list at least 12 hours before the meeting that works it - any meeting that starts by pulling a report has already failed (ORM). Detail in [references/disposition-and-communication.md](references/disposition-and-communication.md).
10. Emit the audit report (Output Shape below), section by section, for user validation.
11. Compute the KPIs and check the Pass Threshold; iterate dispositions and remediation until it holds, or schedule the gap into the next audit.
12. Wire the recurring audit into the rituals that already exist (Cadence below) and recommend automating the recurring check. The prevention layer the audit hands off to is a nudge-escalation system - Jeff Ignacio's (RevOps Impact) mechanic is the reference shape:
- Message the owner on a past-due close date.
- Increment a reminder counter.
- Add the manager at the third reminder.
Describing that handoff is in scope; designing the system is not (Scope Boundaries).
13. If your harness has persistent memory, store the baselines, thresholds, bucket sizes, and exception counts so the next audit starts from a trend line instead of a re-interview.
## Cadence - Ride Existing Rituals, Never Add a Meeting
- **Weekly forecast call**: RevOps brings committed deals with no meaningful activity in the last 14 days; the rep produces buyer-engagement evidence or the deal drops out of commit (ORM).
- **Biweekly pipeline review** per rep - weekly in the final month of the quarter - working aging, early-stage, and stalled deals off the pre-published exception list.
- **Quarterly territory scrub**, about two weeks before period end, so the cleanup lands before next quarter's coverage is measured.
- **Deal desk** for late-stage, non-standard, or flagged deals (re-stages, deal splits) - not routine hygiene.
- Keep executives out of rep-level pipeline reviews: their presence makes reps defend pipeline instead of exposing risk in it (ORM). Reps attend their manager's session; leadership gets the roll-up.
## Detection Rules
Three families, all reading "meaningful activity" as defined above. Label every threshold with its provenance; numbers are practitioner starting points to calibrate on the user's own data.
- **Stale deals** - two independent triggers, used together:
- Stage age: flag past 1.5x-2.0x that segment's median days-in-stage. The multiplier is segment-dependent, not a matter of taste: ~1.5x for SMB/high-velocity, 1.5-2.0x mid-market, 2.0x enterprise (convergent: Umbrex, Outreach, DealHub).
- Last-activity age: no activity in 14 days for mid/late stages (Umbrex, Outreach). As an inactivity rule of thumb, SMB flags at 14-21 days, mid-market 30-45, enterprise 60-90, with legal and procurement reviews explicitly exempt (DealHub).
- A next step dated in the past, or no scheduled future meeting, also flags.
Classify every stale deal into the four buckets. ORM's 12-month rule marks the truly dead layer - close curves rarely carry meaningful expectation past 52 weeks.
- **Push-count anomalies** - track pushes as a field, not a memory: count close-date changes per deal from field history.
- The second push is the escalation trigger (ORM: the best single predictor of slippage is a rep changing the close date, and the second push is the one to act on). It moves the deal to manager inspection.
- A push crossing a quarter boundary is worse than an in-quarter nudge: require a stated reason on any close-date change that crosses a period boundary.
- Three or more slips is disqualification-warranting (SalesOpsClub).
Separate slipping from dead with evidence tests, not the close-date field. Ask "what has to happen before this date becomes realistic?", then stack the signals:
- Mutual-action-plan progress with dated owners.
- Multi-threading depth.
- Economic-buyer engagement.
- Entry into procurement/legal.
- Champion responsiveness.
A delayed next step alone may be harmless; combined with a pushed date, single-threading, and budget hesitation it becomes an explainable case for intervention. Once a slip is confirmed, update the close date immediately with a note on the evidence - the worst outcome is intervening on the deal but leaving the forecast untouched.
- **Field completeness** - check forecast-critical fields only, not the whole schema:
- Next step and its date, close date, amount, stage, forecast category, loss reason on closed-lost, plus whatever qualification fields the forecast actually reads.
- Amount, stage, and close date are the highest-value targets - they are the meaningful-activity fields themselves.
Target 90-95% completeness on forecast-critical fields, 80% as the minimum floor. Remediate in efficiency order - **stage-gated validation rule > owner nudge > auto-capture** - with the three axes behind that order, and the magnitudes, in [references/detection-rules.md](references/detection-rules.md).
- The validation rule leads: it costs about an hour of admin, fires only on advancement to a late stage so it costs the rep seconds, protects exactly the fields the forecast reads, and switches off again if it misfires. A required field checks that something was entered; a validation rule checks that what was entered makes sense.
- More required fields is not on that list: it is ruled out rather than ranked last, because heavy requirement produces fabricated placeholders ("n/a n/a n/a" at scale), worse than an honest blank because it looks like signal. Hold the cap at 5-7 required fields per object.
- Auto-capture is what the order starves: it removes the friction permanently but costs an integration project plus a consent review, so a ratio picks a nudge over it every round. Promote it when a capture tool is already deployed, or when reps are at their friction limit and there is no nudge left to spend.
The order is a default, not a law; re-rank it against the Interview answers and against who will execute it.
## Dispositions
Every flagged deal exits the review with exactly one disposition, an owner, and a recorded reason. For the stale working list, only two answers are acceptable: revive it with a real next step and a validated close date, or close it out (ORM).
| Disposition | When |
| ------------------------------------- | ---------------------------------------------------------------------------------------------- |
| Close lost, with a real reason code | No buyer-side evidence of an active buying process; the honest state is "not happening" |
| Move to nurture | Genuine future interest, but no active buying process now |
| Re-stage backwards | Deal is real, but the stage overstates the buyer's actual position |
| Re-date with evidence | Date is wrong but the deal is moving; the new date is the answer to "what has to happen first" |
| Keep, with a named next step and date | The flag was a data gap, not a dead deal; fix the record |
This table is deliberately unranked: each row is a different deal state, selected by what the buyer-side evidence supports, not a competing route to the same outcome - ordering them by efficiency would be false precision.
Route non-standard re-stages and deal splits through the deal desk. Never delete - classify instead: deleting removes the record the next audit would learn from, corrupts history and conversion baselines, and recycle-bin retention in typical CRMs is short. Default a returning buyer to a _new_ record linked back to the closed-lost one; reopening the original buys the same recovery at a higher and irreversible cost, and only two named conditions flip that - see [references/disposition-and-communication.md](references/disposition-and-communication.md).
## B2B vs B2C / High-Velocity / PLG
The real divergence is not the thresholds - it is the unit of analysis, the acceptable degree of automation, and whether qualification lives in the CRM at all:
- **B2B (long cycle, high ACV, buying committee)**: deal-by-deal inspection in the pipeline review; 2.0x multipliers, enterprise silence tolerated to 60-90 days; qualification depth in CRM fields (champion, economic buyer, paper process); push-count and quarter-boundary crossings are the slippage focus.
- **High-velocity / B2C**: aggregate rules and exception-based automation replace deal-by-deal review; ~1.5x multipliers, 14-21 day flags; 3-5 stages; scheduled auto-close is acceptable for pre-qualified early stages only, referencing last-activity date to avoid false positives, and only with sales-leadership buy-in. Velocity and conversion-rate thresholds matter more than push counts.
- **Pure PLG**: prospects qualify themselves through usage and self-serve deals convert in-product - a traditional deals pipeline, and therefore a rep-facing hygiene audit, may not be warranted at all. Say so rather than forcing the audit; hygiene shifts to product-signal and PQL routing.
Identical across all motions:
- The meaningful-activity definition (field change, not logged touch).
- Classify-don't-delete.
- Validation-rules-over-required-fields.
- The coaching-not-policing posture.
Shared SLA mechanic: set a maximum allowable age per stage proportional to baseline cycle length, and on SLA breach auto-tag for manager review - never auto-close, which breeds distrust.
## Output Shape
Compact skeleton - full worked examples, including one audit done wrong, in [references/audit-report-examples.md](references/audit-report-examples.md):
```
PIPELINE HYGIENE AUDIT - <pipeline>, as-of <date>
Definitions : meaningful activity = stage/close date/amount change;
per-segment thresholds with provenance
Stale layer : value by bucket (<90 / 90-180 / 180-365 / >365d);
headline coverage vs coverage excluding >365 bucket;
amnesty recommended yes/no
Summary : deals audited, flagged, % of pipeline value flagged
Exception list: deal | owner | flags | evidence | proposed disposition |
decided disposition | disposition owner | reason
Field gaps : field | % complete vs 90-95% target | decision it feeds |
fix (validation rule / nudge - not new required fields)
Push report : push-count distribution; second-push deals at top with
stacked-signal evidence and "what has to happen" answers;
quarter-boundary pushes with stated reasons
Remediation : actions, owners, due dates
Communication : rituals the audit rides on; exception list published >=12h
ahead; who is told what before enforcement
KPIs : baseline vs target per KPI, pass/fail, next audit date
```
## Common Failure Modes
| Failure | Consequence | Fix |
| ------------------------------------------------ | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| Staleness keyed on logged calls/emails | Rules satisfied without progression; stale pipeline survives every review | Key on stage/close date/amount change; last-activity as second trigger |
| One flat threshold across segments | Over-flags enterprise, under-flags SMB | Segment-specific medians and multipliers |
| Measuring before cleaning | Dead tail flattens close curves; baselines corrupted | Exclude the stale layer, then compute medians and coverage |
| RevOps as "CRM police" / auto-close, auto-delete | Distrust; real activity moves off-CRM; honesty punished | Auto-tag for manager review; amnesty before enforcement; coaching posture |
| Deleting flagged deals | The record the next audit would learn from is gone; baselines and rep metrics corrupted | Classify, never delete |
| Enforcing rules nobody was told about | Reps discover rules by being flagged; gaming begins | Publish rules and thresholds first; exception list 12h ahead |
| More required fields as the completeness fix | "TBD" / "." / "123" junk at scale | Cap at 5-7 required; stage-gated validation rule first, nudge second |
| Comp tied to field completion | Fast, complete, low-quality data | If comp touches hygiene at all, tie it to forecast accuracy (outcome), never completion (input) |
| Close-date stuffing at quarter end | Mass date edits to pass the audit; forecast fiction | Require a stated reason on any push crossing a period boundary; fix the incentive |
| Sandbagging | Deals held or timed for comp/quota reasons | EOQ close concentration 20-25% is healthy; sustained >35% for one rep opens a comp-design conversation, not a compliance one (Avoma) |
| Happy ears | Commit deals slip or no-decision out at 40-60% too late to react | Evidence-based forecast categories; stacked-signal tests |
| Treating every push as a dead deal | Genuinely slipping deals killed; legal/procurement stalls mislabeled | Evidence test; exempt legal/procurement review periods |
| "Dibs" deals left untouched | Claim-only records rot, block marketing and territory moves | Explicit disposition rule for claim-only deals |
| Hygiene score as vanity KPI / audit theatre | Score improves, forecast doesn't; same problems persist yearly | Grade on forecast-linked KPIs; recurring exceptions past 30 days become system rules, not more meetings |
## KPIs and Pass Threshold
Track per audit and as a trend across audits, each labelled with provenance:
- Stale value as % of open pipeline: healthy is below 20-30%, late-stage stale below 15% (Umbrex); bucket distribution across the four staleness buckets.
- Honest coverage: headline coverage vs coverage excluding the over-365-day bucket - track the gap shrinking.
- Slipped-deal rate (forecasted deals that push out of period): target below 20%; consistently above 30% signals systemic qualification or discipline problems (Revenue.io).
- Push-count distribution: share of deals at 0 / 1 / 2+ pushes; quarter-boundary pushes with vs without stated reasons.
- Field completeness on forecast-critical fields: 90-95% target, 80% floor (Saber; Komo/DAMA).
- % of open deals with a future-dated next step: core metric; set the target from the user's own baseline, never a published number.
- Close-date accuracy: % of closed deals whose CRM close date matched actual within a tolerance (14 days is ORM's version; tighten from own data).
- EOQ close concentration per rep, as the sandbagging watch metric.
Pass threshold - the first audit sets the baseline; targets come from that baseline, not published numbers. The audit passes when:
- Every flagged deal has a decided disposition with an owner and reason - zero unresolved.
- Zero open deals with a past-due close date at audit close.
- Zero second-push or quarter-boundary-push deals without a documented evidence answer.
- Stale-value %, honest-coverage gap, completeness, and next-step rates all improved against baseline toward the agreed target.
Iterate until all four hold. Before quoting any hygiene statistic to stakeholders (including "40-60% of pipeline is stale"), check its credibility flag in [references/evidence-and-benchmarks.md](references/evidence-and-benchmarks.md) - much of the numeric detail in this field comes from vendors selling forecast tooling.
## Optional Integration Note
Skip unless the user names one of these platforms.
- **Salesforce**: the Recycle Bin retains deleted records for only 15 days, one more reason deletion is irreversible in practice; field history tracking must be enabled per field before push counts become reconstructable.
- **Pipedrive**: per-stage "rotting" day thresholds are a native feature and can encode the derived stale thresholds directly.
## Invocation Examples
- "Our pipeline is full of junk before the QBR - half these deals haven't moved in months. Run a hygiene audit and tell me what to close, keep, or push to nurture."
- "Here's a CSV of our open deals with stage history and close-date changes. Flag everything stale, everything that keeps pushing, and every deal missing a next step."
- "Three deals in my commit have pushed their close date twice each. Audit the book for push anomalies and give my managers an exception list to work with reps."
## Reference
- Read [references/detection-rules.md](references/detection-rules.md) when computing baselines and running the rules - the meaningful-activity definition, per-segment median tables, derivations, fallbacks when history is missing, placeholder detection, and dibs-deal detection.
- Read [references/disposition-and-communication.md](references/disposition-and-communication.md) when deciding dispositions and drafting the rollout - the evidence test per disposition, reason-code design, the pipeline amnesty, the reopen-vs-new-record default and the two conditions that flip it, the bulk-versus-conversation split, and the communication plan.
- Read [references/audit-report-examples.md](references/audit-report-examples.md) when shaping the deliverable - one B2B audit, one high-velocity audit, and one audit done wrong.
- Read [references/evidence-and-benchmarks.md](references/evidence-and-benchmarks.md) before citing any number - every threshold and statistic with source and credibility flag, including the vendor-incentive caveat.