conditional-customer-success

Conditional Customer Success

A CONDITIONAL skill for products with recurring human relationships. This skill must never be loaded for every product context. It loads only when the product has accounts, renewals, QBRs, or a dedicated customer-success team. When those conditions are absent — for internal tools, pure transactional products, or public services without account-based engagement — this skill declines and routes the caller away.

When to Load (Should-Trigger Examples)

When not to use

This skill must not be loaded for products without accounts, renewals, QBRs, or a customer-success team. See the should-not-trigger examples below.

When NOT to Load (Should-Not-Trigger Examples)

This skill must not load when the product context lacks the required preconditions. The skill must decline and route the caller away.

Decline rule: If none of the should-trigger conditions are present — that is, the product has no accounts, no renewals, no QBRs, and no customer-success team — this skill must decline with an applicability assessment that records which preconditions were absent and routes the caller to the nearest appropriate skill (product-analytics-and-measurement, product-adoption, or product-lifecycle-learning).

Product/Relationship Models

This skill defines when customer-success practice applies and what adaptations are needed for four distinct models. None assumes SaaS.

1. B2B Subscription

Applies fully. Accounts, renewals, QBRs, expansion tiers, and a dedicated customer-success team are the canonical fit. All artifacts apply: success plans, health/risk records, escalation paths, handoff protocols, and closed-loop feedback.

2. Transactional (Non-Subscription)

Partial application — adapted. The product may have repeat customers and account relationships without formal subscriptions. CS adaptations:

• Success plans focus on repeat-purchase patterns and re-order outcomes, not subscription renewal dates.
• Health evidence uses purchase frequency, order-value trends, and account engagement signals — not MRR or churn metrics.
• QBRs become periodic business reviews triggered by purchase milestones or account tier, not calendar dates.
• Escalation triggers on declining purchase frequency or account dormancy.

3. Public Service

Minimal application — routing preferred. Public-service products often have citizens or beneficiaries, not "accounts." CS applies only when there is explicit account-based engagement (e.g., a case-management portal).

• Success plans become service-outcome plans, not commercial plans.
• Health evidence uses service-access equity, completion-rate gaps across cohorts, and accessibility barriers — never commercial metrics.
• Escalation routes to program governance, not commercial leadership.
• Privacy boundaries are stricter: citizen data must not be repurposed. See references/privacy-and-human-judgment.md.

When no account-based engagement exists, decline and route to product-adoption (for service-adoption diagnostics) and product-analytics-and-measurement (for service-outcome measurement).

4. Internal Product

Conditional — strong routing preference. Internal products may have "internal customers" (other teams, business units), but CS applies only when there is a recurring human relationship with structured engagement.

• Success plans become internal service-level agreements, not commercial plans.
• Health evidence uses internal adoption, workflow-completion, and time-saved metrics — never revenue or MRR.
• QBRs become internal service reviews, structured around team outcomes.
• Escalation routes to internal governance, not commercial leadership.

When the internal product has no recurring human relationship (e.g., a single-team analytics dashboard), decline and route to product-adoption or product-lifecycle-learning.

Core Artifacts

Every artifact is a decision-support tool, never an automated decision.

1. Applicability Decision

Before applying any customer-success method, produce an applicability assessment. If the product context lacks accounts, renewals, QBRs, or a CS team, decline and route the caller away. Record which preconditions were absent.

Template: templates/applicability-decision.md

2. Success Plan

A structured record of the customer's desired outcomes, aligned product capabilities, measurable milestones, and assigned relationship owner. Not a sales plan; not a support ticket; not a project plan. The success plan is the living artifact that connects customer intent to product evidence.

Template: templates/success-plan.md

3. Health / Risk Record

An evidence-based record — never an automated score. For each health dimension, capture:

• The signal (observable evidence, not a proxy metric).
• The source (analytics, adoption, direct observation).
• The trend (direction and recency).
• The confidence (how reliable the evidence is).
• Conflicting signals (surface disagreement, not a forced consensus).

Template: templates/health-risk-record.md

4. Escalation Path

A defined path from signal to decision-maker, with explicit human-judgment gates. Every escalation requires a human decision before action. The path defines:

• The trigger signal and its threshold.
• The escalation owner (named role, not a system).
• The review cadence.
• The decision options (and who makes each).
• The fallback if no decision is reached.

Template: templates/escalation-and-feedback-closure.md

5. Handoff Protocols

Defined handoffs to product, support, and engineering teams with clear ownership boundaries:

6. Closed-Loop Feedback Closure

The path from customer insight to product change to customer communication:

Customer Insight → Validate (pattern? isolated?) →
  Product Decision (build / defer / decline) →
    Implementation → Communication Back to Customer →
      Close Loop (record evidence)

Every step is recorded. "Communication Back to Customer" is mandatory — closing the loop means the customer knows what happened with their feedback. See templates/escalation-and-feedback-closure.md.

Privacy and Human Judgment Boundaries

These boundaries are non-negotiable.

Customer Feedback Must Not Become Surveillance

• Feedback is collected with consent and a stated purpose.
• Usage is limited to the stated purpose.
• Aggregation is permitted for pattern detection; individual-level behavior tracking beyond the stated purpose is not.
• Customer data shared across teams is scoped to the minimum necessary.

Health Scores Are Decision-Support, Not Automated Decisions

• A health signal is evidence; it never becomes an automated action (no auto-churn, no auto-escalation without human review).
• Conflicting signals must be surfaced, not averaged into a single score.
• The health/risk record includes confidence and provenance for every signal.

Human Judgment Is Required for Escalation Decisions

• Every escalation trigger requires a human decision before any action.
• The escalation path defines who decides, on what evidence, with what options.
• A "no decision" state has a defined fallback — escalate further, not auto-act.

Privacy Boundaries Around Customer Data

• Customer-identifiable data is never embedded in templates shared outside the CS team.
• Health evidence uses anonymized or aggregated signals when shared across teams.
• Data retention and access are governed by the product's privacy policy, not the CS practice.

See references/privacy-and-human-judgment.md for the full boundaries reference.

Routing and Related Skills

This skill routes to specialist skills rather than re-deriving their methodology. All routing references use relative paths to existing directories, or prose references for skills not yet landed.

Routes to (existing skills)

Routes to (prose references — skills not yet landed)

Does NOT own

• Statistical inference or experiment design — belongs to data-scientist and product-experimentation.
• Product-analytics instrumentation — belongs to product-analytics-and-measurement.
• Acquisition, marketing conversion, or campaign design — belongs to go-to-market.
• Product roadmapping or portfolio prioritization — belongs to product-roadmapping-and-portfolio.
• Customer support operations or ticket management — belongs to support-tooling skills.
• Contract negotiation, pricing, or legal terms — belongs to go-to-market and legal-strategy skills.

File Map

QBR and Engagement Cadence

Quarterly Business Review (QBR) Structure

A QBR is an evidence review, not a sales presentation. The structure:

1. Success-plan review — progress against desired outcomes, milestone achievement.
2. Health evidence — each dimension, its signal, trend, and confidence. Conflicting signals presented, not averaged.
3. Adoption evidence — feature adoption, activation trends, sustained-use patterns (from product-adoption evidence).
4. Risk review — open risks, mitigation status, escalation history.
5. Forward plan — next-period success-plan adjustments, expansion opportunities (routed to go-to-market for commercial motion), and risk-mitigation actions.
6. Feedback loop status — open feedback items, product decisions made, communication-back status.

Triggering QBRs Outside B2B Subscription

For non-subscription models, QBRs are triggered by events, not calendar dates:

Output Contract

1. An applicability decision recorded before any CS method is applied.
2. A success plan with desired outcomes, milestones, evidence gates, and a named relationship owner.
3. A health/risk record with evidence per dimension, not a score.
4. An escalation path with explicit human-judgment gates.
5. A closed-loop record tracing customer insight → product decision → customer communication.
6. Handoff records to product, support, or engineering with account context and evidence.