Health Scoring
Part of Customer success programme improvement
Identifying product issues behind repeated success interventions
Investigate repeated customer success help across accounts, separate product friction from other causes and give product a checkable problem.
Repeated help at the same step warrants checking whether the product route contributes to the difficulty. Gather comparable cases, confirm the customer's task, then trace what happened before classifying the pattern. Repetition signals a possible issue; it does not prove a defect.
Build a case set around one task
Pick a narrow workflow. For every intervention, log the affected role, customer configuration, attempted task, point of difficulty, workaround, support reference and outcome. Count distinct affected customers alongside contacts: many calls from one account and one call from each of many accounts indicate different reach.
Where records exist, include cases that reached the same step unaided. Compare permissions, setup choices and customer processes. Flag missing evidence instead of treating an incomplete note as a product failure.
Key Metrics for Tracking Intervention Patterns
- Distinct Affected Customers
- Count unique accounts experiencing the issue
- Support Contacts per Account
- High calls from one account vs. low calls across many
- Workaround Usage Rate
- Percentage of customers using a workaround instead of standard path
Classify the obstacle provisionally
- Suspected fault:
- observed behaviour differs from the intended behaviour; reproduction may still be incomplete.
- Product design:
- the step works as built but makes the intended task difficult.
- Guidance or discovery:
- users cannot find or understand the route.
- Configuration or entitlement:
- a setting, permission or available capability affects the route.
- Customer process:
- a decision outside the product remains unresolved.
More than one category may apply. Ask support or a technical owner to assess suspected behaviour; ask the product owner about design or capability questions. Check with the customer whether a proposed route meets its work. A success manager should not promise a fix from notes alone.
Types of Obstacles in Product Usage
- Suspected Fault
- Observed behaviour differs from intended; may not be fully reproducible
- Product Design
- Step works as built but makes task difficult
- Guidance or Discovery
- Users can’t find or understand the correct route
- Configuration or Entitlement
- Settings, permissions or capabilities affect access or flow
- Customer Process
- Decision outside the product remains unresolved
Trace the task across evidence
Start with a recent attempt the customer can describe: what they were trying to complete, what they saw, and how the work finished. Compare their account with support records and product events.
Check event definitions, role and account mapping, and whether an eligible task arose. An absent completion event could mean the work failed, happened elsewhere or was not recorded.
Suppose several customers in a hypothetical approvals workflow need a success call at the same decision step. Check whether they face the same screen, permission state and task.
A difficulty limited to one configuration may call for a targeted correction; friction across configurations may warrant a broader design review. Call counts alone settle neither question.
Give product a decision-ready problem
Summarise the task, observed friction, affected configurations, distinct customers, customer impact, examples and current workaround. Separate confirmed facts from suspected causes. Ask the product owner who will investigate and whether the next decision concerns a fault, design, documentation or an unsupported use case.
Keep account-level help running while the wider issue is assessed. Tell customers what is known, who owns the next step and when they will hear more. Do not turn an investigation into an unapproved delivery promise.
After a change, check the next eligible tasks. Fewer calls may suggest the obstacle eased, but also check whether customers completed the workflow without a hidden workaround. Close the wider issue against the task it was meant to improve.
