Customer Health Score for PLG SaaS: 7 Signals

A customer health score for PLG SaaS should answer one operational question: which accounts are moving toward durable value, and which need action now? Product-led teams cannot rely on a CSM's opinion because many customers buy, activate, and expand without speaking to anyone. The score has to come from product behavior, commercial data, and friction signals already stored in your systems.

The useful version is not a mysterious machine-learning probability. It is a transparent 0-to-100 model that shows why an account gained or lost points. This guide gives you seven signals, a weighted formula, a worked example, and a practical dashboard-and-alert workflow for operating the score.

What makes a PLG customer health score different?

A sales-led health score often includes relationship strength, executive sponsorship, meeting sentiment, and a CSM's judgment. Those inputs can help when every account has an owner. They break down in product-led growth, where thousands of self-serve accounts may never meet your team.

PLG health therefore starts with evidence of value: activation, repeated use of the core workflow, retention across periods, adoption by teammates, and willingness to pay. Support and reliability data matter too because an active account can still be unhealthy when errors or unresolved tickets block the job it hired your product to do.

Calculate the score at account or workspace level, not only at user level. A single power user can look healthy while the company remains dependent on one champion. Keep user-level detail underneath the account score so the team can see who is active, who disappeared, and whether adoption is spreading.

The 7-signal PLG health score model

Normalize every signal to a 0-to-100 component score. Multiply each component by its weight, then add the results. The weights below total 100%. Treat them as a sensible starting model, not a universal truth; your value event and customer lifecycle should determine the final version.

1. Activation quality — 20%

Activation should represent the first completed value loop, not a tour click or profile update. For a reporting product, that might mean connecting a data source, creating a report, and sharing it with a teammate. For a workflow product, it might mean publishing an automation and seeing its first successful run.

2. Core workflow frequency and recency — 20%

Measure how often the account completes the action that delivers recurring value, and how recently it happened. Compare actual frequency with the cadence expected for that use case. A weekly planning tool and a monthly payroll tool need different healthy windows.

Count successful outcomes rather than clicks, retries, or background noise. A simple component can combine 70% frequency and 30% recency. Cap extreme usage at 100 so one burst of activity cannot compensate for missing signals elsewhere.

3. Retained usage across periods — 15%

Activation says the account reached value once. Retained usage shows that it came back and repeated the behavior. Measure the share of eligible weeks or months in which the account completed the core workflow, using only complete periods.

This signal prevents a launch-day spike from looking permanently healthy. Use a rolling window that matches the product cadence, such as four complete weeks for a weekly tool or three complete months for a monthly workflow. Exclude the current partial period from the denominator.

4. Depth and second-value adoption — 10%

Healthy PLG accounts usually move beyond the first use case. Measure adoption of one or two capabilities that make the product more embedded: saving a dashboard, scheduling a report, adding an integration, creating a second workflow, or consuming an output in another team.

Do not award points for touching every feature. Define the second-value moment for each plan or use case and require repeated successful use when a one-time trial proves little. This keeps the score tied to durable value instead of your feature catalog.

5. Team adoption and champion concentration — 10%

Track how many eligible members perform meaningful actions and how much usage depends on the most active person. A five-seat account where four people complete the core workflow is less fragile than one where a single champion produces 95% of activity.

Score both active-seat coverage and concentration. For example, give half the points for the percentage of enabled members who were meaningfully active and half for avoiding excessive dependence on one user. For solo plans, mark this component not applicable and redistribute its weight instead of assigning an automatic zero.

6. Support and reliability friction — 10%

Product activity can stay high while the customer experience deteriorates. Subtract points for unresolved high-severity tickets, repeated failures in the core workflow, long error streaks, or incidents that affect the account's main use case.

Use friction that your team can verify and resolve. Ticket volume alone is misleading because highly engaged customers often ask more questions. Weight severity, age, recurrence, and whether the issue blocks value. Restore points when the problem is fixed and normal behavior resumes.

7. Commercial trajectory — 15%

Include payment status, plan fit, usage relative to limits, renewal timing, and expansion or contraction signals. Failed payments and repeated downgrades reduce health. Sustained use near a meaningful plan limit can increase expansion potential, but only when the account is also receiving value.

Worked example: score a PLG account

Suppose a paid workspace completes activation, uses the core workflow most weeks, has weak team spread, and recently opened a blocking support ticket. Its normalized component scores are: activation 100, frequency and recency 80, retained usage 75, second-value adoption 60, team adoption 30, support and reliability 40, and commercial trajectory 90.

The total is 73.75. Calling it simply 'healthy' would waste the score. The action is specific: resolve the blocking issue, then help the champion add a second active teammate. The account does not need a generic re-engagement email because frequency and retained usage remain solid.

Use lifecycle-specific thresholds

Do not compare a three-day-old free workspace with a two-year paid customer. New accounts need activation and early retention thresholds. Mature paid accounts need stable recurring value, team spread, reliability, and commercial signals. Churned or paused accounts should leave the active scoring population entirely.

Add trend beside the current band. An account holding at 62 for months is different from one that fell from 86 to 62 in a week. Alert on meaningful movement, a critical component failure, or sustained time below a threshold rather than every one-point fluctuation.

How to build the score from database data

1. Define the value event

Write one sentence describing the successful outcome customers return for. Name the database events and status fields that prove it happened. If product, success, and engineering disagree, resolve the definition before building a dashboard.

2. Fix account identity

Create a stable mapping between users, workspaces, subscriptions, and plans. Handle users who belong to multiple workspaces, anonymous activity before signup, internal accounts, and deleted users. Identity errors create confident but wrong health scores.

3. Calculate transparent components

Store every component, weight, raw input, total, previous total, and reason code. Define how missing data behaves. If a component does not apply to a segment, redistribute its weight among relevant signals instead of treating absence as poor health.

4. Backtest before alerting

Calculate historical scores using only data available at each past date, then compare them with later outcomes. Check whether at-risk accounts churn or fail to activate more often than healthy ones. Review surprising accounts manually; they usually expose broken events, bad segments, or a mistaken assumption about value.

5. Version and recalibrate

Save a score version whenever inputs, weights, or thresholds change. Recheck the model after major onboarding, pricing, packaging, or product changes. Without versioning, a formula edit silently rewrites the meaning of every trend line.

Turn the score into a dashboard and workflow

A useful dashboard shows the account, lifecycle segment, current score, prior score, band, component breakdown, owner, and recommended action. Add distributions by plan and cohort so you can see whether one segment is systematically scored too high or too low.

If your data lives in PostgreSQL, MySQL, MongoDB, Supabase, BigQuery, or another supported database, AI for Database can build this view from a plain-English request. Ask it to calculate the seven components by workspace, exclude staff and test accounts, apply separate free and paid thresholds, and explain the three largest reasons behind each score.

Save the validated result as a self-refreshing dashboard. Then create action workflows: send Slack or email when a paid account drops two bands, notify support when a blocking issue pushes health below the threshold, or trigger a webhook when a newly activated workspace shows expansion potential. Always attach the reason codes so the recipient knows what to do.

Common PLG health score mistakes

Using one model for every lifecycle stage

Free trials, new paid accounts, mature workspaces, and enterprise plans follow different paths. Split models only where the path to value genuinely changes, but do not force obviously different populations into one denominator.

Hiding the score's reasons

A number without components produces generic outreach. Show which signals changed, the raw evidence, and the next action. Customer success should not reverse-engineer your formula while a renewal is at risk.

Sending alerts on noise

Daily behavior is volatile. Require a sustained decline, a two-band movement, or a critical failure before notifying someone. Measure whether alerts lead to investigation and action; silence alerts that repeatedly get ignored.

Quick answers for PLG teams

What signals should a PLG customer health score include?

Use activation quality, core workflow frequency and recency, retained usage, second-value adoption, team spread, support or reliability friction, and commercial trajectory. Adjust weights by lifecycle and customer job.

Should free users and paid customers share one health score?

Usually no. Free users need activation and conversion signals, while paid customers need durable value, retention, reliability, and commercial health. Keep a common scale if helpful, but use separate inputs or thresholds.

How often should a PLG health score update?

Update daily when your product is used daily or weekly, but calculate retention and trend from complete periods. Monthly products may only need weekly refreshes. Match the cadence to how quickly your team can act.

Can a PLG team build a health score without SQL?

Yes. A natural-language database tool can calculate transparent components from application, billing, and support tables, maintain a live dashboard, and trigger actions. Validate the definitions and sample accounts before automating outreach.

Start with a score that produces one clear action

Choose one lifecycle segment, define its value event, and calculate the seven components for a small set of accounts you know well. Investigate mismatches, backtest against completed outcomes, and only then route alerts to the team.

When the score is explainable and separates real outcomes, put it into operation. Try AI for Database at aifordatabase.com to calculate PLG customer health in plain English, keep the dashboard current, and notify the right person when the evidence changes.