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.