Aestus-native

A health score you can defend line by line

Every account scored on five factors, with the measure, its value, the ladder step it landed on, the weight and the record it came from printed under each one.

Join the waitlist See what it produces

Customer health

Build the customer health review

Who it is for: The person who owns renewals for 20 to 200 accounts and has stopped believing health scores.
What starts it: Monthly on the first, in your workspace's time zone, and on demand for one account before a business review; On a schedule

Coming soonBuild the customer health review is built, but not ready yet, so it cannot be turned on today. In Aestus you can ask to be told when it is ready.

A health score is a number people act on. Somebody takes it into a renewal conversation, somebody else reprioritises a week around it, and a quarter later it decides which accounts get a human. Which means an unjustified health score is worse than no health score at all: it reads exactly like a justified one, and there is no way for the person holding it to tell.

So the whole design of this one is the answer to a single question — what evidence actually supports a judgement about a customer, from records you already hold? The answer is narrower than the category's marketing, and saying so is the point.

Three of the five factors come from your Aestus board, and they are the half a customer-success platform cannot see: how many escalations are open, how long the account's least-recently-touched open ticket has gone without anybody speaking on it, and what actually shipped for them in the period against what is still outstanding. A support desk sees its own queue. Aestus sees the engineering ticket the customer is blocked on, which is usually the thing that decides how the renewal conversation goes.

Two come from your own SQL warehouse, read-only: seat utilisation with the direction it is moving, and how close the renewal is. Those are the numbers a usage-first health score is normally built almost entirely from, and here they carry the smaller share of the weight on purpose — they are also the two most likely to be absent, and a ladder that puts most of its weight on its most-absent measure lurches from period to period. The score then moves because the data moved, and the reader reads it as the account moving.

There is no sentiment factor, and its absence is deliberate. No survey platform is connected, and grading the tone of a customer's ticket text is a model's impression rather than a measure — the one thing this is built not to publish. A sixth factor nobody could check would undo the other five.

The ladder is code. Every factor's steps, every weight and every band floor live in one module, that module prints itself into the document's Method section, and a checkpoint re-does all of the arithmetic against the printed version before anything is written. The points column is the sub-score times the printed weight, and the total is the sum of that printed column — so you can add it up by hand and get the number, which is the only definition of "defensible" that survives you not having the code.

Then there is the defect this exists to prevent, which is small to describe and expensive to live with: a missing measure scored as zero. "We have no usage data for this account" and "nobody is using this account" produce the same red number, and only the second one is a reason to call somebody. Here a factor with no sourced reading is marked unmeasured, its weight is removed from the denominator, and the remaining weights are re-normalised and printed. There is no code path that turns an absence into a zero. A value that arrives with no record behind it is treated the same way, because a number nobody can open reads exactly like one they can.

One level up, the same rule again: an account with fewer than two measured factors is not scored at all. It appears under "Not scored" with the reason and with how many factors had a reading. Scoring it low would send somebody to repair a relationship that may be perfectly fine, and would quietly turn "we are not watching this account" into "this account is in trouble".

And there is a section headed "What this review does not conclude", which exists because a document that only prints what it concluded lets a reader assume it considered everything. It makes no churn prediction and no renewal forecast: Aestus records no renewal outcomes, so there is nothing such a number could have been fitted to, and a fabricated probability is the figure a reader would act on hardest. It states no cause for any score — only what the records show and when they were read — because the why belongs to the person who picks up the phone.

What it produces is not a chart you still have to act on. The review and the account roster land on that period's review ticket as artifacts with their own revision history. Every account in the red band gets a ticket that ends with the account's own marker, so the next period appends a line instead of filing a second one, and moving that ticket to a terminal column is what records the run's work as accepted. The Slack post waits for a person to approve it. Nothing leaves Aestus without that, and nothing is emailed to anybody at all.

What you get

The artifact this use case produces, in the product view you would read it in.

Example — fictional team and data. Not a live run or customer result.

Worked example

document

Customer health review — August 2026

Produced by: Run EXAMPLE-CH-01 · board and warehouse read-only · document artifact · demo values

Scope and what this review cannot see: 8 accounts in scope: 7 scored, 1 not scored, 0 dropped by the roster cap. Then four sentences a health-score product does not usually write — no CRM was read, so there is no deal stage and no logged contact; no support desk was read, so support load is what is on the Aestus board; no survey platform was read, so nothing here is a sentiment score; and no finance system was read, so no figure on the page is about money.
Roster: Every account, worst first, with its score, its band and how many of the 5 factors it was scored on. 2 red, 1 amber, 4 green, median 74. The factor count sits beside the score on purpose: a 86 out of 3 factors and a 86 out of 5 are different claims.
Red accounts: One subsection per red account. Stellwood Freight scores 11, and the table under it carries one row per factor: the measure, its value, the ladder step, the weight, the points and the record. Its weakest factor is responsiveness — abandoned, landing on "abandoned -> 0" for 0, which at weight 0.2 is 0 points. Add the points column up and you get 11.
Not scored: Verdigris Studio is listed here rather than given a number: only 1 factor had a sourced reading, and this review publishes no score below 2. An account nothing is recorded about is unobserved, not unhealthy, and the two call for different work — so it gets no score, no band and no ticket telling somebody it is in trouble.
Movers: 2 accounts changed band against the previous review, named in both directions. When there is no previous review the section says "none recorded" rather than going quiet, because a first review and a review with nothing to report look identical otherwise.
What this review does not conclude: The refusals, stated out loud: no churn prediction and no renewal forecast, because Aestus records no renewal outcomes to fit one to; no cause for any score, only what the records show and when; no sentiment, because no survey platform is connected and reading tone out of ticket text is an impression rather than a measure; and an account with too little recorded activity listed as not scored rather than scored low.
Method: The whole ladder, printed every time: all 5 factors, their steps, their weights and the band floors. Tessellate Media had no warehouse row at all, so usage and commercial are unmeasured, their weight is removed, and the 3 remaining weights printed here sum to 1.00. A missing factor is never scored as zero — that is the one defect that would make this number lie.
Sources: 5 numbered records behind every figure above: the board reads, the tickets' own discussions and the warehouse queries, each with the moment it was read. A measure that arrives with no record behind it is refused before the document is written, because a number nobody can open reads exactly like one they can.

How it runs

Each step is one node in the workflow graph the interpreter runs. Nothing here is a prompt chain hidden in a route handler.

Workflow steps

01It reads the records you actually have
Open escalations and how long the oldest has waited, from your Aestus board — including the engineering ticket the customer is blocked on. Seats, active users and renewal dates from your own SQL warehouse, read-only. Every measure is recorded with its value and the record it came from.
02It checks the evidence before it scores anything
A checkpoint rejects any measure with no source, any value outside its possible range, and anything estimated, rounded or carried over from last period. A measure that could not be read is absent, never written as a zero.
03It applies a ladder that is code, not a model
The ladder, the weights and the bands live in one place and are printed in the document every time. A factor with no reading is marked unmeasured, its weight is removed, and the remaining weights are re-normalised and printed. A missing factor is never scored as zero.
04It checks its own arithmetic
A second checkpoint re-does every sub-score, every weighted sum, every band and every re-normalisation against the printed ladder. If it fails twice nothing is published — no document, no roster, no ticket, no message.
05It says what it could not judge
An account with too little recorded activity is listed as not scored, with the reason and how many factors had a reading. It is never given a low score, because an account nobody has recorded anything about is unobserved rather than unhealthy.
06It writes the review and files the work
The review document and the roster spreadsheet land on that period's review ticket. Each account in the red band gets a ticket with the score, the weakest factor and the evidence, deduplicated across periods. The Slack post waits for your approval.

By hand, and on Aestus

The same job, on either side.

By hand
Four tabs per account, once a quarter.
On Aestus
One run reads your board and your warehouse and records every measure with its source.
By hand
A spreadsheet formula nobody else can open.
On Aestus
The ladder is printed in the document. A reader can re-derive any account's score by hand from the table and the weights beside it.
By hand
A blank cell that quietly scores zero.
On Aestus
Marked unmeasured, the weight removed, and the re-normalisation printed. Nothing absent is ever scored as bad.
By hand
A quiet account gets a low score and somebody calls them.
On Aestus
An account with too little recorded activity is listed as not scored, with the reason. It gets no number and no ticket.
By hand
"Trust me, they have gone quiet."
On Aestus
Every factor cites the record it was read from and the moment it was read.
By hand
A note in your own document, and the follow-up never happens.
On Aestus
A ticket per at-risk account, on the board, deduplicated across periods and linked to the review.
By hand
You find out the number was wrong in the meeting.
On Aestus
Two checkpoints before anything is published, and the reader recomputes every figure afterwards and reports how many it had to correct.

What Aestus records

Every run is auditable after the fact, which is what makes handing the job over survivable.

The run
Cost, tokens, duration, which model, and why it failed if it did — on the same ledger as every other run in the workspace.
The review and the roster
Both are artifacts on that period's review ticket, with their own revision history, so last period's numbers stay readable.
The tickets it filed
Ordinary tickets you move. Moving one to a terminal column is what records the run's work as accepted.
What it could not judge
Every account it would not score and why, and every measure it could not read — so a gap has a reason rather than a silence.

What it connects to

Only the tools this workflow actually uses. Each one has a setup guide.

slackOptional

Questions teams ask

Where does the score come from?

A published ladder over five factors, with weights you set. The document prints the whole ladder, and under every factor it prints the measure, the value, the step that value landed on, the weight, the points and the record it came from. You can add the points column up by hand and get the score.

What if we have no usage data for an account?

That factor is marked unmeasured, its weight is removed, and the remaining weights are re-normalised so they still total one — and the re-normalised weights are printed. It is never scored as zero. The review also says how many factors each account was scored on, because a 62 out of five factors and a 62 out of two are different claims.

What does it read, and what does it not read?

It reads your Aestus board and your own SQL warehouse. It does not read a CRM, a support desk, a survey platform or a finance system — none of those is connected, so there is no deal stage, no logged contact, no NPS and no invoice state in the document, and the document says so in its first section.

Does it predict churn?

No, and it will not. Aestus records no renewal outcomes, so there is nothing a churn probability could have been fitted to — it would be a number that reads as insight and is noise. The review states what the records show and when they were read. It also states no cause: the why belongs to the person who calls the customer.

Can it change anything outside Aestus?

No. It has read access only, and there is no CRM write, no warehouse write and no email tool anywhere in it. It files and updates tickets on your own board. Sending the pack to a customer stays a person's action.

All use cases How access is governed

Sources

Gainsight, "Customer health score" — scorecard measures: product usage, feature adoption, sentiment, engagement, relationships, customer value. https://www.gainsight.com/blog/customer-health-score/ (read 2026-09-11)
ChurnZero, "Customer health score" — input categories include license utilization and support history: ticket volume, duration and severity. https://www.churnzero.com/blog/customer-health-score/ (read 2026-09-11)
Gainsight, "Quarterly business review" — QBR agenda: support review (cases opened and closed, resolution times), health scorecard trends, usage and adoption, license deployment. https://www.gainsight.com/blog/quarterly-business-review-qbr/ (read 2026-09-11)

Hand over Build the customer health review.

Tell us how your team does this today and we will set it up with you.

Talk to us

Build the customer health review

Who it is for

The person who owns renewals for 20 to 200 accounts and has stopped believing health scores.

What starts it

Monthly on the first, in your workspace's time zone, and on demand for one account before a business review

On a schedule

Coming soonBuild the customer health review is built, but not ready yet, so it cannot be turned on today. In Aestus you can ask to be told when it is ready.

Customer health review — August 2026

Produced by: Run EXAMPLE-CH-01 · board and warehouse read-only · document artifact · demo values

Scope and what this review cannot see: 8 accounts in scope: 7 scored, 1 not scored, 0 dropped by the roster cap. Then four sentences a health-score product does not usually write — no CRM was read, so there is no deal stage and no logged contact; no support desk was read, so support load is what is on the Aestus board; no survey platform was read, so nothing here is a sentiment score; and no finance system was read, so no figure on the page is about money.
Roster: Every account, worst first, with its score, its band and how many of the 5 factors it was scored on. 2 red, 1 amber, 4 green, median 74. The factor count sits beside the score on purpose: a 86 out of 3 factors and a 86 out of 5 are different claims.
Red accounts: One subsection per red account. Stellwood Freight scores 11, and the table under it carries one row per factor: the measure, its value, the ladder step, the weight, the points and the record. Its weakest factor is responsiveness — abandoned, landing on "abandoned -> 0" for 0, which at weight 0.2 is 0 points. Add the points column up and you get 11.
Not scored: Verdigris Studio is listed here rather than given a number: only 1 factor had a sourced reading, and this review publishes no score below 2. An account nothing is recorded about is unobserved, not unhealthy, and the two call for different work — so it gets no score, no band and no ticket telling somebody it is in trouble.
Movers: 2 accounts changed band against the previous review, named in both directions. When there is no previous review the section says "none recorded" rather than going quiet, because a first review and a review with nothing to report look identical otherwise.
What this review does not conclude: The refusals, stated out loud: no churn prediction and no renewal forecast, because Aestus records no renewal outcomes to fit one to; no cause for any score, only what the records show and when; no sentiment, because no survey platform is connected and reading tone out of ticket text is an impression rather than a measure; and an account with too little recorded activity listed as not scored rather than scored low.
Method: The whole ladder, printed every time: all 5 factors, their steps, their weights and the band floors. Tessellate Media had no warehouse row at all, so usage and commercial are unmeasured, their weight is removed, and the 3 remaining weights printed here sum to 1.00. A missing factor is never scored as zero — that is the one defect that would make this number lie.
Sources: 5 numbered records behind every figure above: the board reads, the tickets' own discussions and the warehouse queries, each with the moment it was read. A measure that arrives with no record behind it is refused before the document is written, because a number nobody can open reads exactly like one they can.

Questions teams ask

Where does the score come from?

What if we have no usage data for an account?

What does it read, and what does it not read?

Does it predict churn?

Can it change anything outside Aestus?

Sources

Gainsight, "Customer health score" — scorecard measures: product usage, feature adoption, sentiment, engagement, relationships, customer value. https://www.gainsight.com/blog/customer-health-score/ (read 2026-09-11)

ChurnZero, "Customer health score" — input categories include license utilization and support history: ticket volume, duration and severity. https://www.churnzero.com/blog/customer-health-score/ (read 2026-09-11)

Gainsight, "Quarterly business review" — QBR agenda: support review (cases opened and closed, resolution times), health scorecard trends, usage and adoption, license deployment. https://www.gainsight.com/blog/quarterly-business-review-qbr/ (read 2026-09-11)

A health score you can defend line by line

Build the customer health review

What you get

Customer health review — August 2026

How it runs

By hand, and on Aestus

What Aestus records

The run

The review and the roster

The tickets it filed

What it could not judge

What it connects to

Questions teams ask

Other use cases

Hand over Build the customer health review.

A health score you can defend line by line

Build the customer health review

What you get

Customer health review — August 2026

How it runs

By hand, and on Aestus

What Aestus records

The run

The review and the roster

The tickets it filed

What it could not judge

What it connects to

Questions teams ask

Other use cases

Hand over Build the customer health review.