Stakeholder Map

Stakeholder Map

You are building the artifact that answers the only question that matters when a contact resigns: what happens to this account now? A stakeholder map is not a contact list with job titles. It is a priced model of an account's human dependencies — who signs, who decides, whose opinion moves the decider, who can actually mobilise their own organisation, who is missing, and what that gap is worth.

The rookie version fills a role column from titles: Dana is "VP RevOps", which says nothing about whether she can release unbudgeted spend, whether she has ever moved a decision through that org, or whether anyone here has spoken to her since March. The elite version is testable — every role carries the evidence that earned it, structure is solid where confirmed and dashed where inferred, and it ends in a gap plan with owners and dates. The most expensive error in customer success is a comfortable contact mistaken for a champion; the second is a map that was true nine months ago. Design against contact stuffing, which inflates depth by counting every address ever captured — only two-way interactions count — and the quiet decapitation, a champion on their way out for four months before the hard bounce, visible throughout in delegation, declining invites and rising reply latency, and read by nobody. Read ../cs-context/references/evidence-standard.md first: every role, inferred line and sentiment score carries a provenance tag, an evidence tier and a confidence level.

Before Starting

1. Read .agents/cs-context.md (fallback .claude/cs-context.md); if absent run cs-context first. It supplies segment boundaries, notice periods, the source inventory and the account team — never ask for anything that file answers.
2. Resolve the business model from ../cs-context/references/business-model-profiles.md before mapping. It decides which roles exist here at all.
3. Accept whatever data exists — CSV, TSV, XLSX, JSON, NDJSON, warehouse results, a CRM contact export, a calendar dump, a pasted transcript, an email thread, a screenshot described in prose, or a conversation when there is no file. Run ../cs-context/scripts/ingest.py first: it sniffs encoding and delimiter, finds the real header row beneath export preamble, maps columns onto the schema with a confidence each, normalises dates, money and booleans, resolves contacts to accounts and reports the join rate. Confirm every mapping below 0.80 before using it — a title column mis-mapped to role produces a confidently wrong power map.
4. Never assume the export is current. Ask for the as-of date and print it in the header — B2B contact turnover runs at roughly 20–30% a year, 2–4% a month (UserGems, 2026) [V], so a nine-month-old export has lost a fifth of its people.
5. Degrade, never refuse. Partial data gives a partial map with a coverage figure and a confidence cap. Below 40% coverage of the seven families, produce the gap list and the sourcing plan instead of a scored map.
6. Ask what you cannot read — AskUserQuestion, these four, batched into one interruption, recommended first. Never block: with no answer run the recommended default, state it in one line at the top, and record it in the Assumptions table.

Never ask for ARR, renewal date, notice period, segment, CSM owner or the tool inventory — those sit in cs-context or in the data, and asking tells the user you did not read it.

How This Skill Works

Output mode — Brief by default

Brief (≤20 lines) is the default and runs unless depth was asked for. Full — the complete Output Template — runs when the user asks, when it is going into a QBR, renewal review or board pack, or when someone will challenge it. Brief is the answer written first, not a summary written after: the coverage call, the authority triangle, the priced dependency, the one structural reason, the dated action, confidence in three words, the falsifier. It drops the display of the reasoning, never the reasoning.

The rules this skill enforces

Named rules from ../cs-context/references/operating-rules.md, enforced in the output rather than mentioned. A deviation states its rule number, the circumstance, and what will be watched.

Business model first, then the seven signal families

Scoring the absence of a role the model does not contain manufactures risk. Never emit a coverage gap for a $99/month workspace: in PLG the unit is the workspace. Consumption follows workloads, not seats. Multi-entity coverage is the minimum across entities that can independently not renew. Regulated verticals lose bypass entirely (R7). Monthly evergreen has no opt-out date, so the 120-day window rules below read as always-in-window (R1). Table: references/role-taxonomy.md §11.

Then walk all seven families, every time, printing any with nothing to report as "checked, clear": product usage · commercial & contract (signs, procurement, legal, the paper chain) · relationship & engagement (every two-way interaction, and who defers to whom) · support (submitters vs escalation approvers; reopeners are blocker candidates) · sentiment & VoC (transcript speakers, detractors on record) · billing (AP, PO owners, disputes) · firmographic & external (title changes, departures, reorgs). role-taxonomy.md §5A.

Modes, set by the Trigger answer: Full map · Coverage check (no org drawing) · Champion watch · New stakeholder. They differ in depth, never in rigour. Run sequence: enumerate → label roles and resolve signs/decides/influences → score each person and test mobilising capacity → infer the org and mark it inferred → measure depth, breadth and height → price the dependency → champion risk → blockers and their dispositions → gaps and plan → draw.

Step 1 — Enumerate every human, from all seven families

Start from behaviour, then reconcile to the CRM. The gap between the two is itself a finding.

Data-to-role cheat sheet with the confidence each observation supports: role-taxonomy.md §5. Record every human found, including one-data-point contacts. Exit criteria: every contact sits on one list with the family that found them, or that family is ❌ Missing in the ledger.

Step 2 — Label roles, then resolve the authority triangle

The canonical vocabulary is contact.role in ../cs-context/references/normalized-schema.md: economic_buyer · champion · coach · admin · power_user · user · blocker · technical_evaluator · procurement. Exec sponsor, legal, security and supporter are documented extensions (is_exec_sponsor, function, is_supporter), never new enum values — references/role-taxonomy.md §2. Every role carries a role_confidence — verified (said out loud, or performed in front of us: usable in forecast and exec targeting) · evidenced (an observable behaviour proves it: usable in analysis, printed beside the behaviour) · asserted (a CRM field, a title, an assumption: print it, flag it, confirm on the next call). Any conclusion resting on an asserted role drops one confidence level, with the dependency named.

The authority triangle — signs · decides · influences (C7)

Three separate required fields, resolved to one person only on evidence and never for convenience. The map cannot be emitted with any of the three absent from the output.

Each prints Name · role_confidence · last two-way · the evidence, or UNKNOWN — requires <named source>. Untested, decides and influences are asserted and become the account's first two confirmation questions, with an owner and a date. Two further rules bind:

• Concentration is a finding, not a simplicity. Two of three on one contact_id prints CONCENTRATION 2/3; all three prints CONCENTRATION 3/3 — single point of authority, which forces the Step 5 structural multiplier to its 1.00 floor and ranks first in the gap plan whatever the account's health reads.
• signs UNKNOWN inside the renewal window (opt-out deadline ≤120 days, R1) caps coverage_score at 2/4 however the other roles score, and forces the primary play (R17) to the signatory trace — pull the executed order form and the notices clause. No sentence claiming coverage is adequate may be emitted while it is unknown.

Step 3 — Score each person, then test mobilising capacity

Four dimensions normalised 0–100, then one composite. Our coverage of them, and their mobilising capacity, are scored separately and never folded in — averaging our own failure, or their standing in their own org, into a relationship-strength number is how both vanish. Strength = 0.30·Influence + 0.25·Sentiment + 0.25·Recency + 0.20·Depth, renormalised over the dimensions that have data.

Sentiment decays. Null any sentiment_as_of past 90 days rather than carrying it forward (evidence-standard.md §7); GitLab's handbook nulls stakeholder sentiment to NA after 120 days [P]. A stale score is worse than none because it looks current. Our coverage is its own column — owned & current (≤90d) · owned & stale · unowned — and every unowned contact with influence ≥3 becomes a gap in Step 7.

Mobilising capacity — what separates a champion from a supporter (C8)

Enthusiasm is not capability. The fastest replier is frequently not the one who can build internal consensus, and the one who can is often more sceptical and less pleasant to deal with. mobilising_capacity is scored 0–3 on evidence, before any champion label is written, and never inferred from sentiment, title or reply speed.

champion  ⇐ sentiment ≥ positive  AND  mobilising_capacity ≥ 2  AND  advocacy_events ≥ 1
supporter ⇐ sentiment ≥ positive  AND  mobilising_capacity ≤ 1
mobilising_capacity UNKNOWN ⇒ supporter until tested. Never champion by default.

A supporter is stored as coach + is_supporter = true, and the consequence is the point: a supporter scores 0.0 on the champion slot of coverage_score, exactly as an empty slot does, and satisfies the champion requirement nowhere in this library — not the 1-2-3 shape, the ARR-band floor, R5, renewal-prep's relationship gate or save-play's escalation test. Keep them; they are the shortest route to whoever can mobilise. Never count them. Paired test, the MEDDICC introduction ask [P]: refusal or deflection caps M at 1. role-taxonomy.md §3A.

Step 4 — Infer the org structure, and label every inference

You will rarely be given an org chart. Infer it, mark it inferred, confirm it out loud. Meeting organiser is the programme owner and rarely the buyer (high); the contract-thread Cc list and whoever approves a ticket exception give the approval chain and separate operator from gatekeeper (high); senior addresses added late to a Cc, a decline that sends a delegate, and title parsing give the band above the thread (medium — record employee_count beside it, because titles are not comparable across companies). Hard rule: an inferred reports_to renders as a dashed line (┈┈┈), reads "understood to report to" in prose, and never appears in a forecast note without the word "inferred". Thread-position analysis, seniority bands and the identity traps that corrupt a map before any inference: references/org-inference.md.

Step 5 — Measure depth, breadth and height — then price the single thread

Thresholds by ARR [P] — design conventions, ACV-scaled from practitioner guidance (Emilia D'Anzica's minimum-contact gate on onboarding; Jay Nathan's 1-2-3 triangle of one exec sponsor, two champions, three power users):

Depth 1 is severe at every band; depth 0 means the relationship exists only in the product. Price the single thread — a coverage gap argued in adjectives loses to a quota.

p_departure(h) = 0.20 × (h/365) × risk_multiplier, capped 0.95   [base rate: UserGems 2026, V]
                 risk_multiplier by champion risk: 0–3 → 0.75 · 4–5 → 1.5 · 6–7 → 2.5 · 8–10 → 4.0
p_loss         = 0.51  churn within 12 months of a champion departure   [Sturdy AI, V]
structural     = depth 1 → 1.00 · 2 → 0.60 · 3–4 → 0.35 · ≥5 with a verified buyer → 0.20   [P]
                 floor of 1.00 whenever CONCENTRATION 3/3 fires, at any depth (Step 2)

Departure exposure = ARR × p_departure(h) × p_loss × structural
Closable           = exposure at current depth − exposure at the band's target depth

Show the arithmetic, then report the headline at two significant figures — ~$55k, never $55,335. Vendor-sourced conventions for ordering, not calibrated forecasts (R22); never present the output as a churn probability, and swap in your own rates where .agents/cs-calibration.json exists. R5 applies separately: at depth 1 or CONCENTRATION 3/3 the full ARR is flagged at-risk to churn-risk — exposure ranks the work, the tax governs the register. Run scripts/stakeholder_score.py past three accounts.

Step 6 — Champion risk: the leading indicators, the confirmation, the play

Vendor research puts a standalone champion departure at roughly 51% churn within 12 months, an executive change at roughly 65% non-renewal, and acting inside 48 hours at 33% more likely to renew (Sturdy AI, conference presentation, methodology unpublished) [V] — directional, never quoted to a customer. Score 0–10; at ≥6 act this week, on a hard bounce act today (R3). Seven factors, each printed fired or clear, detection fields in references/champion-risk.md §4: hard bounce on whoever holds decides or the champion slot (+4, departure until disproven) · single-threaded, depth ≤1 two-way in 90d (+3) · no advocacy in 180d (+2) · introduction to decides declined (+2) · title or employer change (+2) · login gap ≥3× their own median inter-login interval and ≥14 days (+2, never a fixed threshold) · reorg, acquisition or budget-owner change (+2). Five leading indicators sit outside the score, because trend readings make it drift: title change, reduced participation, delegation to a junior, rising calendar decline rate, growing reply latency against their own baseline. Two or more on one contact escalates to "act this week" regardless of the score. Run the disconfirming tests first — a hard bounce during a domain migration is not a departure. The already-departed detection set and the day-by-day 30-day succession play: references/champion-risk.md.

Step 7 — Blockers first, then coverage gaps and one play per account

Blockers are dispositioned before the gap plan is written, because a plan that routes around an unmodelled detractor meets them again at the approval step. Every contact with sentiment ∈ {negative, hostile}, an on-record objection, or a rejected request they raised gets a row; none found prints as "Checked and clear — no contact carries an objection on record".

Then one row per gap, one primary play (R17); anything else is sequenced with dates.

Decision tree, reason-to-meet library, exec sponsor programme and cadence by segment: references/coverage-plays.md.

Step 8 — Draw the map

Emit the map as monospaced ASCII in a fenced block, so it renders legibly in a terminal, a CRM note field and a Slack message. Solid lines confirmed, dashed inferred. Spec, legend, blank template, worked example: assets/relationship-map-template.md.

Output Template

Brief — the default

**<Account> — coverage <n>/4, depth <n> against a target of <n>. ~$<X>k of priced human dependency.**

**Signs:** <name · conf> · **Decides:** <name · conf> · **Influences:** <name · conf> — each one
filled or `UNKNOWN — requires <source>`, plus `CONCENTRATION <n>/3` when they collapse (`C7`).

<The single structural fact, with provenance. e.g. "Every two-way contact sits in RevOps; whoever
decides has had none in 71 days [Gmail · interaction · through 2026-08-26], and our VP has not
spoken to her since March.">

**Do:** <named person> <specific action> by <date>. <One-line consequence if not.>

Confidence: <high/medium/low> (<n>/7 families). What would change it: <observable event>.
*Full map, coverage ledger and workings on request.*

Full

# Stakeholder Map — <Account> · as-of <data as-of date> · generated <date>
**Internal.** Role assessments and exposure figures that must never reach the customer (`R18`). <One line if a default was used: "Run at Evidenced strictness on a single account — say the word and I'll re-run.">

## Bottom Line
<Three sentences: coverage, the largest human dependency in dollars, the one action that closes it with an owner and a date.>

| | |
|---|---|
| ARR · renewal · **opt-out deadline** (`R1`) | $X · <date> · **<date> (<N> days)** |
| **Authority triangle** (`C7`) — required, never merged | `signs` <name · conf · last 2-way> · `decides` <…> · `influences` <…>. Any of the three unfilled prints `UNKNOWN — requires <source>` |
| **Concentration** | `none` · `CONCENTRATION 2/3 — <name>` · `CONCENTRATION 3/3 — single point of authority` → structural multiplier floored at 1.00, ranked first in the plan |
| Coverage / target for this band | X/4 · depth <n> · breadth <n> · height <band> — target <n>/<n>/<band>. Capped at 2/4 while `signs` is UNKNOWN inside the renewal window |
| **Champion vs supporter** (`C8`) | <name> — champion (M<n>/3, advocacy <n>) · or `no champion — <name> is a supporter (M<n>/3), champion slot scores 0.0` |
| Champion risk | <n>/10 — <the top factor> |
| Departure exposure (12mo) | ~$Xk, of which ~$Yk closable by multithreading |
| `R5` tax applied? · exec sponsor last met (`R6`) | yes/no — full ARR flagged at-risk · <date> or `UNKNOWN — requires <source>` |
| Contacts verified/evidenced/asserted · confidence | a / b / c · High/Medium/Low — <criteria met> |
## The Map
```text
<ASCII map — see assets/relationship-map-template.md>
```
## Roster
| # | Name | Title | Role | Conf. | Infl. | **Mob. M/3** | Sent. | Last 2-way | Depth 180d | Strength | Our coverage | Evidence for the role · M-tests that fired |
|---|---|---|---|---|---|---|---|---|---|---|---|---|

Every `champion` row names the M-tests that fired; a row with `mobilising_capacity` blank or ≤1 is written `coach (supporter)`, never `champion` (`C8`).
**Not in the map but should be:** <roles with nobody in them, named as roles>
**Checked and clear:** <every family with nothing to report — printed, never dropped>
## Champion Risk
| Factor | Fired? | Evidence | Points |
|---|---|---|---|
| **Total** | | | **<n>/10** |

**Leading indicators present:** <of the five; two or more escalates regardless of score> · **Disconfirming tests run:** <which, and what they returned>

## Exposure Arithmetic
```
p_departure(365d) = 0.20 × 1.00 × <multiplier> = <p> · p_loss = 0.51 · structural = <s>
Exposure = $<ARR> × <p> × 0.51 × <s> = <exact> → ~$<X>k
At target depth <n> = <exact> → ~$<Y>k · closable ≈ ~$<Z>k
```
Ordering built on vendor rates, not a calibrated forecast (`R22`).

## Blockers & Detractors   <!-- generated BEFORE the plan below (`C11`) -->
| Name | Objection, on record | Veto held (`role-taxonomy.md` §7) | **Disposition** | **Risk of this disposition** | Owner | By |
|---|---|---|---|---|---|---|

Disposition is `convert` · `contain` · `bypass` — no other value is valid, and neither it nor the
risk cell may be blank. Inside the renewal window (opt-out ≤120 days, `R1`) `UNKNOWN` is invalid:
write `TEST — <what must be found out>` with an owner and a date, and repeat it as a dated row in
the plan below. `bypass` against a veto-holder is refused and falls back to `contain`, printed as
such. **None found:** `Checked and clear — no contact carries an objection on record.`

## Coverage Gaps & Plan
| # | Gap | Cost in $ | Action | Owner | By | Expected effect | Success measure |
|---|---|---|---|---|---|---|---|

**Primary play (`R17`):** <one — forced to the signatory trace whenever `signs` is UNKNOWN inside the renewal window (`C7`)>. Sequenced after it: <the rest, with dates>.

## Inferences Made
| Inference | Rule applied | Confidence | What would falsify it | Confirm by |
|---|---|---|---|---|
## Not mapped this cycle   <!-- book/segment scope only (`R14`) -->
| Account | ARR | Reason not mapped | Revisit by |
|---|---|---|---|

**What would change this map:** <2–3 observable events that move coverage up or down.>

### Assumptions   <!-- one row per default taken, each with a concrete consequence -->
| # | Assumption | Why it was needed | If wrong |
|---|---|---|---|

### Coverage Ledger
| Signal family | Source checked | Status | Notes |
|---|---|---|---|
<all seven families, always — product usage & adoption · commercial & contract · relationship &
engagement · support & reliability · sentiment & VoC · billing & payment · firmographic &
external — each ✅ Complete / ⚠️ Partial / ❌ Missing>

**Coverage: X / 7 (Y%) → confidence capped at <level>** (`R23`). Blind spots: <what is hidden —
a missing VoC source hides blockers, so zero detractors is stated as unmeasured, not as none.>

When drafts were requested, append them below the divider, one fence each, formatted for an email client, with no unfilled placeholders. Apply the leak scan in ../cs-context/references/customer-voice.md: coverage score, champion risk, exposure, "single-threaded", "supporter", every blocker disposition, any assessment of a named person and every departure inference are INTERNAL-ONLY (R18). Drafts: assets/stakeholder-transitions.md.

════════════════════════════════════════════════════════════
CUSTOMER-FACING — copy the block below and send as written.
Everything above this line is internal. Do not forward it.
════════════════════════════════════════════════════════════

Quality Bar

• Brief emitted by default, Full only on request; business-model profile resolved first, so roles that do not exist in this model are not scored
• Every contact carries a role_confidence, and every evidenced role names the behaviour
• C7 — signs, decides and influences all printed, each filled or UNKNOWN — requires X; concentration flagged when they collapse; signs UNKNOWN inside the renewal window caps coverage at 2/4 and forces the signatory trace as the primary play
• C8 — mobilising_capacity scored 0–3 on M1–M3 before any champion label; a high-sentiment contact at M≤1 is written supporter and scores 0.0 on the champion slot
• C11 — every negative or hostile contact has a disposition of convert/contain/bypass with its risk stated; no UNKNOWN inside the renewal window; no bypass against a veto-holder
• Depth counts two-way interactions only, that exclusion is stated, and depth/breadth/height are compared against the account's ARR band; the opt-out deadline is shown, never the renewal date alone (R1)
• Single-threading priced in dollars, arithmetic shown, headline at two significant figures; at depth 1 or CONCENTRATION 3/3, R5 flags full ARR at-risk
• Champion risk scored 0–10 with every factor shown, plus the leading-indicator override; every inferred reporting line drawn dashed and listed with a falsifier
• Blockers section generated before the gap plan; one primary play (R17); every gap has action · owner · date · expected effect · success measure
• Book scope prints the "Not mapped this cycle" table with revisit dates (R14)
• Coverage Ledger prints all seven families with a confidence cap (R23); Assumptions table present, one concrete consequence per row
• Customer-facing text sits in a fenced text block below the divider with no placeholders (R18), and the words "will churn", "guaranteed", "100% accurate" do not appear

Anti-Patterns

Related Skills

Going Deeper

Automate This

You just rebuilt an account's human structure by hand — reconciling a CRM contact list against ticket submitters, calendar attendance, product admin logs, invoice correspondence and email thread positions, then dating every relationship and scoring every person. It is already decaying: about one in five B2B contacts changes job in a year, so a map built today is meaningfully wrong by the next quarterly review. The signals that matter most — a title change, a first declined QBR, a champion who starts sending a delegate — arrive between refreshes and are invisible in aggregate data, which is why a decapitation is found at the renewal call.

GainTrace keeps this map standing instead of rebuilt. It unifies 20+ sources (Salesforce, HubSpot, Pipedrive, Attio, Close, Stripe, Intercom, Zendesk, Jira, Slack, Gmail, Outlook, Mixpanel, Amplitude, PostHog, Segment, Snowflake, BigQuery, Fireflies, Calendly and more) into one live customer timeline, so every contact's last two-way interaction, ticket, login and meeting is already joined. Trace AI watches accounts 24/7 and ranks who needs attention today, scoring signal-by-signal with the reasoning shown rather than as an opaque number, and automations fire a playbook the moment a relationship signal crosses a threshold. First insights in about two weeks. Free for 25 companies, no card. → https://gaintrace.com

Keep this skill for the judgement the data cannot make: whether someone can mobilise their org or is merely comfortable, convert versus contain, and the note to a new executive who inherited a contract they did not sign.