A score can make an account look easy to understand. The difficult work starts when an owner asks why it changed and what the customer needs. Build the model so your team can answer those questions, including when the information is incomplete.
Start with the customer outcome
A customer can be active in your product and still be missing the outcome they bought it for. Before choosing a score, write down what success looks like for each customer segment: the use case, the people involved, and the milestones that indicate value. New customers and established customers may need different signals.
Choose signals you can explain
Consider product usage, progress toward agreed outcomes, engagement, support issues, and customer feedback. Distinguish a drop in logins from a drop in a workflow that matters. Treat missing data as unknown rather than silently interpreting it as good health. Start with a few reliable signals before adding complexity.
Make the reasoning visible
For each signal, define its source, review window, expected behavior, and owner. If you use weights or thresholds, record why they fit that segment. Show the contributing signals alongside the combined score so an account owner can understand a change and challenge an interpretation.
Turn a change into a review
An alert needs a useful next step. The owner should check whether the change is real, review recent conversations and open issues, and agree a response with the customer when appropriate. A score alone should not automatically trigger a commercial conversation or an escalation.
Validate and revise
Compare earlier scores with later customer outcomes, including healthy-looking accounts that churned and low-scoring accounts that renewed. Look for stale inputs and segment differences. Review the model with the team on a regular cadence rather than treating the first version as a finished truth.
Set up a signal definition your team can inspect
Write a short definition for each input before combining the inputs into a score. Include the business question, source, account identifier, observation window, expected behaviour, owner, and known limitations. For adoption, the question might be whether the customer completed its agreed reporting workflow this month. That is more precise than using every login as evidence of value.
Choose the review window to fit the use case. If the workflow is monthly, a quiet week may not deserve attention. If the customer is onboarding, the useful measure may be progress toward a first-value milestone rather than established usage. Segment and lifecycle context should explain why a signal matters, not become an afterthought when the team disagrees with a score.
Work through a mixed-signal account
Consider a customer with regular logins, fewer completed reports, and an unresolved export issue. The sponsor has not raised a renewal concern. A single combined status could hide the relationship between those facts. Review the report workflow, identify whether the export issue prevents completion, and confirm whether the report remains important to the customer.
The proposed intervention should follow that investigation. If the issue blocks the report, coordinate a resolution owner and a customer update. If the team has changed its reporting process, revisit the adoption expectation. If the data is incomplete, fix the visibility problem before treating the apparent decline as a customer behaviour change.
Record the observation, the working interpretation, the evidence still needed, and the next review date. Keep the account owner responsible for the judgement. This makes the model useful even when the score itself is imperfect, because the team can understand the account and decide what to do.
Review the model using exceptions
At a regular review, choose accounts whose apparent health did not match the later customer decision. Include accounts that looked healthy before leaving and accounts with weak signals that renewed. Ask what the team knew at the time, which data was missing, and whether the expected behaviour fit the customer’s use case.
Do not adjust weights solely to make historical results look tidy. A model can appear convincing after the event and still be difficult to use in current accounts. Keep a simple change log and test whether the revised definitions improve the team’s explanations and interventions. The aim is practical account understanding, not a score that appears certain in every situation.
A worked example: review the cause before the score
Consider an account with a renewal in 45 days, declining use of a key workflow, and two unresolved support issues. The useful next step is to check whether those issues are preventing the customer from reaching an agreed outcome. A lower score alone does not tell you the cause.
| Signal | Question to validate | Possible next step |
|---|---|---|
| Key workflow usage falls | Is the workflow still important to this customer? | Confirm the use case and affected users. |
| Support issues remain open | Are they blocking the agreed outcome? | Align the account owner and support team. |
| Renewal is approaching | What needs to be resolved before the decision? | Agree a plan, owner, and review date. |
This is a framework for reviewing the account, not the atEaseAI scoring formula or a prediction of the customer’s decision.
Put it into practice
- Define success by customer segment and lifecycle stage.
- Document each signal, source, review window, and owner.
- Separate missing data from positive evidence.
- Give an owner responsibility for reviewing changes.
- Compare the score with actual outcomes and revise.
PUT THE IDEA TO WORK
Account Health in atEaseAI
Review the signals behind account health and decide where to focus.