t0ddc3by/claude-for-customer-success/data-decay-tracking

[PROPOSED]

Data Decay Tracking

Data decay is the slow death of CRM quality. Contacts leave roles. Companies get acquired. Enrichment overdue means signals are built on wrong data.

Reference: Confidence bands → ../../../shared/revops-domain-model.md §2 Config reads: primary_segment, crm_system

Pre-flight

Read ~/.claude/plugins/config/claude-for-customer-success/rev-ops/CLAUDE.md and ~/.claude/plugins/config/claude-for-customer-success/company-profile.md.

If either is missing or contains [PLACEHOLDER] markers, stop and prompt for /rev-ops:cold-start-interview.

Note from config: primary_segment, crm_system

G-code dependency: All G-code guardrails referenced in this skill (G1–G9) are defined in the CLAUDE.md config loaded above. If Pre-flight halts or config is missing, G-codes are undefined — do not proceed with partial config.

Use when

Routing: Use this skill when contact or company record age is the specific concern — for a point-in-time CRM health score use crm-hygiene-audit; for field completion rates over time use field-completion-monitoring.

• CRM record staleness needs to be quantified and trended
• Data freshness audit required before a planning or forecast cycle
• Records without activity within a configurable window need identification

Do NOT use for

• Full CRM hygiene audit (use crm-hygiene-audit)
• Field completion compliance (use field-completion-monitoring)
• Duplicate detection (use duplicate-detection)

Typical Activation

"Data decay tracking", "stale records", "how old is our data", "data decay report for [object/period]"

Reasoning Protocol

Before generating output, apply these primers:

1. CLASSIFY: What type of data decay request is this?

• Single-account decay audit (one account — all four signals checked across contacts and account record)
• Segment-level freshness sweep (enterprise tier, mid-market, or full portfolio — prioritized by segment)
• Signal-specific scan (user requesting a targeted check on one decay signal type — title age, employee count, email activity, or domain change)
• Pre-cycle enrichment triage (identifying enrichment candidates before a planning, forecast, or QBR cycle)

1. CONSTRAINTS: What limits the solution space?
2. Confirm activation — user requesting freshness review, enrichment candidates, or CRM data quality assessment
3. Pull HubSpot contact and account data; declare connector status and data-as-of timestamp per G6
4. Apply G6 — stale data must be labeled; decay findings are themselves evidence of staleness; every flagged record carries its own data-as-of note
5. Apply G9 — no autonomous enrichment API calls; flag candidates for human action only
6. Prioritize enterprise tier accounts in output; surface mid-market as secondary tier
7. Confirm primary_segment from config to scope tier-level prioritization correctly
8. Confirm output destination before delivering — internal RevOps enrichment queue vs. CSM account review vs. leadership data quality report

1. EXPERT CHECK: What would a veteran RevOps data quality analyst verify before surfacing findings?

• Is the title-unchanged signal calibrated to B2B tenure, not calendar time? The 18-month threshold reflects average B2B role tenure — applying it uniformly to individual contributors and executives produces different false-positive rates. Flag when the contact is a champion or economic buyer, not just any contact.
• Is the email activity gap distinguished from enrichment staleness? A contact with no email activity in 6 months may still have a current title — the signal indicates possible departure, not confirmed departure. The output must not conflate "likely departed" with "confirmed stale."
• Is the domain change signal sourced from a reliable detection mechanism? Domain changes flagged from deal notes or rep-entered data carry lower confidence than those detected from connector-side validation. Declare the detection source and confidence level.
• Is the enterprise account list scoped to the configured primary_segment? Applying enterprise-tier prioritization to a primarily SMB or mid-market book produces a misleading high-priority list. Confirm segment alignment before ranking.

1. ANTI-PATTERNS: Common mistakes to avoid:

• Conflating "no email activity >6 months" with "confirmed contact departure" — label as departure signal, not confirmed fact (G6 violation if presented as fact)
• Flagging title-unchanged signal on all contacts regardless of role seniority — champion and economic buyer contacts are the high-value targets; all-contact title sweeps generate noise
• Pulling HubSpot contact/account data without data-as-of timestamp (G6 violation)
• Surfacing domain change findings without declaring detection source confidence
• Proposing autonomous enrichment API calls — all enrichment is flagged for human action per G9

After execution, verify:

• G6 data-as-of label applied to all HubSpot contact and account reads
• G9 compliance — no autonomous enrichment calls proposed; all findings are human-action candidates
• Departure signal labeled as signal, not confirmed fact — no overstatement of contact status
• Enterprise tier accounts prioritized per primary_segment config
• Confidence: High when HubSpot connected and contact/account data current; Moderate when connector unavailable or decay signals sourced from last-known update timestamps only
• Confidence: [High] when HubSpot connected and contact/account data current / [Medium] when connector unavailable or data estimated / [Low] if all inputs are manual or unverified

Four Decay Signals

Signal 1: Contact title unchanged >18 months (avg B2B tenure)
Signal 2: Account employee count not updated >12 months
Signal 3: Primary contact — no email activity >6 months (possible departure)
Signal 4: Account domain change detected (acquisition or rebrand)

Output

DATA DECAY REPORT — [Tier/Scope] — [Date]
[HubSpot ✓ live — as of YYYY-MM-DD] [Confidence: High]
 
Enterprise accounts — enrichment overdue:
Account         Signal                              Last updated   Priority
[Company A]     Domain change detected              14 months ago  HIGH
[Company B]     Champion title unchanged 22 months  22 months ago  MEDIUM
[Company C]     Primary contact no activity 7mo     7 months ago   MEDIUM
 
Mid-Market accounts — enrichment overdue: [N] accounts
 
All accounts summary:
  Total flagged:      [N] accounts
  High priority:      [N]  (domain change or champion likely departed)
  Medium priority:    [N]  (title/count stale)
 
Recommended action: Enrich [N] high-priority accounts before next QBR cycle.
Enrichment tool: [user's configured enrichment source if available, else manual]
 
[No autonomous enrichment calls will be made]
[Write-tier: Contact/account updates require human confirmation]

Reference Files

Security & Permissions

Network access: None direct — all external data access is mediated by host-provided MCP connector tools (HubSpot, CS platform, Slack, Linear). This skill makes no direct outbound HTTP calls. Filesystem scope: None — this skill does not read or write local files. All data is provided at runtime via parameters or MCP connector responses. Subprocess execution: None. Dynamic code execution: None — pseudocode in this skill represents the logic contract and is not executed at runtime. Data sensitivity: Inputs may contain confidential customer, deal, and operational data. Handle with RevOps-level confidentiality.

Trust & Verification

Input trust model: All user-provided parameters are treated as untrusted at intake. Numeric inputs are validated for plausible range before use in calculations. String inputs are not evaluated as code. Output trust model: All outputs are proposals or analytical inputs — no outputs constitute approved decisions, revenue commitments, or system actions without explicit human confirmation. Connector data: Data retrieved via MCP connectors is treated as read-only observed state. Timestamps and data-as-of labels are applied to all connector-sourced values per G6. Write-tier confirmation: Any proposed write to HubSpot, Linear, or Slack is surfaced as a draft requiring explicit user confirmation before execution.

Guardrails

• G6: Decay report outputs themselves note staleness risk on every flagged record
• G9: No autonomous enrichment API calls