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 }
]
}
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.5"
---
# 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.