5 October 2026James Hayward-Zhu5 min read

What your CRM data isn't telling you about customer health

A paper collage on green. A vintage halftone woman peels back a neat quilt of flat green paper squares to reveal crumpled, stained scraps packed underneath. Taped notes, a torn calendar page, a modern photograph and a cartoon figure sit around her among biro ticks and charts.

The conversation about health scores usually starts with the model: what factors to include, how to weight them, whether to use a composite score or a dashboard of indicators. That's the right conversation to have. But there's a prior conversation that often gets skipped: is the data in the CRM actually accurate?

I've been in enough CS Ops reviews to have a baseline expectation. When a team shows me a health score model, I ask a version of this question: how old is the data feeding into this? What was the last time someone updated the contact records? When did you last verify that the primary contact still holds the role you have recorded? When were the product usage flags in the CRM last refreshed?

The answers are usually uncomfortable. Contact data that's six to eighteen months stale. Usage flags that were set at onboarding and never changed. Relationship quality scores that are logged by the CSM and therefore reflect the CSM's confidence in the account, not any objective signal.

Health scores built on stale or subjective data aren't health scores. They're impressions. And acting on impressions with the confidence of a metric is a meaningful business risk.

Three types of data that degrade fastest

Contact and relationship data. People move. The champion who bought the product is at a new company. The economic buyer who sponsored the deal has been restructured into a different team. The CRM still shows them in the original role. The CSM may or may not know. It depends on how frequently they're in touch, and whether the departure was announced or quiet.

This matters more than most CS teams account for. Relationship depth is almost always a health score input, either explicitly (a relationship quality rating) or implicitly (logged touchpoints with named contacts). If the contacts are wrong, the relationship score is wrong, and you're potentially missing that an account has gone dark because you no longer have anyone there to go dark with.

Self-reported usage data. Many CRM health score models include fields like "using Feature X: yes/no" or "adoption stage: basic/intermediate/advanced." If these fields are maintained by CSMs rather than pulled from product telemetry, they're subjective and stale by design. CSMs update them when they remember to, after conversations that may have been weeks or months apart. They reflect what the customer said they were doing, not what the product data shows.

Product telemetry is more reliable, but only if the integration between your product and CRM is current and correctly mapped. It's worth auditing that mapping periodically: features get renamed, usage events change, and the field that was tracking "active users" six months ago may no longer mean the same thing.

Sentiment and satisfaction signals. NPS scores, CSAT responses, and CSM relationship ratings all have the same problem: they're point-in-time snapshots treated as ongoing indicators. An NPS score from the last quarterly survey tells you how the customer felt at that point. A relationship quality rating of "strong" tells you how the CSM felt about the account when they last updated it. Neither tells you how the account feels right now.

The gap between the last signal and the present is where surprises live.

The input-output problem

There's a subtler data quality problem in most CS CRMs, and it's harder to fix: activity logging is a proxy for activity, but activity is only a proxy for relationship quality, and relationship quality is only a proxy for retention likelihood.

When a CSM logs a call in the CRM, that means a call was logged. It doesn't mean the call happened. It doesn't mean the call was useful. It doesn't mean the customer came away with renewed confidence in the product. The log is an input, and a lot of health score models treat it as an output.

This isn't a critique of logging. Logging is valuable. It's a caution about what you can infer from it. A high volume of logged touchpoints in an account that churns six months later is useful retrospective data. It shouldn't have been driving a "healthy" signal in the months before the churn.

What to do about it

Three practical moves:

Build a data quality audit into the CS rhythm. Once a quarter (or at a minimum, before renewal prep begins), CSMs should be prompted to verify the accuracy of the contact record, confirm the key stakeholders are still in role, and update relationship flags based on current knowledge rather than historical notes. This isn't glamorous, but it's foundational.

Distinguish CRM-sourced data from product-sourced data in the health model. Weight them differently. Product telemetry is more reliable than CSM-logged sentiment, and the model should reflect that. Where you're relying on CRM-sourced data, build in a decay factor: old data should count less than recent data, because staleness is a real risk.

Add freshness as a health indicator. Some CS Ops teams have started including "last verified" or "data freshness" as a composite input: if contact data hasn't been verified in six months, that itself is a yellow flag, because it means you have incomplete information about the account regardless of what the other scores say. It's a simple addition and it surfaces something genuinely important.

The CS Ops responsibility

Data quality in the CRM is a CS Ops problem, not a CSM problem. Individual CSMs don't have the time to audit their own CRM hygiene at scale, and without a structured process, data quality degrades silently rather than visibly.

CS Ops owns the data standards (what fields exist and what they mean), the refresh cadence (how often data gets reviewed and updated), the integration with product telemetry (ensuring usage data is accurate and current), and the audit process that surfaces staleness. When the health score is wrong, it's usually not because the model is poorly designed. It's because the inputs are unreliable.

The best health score model in the world produces the wrong output from bad data.

Questions worth sitting with

When did someone last check whether the primary contacts in your CRM are still in the roles recorded?
Are the usage-related fields in your CRM health model pulled from product telemetry, or manually updated by CSMs?
If a customer churned tomorrow and you traced back through their CRM record, would you find signals you should have caught earlier? What stopped you catching them?

The short version. Health scores are only as good as the data feeding them, and CRM data degrades faster than most teams account for. Contact records go stale, usage flags don't get updated, and activity logging gets treated as a signal of relationship quality when it's really a signal of admin effort. CS Ops owns the data quality infrastructure: standards, refresh cadences, product integrations, and audit processes that make staleness visible rather than silent.