AI customer health monitoring is a repeatable process for finding meaningful changes in an account, gathering the evidence behind them, and routing the investigation to the customer-success person who can decide what to do. It can use a health score, but the score is only a signal. The workflow is what turns that signal into a responsible action.

That distinction matters. A red account with no explanation creates more work for a CSM. A green account can create false comfort if the score missed a sponsor change, an unresolved implementation issue, or a different pattern of product use. The goal is not to have AI declare which customers will churn. It is to help a team notice where human attention may be valuable and arrive with the relevant context already assembled.

Start with the decision, not the score

Before choosing inputs or weights, define the decision the workflow should support.

A useful job statement might be:

Every Monday, identify enterprise accounts renewing in the next 120 days that show a material change in value realization, support experience, or relationship activity. Prepare the supporting evidence for the assigned CSM, who decides whether to investigate, watch, or act.

This statement names the portfolio, time horizon, signal groups, cadence, output, and accountable person. It is narrow enough to test. “Predict churn” is not.

Choose one primary decision for the pilot. Examples include:

  • which accounts need discussion in the weekly customer-success review;
  • where a CSM should validate whether an agreed outcome is off track;
  • which onboarding accounts need an internal blocker removed;
  • which renewals need an evidence-based risk review before the forecast is updated.

If the workflow tries to prioritize risk, expansion, adoption, advocacy, and support escalation at once, nobody will know what a change in health is asking them to do. The same discipline used to build an AI agent around one recurring job applies here.

Build a source map for each signal

Customer health usually spans several systems. Do not connect them as an undifferentiated pool. For every signal, record its source, meaning, freshness, owner, and limits.

  • Value realization: Look for completion of the customer’s core workflow, adoption of agreed capabilities, and progress against success milestones. Ask whether the customer is getting the outcome the relationship is built around. Raw logins can rise while meaningful use stays flat.
  • Support experience: Review open severity, age, repeat issues, affected users, and the recent resolution pattern. Ask whether an unresolved problem is blocking value. High ticket volume can indicate poor experience or healthy engagement.
  • Relationship: Check the last substantive meeting, agreed actions, stakeholder participation, and sponsor continuity. Ask whether there is still an active path to the customer’s goal. Missing activity may reflect poor logging rather than customer silence.
  • Commercial: Use the renewal date, contract scope, invoice status, proposed changes, and renewal-stage history. Ask whether the timing or commercial state changes the urgency. Finance and contract fields often need tighter access.
  • Delivery: Review onboarding steps, implementation dependencies, owners, and due dates. Ask whether the account is waiting on the customer, your team, or a third party. A late milestone is not equally important for every segment.

The source map prevents a familiar failure: treating what is easy to count as what matters. If the customer bought the product to complete a particular business workflow, progress toward that outcome is usually more informative than generic activity. The definition still needs validation against your own customer outcomes; it should not be copied from another company’s template.

It also makes missing evidence visible. “No executive meeting recorded” is an observation about the CRM. It is not proof that executive engagement disappeared. A useful output says which one it knows.

Use a score to route attention, not explain the account

Customer-success platforms commonly combine several measures into a scorecard. Gainsight’s scorecard documentation, for example, supports multiple measure groups, manual and automatic inputs, weighting, exceptions, and different scorecards where one scoring method does not fit every customer.

That last point is the important one. A small self-serve account and a global enterprise rollout do not produce the same evidence on the same cadence. Segment the model when the customer motion differs materially.

A practical first version can be simpler than a 100-point formula:

  • Watch: one meaningful signal changed, but the evidence is incomplete or the change is within expected variation.
  • Review: several related signals changed, or one high-consequence condition needs a person to assess it.
  • Act: the assigned owner confirmed a problem and chose a next step.

Keep “act” as a human decision, not a model-generated state. The agent can prepare a recommendation, but the CSM owns the account context and the response.

If the team already uses a numeric score, preserve the component scores and their recent movement. A fall from 82 to 68 carries more information than the label “yellow.” The evidence packet should explain which inputs moved, over what period, and whether any data was stale or missing.

Design the evidence packet before the alert

An alert that says “Acme is at risk” sends the CSM back through product analytics, support tickets, CRM notes, and billing records. The workflow has detected work, not reduced it.

Define a standard evidence packet first:

  1. Account and review window: customer, segment, owner, renewal horizon, and comparison period.
  2. Trigger: the exact rule or change that caused the review.
  3. Changed signals: current value, prior baseline, direction, and materiality threshold.
  4. Supporting records: the relevant usage events, cases, milestones, meetings, or commercial records.
  5. Definitions: what “active,” “adopted,” “severe,” or “stalled” means for this workflow.
  6. Missing or conflicting evidence: stale sources, absent fields, and disagreements between systems.
  7. Interpretation: a clearly labeled hypothesis, separate from the observed facts.
  8. Next decision: watch, investigate, contact, escalate internally, or take no action.

This is the same foundation behind trusted AI answers: sources, definitions, and permissions. A generated summary should make the evidence easier to inspect, not replace it.

Put AI in the investigation step

AI is most useful here when the evidence is mixed and the path varies by account. It can help assemble a consistent brief, compare current signals with a relevant baseline, group related support themes, and state what information is missing.

A dependable workflow separates deterministic controls from model-assisted work:

Scheduled account cohort
        ↓
Deterministic signal and access checks
        ↓
Agent gathers approved evidence
        ↓
Agent prepares facts, gaps, and a labeled hypothesis
        ↓
CSM reviews and chooses the next action
        ↓
Outcome and feedback return to the workflow owner

Use code or policy rules for portfolio membership, date windows, permission checks, thresholds, and allowed actions. Use the agent where language and investigation help: summarizing a cluster of related cases, comparing account notes with milestones, or explaining why several signals may belong to the same issue.

A concise agent contract could read:

Review only accounts in the supplied cohort. Use the approved usage, support, CRM, and commercial views. Report observations separately from hypotheses. Cite the records behind every material claim. If a source is stale, a definition is ambiguous, or evidence conflicts, state the limitation. Do not change a health field, contact a customer, or create a task unless a separate approved workflow permits it.

Retrieved notes and tickets are evidence, not instructions to the agent. Sensitive commercial fields should remain subject to the same source and user permissions that apply outside the AI workflow. The practical AI governance checklist for business data teams is a useful companion when assigning owners and boundaries.

Test whether the workflow finds useful work

Do not evaluate the system by asking whether its summaries sound plausible. Test the complete workflow against cases with known source state and expected behavior.

Build a small test set that includes:

  • Stable account with normal seasonal usage: Avoid an unnecessary escalation or explain why the change is expected.
  • Usage decline with a known planned pause: Surface the decline and the plan together.
  • Severe unresolved issue near renewal: Assemble the issue, affected workflow, ownership, and timing for review.
  • Missing CRM activity: Mark the evidence as missing; do not infer customer disengagement.
  • Restricted commercial record: Respect the denial and complete only the permitted portion.
  • Conflicting renewal dates across systems: Show the conflict and identify the source owners.
  • Score changes because a definition changed: Report the definition change instead of presenting a customer event.

For historical evaluation, choose account snapshots from a point before the outcome was known. Ask whether the workflow would have assembled accurate, useful evidence at that time. Do not tune on the same accounts used to judge success, and do not turn a small retrospective sample into a claim that the system predicts churn.

Then run a bounded prospective pilot. Track whether CSMs agreed that a review was warranted, which evidence they used, what they overrode, and whether the workflow produced a clear next step. Also record false alarms, missed cases, stale sources, and time spent validating the packet.

The NIST AI Risk Management Framework calls for intended scope and human oversight to be documented, testing to reflect deployment conditions, and system behavior to be monitored in production. For this workflow, that means review cannot stop when the first score looks good. Definitions, customer behavior, source quality, and the agent itself will change.

A four-week pilot plan

Week 1: define the job

Choose one segment, one owner, one review cadence, and one decision. Write the source map and name the person responsible for each definition.

Week 2: build the evidence packet

Start with three to five signals that the CS team can explain. Set freshness expectations and missing-data behavior. Produce the packet before adding a composite score.

Week 3: test edge cases

Run known stable, risky, ambiguous, restricted, and broken-source cases. Fix problems at the layer that caused them: data, definition, access, trigger, instruction, or review process.

Week 4: run alongside the current review

Do not replace the existing customer-health meeting yet. Compare what the workflow surfaced with what CSMs brought independently. Capture disagreements and turn them into test cases.

At the end of the pilot, expand only if the workflow consistently gives the team a better starting point for account review. A lower-friction investigation is a credible win. A claim that AI now knows which customers will churn is not.

Jovis gives teams a governed workspace for agents that work with approved business sources and shared context. If customer health is your first workflow, begin with one renewal cohort and the evidence packet above. Give the agent enough context to prepare the investigation, and keep the account decision with the customer-success owner.