|
|
| (One intermediate revision by the same user not shown) |
| Line 1: |
Line 1: |
| Part of [[The Playbook]]. Before you can run a play, you need to know something's wrong. Observability is the monitoring layer of Customer Success: a customer health score that tells you the state of an account before the customer has to tell you themselves.
| | #REDIRECT [[Adopt]] |
| | |
| ==What actually goes into a health score==
| |
| | |
| A health score that only measures sentiment is a lagging indicator dressed up as a dashboard. The useful ones combine:
| |
| | |
| * '''Product usage and adoption depth''' — not just "did they log in," but which features, how deep, and whether usage is trending up or down. This is the highest-weight signal, because usage drops before satisfaction scores do.
| |
| * '''Support signal''' — ticket volume and severity trend, not a raw count. A spike after a quiet stretch matters more than a steady baseline.
| |
| * '''Relationship and engagement''' — meeting attendance, response latency, whether the champion is still the champion or quietly changed jobs.
| |
| * '''Commercial signal''' — contract terms, upcoming renewal date, prior expansion or contraction history.
| |
| * '''CSM/TAM pulse''' — the qualitative gut-check from the human who actually talks to the account. Don't let the model override this; let it flag disagreement instead.
| |
| | |
| ==Leading vs. lagging==
| |
| | |
| Leading indicators (usage decline, feature abandonment, unanswered emails) predict a problem before it's visible. Lagging indicators (a formal complaint, a support escalation, a churn notice) confirm a problem that's already arrived. A health score built entirely on lagging indicators is just a churn report with extra steps — weight leading indicators higher, and treat lagging indicators as confirmation, not discovery.
| |
| | |
| ==Score bands and what they trigger==
| |
| | |
| A workable default, tuned per business:
| |
| | |
| {| class="wikitable"
| |
| ! Band !! Meaning !! Action
| |
| |-
| |
| | 0–40 || Critical || [[Incident Response for At-Risk Accounts|Declare an incident]]
| |
| |-
| |
| | 41–60 || At-risk || Run the matching [[The Play Library|play]], proactively
| |
| |-
| |
| | 61–80 || Healthy || Standard cadence, no special action
| |
| |-
| |
| | 81–100 || Thriving || Flag for expansion, hand to the growth motion
| |
| |}
| |
| | |
| ==What breaks health scores==
| |
| | |
| * '''Overcomplication.''' A score with 40 weighted inputs is a score nobody trusts and nobody can explain to a customer's exec sponsor. Fewer inputs, clearly defensible, beats a black box every time.
| |
| * '''Static snapshots.''' A single number hides the story. Track the trend — an account moving from 90 to 65 over three weeks is a different problem than one sitting at 65 for a year.
| |
| * '''Mistaking activity for engagement.''' Logins aren't adoption. A user opening the product every day to check one report they could get from an email digest is not a healthy account, even though the login graph looks great.
| |
| | |
| ==Where this feeds==
| |
| | |
| The score sets the trigger for [[The Play Library]] and defines the target in [[SLOs for Customer Outcomes]]. When a score crosses into critical, it's the input to [[Incident Response for At-Risk Accounts]].
| |
| | |
| [[Category:Customer Success Manager]]
| |
| [[Category:Customer Engineering]]
| |
