Customer Health Score Missing Data: 6 Rules for SaaS

A customer looks healthy because their last survey was positive. Their product usage feed stopped updating three weeks ago. Your dashboard still shows green, so nobody checks in before renewal.

Customer health score missing data needs its own policy. Keep unknown values separate from measured zeroes, show how much evidence supports each score, and route data problems to an internal owner before they trigger customer outreach.

This guide gives you six rules, a worked calculation, and a copyable operating checklist. The thresholds below are proposed starting points for your team to validate, not industry benchmarks or a built-in scoring standard.

1. Separate zero, missing, stale, and not applicable

These four states describe different situations. Converting all of them to zero makes your score easy to calculate and difficult to trust.

Zero means you observed the full measurement window and found none of the defined activity. For example, a working event feed recorded no completed reports for an eligible account over seven days. That may be a real usage warning.

Missing means you cannot determine the value. The event feed might be disconnected, the account identifier might not match, or nobody has recorded the latest relationship assessment. You do not yet know whether the customer is doing well.

Stale means you have a value, but it is older than the freshness rule for that signal. A champion's positive comment from six months ago should not silently stand in for their current opinion.

Not applicable means the signal does not belong in this account's model. A customer on a plan without the collaboration feature should not be penalized for lacking collaboration events. Define applicability from plan and lifecycle rules before looking at the results.

Keep those states in a separate field alongside the numeric value. Do not encode them as negative numbers or a neutral score of 50, because those shortcuts become indistinguishable from genuine observations later.

2. Write a freshness rule for each input

Your product usage feed, billing records, and executive relationship notes should not share one arbitrary expiration date. Their update schedules and business meanings differ.

For a daily usage import, you might flag data as stale when the last successful import is more than 48 hours old. For a relationship assessment, you might require a review every 30 days. These are example policies; choose intervals based on your actual collection process and customer cadence.

Track both the observation time and the ingestion time. A record imported this morning can still describe a conversation from April. Conversely, yesterday's event might arrive late without indicating a customer problem.

Also check whether the source covers the full analysis window. A successful import today does not prove that the previous seven days are complete. Keep a source-level completeness flag or a known gap interval when an import fails.

This distinction matters even in established tools. Gainsight's scorecard configuration documentation explains that validity periods can mark scores as stale while those scores remain included in calculations. Check the behavior of your own implementation rather than assuming a stale label excludes a value.

3. Publish weighted data coverage beside health

A health score answers, “What do the available signals suggest?” Coverage answers, “How much of the intended evidence is usable?” Show both because a high score can be based on a thin slice of the account.

Use this definition: weighted data coverage = total weight of applicable, fresh, observed signals divided by total weight of all applicable signals, multiplied by 100.

Suppose your model has three inputs: product usage at 50% weight, relationship sentiment at 30%, and billing status at 20%. Usage is missing, sentiment scores 80 out of 100, and billing scores 100.

Only half of the intended weight is available, so coverage is 50%. A provisional score calculated over observed inputs is (80 × 30 + 100 × 20) ÷ (30 + 20) = 88.

That 88 is mathematically correct for the observed inputs. It is not enough evidence to label the entire account healthy. Display “88 provisional; 50% coverage; usage missing” and keep it out of the normal green-account queue until your coverage policy is satisfied.

Replacing missing usage with zero produces 44, which implies observed poor performance. Replacing it with 100 produces 94, which implies observed excellent performance. Neither assumption is justified by a failed feed.

If every applicable input is missing, return unknown rather than dividing by zero. If no inputs apply, flag a model-assignment problem. Coverage is an operational completeness measure, not a statistical confidence interval or a probability of renewal.

4. Define when a score is actionable

Write the action policy before adding colors to the dashboard. Otherwise, every team member invents a different interpretation of a partly observed account.

A starting policy could require at least 80% weighted coverage and a valid product usage signal before the overall score can enter an automated health-based outreach workflow. Below that level, show a provisional score for internal review and open a data-quality task.

The essential-signal requirement matters. A model can pass a numeric coverage threshold while missing the one signal your team considers necessary for the decision. Name those required inputs explicitly.

Do not let the coverage gate hide direct evidence of a problem. An explicit cancellation request or verified service outage still needs attention even if the overall health score is unknown. Route those events through separate rules with their own owners.

New customers need particular care. A customer who joined yesterday cannot have a complete 30-day usage history. Use a lifecycle-appropriate onboarding model or label the account as still accumulating evidence; do not compare it with mature customers as if their observation windows were equal.

5. Give missing data an owner and a resolution path

Build an internal queue with account ID, missing signal, reason, first detected time, last valid observation, owner, and next action. Add affected account count for source-wide incidents so one broken import does not create hundreds of disconnected tasks.

Assign collection problems to the integration or data owner. Assign a missing relationship review to the account owner. Assign a plan-eligibility mismatch to whoever maintains the account model. “Data missing” is a diagnosis category, not an owner.

Use a source incident key to group failures and avoid repeated notifications. Close the incident only after the missing window has been checked or explicitly documented as unrecoverable. A resumed import does not automatically repair historical gaps.

Preserve historical score snapshots. When data returns, annotate the coverage change so a jump from unknown to healthy is not presented as customer recovery. If you recompute past scores with backfilled data, label those as restated values and retain the original decision-time record.

Review your queue weekly. Track the share of accounts with actionable coverage, the age of unresolved gaps, and how often coverage-related reviews reveal actual customer risk. Those measures tell you whether the policy helps your team act with better evidence.

6. Test the policy before connecting alerts

Start with a small account sample you can inspect manually. Include a mature healthy account, an account with a verified usage decline, a new customer, a disconnected source, a stale relationship review, and an account where a feature does not apply.

For each case, write the expected data state, coverage, display label, and next action. A disconnected source should produce an internal data issue. A verified decline with adequate coverage can produce a customer-success review. A new customer should use the correct observation window.

Then simulate the return of missing data. Check that the coverage indicator changes, duplicate incident alerts stop, and the account does not acquire a misleading “recovered” label simply because the feed resumed.

Run the policy in observation mode before allowing automated outreach. Compare suggested actions with account-owner judgment and investigate disagreements. Keep the scoring rules stable during that comparison so you can explain why each recommendation was made.

Put the coverage check into your database workflow

If the required account, event, billing, and sync-status records already live in your database, AI for Database lets your team ask questions in plain English and build self-refreshing dashboards. Its action workflows can send notifications from database conditions.

Start with this question: “For each active account, show the latest successful usage import, whether the last seven days are complete, the latest relationship review date, and which required inputs are missing. Keep unknown values separate from zero.”

Validate the result against several source records. Your schema needs timestamps, stable account identifiers, and explicit eligibility rules; natural-language querying cannot reconstruct data that was never collected. Have the data owner prepare the necessary fields or view if they are absent.

Once the checks are reliable, add weighted coverage alongside your existing health dashboard and send internal alerts for unresolved gaps. Start at aifordatabase.com with the missing-input query, then add health-based automation after the policy passes review.

Copy this policy into your operating notes

Record the signal name, account eligibility, measurement window, observation timestamp, ingestion timestamp, freshness limit, completeness check, model weight, required-for-action flag, missing-data owner, and resolution procedure.

For every account, retain the score, coverage, missing reasons, model version, and calculation time. Make those fields visible wherever someone decides whether to contact the customer. A number without its evidence can send your team in the wrong direction.