Zendesk Customer Health Score Dashboard: Spot Churn Risk in Support Data

Your Zendesk instance already contains signals that predict which customers are about to churn. The problem is that those signals are scattered across tickets, CSAT surveys, escalation logs, and wait time reports — invisible in day-to-day operations until a customer cancels and you look back and wonder how you missed it.

A customer health score dashboard pulls these signals into a single view. For each account, it answers: is this customer healthy, at risk, or in trouble? This guide shows how to build one using the data you already have in Zendesk, without requiring a separate customer success platform or data warehouse.

What a customer health score measures

An organization health score in the support context is a composite metric that combines multiple signals from a customer’s support interactions to estimate account health. It’s not a prediction — it’s an early warning system.

The signals that matter most for support-derived health scoring:

Signal What it captures Why it predicts churn
Repeat contact rate Same customer filing 3+ tickets in 30 days Active struggle with your product
CSAT trajectory Declining satisfaction trend over last 3–5 interactions Eroding patience
Escalation rate per customer Tickets requiring senior or specialist intervention Chronic complexity or frustration
Requester wait time vs team average Customer getting slower service than your average Perception of deprioritization
Ticket silence Sudden drop in contact frequency from a previously active account May have given up or started migrating
Reopen rate per customer Tickets frequently reopened after being marked solved Not getting real resolution

None of these alone is definitive. Combined, they build a picture that’s surprisingly accurate.

How to build the health score in Zendesk Explore

Step 1: Choose your scoring model

Start simple. A weighted scoring model with 3–5 signals is more useful than a complex model that nobody trusts:

Signal Weight Green (healthy) Yellow (watch) Red (at risk)
Repeat contacts (30 days) 25 pts 0–1 tickets 2 tickets 3+ tickets
CSAT trend (last 3 ratings) 25 pts Stable or improving 1 negative 2+ negative
Escalations (90 days) 20 pts 0 1 2+
Wait time vs average 15 pts ≤ team median 1–1.5× median >1.5× median
Reopen rate 15 pts <15% 15–30% >30%

Score each signal: Green = full points, Yellow = half points, Red = zero. Total score out of 100. Accounts below 50 are at risk. Accounts between 50–70 need watching.

Step 2: Build the component reports

Create separate reports in Explore for each signal:

Repeat contact report: 1. Dataset: Support — Tickets 2. Metric: COUNT(Tickets) 3. Dimensions: Ticket requester organization, Ticket created (last 30 days) 4. Filter: Created date = last 30 days 5. Sort: Descending by count

CSAT trajectory report: 1. Dataset: Support — Tickets 2. Metric: CSAT score (per survey response) 3. Dimensions: Ticket requester organization, Ticket solved date 4. Filter: Last 90 days, only rated tickets 5. Calculate: Rolling average of last 3 ratings per organization

Escalation count report: 1. Dataset: Support — Tickets 2. Metric: COUNT(Tickets) where ticket has escalation tag or was reassigned to escalation group 3. Dimensions: Ticket requester organization 4. Filter: Last 90 days

Wait time report: 1. Dataset: Support — Tickets 2. Metric: Median requester wait time 3. Dimensions: Ticket requester organization 4. Filter: Last 90 days 5. Compare each organization to the team-wide median

Reopen rate report: 1. Dataset: Support — Tickets 2. Metric: COUNT(Reopened tickets) / COUNT(Solved tickets) × 100 3. Dimensions: Ticket requester organization 4. Filter: Last 90 days

Step 3: Combine into a dashboard

Create a new Explore dashboard with:

  1. Summary table — One row per organization, columns for each signal (color-coded green/yellow/red), composite score, and trend arrow (improving/declining/stable)
  2. Risk distribution — Pie or bar chart showing count of accounts in each health tier
  3. Watch list — Filtered view showing only Yellow and Red accounts, sorted by revenue or contract value if available
  4. Trend line — Overall account health distribution over time (are more accounts getting healthier or sicker?)

Step 4: Automate the review

Add the health score dashboard to your weekly support ops review agenda. Review the top 5 at-risk accounts every week. Assign follow-up actions: customer success outreach, ticket review, or escalation pattern investigation.

Adding ticket silence detection

Ticket silence — when a previously active customer goes quiet — is one of the strongest churn signals but the hardest to measure in Explore.

The approach:

  1. For each organization, calculate the average monthly ticket volume over the last 6 months
  2. Compare to the current month’s volume
  3. Flag organizations where current volume is less than 50% of their historical average

In Explore, build this as two metrics: - AVG monthly tickets (last 6 months) — Average of monthly ticket counts from months 2–7 ago - Current month tickets — Ticket count for the current month

Organizations where current month is below 50% of their average get flagged. This catches both the obvious cases (active account goes to zero) and the subtler ones (account dropping from 8 tickets/month to 2).

Connecting health score to action

The dashboard is only valuable if it triggers action. Define a playbook for each health tier:

Green accounts (score 70–100)

  • No action required from support ops
  • Share positive signals with customer success for expansion conversations
  • Use as case study candidates

Yellow accounts (score 50–69)

  • Review last 5 tickets for patterns
  • Check if the same issue is recurring
  • Monitor for one more week before escalating to customer success
  • If CSAT is the main driver, do a ticket quality audit

Red accounts (score 0–49)

  • Immediate alert to account owner or customer success manager
  • Support lead reviews all open tickets for the account
  • Proactive outreach within 48 hours: “I noticed you’ve had a few issues recently — I want to make sure we’ve fully resolved everything”
  • Log outreach and outcome for follow-up

Ticket silence accounts

  • Separate process: verify the customer is still active (check product usage if available)
  • If still active but not contacting support, it may be fine — or they may have switched to a competitor
  • Outreach with a check-in, not a sales pitch

What this dashboard won’t tell you

Be honest about the limits:

  • Product usage — Support data shows how customers feel when things go wrong; it doesn’t show how often they use the product. The best health scores combine support data with product analytics.
  • Decision-maker sentiment — The person submitting tickets may not be the person deciding to renew. A frustrated end-user and a satisfied VP can coexist.
  • Competitive evaluation — A customer quietly evaluating competitors won’t show up in your support metrics until they’re already partly migrated.
  • Contract-locked customers — Some unhappy customers stay because they’re locked into annual contracts. They’ll churn at renewal even though support metrics stabilized.

This dashboard catches friction-based churn risk. It doesn’t catch strategic churn (budget cuts, market shifts, competitive switches).

Common mistakes

Building a complex model before building a simple process. Start with 3–5 signals and a manual weekly review. You can add sophistication later. A 50-variable machine learning model that nobody looks at is worth less than a spreadsheet that the support lead reviews every Monday.

Treating all accounts equally. A red score on a $500/year account and a red score on a $50,000/year account require different responses. Weight your review by account value.

Using absolute thresholds instead of relative ones. An account that submits 10 tickets/month might be healthy (they’re a power user with a complex implementation) or at risk (they used to submit 2 tickets/month). Compare each account to its own baseline, not just to team averages.

Not closing the feedback loop. If you flag an account, reach out, and fix the issue — record it. Over time, this builds a dataset of which interventions work and which signals were false positives. That’s how you improve the model.

FAQ

Can I build this without Explore Professional? Explore Professional (included in Suite Professional and above) gives you custom reports and calculated metrics. With Explore Lite, you can view prebuilt dashboards but can’t build the custom reports needed for a health score. For teams on lower plans, a tool like TicketBoard can provide this analysis without Explore Professional.

How is this different from the organization health score in the glossary? The organization health score glossary entry defines the concept. This guide is the implementation — how to actually build it in Zendesk Explore, what signals to use, how to weight them, and what to do with the results.

Should I share the health score with customers? No. The health score is an internal tool for prioritizing outreach and resources. Sharing it with customers creates awkward conversations and can feel surveillance-like. Share the actions you take based on it — proactive check-ins, prioritized support — not the score itself.

How often should I recalibrate the scoring model? Review the thresholds quarterly. Are you getting too many false positives (accounts flagged as at-risk that are actually fine)? Tighten the thresholds. Too many false negatives (accounts that churned without being flagged)? Loosen them or add new signals.

What’s the minimum number of tickets needed for a reliable score? Accounts with fewer than 3 tickets in the lookback period don’t have enough data for a meaningful score. Exclude them from the scored list or flag them as “insufficient data” rather than defaulting to green.


Build a customer health view from your Zendesk data — start free