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)

Example	What makes it a match
B2B subscription product with named account managers	Accounts, renewals, dedicated CS team
Enterprise SaaS with quarterly business reviews	QBR cadence, account-tier engagement
Renewal-risk analysis needed for a contract portfolio	Renewal evidence, churn-risk signals
Product with an assigned customer-success team managing health plans	Success plans, health tracking
Account-expansion opportunity identified but adoption signals are mixed	Expansion with relationship context
Customer feedback loop — insight surfaced, product change made, customer communication needed	Closed-loop Voice of Customer

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.

Example	Why it does not apply
Internal developer tool with no accounts, no renewals, no QBRs	No recurring human relationship; no CS team
Pure transactional e-commerce product — one-time purchases, no account management	No accounts, no renewals, no QBRs, no CS team
Public-service benefit-application portal — no account-tier engagement, no CS team	No accounts (in the CS sense), no renewals, no QBRs
Consumer mobile game with subscription billing but no human CS relationship	Subscription alone is insufficient; no human CS relationship
Open-source project with community support but no paid accounts	No accounts, no renewals, no CS team
Internal analytics dashboard for a single team	No recurring relationship outside the team; no CS team

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:

Handoff	Trigger	Receiving Team	Artifact
Feature request from customer evidence	Validated pattern across ≥3 accounts	Product	Success-plan extract + health evidence
Support escalation	Blocking issue with account impact	Support	Escalation record with account context
Technical defect with account risk	Reproducible bug affecting ≥1 account	Engineering	Defect record + account-impact assessment
Churn risk requiring lifecycle action	Sustained health decline, 2+ remediation attempts failed	Product-lifecycle-learning	Health/risk record + remediation history

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)

Skill	What it owns	How this skill consumes it
../product-analytics-and-measurement/SKILL.md	Metric trees, tracking plans, instrumentation QA, measurement governance	Provides health evidence and metric definitions for health/risk records
../product-adoption/SKILL.md	Onboarding, activation, behavior change, feature discovery, sustained use	Provides adoption signals (activation, feature adoption, sustained use) as health dimensions
../product-experimentation/SKILL.md	Experiment design, readout, ship/no-ship decisions	Consumed when CS evidence suggests an experiment (e.g., intervention test for at-risk accounts)
../go-to-market/SKILL.md	Acquisition campaigns, marketing conversion	Does NOT own. CS consumes acquisition context only.
../crm/SKILL.md	HubSpot CRM operations — contact records, deal pipeline views, confirmed deal stage changes	Provides account records and pipeline/health context for health/risk records and QBR preparation

Routes to (prose references — skills not yet landed)

Skill	What it owns	How this skill routes to it
product-lifecycle-learning	Retirement communication plans, customer treatment during sunset, migration-support coordination, churn-pattern learning across the portfolio	Escalates sustained health decline (2+ remediation attempts failed) for lifecycle action. Routes churn and sunset signals for portfolio-level learning.

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

File	Purpose	Load when
references/discovery-brief.md	Maps existing related content, ownership boundaries, and routing decisions	First load — required context
references/privacy-and-human-judgment.md	Full privacy and human-judgment boundaries, surveillance-risk guidance, consent framework	Privacy or judgment question arises
templates/applicability-decision.md	Structured applicability assessment — decline or proceed with evidence	Customer-success method considered for any product
templates/success-plan.md	Customer success plan with desired outcomes, milestones, evidence gates	Building or reviewing a success plan
templates/health-risk-record.md	Evidence-based health/risk record with signal, source, trend, confidence, and conflicting-signal tracking	Health review, QBR prep, renewal-risk analysis
templates/escalation-and-feedback-closure.md	Escalation path definition and closed-loop feedback closure record	Escalation design or feedback-loop operation

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:

Model	QBR Trigger
Transactional	Purchase-milestone threshold, account-tier change, or 6-month dormancy
Public Service	Service-review cycle, equity-gap detection, or accessibility-audit result
Internal Product	Internal service-review cycle, team-reorg, or adoption decline

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.