RenewalRadar: Churn and Expansion Prediction
Product usage, support sentiment and contract history unified into one account health score, and written back into the tools where someone can actually act on it.
Client
SaaS Enterprise, Split Product and CS Tooling
Industry
Revenue Operations · Customer Success
Duration
5 months
Year
2025
Background
The evidence that an account is disengaging shows up in the product months before it shows up in a renewal conversation: sessions thin out, a team stops using the feature they bought it for, support tickets change in tone. But product analytics belong to product, tickets belong to support, and the contract belongs to sales, so the customer success manager, who is the one person positioned to intervene, sees none of it together until the renewal is already in the quarter.
The Challenge
The modelling is the easy half. The hard half is identity: product analytics knows a workspace, the support tool knows an email domain, and the CRM knows a legal entity that may cover several of both after an acquisition. Resolving those into one account correctly is the difference between a health score and an expensive average. The second problem is that prediction months ahead means training against labels that are months stale, on a business whose product changed in the meantime, so the model has to be re-evaluated against recent cohorts rather than trusted because it validated once.
Our Solution
SageWare built the pipeline and the surface on top of it. Product analytics, support history and CRM contract data are unified into a warehouse with an explicit account resolution layer, so the mapping between workspace, domain and legal entity is a reviewable artifact rather than a join condition buried in a query. The health score combines usage trajectory, support signal and contract context, and is recomputed on a schedule that matches how fast each input actually moves. Critically, scores are written back into the CRM and the customer success tooling by reverse-ETL. A score that only exists on a dashboard is a report, and a report is not an intervention.
Key Deliverables
- Product, support and CRM data resolved to a single account through a reviewable mapping layer
- Health score combining usage trajectory, support signal and contract context
- Scores written back into CRM and CS tooling rather than left on a dashboard
- Model re-evaluated against recent cohorts, not validated once and trusted
Results & Impact
How We Did It
01
Account Resolution
Built the mapping between product workspace, support domain and CRM legal entity as an explicit reviewable layer, because every downstream number depends on it being right.
02
Unified Pipeline
Landed product analytics, support history and contract data into one warehouse with consistent grain and refresh cadence per source.
03
Health Scoring
Combined usage trajectory, support signal and contract context into a score, recomputed at a cadence matching how fast each input genuinely moves.
04
Actioning & Re-evaluation
Pushed scores back into CRM and CS tooling by reverse-ETL, and set up re-evaluation against recent cohorts rather than a one-off validation.
Decisions & Trade-offs
Deterministic matching for the spine, probabilistic only as a suggestion
Probabilistic matching would resolve far more of the estate automatically, and the one thing worse than an unresolved account is two different companies merged into one. That does not produce a slightly wrong health score; it produces a confident average of two unrelated businesses, and nothing downstream can detect it. Exact identifiers build the graph. Likely matches are queued for a human to confirm. Some accounts stay split for a week. None of them are silently wrong.
Write to our own fields, never over a human’s
Reverse-ETL into a CRM is a write into a system people are working in. A sync that overwrites a note a customer success manager left that morning teaches the team to distrust everything the pipeline touches. Scores land in dedicated fields that only the pipeline owns, and the sync reconciles rather than clobbers. It adds fields to an already crowded object, and it means nobody has ever lost work to us.
Re-scored against recent cohorts, not the one that validated it
Predicting months ahead means the ground truth is months old, and a product that shipped a major release in between is no longer the product the model learned. We re-evaluate on rolling recent cohorts rather than the original holdout, and publish the drift alongside the score. The reported accuracy moves, sometimes downward, in front of the people who commissioned it. A number that is allowed to get worse is the only kind anyone should act on.
Scope & Boundaries
We built the pipeline, the resolution layer, the scoring service and the write-back. Product instrumentation, support tooling and the CRM stayed the client’s systems of record. What a customer success manager does with a score — the playbooks themselves — was theirs to define; we built the triggers, not the plays.
Next Case Study
ClaimGuard: Claims Denial Prediction
Revenue Cycle · Claims Operations