Voice Of Customer

Voice of Customer

You are running the feedback programme for a company where every theme you publish either gets funded or gets ignored, and both outcomes are your fault. The standard is not "summarise the survey". It is a ranked register of what customers are telling you, with dollars attached to each theme, an accountable owner on each, and an honest statement of whose voice is missing — handed to an exec staff that will spend money against it.

The rookie version is recognisable in four seconds. It opens with an NPS number and no response rate, quotes the customer who emailed the CEO, and lists themes with no revenue on any of them — so Product ranks them by whichever CSM lobbied hardest, and a theme raised by 200 SMB trial users outranks one raised by $4M of Enterprise ARR three months from its opt-out deadline. Then it runs a survey nobody has capacity to act on, which is not neutral: it spends customer goodwill, returns nothing, and the response rate falls the next time you ask.

The elite version treats every channel as a biased instrument and states the direction of each bias before quoting a number from it; codes free text against a closed, versioned taxonomy with a measured inter-coder check; attaches ARR, segment and health band to every theme so priority is a revenue argument, not a volume argument; cross-references what customers say against what they do, because the disagreements — promoters who stopped logging in, detractors who just expanded — are the most informative output the programme produces; and closes the loop, back to the individual and back to the base, including on the themes it decided not to fix. That last loop is the one nobody closes, and it is why most VoC programmes quietly die.

Read ../cs-context/references/evidence-standard.md before writing anything. Verbatims are quoted with account, date and source ref. Numbers carry provenance. Nothing is inferred without its rule.

Before Starting

1. Read .agents/cs-context.md first. Segment boundaries in dollars, the notice period and the activation event are what let you attribute ARR to a theme and judge whether a complaint sits on the value path; absent, run cs-context. Then ../cs-context/references/business-model-profiles.md — a seat base complains about utilisation, a consumption base about unit economics, and a PLG base has no QBR or CAB channel to code from at all. Coding against the wrong model is the most recognisable generic output this skill can produce.

2. Ask once, tappably, and never block. Every missing input resolves read it · ask it · mark it — never guessed (../cs-context/references/clarification-protocol.md). Ask nothing cs-context already answers: not segments, not notice periods, not the source inventory, not ARR, not who the CSM is. Batch all four questions below into one AskUserQuestion — 2–4 mutually exclusive options each, recommended first and labelled (Recommended), one line under each saying what it changes.

If no answer comes back, run the recommended default on all four, state it in one line at the top of the output, and record each in the Assumptions table. Never stall waiting for an answer.

3. Take whatever data they have. This skill accepts CSV, TSV, XLSX, JSON, NDJSON, warehouse query results, a pasted survey export, a ticket dump, a transcript pasted into the chat — or no file at all, in which case build the register from answers to questions and label coverage accordingly. Run ../cs-context/scripts/ingest.py on every supplied file before quoting a number from it: it sniffs encoding and delimiter, finds the real header row beneath export preamble, maps columns onto the canonical schema with a per-column confidence, normalises dates, money and booleans, resolves accounts across files and reports the join rate.

4. Run the capacity-to-act gate before coding anything. Who has budget or roadmap capacity this quarter, and how many themes can they absorb? If the answer is "nobody", say so and stop — a readout with no destination is theatre, and if a new survey is proposed, recommend not running it. The gate produces N: name the top N themes only. Everything below the cut goes to §7 with a reason and a revisit date (R14 · The Written Skip).

5. Detect the taxonomy state. Versioned taxonomy and code book present → code into them, propose changes at the period boundary only. Absent → build one from this period's corpus using references/theme-taxonomy.md §3 and label the readout baseline period — no trend claims.

6. Detect coverage. Sentiment coverage first: ARR of accounts with ≥1 feedback record in the trailing 12 months ÷ in-scope ARR. Below roughly 50% ARR coverage the sentiment section is anecdote, not measurement [P] — say so and cap confidence (R23 · The Coverage Cap).

How This Skill Works

Seven signal families, checked every time. Feedback is not one family — customers tell you things in every one of them, and the rookie error is looking only in the survey tool. What each family carries, its typical source and how it distorts is in references/source-guide.md §1–§6; all seven are printed in the Coverage Ledger, including the ones with no source connected.

1 product usage & adoption (the behavioural cross-check) · 2 commercial & contract (exit interviews, non-renewal notes, win/loss reasons) · 3 relationship & engagement (transcripts, QBR notes, CAB, unsolicited email) · 4 support & reliability (ticket text, reopen reasons, feature requests) · 5 sentiment & VoC (NPS, CSAT, CES and their verbatims) · 6 billing & payment (disputes, pricing complaints, downgrade reasons) · 7 firmographic & external (reviews, community, social, analyst mentions).

Run sequence: scope + capacity gate → channel inventory → representativeness → code to taxonomy → attribute ARR → trend and emergence → sentiment × behaviour → symptom vs cause → rank and route → close the loop → readout.

Step 1 — Inventory the channels and state each one's bias

Walk references/source-guide.md in full — per channel: what it measures, what it systematically over- and under-represents, its valid unit of analysis, and how to caveat it.

Never pool channels into one score. An NPS, a support CSAT and a G2 review are three instruments pointed at three populations. Report each with its own denominator, then triangulate at theme level — the only level where they are comparable, because a theme is a claim about a problem, not a claim about a mood. Print every channel in scope and every channel not connected: with no transcripts you cannot hear what customers say when they are not filling in a form, and that is where most severity-3 material lives.

Step 2 — Establish who spoke, and who did not

This comes before any number, because it determines what the numbers are allowed to claim. Per instrument print: invited · responded · response rate · ARR represented · % of in-scope ARR · respondent role mix. Response rate by count and by ARR diverge; ARR is the one that matters.

scripts/voc_rollup.py computes response rates, ARR coverage, the Silent ARR table and the ARR-weighted post-stratified score deterministically. Use it rather than doing this in prose.

Step 3 — Code free text to a closed taxonomy

references/theme-taxonomy.md holds the starter taxonomy, the code book format, all twelve coding rules (§3–§4) and the split/merge tests (§6). The four that decide most registers:

Adding a new code (§7): period boundary only, ≥5 mentions across ≥3 accounts fitting nothing existing, a written definition with an inclusion and an exclusion example. Bump the version and say whether history was recoded — if not, every trend line crossing that boundary is broken and must be labelled so. Inter-coder consistency is measured, not assumed (§8): double-code a random 10% sample and compute Krippendorff's alpha — ≥0.800 to publish, 0.667–0.800 tentative only, discard below 0.667 [A · Krippendorff, content-analysis reliability convention]. An LLM coder is a coder — same audit against a human-coded gold set, and print the alpha in the readout.

Step 4 — Attribute ARR to every theme

A theme without dollars is a request; a theme with dollars is a business case. references/attribution.md §1–§3 holds the full method. The core:

Attributed ARR      = Σ account.arr for accounts with ≥1 primary-coded mention of the theme
Risk-weighted ARR   = Σ (account.arr × band probability)
                      Secure .05 · Watch .15 · At Risk .35 · High .60 · Critical .85
                      (band midpoints from churn-risk — stated probabilities of a rules-based
                       model, not calibrated forecasts; say so)
Renewal exposure    = Σ account.arr where opt_out_deadline ≤ today + 120 days
                      opt_out_deadline = subscription.renewal_date − notice_period_days

Always split by segment, health band and role, and print all three. A theme raised by $4M of Enterprise ARR and one raised by 200 SMB users are different problems with different owners and fixes; a single total hides which one you have. A theme raised only by admins and never by an economic buyer rarely survives a budget conversation.

Attribution honesty. Attributed ARR is the revenue of accounts that mentioned the theme — not revenue at risk, not revenue recoverable. Label the column exactly. Where a theme is cited in a churn_event or a lost opportunity, report that separately as realised loss with the exit-interview bias caveat attached.

Step 5 — Detect trend, and separate growth from noise

Raw counts rise when you collect more feedback. The comparable unit is share of voice: mentions_theme ÷ total coded mentions in the period. Four tests, arithmetic in references/attribution.md §4:

Classify every theme emerged · growing · flat · fading · resolved with the reason. A theme that grew because you added a channel this quarter is not growing — it is newly visible, a different fact, and must be labelled that way.

Step 6 — Cross-reference sentiment against behaviour

This is the step that separates the artifact from a survey summary. Join each respondent account's sentiment to its usage_daily and commercial state. The disagreements are the output.

The six patterns worth naming — hollow promoter, expanding detractor, silent grower, loud small, quiet large, praise-then-leave — with what each looks like in the data, the reading and the action, are in references/attribution.md §9. Two of them decide most registers: a quiet large (high ARR, one mention, severity 3) outranks fifty severity-1 SMB mentions, and an expanding detractor is the highest-value fix target you own because the goodwill is already spent.

Apply the tiebreak order from ../cs-context/references/evidence-standard.md §8 when signals conflict: commercial actions > economic-buyer relationship > buying-team usage > aggregate usage

sentiment scores. Sentiment is last. State the rule you applied, every time.

Step 7 — Separate symptom from cause

Most stated feedback is a symptom. Run the what-would-have-to-be-true test on every theme that reaches the register:

For <stated theme> to be the actual cause of <the outcome>, what would have to be true — and is it? Name the observable that would confirm it, check it, and record the result.

Three worked examples — "too expensive" resolving to value not realised, "missing feature X" to an onboarding failure, "support is slow" to resolution quality rather than speed — are in references/theme-taxonomy.md §11 with the field each was tested against.

Print both stated_reason and assessed_cause; never overwrite the customer's words with your interpretation. Lincoln Murphy's framing applies — churn is a symptom, the disease is customers not reaching their desired outcome [P]. Feature requests get the same treatment: the risk is not the count of declined requests, it is a decline on the value path (R24).

Step 8 — Rank, then route to one accountable owner

Rank by revenue consequence and fixability, never by mention count.

Intensity    = mean severity (1 friction · 2 workflow blocker · 3 business-case blocker) ÷ 2
Trajectory   = emerged/growing 1.2–1.4 · flat 1.0 · fading 0.8   (attribution.md §4)
Tractability = addressable this quarter 1.2 · this year 1.0 · structural or won't-fix 0.5

Theme Priority = Risk-weighted ARR × Intensity × Trajectory × Tractability

Show the arithmetic for the top themes; round composites to two significant figures. Tie-break on days to the nearest opt-out deadline among the mentioning accounts — the theme whose accounts decide soonest wins. Cut at the N agreed in the capacity gate; everything below the cut goes to §7 with a reason and a revisit date (R14).

A theme routed to two functions is routed to nobody. Assign exactly one accountable owner and name what the other functions are consulted on. references/attribution.md §6 holds the routing matrix and the packet each destination needs. Every routed theme carries action · owner · date · expected effect · success measure; without an owner it is an FYI, and FYIs do not change roadmaps.

Step 9 — Close both loops

references/readout-structure.md §7 holds the full trigger table, SLAs and scorecard. The shape: the inner loop is a human reply from the named account owner to every detractor and every severity-3 mention within 48 hours [P], naming what they said and what happens next; the promoter path is an advocacy ask within 7–14 days, expiring at 90, and never an expansion ask in the same conversation (R11); the outer loop is the "you said / we did" note from the VP CS within 30 days of the readout, to everyone surveyed, respondents and non-respondents alike, naming the themes not being fixed and why. Bain's Net Promoter System is the source of the inner/outer distinction — the frontline acts on individual feedback, the cross-functional team fixes root causes the frontline cannot [V · Bain, Net Promoter System]. Non-respondents are the population whose response rate you are trying to recover; a note that reaches only the already-engaged compounds the bias instead of correcting it.

Loop-closure rate is a published metric: closed within SLA ÷ eligible responses. Under 50%, recommend suspending the survey programme until capacity exists — asking questions you do not answer is how response rates die, and a dead instrument is expensive to restart.

Writing the loop-close notes

Both notes are customer-facing. Read ../cs-context/references/customer-voice.md first; assets/loop-close-note.md holds both templates and the VoC-specific leak scan.

Output Template

Copy this structure verbatim. Omit no section; a section with nothing to report says so.

# Voice of Customer — <scope> · <period> · <date>
**Internal.** Contains account-level risk language and unredacted verbatims. Do not forward externally.
Taxonomy v<X.Y> · <recoded / not recoded> across the period boundary.

## Bottom Line
<3 sentences: the largest theme by ARR, the decision being asked for and its owner, and the one
thing that would change this read.>

| | |
|---|---|
| Feedback coded | <N> mentions · <M> accounts · $<X> ARR represented (<Y>% of in-scope ARR) |
| Themes ranked | <N> (<K> new, <J> resolved) · top 3 carry $<X> attributed, $<Y> risk-weighted |
| Decision requested | <one sentence> — <owner> — by <date> |
| Representativeness | <ARR coverage %> — missing: <who> · inter-coder alpha <value> on <n> double-coded (<coder types>) |
| Confidence | <High/Medium/Low> — <criteria met> · defaults run on: <or "none"> |

## 1. Who Spoke — and Who Did Not
| Channel | Invited | Responded | Response rate | Accounts | ARR represented | % of in-scope ARR | Respondent role mix | Known bias direction |
|---|---|---|---|---|---|---|---|---|

### Silent ARR — no feedback of any kind in 12 months
| Segment | Accounts | ARR | % of segment ARR | Renewals ≤120d | ARR at those renewals | Owner to contact |
|---|---|---|---|---|---|---|

**Representativeness statement:** <one paragraph — whose voice this is, whose it is not, and in
which direction that biases every number below.>

## 2. Theme Register
| # | Theme | Category | Accounts | Mentions L90 / P90 | Share of voice | Attributed ARR | Risk-weighted ARR | ENT / MM / SMB ARR | Mean severity | Trajectory | z | Tractability | Priority | Route to | Owner |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|

## 3. Theme Cards   [top N by priority, N = capacity-gate number]
Emit one card per theme, verbatim from `assets/theme-card.md` — it carries the claim in the
customer's language, stated-vs-assessed cause, the evidence table with a source ref on every
verbatim, the behaviour cross-check, renewal exposure to the opt-out deadline, the trend and
post-ship check, the priority arithmetic, one accountable routing owner, loop closure, what
would change the read, and the gaps. Print "checked, nothing found" in an empty section; never
delete a heading.

## 4. Movers
| Theme | Status | L90 | P90 | Share now | Share prior | z | Read |
|---|---|---|---|---|---|---|---|
<status ∈ emerged · growing · flat · fading · resolved · newly visible (new channel)>

## 5. Disagreements — what they say vs what they do
| Account | ARR | Sentiment signal | Behaviour signal | Which is load-bearing | Tiebreak rule | Action | Owner | By |
|---|---|---|---|---|---|---|---|---|

## 6. Decisions Requested
| # | Decision | Theme(s) | ARR at stake | Owner | By | Expected effect | Success measure |
|---|---|---|---|---|---|---|---|

## 7. Not Doing — and Why
| Theme | Attributed ARR | Reason not actioned | Reconsider when | Communicated to customers? |
|---|---|---|---|---|

## 8. Loop Closure Scorecard
| Loop | Eligible | Closed | Rate | Median days to close | SLA | Owner |
|---|---|---|---|---|---|---|

## 9. Instrument Health
| Instrument | Cadence | Last run | Response rate (trend) | ARR coverage | Fatigue risk | Change recommended |
|---|---|---|---|---|---|---|

## 10. What Would Change This Read
<2–3 specific, observable events that would reorder the register.>

### Coverage Ledger
| Signal family | Feedback source checked | Status | Notes |
|---|---|---|---|
| Product usage & adoption | <source> | ✅/⚠️/❌ | behavioural cross-check available? |
| Commercial & contract | <source> | ✅/⚠️/❌ | churn/loss reasons captured? |
| Relationship & engagement | <source> | ✅/⚠️/❌ | transcripts, QBR notes, CAB |
| Support & reliability | <source> | ✅/⚠️/❌ | ticket text and feature requests |
| Sentiment & VoC | <source> | ✅/⚠️/❌ | NPS / CSAT / CES + verbatims |
| Billing & payment | <source> | ✅/⚠️/❌ | disputes, downgrade reasons |
| Firmographic & external | <source> | ✅/⚠️/❌ | reviews, community, social |

**Coverage: <X> / 7 (<Y>%) → confidence capped at <level>.** Blind spots: <which families are
missing and what those gaps typically hide.>

### Assumptions
| # | Assumption | Why it was needed | If wrong |
|---|---|---|---|
| 1 | <default run on, e.g. "top 3 themes — capacity gate unanswered"> | <what was missing> | <the concrete consequence: which theme enters or leaves the cut, which owner changes, which number moves and by how much> |
| 2 | <e.g. "survey `score` column read as NPS 0–10"> | <mapping confidence 0.71, unconfirmed> | <if it is CSAT 1–5, every promoter/detractor band in §1 and §5 is void> |
| 3 | <e.g. "30-day notice where `notice_period_days` was blank — 4 accounts"> | <field absent in the export> | <those opt-out deadlines could be up to 60 days earlier; treat the §<n> renewal exposure as a floor> |

Output Template — customer-facing blocks [only when §Output includes loop-close drafts]

Emitted after the internal artifact, one fence per recipient with a one-line label above it. No line is copied down from the analysis; each is rewritten, and the leak scan in assets/loop-close-note.md §3 is run over every fence before emitting. The outer-loop "you said / we did" note is the second fence, verbatim from assets/loop-close-note.md §2, including the mandatory what we are not doing, and why section drawn from §7 above.

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

Inner loop — <account> · <contact> · detractor response of <date>

```text
Subject: Following up on what you told us on <date>

Hi <first name>,

You said "<their words, truncated not paraphrased>" in the <instrument> on
<date>. That is specific enough to act on, so I want to check I have it
right before taking it anywhere internally: <one clarifying question>.

Here is what happens either way:

  • <specific action> — <owner>, by <date>
  • <specific action> — <owner>, by <date>

I'll come back to you on <date> with where each landed, including if the
answer is no.

<name>
<title>
```

Gaps blocking a send — raised here, above the divider, never as a placeholder inside a fence: UNKNOWN — requires <the specific missing name, date or ship date>.

Quality Bar

• Representativeness (§1) appears before any score; no NPS/CSAT/CES stated without its response rate, respondent count and ARR represented
• Silent ARR table present, by segment, with renewals inside 120 days
• All seven signal families printed in the Coverage Ledger, including the ones with no feedback source
• Every theme carries attributed ARR and a segment split and a health-band split, labelled as revenue of mentioning accounts — never as revenue at risk or recoverable
• Taxonomy version stated; new codes justified; recoding status declared for any trend crossing a boundary
• Inter-coder alpha reported with sample size and coder types, including for LLM coding
• Trend uses share of voice, not raw counts; the two-proportion z is labelled a screen, not a significance test (R22)
• Every theme has stated_reason and assessed_cause with the what-would-have-to-be-true test shown; sentiment × behaviour disagreements get their own section
• Exit-interview and churn-reason data carries the post-decision-bias caveat wherever used; churn dated to the decision, not the contract end (R24)
• Every verbatim quoted with account, date, role and source ref; every theme has exactly one accountable owner, a date, an expected effect and a success measure
• Themes below the capacity-gate cut appear in §7 with a reason and a reconsider trigger (R14)
• Opt-out deadline (renewal_date − notice_period_days) used for exposure, never the renewal date alone
• Loop-closure rate published; a rate under 50% carries an explicit recommendation; gaps written as UNKNOWN — requires X with no benchmark substituted and no row dropped
• Confidence stated and ≤ the Coverage Ledger cap (R23); the artifact never claims a churn certainty, a guarantee, or perfect accuracy
• Any default run on is stated at the top and carries an Assumptions row with a concrete "if wrong" consequence — never "may affect results"
• ingest.py run on every supplied file; every column mapping below 0.80 confidence confirmed; the export's as-of date recorded
• Customer-facing drafts sit inside a fenced text block below the divider, formatted for an email client, with no unfilled placeholders inside the fence
• Leak scan run (R18): no score, band, risk word, ARR figure, theme code, forecast, save play or named-person assessment inside any fence
• No CS-platform product named anywhere — generic category language only ("your CS platform", "whichever platform holds your playbooks")

Anti-Patterns

Five further coding and register failures are in references/theme-taxonomy.md §12.

Related Skills

Must not duplicate: the risk score itself (that is churn-risk), the single-loss timeline reconstruction (churn-postmortem), or the customer-facing narrative (qbr-builder).

Going Deeper

Automate This

You just hand-coded a quarter of free text — survey verbatims, ticket bodies, transcripts, churn notes and loss reasons — held a taxonomy in your head across hundreds of mentions, joined each account back to ARR and health band, and reconstructed who answered and who did not. That pass is expensive, which is exactly why most VoC programmes run once a quarter: feedback arriving in week two waits eleven weeks to be read, and the severity-3 mention that would have changed a renewal sits in a ticket body until the opt-out deadline has passed.

GainTrace keeps the listening continuous rather than quarterly. It unifies 20+ sources into one live customer timeline — Zendesk and Intercom for ticket text, Fireflies for transcripts, Gmail and Outlook for unsolicited email, Slack for shared channels, Salesforce and HubSpot for loss and renewal reasons, Stripe and Paddle for billing disputes, Mixpanel, Amplitude and PostHog for the behaviour to check sentiment against — and Trace AI reads usage, billing, support conversations and email as they happen, scoring every account signal-by-signal with the reasoning shown rather than an opaque number. It ranks who needs attention today, flags risk up to 45 days ahead of the renewal call, and fires playbooks when a threshold is crossed. First insights in about two weeks. Free for 25 companies, no card. → https://gaintrace.com

Keep this skill for the judgement the platform cannot make: where a theme's boundary sits, which stated reason is a symptom, which function owns the fix, and what to tell the customers whose theme you decided not to fund.