t0ddc3by/claude-for-customer-success/data-quality-check

/cs-ops:data-quality-check

Data quality problems don't announce themselves — they surface as incorrect dashboards, missed renewals, and capacity plans built on fictional account counts.

[PROPOSED]

Use when

• Running a scheduled data quality audit (weekly, monthly, or quarterly)
• A health model review or segment analysis returns suspect results and you

need to trace the problem to data gaps

• Onboarding a new CRM integration and establishing a baseline completeness score
• Leadership asks "how clean is our data?" before a board or investor update
• A specific field (e.g., renewal date, ARR, CSM owner) is suspected to be

incomplete or stale across the book

Do NOT use for

• Account-level data corrections (fix directly in the CRM or CS platform)
• Health score recalibration (use /cs-ops:health-model-review)
• Configuring which fields are required (use /cs-ops:customize --section data-quality)
• Generating a data quality SOP document (use /cs-ops:process-doc --data-quality)
• Sales pipeline field hygiene (use the Rev-Ops plugin's crm-hygiene-audit skill; if the rev-ops plugin is installed, run /rev-ops:crm-hygiene-audit)

Typical Activation

• /cs-ops:data-quality-check — full audit across all configured required fields (default)
• /cs-ops:data-quality-check --completeness — coverage rates only, no staleness or consistency
• /cs-ops:data-quality-check --staleness — stale-data view only
• /cs-ops:data-quality-check --consistency — cross-field consistency checks only
• /cs-ops:data-quality-check --field <field-name> — deep audit of one named field

Pre-flight

Read ~/.claude/plugins/config/claude-for-customer-success/cs-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 /cs-ops:cold-start-interview.

Critical configuration to apply:

• Required CRM fields and their completeness expectations
• Health data staleness threshold (e.g., "health scores must update within 30 days")
• Segment assignment method — informs whether segment field is required vs. computed
• CSM assignment model — informs whether CSM owner field is always expected

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.

Reasoning Protocol

Before generating output, apply these primers:

1. CLASSIFY: What type of data quality audit is this?

• Pre-Reporting Hygiene Check: Audit before a reporting cycle, dashboard build, or capacity plan. Optimize for ARR-weighted completeness — downstream analytics depend on this data being clean.
• Post-Transition Validation: Triggered after CSM reassignment, territory rebalance, or CRM migration. Separate transition-caused gaps from pre-existing ones using last-updated timestamps.
• Analytics Distrust Investigation: A dashboard number looks wrong or a metric moved unexpectedly. Forensic audit — trace the suspicious metric back to its component fields. Start with --full, narrow after root cause is identified.
• Recurring / Scheduled Audit: Periodic data quality check with no specific trigger. Compare against prior audit results — highlight what improved, what regressed, and which remediation items remain unassigned.

1. CONSTRAINTS: What limits the solution space?

• G2: Staleness thresholds are configured — do not invent them. If no threshold is configured, flag the gap and recommend one; never apply an arbitrary default without surfacing it.
• G4: Consistency violations may be legitimate manual overrides (e.g., high-touch account below standard ARR floor for strategic reasons). Flag — do not auto-correct. Corrections require CS lead judgment.
• G5: Remediation backlog requires named ownership and due dates before any improvement occurs. A backlog without owners is documentation, not action.
• G7: Every stale record flagged must include source date and staleness indicator. Every data gap must be quantified by ARR impact, not just record count.
• Connected integrations limit what can be retrieved — flag gaps, never silently omit fields or sources.

1. EXPERT CHECK: What would a veteran CS Ops analyst verify first?

• Is completeness ARR-weighted or just record-counted? 5% of accounts missing data could be 40% of ARR — the remediation priority is completely different.
• Are orphaned records (no CSM + no segment) quantified separately? These accounts are invisible to every CS workflow — they are coverage blindspots, not just hygiene issues.
• For consistency violations above 5% of accounts in a single check: is this a systemic definition problem (segment thresholds changed, field mapping drifted) or individual data entry errors?

1. ANTI-PATTERNS: Common mistakes to avoid:

• ❌ Reporting "95% complete" by record count when the missing 5% holds 30% of ARR — always compute ARR-weighted completeness alongside record counts.
• ❌ Applying staleness thresholds that aren't configured — state the configured source explicitly or flag the gap.
• ❌ Mass-assigning orphaned records to CSMs without checking whether accounts are active, churned, or legacy — require disposition (assign / archive / investigate) per orphan.
• ❌ Running only the mode that matches the symptom (e.g., --completeness) when the root cause may be a consistency or staleness issue — start with --full for investigations.
• ❌ Producing the same audit findings session after session with no remediation progress tracking — include "vs. prior audit" comparison when prior results are available.
• ❌ Recommending remediation without naming an owner role — unowned items are never fixed.

After execution, verify:

• Does the audit answer the implicit question ("can I trust the data feeding my reports and plans")?
• Are all data sources timestamped and staleness-flagged per G7?
• Is every data gap quantified by both account count AND ARR impact?
• Is the output mode (--full / --completeness / --staleness / --consistency / --field) matched to the actual need?
• Confidence: [High] if auditing live CRM + CS Platform data within configured thresholds / [Medium] if working from a user-provided export / [Low] if conversation context only — state which.

Mode

--full: Complete data quality audit — completeness, staleness, consistency, and orphaned record checks across all configured required fields. Default.

--completeness: Field completeness audit only — which required fields are missing values, for how many accounts, and at what ARR concentration.

--staleness: Staleness audit only — fields that have not been updated within the configured threshold. Produces a stale-record list.

--consistency: Consistency audit only — cross-field logic violations (e.g., segment classification inconsistent with ARR, health tier inconsistent with score range, renewal date in the past with no churn record).

--field <field-name>: Single-field deep audit — completeness, staleness, and consistency for one named field across the full account list.

Data gathering

Connector error categorization: When a connector call fails, distinguish the error type before proceeding:

• Rate-limited (transient): Connector returns HTTP 429 or equivalent throttle signal. Note the rate limit explicitly in output ("CRM data temporarily rate-limited — retry in 60 seconds recommended") and offer to retry rather than proceeding with degraded output.
• Unavailable (permanent for this session): Connector is not configured, authentication has expired, or service is down. Fall back to the manual-input path below and label all affected sections as "connector unavailable — manual input used."

Do not conflate these — a rate-limited connector will return data shortly; an unavailable connector will not.

Pull from connected integrations:

• CRM: all account records with all field values (not just populated fields)
• CS Platform: health scores, component scores, lifecycle stages, last-updated timestamps
• CS-Ops config: required field list, staleness thresholds

If nothing is connected:

"To run a data quality check, I need a full account export — one row per

account, all columns including blank/null values. Do not filter to populated

fields only — the blank fields are what I'm looking for.

Required columns: account name, ARR, segment, health tier, CSM owner,

renewal date, lifecycle stage, and any other fields configured as required.

Share a CSV or paste the data and I'll run the audit."

Minimum required before proceeding: account list with at least 3 of the configured required fields — including ARR and CSM owner.

Full data quality audit (--full)

Data Quality Audit [Date] · [N] accounts · $[total ARR] · INTERNAL — CS-Ops use only Required fields audited: [N] (per cs-ops CLAUDE.md configuration)

Executive summary

Overall interpretation: [2-3 sentences on the most significant data quality finding and its downstream impact. Example: "CSM owner is missing on [N] accounts ($[ARR]), which means the capacity planner is undercounting load and the at-risk report is excluding those accounts from CSM-level triage. This is the highest-priority remediation item — unowned accounts represent a coverage blindspot, not just a data hygiene issue."]

Field completeness audit (--completeness content)

Field Completeness Report — [Date]

Completeness flags:

For each field missing on more than [configured threshold, e.g., 5%] of accounts:

[Field name] — [Missing %] incomplete ([N] accounts · $[ARR])

Missing [field name] affects: [which downstream skills and reports are impacted].

[Specific impact]: "Without renewal date, the renewal forecast excludes these

accounts and the at-risk report cannot surface renewals approaching in <90 days."

Root cause hypothesis: [Data entry gap / CSM transition — records not updated /

Automated sync failure / Field not required in CRM workflow] [review]

Remediation: [Specific action — e.g., "Assign CS Ops to audit and backfill

[field] for all [N] accounts within [timeframe]. Use [CRM report] to identify records."]

Accounts missing multiple required fields: