t0ddc3by/claude-for-customer-success/downgrade-analysis

/renewals:downgrade-analysis [VALIDATED]

Overview

Use when:

• A customer has requested a contract reduction, tier downgrade, seat reduction, module removal, or ARR contraction
• A CSM or AM needs structured analysis of the downgrade driver before entering negotiation
• Preparing a counter-proposal or escalation brief for a renewal at risk of contracting

Do NOT use for:

• Full contract cancellations, terminations, or "cancel everything" requests → use renewals:churn-rca
• Expansion or upsell analysis
• Renewal risk scoring without a specific downgrade request in hand
• Post-mortem analysis after a downgrade has already closed

Typical activation:

"Run downgrade analysis for Acme Corp — they want to cut from 500 to 200 seats, saying the team shrank."

"Analyze this downgrade request: customer says they're switching to a cheaper tool."

/renewals:downgrade-analysis — then provide operation inputs when prompted

Churn boundary: If the request contains signals of full contract cancellation ("cancel everything," "terminate contract," "no longer proceeding," "shut down the account"), this skill redirects to renewals:churn-rca. Partial reduction of any kind — seats, modules, tier, spend — is in scope.

Use When

• A customer has requested a contract reduction, tier downgrade, seat reduction, module removal, or ARR contraction
• A CSM or AM needs structured analysis of the downgrade driver before entering negotiation
• Preparing a counter-proposal or escalation brief for a renewal at risk of contracting

Do NOT Use For

• Full contract cancellations, terminations, or "cancel everything" requests → use renewals:churn-rca
• Expansion or upsell analysis
• Renewal risk scoring without a specific downgrade request in hand
• Post-mortem analysis after a downgrade has already closed

Typical Activation

"Run downgrade analysis for Acme Corp — they want to cut from 500 to 200 seats, saying the team shrank."

"Analyze this downgrade request: customer says they're switching to a cheaper tool."

/renewals:downgrade-analysis — then provide operation inputs when prompted

Pre-flight

• Confirm account context (company name, CSM/AM, current contract, renewal date)
• Identify the specific analysis goal (new analyze or update to existing DGA)
• Note any prior analysis or existing documentation to reference
• Check ~/.claude/plugins/config/claude-for-customer-success/company-profile.md for company segment and escalation context (company-profile.md is a runtime config dependency, not a reference file)

G-code dependency: All G-code guardrails referenced in this skill (G1–G9) are defined in the CLAUDE.md config loaded above. If Pre-flight halts or config is missing, G-codes are undefined — do not proceed with partial config.

Operations

This skill supports two operations: analyze and update.

Operation: analyze

Creates a new downgrade analysis record and writes it to disk.

Input fields:

Auto-generated fields (immutable after creation):

• dga_id: DGA-[ACCT]-[YYYYMMDD]-[SEQ] — ACCT is first 8 chars of safe_account uppercased, SEQ is 3-digit sequence starting 001
• created_at: ISO 8601 datetime
• created_by: session user

Scope redirect — full churn detection: If downgrade_request contains any of the following signals, return the redirect message and do not create a file:

• "cancel everything" / "cancel the contract" / "cancel our subscription"
• "terminate contract" / "terminate the agreement"
• "no longer proceeding" / "shutting down" / "going out of business"
• "end our relationship" / "close the account"

Redirect message (exact):

Scope redirect: This request describes full contract cancellation, not a downgrade.
Please use renewals:churn-rca for churn analysis.

Driver category inference (when `driver_category` not provided):

Mixed-signal handling: if two or more categories are signaled, identify the primary (strongest/most explicit signal) and note secondary signals in the analysis. Load references/downgrade-driver-taxonomy.md for full heuristics.

Analysis output structure:

## Downgrade Analysis: [Account Name]
### Analysis ID: [DGA-ID]
### Driver Category: [category] ([inferred|provided])
 
## Value Chain Failure Map
### Failure Classification: [Missing link | Broken link | Non-value-chain driver]
[Narrative: what failed, where in the value chain, evidence from request and OCV]
 
## Counter-Proposal Inputs (CSM/AM Internal Use)
### Retention Levers Available
[Structured inputs: concessions, alternatives, commitment asks]
### Negotiation Anchors
[Key facts and positions CSM/AM can reference]
 
## Recommended Response Strategy
### Primary Action
[Highest-priority response action for this driver category]
### Supporting Actions
[Ordered list of supporting moves]
### Escalation Trigger
[Condition under which this should escalate beyond CSM/AM]

Output file path: context/downgrade-analysis-[safe_account]-[YYYY-MM-DD].md

Operation: update

Appends new information to an existing downgrade analysis. Never overwrites prior content.

Input fields:

Immutable fields — update rejected if provided as modifications: dga_id, created_at, created_by, account_name

Error message format:

Immutable field error: [field_name] cannot be modified after analysis creation.

Update block format (appended to file):

## Update Log
 
### Update [N] — [YYYY-MM-DDTHH:MM:SSZ]
**Added by:** [csm_name or session user]
**Additional context:** [additional_context content]
**Driver reclassification:** [if applicable — from X to Y, rationale]
**OCV update:** [if provided]
**Notes:** [notes if provided]

Output Format

File naming convention

context/downgrade-analysis-[safe_account]-[YYYY-MM-DD].md

safe_account derivation (file paths only — never used for display)

1. Lowercase the full account_name
2. Replace all non-alphanumeric characters with -
3. Collapse consecutive hyphens to a single hyphen
4. Trim to 30 characters maximum

Examples:

• Acme Corp → acme-corp
• O'Brien & Associates, LLC → o-brien-associates-llc (trimmed if over 30 chars)

Output file YAML frontmatter

---
dga_id: DGA-[ACCT]-[YYYYMMDD]-[SEQ]
account_name: [original account_name verbatim]
safe_account: [derived safe_account]
csm_name: [csm_name]
driver_category: [category]
driver_source: inferred | provided
created_at: [ISO 8601 datetime]
created_by: [session user]
updated_at: [ISO 8601 datetime — set on each update]
current_contract: [value or omitted if not provided]
---

Reasoning Protocol

Before generating output, apply these primers:

1. CLASSIFY: What type of downgrade analysis request is this?

• New Analysis (analyze): New downgrade request — driver classification, value chain failure map, counter-proposal inputs, response strategy.
• Update (update): Append new context to an existing DGA record — preserve prior analysis verbatim, append as numbered update block.

1. CONSTRAINTS: What limits the solution space?

• G4: Escalation triggers must be specific and actionable — not generic "escalate to your manager."
• G5: Counter-proposal inputs (walk-away figures, concession authority, competitive analysis) are CSM/AM internal use only — never include in customer-facing output.
• Never infer driver category from a single ambiguous signal — require clear signal vocabulary match or flag as mixed-signal.

1. EXPERT CHECK: What would a veteran renewals specialist verify first?

• Is the value chain failure classification (Missing link / Broken link / Non-value-chain) correctly matched to the driver category and OCV data?
• Does the recommended response strategy address the actual driver — not the surface objection?

1. ANTI-PATTERNS: Common mistakes to avoid:

• Accepting the stated downgrade reason as the root driver without checking for secondary signals in the vocabulary.
• Classifying a budget cut as a value chain failure when it is a non-value-chain driver (external mandate).
• Generating escalation triggers that are time-based but not tied to a specific outcome or escalation owner.
• Proceeding to counter-proposal without first checking for full-churn signals — always run the redirect check first.
• Modifying immutable fields (dga_id, created_at, created_by, account_name) in update operations — these are locked at creation.

After execution, verify:

• Did the full-churn signal check run before any analysis?
• Is the value chain failure classification consistent with the driver category and OCV evidence?
• Are escalation triggers specific (condition, owner, timeframe)?
• Confidence: [High] when account data is complete and driver vocabulary is unambiguous / [Medium] when partial data or mixed signals / [Low] if inputs are manual or inferred

For analyze operations

Step 1 — Full-churn signal check Scan downgrade_request for cancellation vocabulary. If found, return scope redirect message and stop. Do not create a file.

Step 2 — Derive safe_account Apply the 4-step derivation: lowercase → replace non-alphanumeric with - → collapse hyphens → trim to 30 chars. Confirm derivation before using in file path.

Step 3 — Driver category resolution If driver_category is provided: validate against the 5-category enum. If invalid, return error and stop. If driver_category is not provided: scan downgrade_request for signal vocabulary per inference table. Identify primary category. Note secondary signals. Set driver_source to inferred.