What the system is watching for
It is watching for drift, which is a specific and awkward thing to instrument because every symptom of it is a reduction in signal. A client who is mentally leaving does not escalate — complaining is an investment and they have stopped investing. They get quieter, and quieter is invisible to any system organized around events.
So the system inverts the usual design. Instead of watching for things happening, it watches for things not happening, against a baseline of what normally happens for that account. Absence is the signal.
It is worth distinguishing this from a renewal system, which owns a known date and a known process. Health scoring owns the unknown: which accounts are quietly changing state between now and then. The two feed each other — a renewal conversation is far better informed by six months of health data — and they are different objects.
One more thing worth stating about scope: this system does not tell you why an account is drifting. It tells you which one to look at, which is the part that is mechanizable. The why is a conversation, and treating a score as a diagnosis rather than a pointer is how these systems end up producing confident wrong interventions.
The architecture, part one: the signals and the baselines
Four signals cover most of the value, and each requires capture that most businesses do not currently have.
Days since a human made contact, measured against that account's normal interval. Requires that contact is logged, which is the single biggest prerequisite in the system and the one that decides whether it works. The capture must ride along with something people already do — a call that happens in a system that records it, an email that syncs — because a separate logging act does not survive a busy month.
Reply latency against baseline. Computed from the same capture. This is often the earliest available signal, and it is almost never watched.
Commitment health: work items past their promised date on that account, and open questions unanswered beyond a threshold. Requires that promised dates were recorded, which is a delivery-system prerequisite.
Conversation range: whether any exchange this quarter was about something other than the deliverable. This one is the hardest to capture cleanly and the most predictive, because a relationship that has narrowed entirely to the scope has become a vendor relationship, and vendor relationships are the ones priced against alternatives.
Each signal stores a rolling baseline per account, and the score is the deviation. Stage one of the system is capture, stage two is baseline maintenance, stage three is scoring — all owned by the system, none by a person.
The architecture, part two: thresholds, actions and the review
Stage four is the threshold, and each signal needs one plus a defined action. This is the part that converts an instrument into a system: a signal that produces a feeling of unease has an infinite latency to decision, however good the data is.
So each threshold names what happens and who does it. Contact interval exceeded by half again: an owner reaches out within three days, personally, about something other than the work. Reply latency doubled against baseline: flag for the account owner to raise at the next review. Two or more commitments past date: a delivery conversation this week, before the client raises it. No non-project conversation in a quarter: schedule one.
Stage five is delivery of the signal, and it pushes rather than waits. A weekly digest to whoever owns accounts, listing only the accounts that moved — not a dashboard, because a dashboard requires someone to remember, and remembering is the faculty that fails under load. Restraint is a design requirement here: a digest listing every account is ignored within a month.
Stage six is the account review on a fixed cadence, where the score is context rather than verdict. The score says look here; the human decides what is actually going on, and records it, which feeds the next baseline.
Stage seven is the outcome record: which accounts scored poorly, what was done, what happened. Six months of that is what tells you which signals actually predict churn in your business, which is knowledge no generic model provides.
The failure edges
The first: absolute thresholds instead of per-account baselines. Produces constant alerts on your most communicative clients and silence on the account that has genuinely changed, which is the exact inversion of what you built it for.
The second: a composite score with no components visible. A single number from nought to a hundred tells nobody what to do. The action attaches to the signal, not to the aggregate, and an aggregate that hides which signal moved is decorative.
The third: capture as a separate task. If logging client contact is its own act, the data is complete for six weeks and then increasingly wrong, and a health score computed from partial capture is confidently misleading.
The fourth: no action attached. This is the most common failure and it looks like success — the dashboard exists, the scores are accurate, and nothing changes, because seeing a red account and having no defined next step produces awareness rather than behaviour.
The fifth: alert fatigue. Tune so that the digest lists two or three accounts a week, not fifteen. A muted channel has infinite latency with the appearance of instrumentation, which is worse than where you started because now you believe you are covered.
Where the capture comes from, and what to build first
Contact capture is the prerequisite and it determines everything, so build it first and alone. In practice that means email sync into the CRM, calendar events attached to the account record, and call recordings logged against the client — all things that happen as a byproduct of the work rather than as a separate act, because a logging task does not survive a busy month.
Start with one signal for a quarter rather than four. Days since a human made contact, per account, against that account's own baseline. It is the cheapest to capture, the easiest to act on, and it will surface most of what a full model would — and running it manually for a month first tells you whether the thresholds are right before anything is built.
The scoring itself is trivial once the capture exists, which is worth saying plainly because the market sells it the other way round. There is no sophisticated model needed here: a rolling baseline, a deviation, and a threshold. The engineering is entirely in making the underlying data appear without adding work to anybody's week.
What done looks like, and what it takes to build
Done is a Monday digest naming two accounts that moved, each with a named action and an owner, and a year in which no client cancellation was a surprise.
The checklist: contact capture riding along with existing work; per-account rolling baselines on four signals; deviation scoring; a written threshold and action per signal; a weekly push digest of movers only; a fixed account review cadence; and an outcome record linking scores to what happened.
The build is two to three weeks, and the capture is nearly all of it. Scoring against a baseline is trivial once the data exists; making the data exist without adding a task to anyone's week is the engineering.
The prerequisite is somebody who owns accounts. A health system with no owner produces signals with nowhere to go — and a founder who owns forty accounts personally will find that the digest becomes another thing they do not read.
Score deviation from each account's own baseline, not absolute thresholds, and attach a named action to every signal. Push a digest of movers only, or it gets muted.