# Customer Success Management

Runs the ongoing relationship with accounts after the sale, segmenting coverage...

- Repository: https://github.com/cbrock84/headcount (2554 stars)
- Category: Design
- License: MIT
- Last updated: 2026-10-18
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add cbrock84/headcount --skill customer-success-management -g -a claude-code -y`
Codex: `npx skills add cbrock84/headcount --skill customer-success-management -g -a codex -y`
Cursor: `npx skills add cbrock84/headcount --skill customer-success-management -g -a cursor -y`
Gemini CLI: `npx skills add cbrock84/headcount --skill customer-success-management -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add cbrock84/headcount`

## Description

Runs the ongoing relationship with accounts after the sale, segmenting coverage against account value, building a health score that predicts rather than describes, running reviews customers find worth attending, forecasting renewals honestly, and finding expansion that follows usage instead of quota. Use this to design a customer success motion, decide who gets a named contact, work out why renewals surprise you, or fix a health score everyone ignores.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Customer success management

This is the motion that keeps accounts, as distinct from diagnosing why they leave, for the
churn analysis itself, see `revenue:retention`. The failure this discipline exists to prevent is
finding out at renewal.

## Segment coverage before hiring anyone

Coverage is a cost decision and it should be made explicitly rather than by whoever shouts.

- **Named coverage** for accounts where the revenue justifies a person and the relationship is
  genuinely complex. Fewer accounts per person than instinct suggests, a manager with sixty
  accounts is running a queue, not a relationship.
- **Pooled coverage** for the middle: a team owning a segment, working from signals rather than
  from a calendar.
- **Programmatic coverage** for the long tail: in-product guidance, lifecycle messaging, and
  self-service. This is not a lesser tier, it is the only one that scales, and it usually deserves
  more investment than it gets.

Assign by what the account needs, not only by what it pays. A large account that is live, stable
and happy needs less than a small one mid-implementation.

## Build a health score that predicts something

Most health scores are a weighted average of whatever was available, colored red to green, and
trusted by nobody. A useful one is built backwards: take accounts that churned and accounts that
renewed, and find what actually differed six months out.

- **Usage depth and breadth**, how many people, how often, how many of the things they bought.
- **Trajectory over level.** An account at 60% of expected usage and rising is healthier than one
  at 90% and falling. Level tells you where they are; direction tells you where they are going.
- **Relationship coverage**, how many people you know, and whether your only contact is the person
  who bought.
- **Support and escalation history**, weighted by severity rather than volume.

The rest: https://github.com/cbrock84/headcount/blob/HEAD/plugins/customer-experience/skills/customer-success-management/SKILL.md