{
  "schema_version": 1,
  "skill_name": "conditional-customer-success",
  "evals": [
    {
      "id": "b2b-subscription-success-plan-and-health",
      "prompt": "I manage customer success for a B2B SaaS platform with 200 accounts, named account managers, quarterly business reviews, and annual contract renewals. We need a success plan and health assessment for our largest account (Acme Corp, 500 seats, $1.2M ARR). Their activation rate is 78% (down from 85% last quarter), feature adoption breadth is 3 of 12 capabilities, support-ticket volume is up 40%, and their executive sponsor just changed. Build the success plan and health record.",
      "expected_output": "A success plan with desired outcomes, product-capability alignment, measurable milestones, and a named relationship owner. A health/risk record covering adoption health (activation decline, low feature breadth), engagement health (support-ticket surge), value-realization health (outcome alignment), and relationship health (executive-sponsor change). Each dimension has signals with source, trend, and confidence. Conflicting signals (if any) are surfaced rather than averaged. The record includes a risk register for the sponsor change. The escalation path defines who decides and on what evidence. No automated health score (no red/yellow/green without evidence).",
      "assertions": [
        "The success plan names desired outcomes, product-capability alignment, milestones, and a relationship owner",
        "The health record covers adoption, engagement, value-realization, and relationship dimensions with evidence per signal",
        "The activation-rate decline (78%, down from 85%) is recorded as a health signal with trend direction, not a score",
        "The executive-sponsor change is recorded as a relationship-health risk with mitigation, not ignored",
        "Conflicting signals, if any, are surfaced explicitly rather than averaged into a single indicator",
        "The response includes an escalation path with a named decision-maker and decision options",
        "No automated health score is produced without accompanying evidence and confidence"
      ]
    },
    {
      "id": "internal-tool-customer-success-decline",
      "prompt": "Our team built an internal developer tool for the engineering org — it's a CI/CD dashboard that 80 engineers use. There are no accounts, no renewals, no QBRs, and no customer-success team. The infra lead wants to apply 'customer success' practices to improve dashboard adoption. Should we load the customer-success skill?",
      "expected_output": "An applicability assessment that DECLINES to apply customer-success practice. The assessment records that no preconditions are present: no accounts (it's a shared internal tool), no renewals, no QBRs, no customer-success team. It routes the caller to product-adoption (for dashboard adoption diagnostics — activation, workflow fit, behavior change) and product-analytics-and-measurement (for instrumentation of dashboard usage metrics). It does NOT apply success plans, health scores, QBR structure, or escalation paths. The response explicitly states why customer-success is the wrong framework for this context.",
      "assertions": [
        "The response DECLINES to apply customer-success practice and records which preconditions are absent",
        "The response states that no accounts, no renewals, no QBRs, and no CS team are present",
        "The response routes to product-adoption for adoption diagnostics (not CS method)",
        "The response routes to product-analytics-and-measurement for usage instrumentation",
        "The response does NOT produce a success plan, health score, QBR structure, or escalation path",
        "The response explains why customer-success is the wrong framework for an internal shared tool"
      ]
    },
    {
      "id": "public-service-accessibility-cs-routing",
      "prompt": "We run a public-service portal for unemployment benefit applications. We have citizens applying, not 'customers' with accounts. There are no renewals, no QBRs, and no customer-success team. The program director wants to track 'citizen success' and asked us to load the customer-success skill. How should we respond?",
      "expected_output": "An applicability assessment for a public-service context. The assessment notes that while public-service products can have service-outcome tracking, the standard customer-success framework (success plans, QBRs, account health) does not fit a context with no accounts, no renewals, no QBRs, and no CS team. If there is no account-based engagement, the skill should DECLINE. If there is case-management with account-like engagement, the skill may apply minimally with adaptations: service-outcome plans (not commercial success plans), equity-gap metrics as health evidence (not revenue or MRR), and program-governance escalation (not commercial escalation). The response must state the privacy boundaries (citizen data is not customer data) and route primary responsibility to product-adoption (for service-adoption diagnostics) and product-analytics-and-measurement (for outcome measurement).",
      "assertions": [
        "The response produces an applicability assessment that addresses the public-service context",
        "The response identifies the absence of accounts, renewals, QBRs, and a CS team as preconditions",
        "The response states the privacy boundary: citizen data is not customer data and must not be treated as such",
        "The response routes to product-adoption and product-analytics-and-measurement as primary owners",
        "The response does NOT apply commercial success-plan or QBR frameworks without adaptation",
        "If minimal CS application is possible (case-management context), adaptations are defined explicitly"
      ]
    },
    {
      "id": "renewal-risk-with-mixed-signals",
      "prompt": "We have an enterprise account up for renewal in 60 days. The account shows: product usage (daily active users) is up 22% quarter-over-quarter, feature adoption expanded from 2 to 5 capabilities, and the success-plan milestones are 80% achieved. However, support-ticket sentiment is sharply negative (3 unresolved critical bugs), the executive sponsor has gone silent (no response to last 3 outreach attempts), and a competitor's sales team has been meeting with their procurement department. The CS team wants a health assessment and renewal-risk recommendation.",
      "expected_output": "A health/risk record that surfaces conflicting signals explicitly: product adoption is strong (DAU up 22%, feature breadth expanding, milestones on track) BUT engagement and relationship health are at-risk (critical bugs unresolved, sponsor silent, competitor active). The record does NOT produce a single score or confident verdict. Instead, it surfaces the conflict: adoption says 'healthy,' relationship says 'at-risk,' and the renewal context makes the relationship signal the binding constraint. The response defines an escalation path with evidence package, a named decision-maker, decision options (remediation sprint before renewal, executive-to-executive outreach, competitor-response plan), and a fallback if no decision is made. The health record includes confidence assessments per signal and proposes an investigation path for the silent sponsor (reach adjacent contacts, check for organizational change). It explicitly recommends human judgment over automated renewal scoring.",
      "assertions": [
        "The response surfaces conflicting signals explicitly: strong adoption vs. at-risk relationship",
        "The response does NOT produce a single confident score or automated renewal recommendation",
        "The response identifies the renewal context as making the relationship signal the binding constraint",
        "The response includes an escalation path with a named decision-maker and at least two decision options",
        "The response proposes an investigation path for the silent sponsor rather than assuming the worst",
        "The response explicitly requires human judgment for the renewal decision",
        "The health record includes confidence assessments and provenance for each signal"
      ]
    },
    {
      "id": "conflicting-health-evidence-decision-path",
      "prompt": "A mid-market account shows: NPS of 72 (promoter), feature adoption at 91% of licensed capabilities, weekly active users above target for 6 consecutive months, and the account executive reports the relationship is 'great.' However, the product-analytics data shows time-to-complete-core-workflow has increased 340% over 90 days (from 4 minutes to 17.6 minutes), error-rate-per-session is up 5x, and the account has opened 14 support tickets in 30 days (up from 2/month baseline). The renewal is in 90 days. The CEO wants a 'health score.' Provide the health assessment.",
      "expected_output": "A health assessment that REFUSES to produce a single health score. Instead, it presents the conflicting evidence across two clusters: Cluster A (healthy) — NPS 72, 91% feature adoption, WAUs above target, AE reports strong relationship. Cluster B (at-risk) — workflow time up 340%, error rate up 5x, support tickets up 7x. The assessment explains the conflict: the customer likes the product (NPS) and uses it (WAUs), but the product experience is degrading in ways that NPS hasn't yet reflected (lagging indicator). The response defines a decision path: (1) investigate the root cause of workflow degradation and error-rate increase — is this a product regression, a scale issue, or a configuration problem? (2) set a 30-day review to check if NPS responds to the degradation (NPS is a lagging indicator and may drop later). (3) escalation to product/engineering for the technical degradation, separate from the CS renewal track. The response explicitly states why a single health score would be misleading and why conflicting evidence must drive investigation, not aggregation. Claims are scoped to the harness, model, fixtures, and revision under test.",
      "assertions": [
        "The response REFUSES to produce a single health score and explains why it would be misleading",
        "The response presents conflicting evidence as two explicit clusters, not an average",
        "The response identifies that NPS is a lagging indicator that may not yet reflect the product degradation",
        "The response defines a decision path with investigation steps, a review cadence, and escalation triggers",
        "The response routes technical degradation to product/engineering separately from the CS renewal track",
        "The response sets a specific review date to re-examine the conflict, not a 'monitor and wait' vague directive",
        "The response explains that conflicting evidence must drive investigation rather than aggregation"
      ]
    }
  ]
}

# Discovery Brief — Conditional Customer Success

**Date**: 2026-08-02
**Scope**: Issue #192 — `feat: add conditional customer-success skill`

## Survey of Existing Content

### What already exists in the catalog

| Existing Skill / Area | Relevant Content | Ownership Boundary |
|---|---|---|
| `go-to-market` | Account planning, customer segmentation, expansion strategy, pricing and packaging | Owns commercial motion (acquisition, conversion, pricing, account-tier design). CS consumes account-tier context; does not own commercial design. |
| `product-adoption` | Onboarding, activation, behavior change, feature discovery, sustained-use review, cohort segmentation, non-SaaS adoption contexts | Owns adoption-side diagnostics and plans. CS consumes adoption signals as health dimensions; does not own adoption methodology. |
| `product-analytics-and-measurement` | Metric trees, tracking plans, instrumentation QA, measurement governance | Owns metric definitions and instrumentation. CS consumes health metrics and evidence from the analytics layer. |
| `product-experimentation` | Experiment design, readout, ship/no-ship decisions, stopping rules | Owns experiment method. CS may propose experiments (intervention tests for at-risk accounts) but does not own experiment design. |
| `product-strategy` | North Star, product vision, strategic context, portfolio thinking | Owns strategic direction. CS informs strategy with customer evidence; does not set strategy. |
| `product-methodology` | Prioritization frameworks (RICE, etc.), discovery techniques, stakeholder alignment | Owns tactical product method. CS consumes prioritization context; does not own RICE or discovery. |
| `financial-modeling` | Unit economics, CAC, LTV, churn modeling, renewal forecasting | Owns financial model. CS provides account-level evidence (health, risk) that feeds financial models. |
| `data-scientist` | Statistical inference, causal analysis, experiment analysis | Owns statistical method. CS routes complex health-signal analysis here. |
| `product-roadmapping-and-portfolio` | Roadmap construction, portfolio balancing, investment allocation | Owns roadmap. CS feeds customer evidence into roadmap inputs; does not own prioritization. |

### What is missing (the gap)

No dedicated customer-success capability exists in the catalog. The existing
skills cover isolated pieces:

- Onboarding and activation (`product-adoption`) but not ongoing success
  management or account health.
- Renewal modeling (`financial-modeling`) but not the human relationship
  practice (QBRs, success plans, escalation).
- Expansion strategy (`go-to-market`) but not the evidence-based
  account-expansion signal from CS.
- Stakeholder alignment (`product-methodology`) but not the closed-loop
  Voice of Customer process.

No skill currently defines:
1. When customer-success practice applies and when it should not be loaded.
2. Success plans as living artifacts connecting customer intent to product
   evidence.
3. Health/risk records that are evidence-based, not automated scores.
4. QBR structure and cadence.
5. Escalation paths with explicit human-judgment gates.
6. Handoff protocols between CS, product, support, and engineering.
7. Closed-loop feedback closure (customer insight → product change → customer
   communication).
8. Privacy boundaries specific to customer-success data.

## Ownership Boundaries

### What this skill owns

- **Applicability decision**: determining whether CS practice applies to a
  given product context.
- **Success plans**: desired outcomes, product-capability alignment,
  milestones, evidence gates, relationship ownership.
- **Health/risk records**: evidence-based, signal-per-dimension, with
  trend, confidence, and conflicting-signal tracking.
- **QBR structure**: evidence-review cadence and format (not sales
  presentations).
- **Escalation paths**: trigger thresholds, named decision-makers, human-
  judgment gates, fallback rules.
- **Handoff protocols**: structured handoffs to product, support, and
  engineering with account context and evidence.
- **Closed-loop feedback**: insight → validation → product decision →
  implementation → customer communication → closure record.
- **Privacy and human-judgment boundaries**: consent framework,
  surveillance-risk guidance, decision-support rules, escalation-gate
  requirements.

### What this skill does NOT own (routes to specialists)

| Concern | Routed to | Why |
|---|---|---|
| Metric definition, tracking plans, instrumentation | `product-analytics-and-measurement` | Owns measurement infrastructure |
| Adoption diagnostics, onboarding design, activation plans | `product-adoption` | Owns adoption lifecycle |
| Statistical analysis of health signals | `data-scientist` | Owns statistical method |
| Commercial pricing, packaging, contract terms | `go-to-market` | Owns commercial design |
| Financial modeling (CAC, LTV, churn) | `financial-modeling` | Owns financial models |
| Experiment design for CS interventions | `product-experimentation` | Owns experiment method |
| Product roadmap decisions from CS evidence | `product-roadmapping-and-portfolio` | Owns roadmap |
| Retirement communication, sunset coordination | `product-lifecycle-learning` | Owns lifecycle closure |

## Routing Decision Tree

```
Is there a recurring human relationship?
├── YES: Are there accounts, renewals, QBRs, OR a CS team?
│   ├── YES → LOAD conditional-customer-success
│   └── NO  → Route to product-adoption (adoption-side) or product-lifecycle-learning
└── NO  → DECLINE. Route to:
    ├── product-analytics-and-measurement (for health metrics)
    ├── product-adoption (for adoption diagnostics)
    └── product-lifecycle-learning (for churn/retirement patterns)
```

## Product-Model Applicability Matrix

| Model | Accounts? | Renewals? | QBRs? | CS Team? | CS Applies? | Adaptation |
|---|---|---|---|---|---|---|
| B2B Subscription | Yes | Yes | Yes | Yes | Full | Standard artifacts |
| Transactional | Partial | No (repeat purchase) | Event-triggered | Sometimes | Partial | Adapted success plans, purchase-frequency health |
| Public Service | Rare | No | Program-review | Rare | Minimal | Service-outcome plans; stricter privacy; often decline |
| Internal Product | Sometimes | No | Internal-service-review | Sometimes | Conditional | Internal SLA plans; often decline |

## Routing to Skills Not Yet Landed

`product-lifecycle-learning` (prose reference) is the destination for:
- Sustained health decline after 2+ remediation attempts.
- Churn-pattern learning across the portfolio.
- Retirement communication plans and migration-support coordination.

Until it lands, this skill records the routing in prose. The routing becomes
a resolved link when the directory exists.

# Privacy and Human Judgment Boundaries

This reference defines the non-negotiable privacy and human-judgment
boundaries that govern every customer-success artifact and practice. These
boundaries apply regardless of product model, account tier, or CS team
structure.

## 1. Customer Feedback Must Not Become Surveillance

### Consent Framework

- Feedback is collected with explicit consent and a stated purpose.
- Consent is granular: a customer consenting to health-review data sharing
  has not consented to behavior tracking for other purposes.
- Consent is revocable. When revoked, existing aggregate data may be retained
  (cannot be un-aggregated), but new individual-level collection stops.
- Consent records are maintained alongside feedback records.

### Usage Limitation

- Data is used only for the purpose stated at collection.
- Repurposing customer feedback for unrelated product decisions (e.g., using
  support-call sentiment to score adoption without the customer's knowledge)
  is prohibited.
- Aggregate pattern detection is permitted; individual-level behavior tracking
  beyond the stated purpose is not.

### Data Minimization

- Only the data necessary for the stated purpose is collected.
- Customer-identifiable data is never embedded in templates shared outside the
  CS team (handoff records use anonymized or aggregated signals).
- Cross-team sharing is scoped to the minimum necessary for the receiving
  team's purpose.

### Surveillance-Risk Guidance

If a proposed health signal or feedback mechanism could reasonably be
perceived as surveillance by the customer, it must pass three checks before
proceeding:

1. **Consent check**: Has the customer explicitly consented to this specific
   data collection for this specific purpose?
2. **Proportionality check**: Is the data collected proportional to the
   benefit the customer receives?
3. **Alternative check**: Is there a less invasive way to achieve the same
   evidence?

If any check fails, the mechanism must not proceed.

## 2. Health Scores Are Decision-Support, Not Automated Decisions

### Evidence, Not Scores

- Every health dimension records a **signal** (observable evidence), not a
  score.
- Signals include: source, trend direction, recency, and confidence.
- Multiple signals per dimension are expected. Conflicting signals are
  surfaced, not averaged into a single score.

### No Automated Actions

- A health signal never triggers an automated action (no auto-churn, no
  auto-escalation, no auto-renewal, no auto-expansion).
- Every action requires a human decision, informed by the health evidence.
- Automated alerts ("review needed") are permitted; automated decisions
  ("account downgraded") are not.

### Conflicting Signals Must Be Surfaced

- When one signal indicates healthy and another indicates at-risk for the
  same dimension, both are recorded.
- The health record includes a "conflict note" explaining the disagreement
  and proposing a resolution path (e.g., "adoption signals are strong but
  support-ticket volume has doubled — investigate whether growth is causing
  onboarding gaps").
- The resolution path requires a human decision, not an algorithmic
  tiebreaker.

### Confidence and Provenance

- Every signal includes a confidence assessment: high (directly observed,
  recent, multiple sources agree), medium (indirect proxy, moderate recency),
  or low (stale, single source, or proxy with known limitations).
- Every signal includes provenance: where the data came from, when it was
  collected, and who collected it.

## 3. Human Judgment Is Required for Escalation Decisions

### Escalation Gate Requirements

Every escalation path must define:

1. **Trigger signal and threshold**: What evidence triggers the escalation.
2. **Named decision-maker**: A role (not a system) responsible for the
   decision.
3. **Decision options**: What the decision-maker can decide (with minimum
   viable options defined — never a single forced path).
4. **Evidence package**: What evidence accompanies the escalation.
5. **Decision deadline**: When the decision must be made by.
6. **Fallback**: What happens if no decision is made by the deadline (escalate
   further, never auto-act).

### No-Devision Fallback

A "no decision" state has a defined fallback: escalate further to the next
level of authority. The fallback must never be "auto-act" or "do nothing
silently."

### Escalation Records

Every escalation decision is recorded:
- What was escalated, by whom, on what evidence.
- What decision was made, by whom, on what date.
- What action followed.

Escalation records are reviewable by the CS team and, in redacted form, by
the customer.

## 4. Privacy Boundaries Around Customer Data

### Data Classification

Customer data handled by CS practice falls into three tiers:

| Tier | Examples | Sharing Rule |
|---|---|---|
| **Account-identifiable** | Customer name, company, contract terms | CS team only; never in cross-team templates |
| **Anonymized signal** | "Account in healthcare sector, adoption rate 62%, trend declining" | Shareable with product/support/engineering |
| **Aggregate pattern** | "3 of 12 healthcare accounts show declining adoption" | Shareable broadly |

### Cross-Team Sharing Rules

- Product team receives: anonymized or aggregate health evidence,
  feature-request patterns, adoption signals. Never receives: individual
  customer identities, contract details, or commercial terms.
- Support team receives: escalation records with account context necessary
  for resolution. Receives account identity only when required and only for
  the specific support interaction.
- Engineering team receives: defect records with anonymized account-impact
  assessment. Never receives customer identity unless the defect requires
  account-specific reproduction and the customer has consented.

### Data Retention

- Customer-success records follow the product's data-retention policy.
- When a customer relationship ends, health/risk records are archived.
- Archived records are retained for the period defined by the retention
  policy (for pattern analysis) and then deleted.
- Success plans and QBR records are retained for the customer relationship
  duration plus the retention period.

### Access Control

- CS team members have access to the full customer record.
- Cross-team access is granted on a need-to-know basis, scoped to the
  specific purpose and duration.
- Access is logged and auditable.

## 5. Boundary Enforcement

### Pre-Flight Checklist

Before any customer-success artifact is created or shared, verify:

- [ ] Consent: Has the customer consented to this data collection and use?
- [ ] Purpose: Is the data used only for the stated purpose?
- [ ] Minimization: Is only the minimum necessary data collected/shared?
- [ ] Human gate: Does every action require a human decision?
- [ ] No surveillance: Would the customer reasonably perceive this as
  surveillance? If uncertain, apply the three-check test.
- [ ] Privacy tier: Is the data classified at the correct tier for the
  intended recipient?

### Violation Response

If a boundary is violated:

1. Stop the violating practice immediately.
2. Record what happened, what data was affected, and who was impacted.
3. Notify the CS team lead and, if customer data was exposed, the customer.
4. Update the boundary or process to prevent recurrence.
5. Do not resume the practice until the fix is verified.

This is not a punitive framework — it is a recovery framework. The goal is
to restore the boundary, not to assign blame.

# Applicability Decision

> Use this template before applying any customer-success method. If the
> product context lacks the required preconditions, decline and route the
> caller away. Record the decision.

## Product Context

- **Product name**: _[fill]_
- **Product model**: _[B2B Subscription / Transactional / Public Service / Internal Product / Other]_
- **Description**: _[one-sentence summary of the product and its customer relationships]_

## Precondition Assessment

| Precondition | Present? | Evidence |
|---|---|---|
| Accounts (named, managed customer entities) | _[Yes / No / Partial]_ | _[describe]_ |
| Renewals (contract, subscription, or relationship renewal cycle) | _[Yes / No]_ | _[describe]_ |
| QBRs (quarterly or periodic business/service reviews) | _[Yes / No]_ | _[describe]_ |
| Customer-success team (dedicated or shared) | _[Yes / No]_ | _[describe]_ |
| Recurring human relationship (ongoing, not purely transactional) | _[Yes / No]_ | _[describe]_ |

## Decision

### Proceed

**At least one precondition is present** (accounts, renewals, QBRs, or CS
team). Customer-success practice applies. Select the appropriate product-
model adaptation from the four models in SKILL.md.

- **Product model**: _[select: B2B Subscription / Transactional / Public Service / Internal Product]_
- **Adaptation notes**: _[which artifacts apply fully/partially, which adaptations are needed]_

### Decline

**No precondition is present.** Customer-success practice does not apply.
Record the absent preconditions and route the caller.

- **Absent preconditions**: _[list which were absent]_
- **Route to**: _[product-analytics-and-measurement / product-adoption / product-lifecycle-learning / other]_
- **Routing rationale**: _[why this destination is appropriate for the caller's need]_

## Record

- **Assessor**: _[name or role]_
- **Date**: _[date]_
- **Reviewed by**: _[name or role, if applicable]_

# Escalation Path and Closed-Loop Feedback Closure

> Two related records: (A) the escalation path definition — from signal to
> decision-maker, with explicit human-judgment gates — and (B) the closed-loop
> feedback closure record — tracing customer insight through product change
> to customer communication.

---

## A. Escalation Path

### Path Definition

| Field | Value |
|---|---|
| **Escalation path name** | _[e.g., "Account Health Decline — Tier 1"]_ |
| **Trigger signal** | _[what evidence triggers this escalation]_ |
| **Trigger threshold** | _[e.g., "2 consecutive health reviews with declining trend in any dimension"]_ |
| **Escalation owner** | _[named role, not a system]_ |
| **Review cadence** | _[how often the escalation is reviewed]_ |

### Decision Options

The decision-maker must have at least two options. A single forced path is not
permitted.

| Option | Description | When Appropriate |
|---|---|---|
| 1. _[option name]_ | _[description]_ | _[criteria]_ |
| 2. _[option name]_ | _[description]_ | _[criteria]_ |
| 3. _[option name]_ | _[description]_ | _[criteria]_ |

### Evidence Package

What evidence accompanies the escalation to the decision-maker:

- [ ] Health/risk record (current assessment)
- [ ] Trend data (last N reviews)
- [ ] Success-plan status (milestone achievement)
- [ ] Previous escalation history (if any)
- [ ] Recommended action (from CS team, advisory only)

### Decision Record

| Field | Value |
|---|---|
| **Escalation date** | _[date]_ |
| **Decision-maker** | _[name and role]_ |
| **Decision** | _[which option was chosen]_ |
| **Rationale** | _[why this option]_ |
| **Action assigned to** | _[name]_ |
| **Action deadline** | _[date]_ |
| **Follow-up review date** | _[date]_ |

### Fallback (No-Decision Path)

If no decision is made by the deadline:

- **Escalate to**: _[next level of authority — named role]_
- **Never**: auto-act, silently do nothing, or close without a decision.

### Escalation History

| Date | Trigger | Decision | Outcome | Reviewer |
|---|---|---|---|---|
| _[date]_ | _[signal]_ | _[decision]_ | _[outcome]_ | _[name]_ |

---

## B. Closed-Loop Feedback Closure

### The Loop

```
Customer Insight → Validate → Product Decision → Implement → Communicate Back → Close Loop
```

Every step is recorded. "Communicate Back" is mandatory.

### Step 1: Customer Insight

| Field | Value |
|---|---|
| **Source** | _[customer name, QBR, support interaction, survey, etc.]_ |
| **Date received** | _[date]_ |
| **Insight** | _[what the customer said or what was observed]_ |
| **Type** | _[feature request / defect / friction / praise / suggestion]_ |
| **Recorded by** | _[name]_ |

### Step 2: Validation

Is this a pattern or an isolated observation?

| Field | Value |
|---|---|
| **Validation method** | _[e.g., "checked 3 similar accounts; pattern confirmed in 2 of 3"]_ |
| **Finding** | _[pattern confirmed / isolated / needs more data]_ |
| **Evidence** | _[what was checked and what was found]_ |

### Step 3: Product Decision

| Field | Value |
|---|---|
| **Decision** | _[build / defer / decline]_ |
| **Decision-maker** | _[name and role]_ |
| **Rationale** | _[why this decision]_ |
| **If build**: target release | _[release or timeframe]_ |
| **If defer**: revisit date | _[when to reconsider]_ |
| **If decline**: reason communicated | _[why it was declined]_ |

### Step 4: Implementation

_Only if decision is "build."_

| Field | Value |
|---|---|
| **What changed** | _[the product change made]_ |
| **Release date** | _[date]_ |
| **Verified by** | _[name]_ |

### Step 5: Communicate Back to Customer

**Mandatory.** The customer must know what happened with their feedback.

| Field | Value |
|---|---|
| **Communication date** | _[date]_ |
| **Method** | _[email, QBR, call, in-product message, etc.]_ |
| **Message** | _[summary of what was communicated]_ |
| **Customer response** | _[acknowledgment, satisfaction, follow-up needed]_ |

### Step 6: Close Loop

| Field | Value |
|---|---|
| **Closure date** | _[date]_ |
| **Loop status** | _[closed / partially closed (communication sent but response pending) / blocked]_ |
| **Closed by** | _[name]_ |

### Feedback-Loop Summary (for QBR)

| Open Loops | In Progress | Closed (this period) |
|---|---|---|
| _[count]_ | _[count]_ | _[count]_ |

---

## Combined Record Reference

For a single customer engagement that combines escalation and feedback
closure — e.g., an escalation triggered by a customer insight that leads
to a product change — reference both sections. The escalation path (A)
handles the governance of the decision; the feedback closure (B) handles
the traceability of the customer's voice through to communication.

# Health / Risk Record

> An **evidence-based** record — never an automated score. For each health
> dimension, capture the signal, source, trend, confidence, and any
> conflicting signals. Surface disagreement, never average it away.

## Account Context

- **Customer**: _[name or identifier]_
- **Product model**: _[B2B Subscription / Transactional / Public Service / Internal Product]_
- **Review date**: _[date]_
- **Reviewer**: _[name or role]_
- **Previous review date**: _[date]_

## Health Dimensions

### 1. Adoption Health

Evidence from product-adoption signals.

| Signal | Source | Value | Trend | Confidence |
|---|---|---|---|---|
| Activation rate | _[analytics]_ | _[value]_ | _[↑/→/↓]_ | _[high/med/low]_ |
| Feature adoption breadth | _[analytics]_ | _[value]_ | _[↑/→/↓]_ | _[high/med/low]_ |
| Sustained use (weekly active) | _[analytics]_ | _[value]_ | _[↑/→/↓]_ | _[high/med/low]_ |
| Time-to-value | _[analytics]_ | _[value]_ | _[↑/→/↓]_ | _[high/med/low]_ |

**Dimension assessment**: _[healthy / watch / at-risk]_

**Conflicting signals** (if any):

- _[Signal A says healthy, Signal B says at-risk. Explanation: ...]_
- **Resolution path**: _[what to investigate, who decides]_

### 2. Engagement Health

Evidence from direct customer interaction.

| Signal | Source | Value | Trend | Confidence |
|---|---|---|---|---|
| QBR attendance / engagement | _[CS observation]_ | _[value]_ | _[↑/→/↓]_ | _[high/med/low]_ |
| Responsiveness to outreach | _[CS observation]_ | _[value]_ | _[↑/→/↓]_ | _[high/med/low]_ |
| Support-ticket volume | _[support system]_ | _[value]_ | _[↑/→/↓]_ | _[high/med/low]_ |
| Support-ticket sentiment | _[support system]_ | _[value]_ | _[↑/→/↓]_ | _[high/med/low]_ |

**Dimension assessment**: _[healthy / watch / at-risk]_

**Conflicting signals** (if any): _[record here]_

### 3. Value Realization Health

Evidence that the customer is achieving their desired outcomes.

| Signal | Source | Value | Trend | Confidence |
|---|---|---|---|---|
| Success-plan milestone achievement | _[success plan]_ | _[value]_ | _[↑/→/↓]_ | _[high/med/low]_ |
| Outcome metric vs. target | _[analytics]_ | _[value]_ | _[↑/→/↓]_ | _[high/med/low]_ |
| Expansion / deepening signals | _[CS observation]_ | _[value]_ | _[↑/→/↓]_ | _[high/med/low]_ |

**Dimension assessment**: _[healthy / watch / at-risk]_

**Conflicting signals** (if any): _[record here]_

### 4. Relationship Health

Evidence about the human relationship quality.

| Signal | Source | Value | Trend | Confidence |
|---|---|---|---|---|
| Executive sponsor engagement | _[CS observation]_ | _[value]_ | _[↑/→/↓]_ | _[high/med/low]_ |
| Reference / advocacy willingness | _[CS observation]_ | _[value]_ | _[↑/→/↓]_ | _[high/med/low]_ |
| Contract / renewal posture | _[CS observation]_ | _[value]_ | _[↑/→/↓]_ | _[high/med/low]_ |
| Unresolved escalations | _[escalation record]_ | _[value]_ | _[↑/→/↓]_ | _[high/med/low]_ |

**Dimension assessment**: _[healthy / watch / at-risk]_

**Conflicting signals** (if any): _[record here]_

### 5. Risk Assessment (Non-Health)

External or structural risks that are not health-dimension signals.

| Risk | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|
| _[e.g., customer org restructure]_ | _[high/med/low]_ | _[high/med/low]_ | _[mitigation]_ | _[name]_ |
| _[risk]_ | _[likelihood]_ | _[impact]_ | _[mitigation]_ | _[owner]_ |

## Overall Health Summary

This is a narrative synthesis, not a score.

- **Strongest dimension(s)**: _[which dimensions have clear, positive evidence]_
- **Weakest dimension(s)**: _[which dimensions have weak or negative evidence]_
- **Key conflicting signals**: _[which signals disagree and what the conflict suggests]_
- **Trend direction**: _[improving / stable / declining / mixed]_
- **Recommended action**: _[none / watch / investigate / escalate]_

### Decision Path (if conflicting evidence exists)

When health signals conflict (e.g., adoption is strong but support-sentiment
is declining), the record must:

1. **Surface the conflict** — name both signals explicitly.
2. **Propose an explanation** — what could explain the disagreement?
3. **Define an investigation path** — what additional evidence would resolve
   the conflict?
4. **Assign a decision-maker** — who decides the next action?
5. **Set a review date** — when will the conflict be re-examined?

This ensures the conflict is not buried in an average or a single "green /
yellow / red" indicator.

## Previous Assessments

| Date | Overall | Key Change | Reviewer |
|---|---|---|---|
| _[date]_ | _[assessment]_ | _[what changed since prior review]_ | _[name]_ |

# Success Plan

> A structured record of the customer's desired outcomes, aligned product
> capabilities, measurable milestones, and assigned relationship owner.
> This is a living artifact — update it at each QBR or health review.

## Customer Context

- **Customer**: _[name or identifier]_
- **Product model**: _[B2B Subscription / Transactional / Public Service / Internal Product]_
- **Relationship owner**: _[named CS team member]_
- **Plan period**: _[start date] to [end date]_
- **Last updated**: _[date]_

## Desired Outcomes

What does the customer want to achieve? Each outcome must be measurable.

| # | Outcome | Success Metric | Target | Current | Trend |
|---|---|---|---|---|---|
| 1 | _[e.g., reduce manual data entry]_ | _[e.g., hours saved/week]_ | _[target]_ | _[current]_ | _[↑/→/↓]_ |
| 2 | _[outcome]_ | _[metric]_ | _[target]_ | _[current]_ | _[trend]_ |
| 3 | _[outcome]_ | _[metric]_ | _[target]_ | _[current]_ | _[trend]_ |

## Product-Capability Alignment

| Outcome | Supporting Capability | Adoption Status | Evidence |
|---|---|---|---|
| _[outcome #]_ | _[feature or capability]_ | _[adopted / partial / not adopted]_ | _[adoption signal from product-adoption]_ |
| _[outcome #]_ | _[capability]_ | _[status]_ | _[evidence]_ |

## Milestones and Evidence Gates

| Milestone | Target Date | Evidence Required | Status |
|---|---|---|---|
| _[e.g., complete onboarding]_ | _[date]_ | _[e.g., activation rate > threshold]_ | _[on-track / at-risk / missed]_ |
| _[milestone]_ | _[date]_ | _[evidence]_ | _[status]_ |

## Risk Register

| Risk | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|
| _[risk description]_ | _[high/med/low]_ | _[high/med/low]_ | _[what we're doing about it]_ | _[name]_ |
| _[risk]_ | _[likelihood]_ | _[impact]_ | _[mitigation]_ | _[owner]_ |

## QBR / Review Notes

| Date | Key Discussion | Decisions | Follow-Up |
|---|---|---|---|
| _[date]_ | _[summary]_ | _[decisions made]_ | _[actions assigned]_ |

## Plan Health Summary

- **Overall**: _[on-track / at-risk / critical]_
- **Strongest dimension**: _[which outcome has the best evidence]_
- **Weakest dimension**: _[which outcome has the weakest or conflicting evidence]_
- **Next review**: _[date]_