Maya — CS Health Radar

THE PROBLEM A CSM carrying 60-120 accounts can actively manage about 15 a week. Churn is decided in the other 85 - and it is usually visible months before anyone notices. Signals sit scattered across support, product analytics, CRM and billing, so assembling one account's picture by hand takes ~20 minutes. Detection is calendar-driven, not signal-driven. And knowing is not acting: a credible outreach takes 15-25 minutes to write, so at 6pm the at-risk account gets a generic check-in, or nothing. TARGET USER An individual-contributor CSM at a growth-stage B2B SaaS company. Accounts are $8k-$60k ACV: too small for a named account team, too large to ignore. Paid partly on renewals, so churn is personally expensive. THE COMPLETE WORKFLOW Signal recorded, health recomputed, grounded risk explanation generated, action chosen and outreach drafted, human approves or rejects with a reason, decision written to the account timeline. WHAT MAKES IT DIFFERENT Most CS tooling outputs a score and stops - the CSM still does the thinking and the writing. Maya delivers the drafted action, not the number. The health score is deterministic TypeScript, never a model. Same signals, same score, always - so cause and effect can be verified live rather than trusted. Every account shows the breakdown behind its number: Blue Ridge Partners reads 27 because -34.01 -19.94 -13.57 -5.59. The model only does what rules cannot: turn signals into a narrative, pick an action, write the message. Grounding is enforced in code and schema, not the prompt. A Postgres CHECK makes an explanation citing fewer than two signals impossible to save. Citation ids are validated server-side against the supplied context, so an invented citation is rejected. Actions are bounded to a six-value enum. Nothing is ever sent. Approval records the decision and final text. No outbound sender exists anywhere in the code - enforced by absence, not a flag. IMPACT Assessing one account drops from ~20 min to under 30 sec.