Epismo
Alias
View only

Diagnose and Recover Customer Health

Use when a CSM or account owner sees falling adoption, weakening sponsor engagement, unresolved support issues or other retention risks and must diagnose the cause and secure an evidence-based recovery plan. Ends after recovery actions are agreed and an initial response is verified, not after a generic health score alone. Do not use for an active production incident or a routine healthy-account QBR.

Don't just read it. Run it.

Start the work here, keep the important context together, and hand it off to people or AI.

Use playbook

Starting inputs

observationWindow

Optional timeframe for trend comparisons; e.g. last 90 days.

string

account *

Customer account identifier.

string

riskSignal *

The concrete health concern or observed change.

string

evidenceSources

Optional CRM, product-usage, support, email, meeting and success-plan references.

array

Steps

  1. 1

    Assemble a defensible health picture

    Collect the approved success plan, product adoption or utilization, support history, relationship activity, stakeholder changes and upcoming commercial dates if available. Prefer trend versus prior period to a single snapshot. If customer-health skill is accessible, use it for signal collection and its dimension analysis; otherwise calculate from supplied sources. Explicitly mark missing usage, sentiment, and support dimensions as not visible. Record source, observation date, and contradictory evidence. Gate: the risk assessment is based on observed signals, not invented sentiment or opaque scoring.

    V2 practical protocol:
    Use five diagnostic dimensions: Adoption (eligible active users, repeat usage and depth), Value (verified outcome against customer goal), Relationship (champion/sponsor engagement and decision-maker access), Support (severity, recurrence and unresolved blockers), Commercial (renewal timing, procurement and budget signals). For each, record dated signal, defined baseline, deviation, evidence source, confidence High/Medium/Low and potential business consequence. Missing evidence is Unknown, not green or zero. Avoid a universal weighted score unless the customer's segment and data validity justify it; give a reasoned risk tier instead.

    Skills anthropics/knowledge-work-plugins sales/skills/customer-health github
  2. 2

    Identify the causal failure, not merely its symptoms

    Form 2-4 plausible root-cause hypotheses: missing initial value, workflow friction, broken integration, absent champion, executive priority shift, capability gaps, or delivery failures. Test each against data, case history and feedback; separate correlated signals from causes. Highlight what can and cannot be solved by customer success. Prioritize a small set of questions for the customer and technical owner. Gate: major interventions target a supported cause or a falsifiable hypothesis.

    V2 practical protocol:
    Apply a root-cause decision tree: low activation or shallow usage may signal onboarding/UX/fit; falling engagement may signal sponsor change or low realized value; recurring tickets may signal reliability or inadequate workflow fit; procurement pushback may be economics, budget or failed outcome. For each of the top 2–3 hypotheses, write predicted observable signals and one discriminating test (customer question, cohort cut, incident history, or task observation). Distinguish cause from correlation, especially between low utilization and churn risk. Output table: hypothesis, for/against evidence, missing test, affected outcome, confidence.

  3. 3

    Validate the situation with customer stakeholders

    Prepare a candid, non-defensive outreach or review agenda acknowledging known issues without guessing motives. Seek the perspective of the actual users and sponsor rather than only the primary contact. Establish which business outcome still matters, what failed, the recovery threshold and the customer's willingness to participate. Capture promises and disagreements accurately. Do not present internal speculation as customer sentiment. Gate: proposed recovery goals are anchored to customer-confirmed priorities or explicitly labeled pending.

    V2 practical protocol:
    Customer validation guide: ask which outcome is currently most important, where the workflow fails in actual work, whether the sponsor agrees, which issues are unacceptable, and what minimum change would make continuation worthwhile. Test stated dissatisfaction against examples and avoid leading or defensive questions. Capture customer quotes only from real notes and identify the customer role. Convert any conflicting perceptions into specific evidence requests; never publish internal probability-of-churn speculation as a customer's own statement. The gate should be based on confirmed or explicitly pending recovery criteria.

  4. 4

    Negotiate a bounded recovery intervention

    Choose interventions with named owner, due date, measurable leading signal, dependencies and a stop/escalate threshold. Examples: fix a blocking issue, retrain a segment, restore executive sponsorship, simplify the workflow or reset the value plan. Avoid offering unapproved discounts, product commitments or delivery dates. Sequence the fastest high-confidence corrective action first. Gate: the plan fits available authority and has a testable signal of improvement.

    V2 practical protocol:
    Choose interventions by cause, not playbook habit. Onboarding deficit: observed task coaching and a first-value target. Workflow friction: reduce steps or add an approved workaround. Technical blocker: triage with FDE/support, define verification. Sponsor loss: restore a named decision-maker relationship with actual value evidence. Poor economics: validate ROI and options with the commercial owner, not an unauthorized discount. Each intervention needs hypothesis, leading indicator, baseline, improvement threshold, observation window, named role and stop/escalate condition. Limit simultaneous changes when attribution matters.

  5. 5

    Check the initial response and decide what changed

    At the agreed checkpoint, compare new observations to the original baseline, not to an arbitrary green status. Distinguish actions completed from customer behavior improved. Classify risk as improving, unchanged or deteriorating, state remaining uncertainty, and recommend continuing, revising or escalating the intervention. Update shared systems only with permission. Gate: the owner can credibly explain whether the chosen intervention worked and what evidence warrants the verdict.

    V2 practical protocol:
    Recovery check: compare post-intervention signal with same-metric baseline and relevant time window. Distinguish effort completed (training run, ticket closed) from outcome changed (repeat workflow completion, fewer blocking incidents, sponsor renewal of support). Classify improving/flat/worsening with confidence and potential external confounders; do not declare health restored on one favorable anecdote. If material evidence is missing, output "insufficient to assess" with a small measurement plan. State whether to continue, modify or escalate the intervention, without forcing a separate handoff stage.

Used in public cases

Published work that started from this playbook.

Used in public cases →