The health score is green until the week the customer churns. Here is the model behind a score that moves earlier, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
A customer health dashboard is four parts: signals grouped by category rather than blended into one score, weights you can change without a rebuild, trend as the main display, and an action path to a named owner. The reason most health scores fail is that they blend usage, support and relationship signals into one number, so a collapse in one is masked by strength in another. Show the categories separately and let the blended figure be secondary.
Customer health
4
Declining fast
1.9M
Contract value at risk
11
Renewing this quarter
62%
Interventions that recovered
Halden Foods, overall score 38. Two categories are in the poor band and three are fine, which is exactly what a single blended number hides.
You run customer success or the operations behind it. You already know your renewal dates and your escalation paths. What you want is a signal that moves before the renewal conversation, and a score you can defend to the person whose account it turned red.
What a customer success manager does with it weekly, and what it tells a leader quarterly.
Usage, adoption, support, relationship and commercial each score separately, so a collapse in one is never masked by strength in another.
Contribution per signal sits in a file you change in the first quarter, repeatedly, without a rebuild.
Scores snapshot daily, so the chart is real history rather than a recalculation, and direction sits next to level.
Not by score. A small account at 20 should not outrank a large one at 55 and sliding.
With an owner, the category that moved, and a next step with a date. A dashboard with no action path is a report.
Load accounts that churned and see what the score said 30, 60 and 90 days before. Usually two signals do all the work.
A health dashboard is not a traffic light on an account list. It is four parts, and the first one is where the credibility comes from.
Product usage, breadth of adoption, support burden, relationship strength and commercial signals, each scored separately. Blending them is a display choice, not a modelling one.
The contribution of each category and each signal, in one editable file. You will change these repeatedly in the first quarter, and every change needs to be a config edit rather than a release.
The score over time per account, with the direction and rate of change shown alongside the level. A falling account matters more than a low stable one.
A declining account produces a named owner, a reason drawn from the category that moved, and a next step with a date. A dashboard with no action path is a report.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
The modelling decision that determines whether the score is any use.
In this Helix project, build me a customer health dashboard.
The mistake almost every health score makes is blending everything into
one number, so usage collapsing gets masked by a quiet support queue. So
keep five categories separate all the way through the data model: usage,
adoption, support, relationship and commercial. Blending them is a display
choice at the end, not a modelling one at the start.
Put the signal definitions in a file I can edit: a key, a category, which
direction is good, thresholds for good, watch and poor, and a weight.
Seed it with these: weekly active users against licensed users, distinct
features used, days since anyone logged in, open tickets, escalations in
the last 90 days, days since we last met them, how many contacts are
engaged, payment delays, and expansion or contraction last term.
The last two relationship signals are the ones teams leave out, and
champion departure is the churn cause they most often miss.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.The back-test, built early rather than never.
Score each signal against its thresholds, roll up to a category, then roll
categories into an overall figure using the weights in that file. Show the
overall score, but always with the five category scores beside it. A
category in the poor band has to stay visible even when the total looks
healthy.
Snapshot every score daily, so trend is history rather than a
recalculation.
Then build the back-test, and build it now rather than later. Let me load
a list of accounts that churned or contracted with their dates, and report
what the score and each category said 30, 60 and 90 days beforehand. Show
me which individual signals had predictive value and which were noise.
Without that, a health score is a shared opinion with a colour attached.Worth knowing. Most health scores are never validated. The back-test usually shows two or three signals doing all the work.
Ranked by money at risk, not by score.
Build the portfolio view for whoever is signed in: their accounts, sorted
by risk, showing score, direction over 30 days, renewal date, contract
value, and which category is currently weakest.
Rank by contract value at risk rather than score alone. A small account at
20 outranking a large one at 55 and falling gets the priorities exactly
backwards.
Then the account view: the overall score charted over time, each category
charted, and the individual signals behind whichever category is weakest.
Let me annotate the chart with events I record, like an escalation or a
champion leaving.
And flag any account that dropped more than a threshold I set in the last
30 days, regardless of where it started.The action path, and the uncomfortable report that follows it.
When an account crosses into a risk band or drops sharply, create a draft
intervention assigned to its owner, pre-filled with the category that
moved and the signals behind it. Alert the owner and their manager with
the reason in the message, not just the score.
Track what happened to each intervention: what was done, by when, and the
outcome.
Then report whether accounts that received an intervention recovered more
often than those that did not. That is uncomfortable and it is the only
honest measure of whether this dashboard is worth running.
Finally a renewal view: accounts renewing in the next two quarters, ranked
by score and value. That list is where a renewal forecast should start.The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<Amplitude>. Read active users, feature breadth and last login, which is
the usage half of the score.
<Zendesk>. Read ticket volume and escalations, which is the signal teams
already have and rarely weight.
<Salesforce>. Read contract value, renewal dates and who the engaged
contacts are.
<Google Calendar>. Read days since the last meeting, which is the
relationship signal most scores omit.
<Okta>. Verify identity and read the manager chain, which is what the app
uses to give an owner their accounts and leadership the whole book.
<Snowflake>. Read the history behind each signal, which is what makes the
back-test possible.
<Looker>. Publish the book view for the leadership review without a second
export.
<Slack>. Alert an owner when an account drops sharply, with the category
that moved in the message.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. Account health and contract values are commercially sensitive, so set Access Control before sharing: owners see their portfolio, leadership sees the book.
A health score is only as good as the signals behind it, and they live in four different systems.
Amplitude
Read active users, feature breadth and last login, which is the usage half of the score.
Zendesk
Read ticket volume and escalations, which is the signal teams already have and rarely weight.
Salesforce
Read contract value, renewal dates and who the engaged contacts are.
Google Calendar
Read days since the last meeting, which is the relationship signal most scores omit.
Okta
Verify identity and read the manager chain, which is what the app uses to give an owner their accounts and leadership the whole book.
Snowflake
Read the history behind each signal, which is what makes the back-test possible.
Looker
Publish the book view for the leadership review without a second export.
Slack
Alert an owner when an account drops sharply, with the category that moved in the message.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working dashboard. It reads product usage, support and CRM data, and it drives conversations with customers, so it needs to be run properly.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
Account health and contract values are commercially sensitive. SSO means people sign in with their existing account, and access is scoped so an owner sees their portfolio while leadership sees the whole book.
App Security
Pulling usage, support and CRM data on a schedule needs real access to each system. Granting it to the app rather than pasting keys into it means credentials can be rotated or revoked without a redeploy.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
It combines usage, adoption, support, relationship and commercial signals into a per-account view of renewal risk, with the trend shown alongside the level. Its purpose is to move the risk conversation earlier than the renewal date.
Usually because they blend everything into one number, so a collapse in usage is masked by a quiet support queue. Scoring each category separately and showing them alongside the overall figure keeps the failing signal visible.
Active users against licensed users, feature breadth, recency of login, support ticket volume and escalations, days since the last customer meeting, number of engaged contacts, payment behaviour, and expansion or contraction. The relationship signals are the ones most often omitted and most often decisive.
Back-test it. Load accounts that churned or contracted with their dates, and check what the score and each category said 30, 60 and 90 days beforehand. It usually shows a few signals doing the work and several adding noise.
By contract value at risk, which combines both. Ranking by score alone puts a small account at 20 above a large one at 55 and falling, and the second is the more urgent conversation.
Yes. The prompts here are written for Claude Code, Codex or Cursor and stage the build from CSV imports. The judgement calls are your signals, your thresholds and your weights, and the back-test is what tells you whether you got them right.
Customer Success
Work renewals from the notice date backwards, with a stage for each step, an owner, and a forecast leadership can trust. Prompts to build it, and what it takes to run it.
Customer Success
Give escalations a severity, an owner, a communication cadence and a closure record, so the customer hears from you on schedule rather than when someone remembers. Prompts to build it, and what it takes to run it.
Customer Success
Assemble the usage, support, commercial and relationship picture for an account into one reviewable draft, so preparation is editing rather than gathering. Prompts to build it, and what it takes to run it.
Customer Success
Track every new customer through the same stages, with the tasks that belong to them as visible as the ones that belong to you. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.