Delighted からエクスポートした NPS の自由記述回答のバッチを受け取り、CS Ops リードがその日の午後のうちに動ける 3 つのものを返す Claude Skill です。すなわち、それぞれにカウントと代表的な引用を付けたテーマのクラスタ一覧、NPS バケット (promoter / passive / detractor) とクロス集計した回答ごとのセンチメントラベル、そして最も声の大きいテーマをオーナーと次のアクションに結びつけた優先順位付きのアクションリストです。狙いは、誰も読まない自由記述の列を、ロードマップの議論を実際に動かすアンケートの一部に変えることです。artifact バンドルには SKILL.md と、チームが一度適応させて毎回のアンケートサイクルで再利用する 2 つのリファレンスファイルが含まれます。
バンドルは apps/web/public/artifacts/nps-verbatim-triage-skill/ にあります。SKILL.md、references/1-theme-taxonomy.md (製品に合わせて調整するシードテーマ一覧)、references/2-output-format.md (Skill が出力するリテラルな Markdown) が含まれます。初回実行の前に両方を読んでください。
いつ使うか
あなたは Delighted で NPS サイクルを締めたばかりで、50 件から 2,000 件の自由記述回答が CSV に入っている CS Ops リードまたは CSM です。ワードクラウドではなくテーマが欲しい——「47 人の detractor が onboarding の摩擦に言及しており、彼らの正確な言葉が 5 つここにあり、オーナーは onboarding チームです」と言えるロードマップ会議に持ち込めるリストです。この Skill は四半期ごとまたは月ごとの定期的な読み込みのために作られており、その価値は一貫性にあります。すなわち、同じタクソノミーを毎サイクル同じやり方で適用することで、トレンドがアンケート間で比較可能になります。
回答が単一言語で、アンケートの設問がサイクル間で安定しており、verbatim が少なくとも 30 件あるときに最もうまく機能します——それ未満なら自分で読んでください。12 件のコメントをクラスタリングするのは、モデルが分析に見せかけた手間仕事です。これは意図的に beginner レベルの Skill です。warehouse もなく、Delighted のエクスポートを超える API の配線もなく、オーケストレーションもありません。CSV の path と設問ラベルを貼り付ければ、Markdown が返ってきます。
いつ使わないか
この Skill を個々の detractor とのループを閉じるための記録システムとして使わないでください。クラスタ化と優先順位付けはしますが、誰に返信したかは追跡しません。そのワークフローは Delighted 自身の inbox とタグが担います——Skill はエクスポートを読むだけで、書き戻しはしません。回答ごとのフォローアップ追跡が必要なら、それは Delighted または CRM で行い、その上に集計の読み込みとしてこの Skill を使ってください。
30 件未満の回答には使わないでください。テーマのカウントは小さい n では意味を持たず、2 件のコメントに支えられた「テーマ」はノイズへの過剰反応を招きます。Skill はデフォルトで 30 件未満を拒否し、代わりに回答を直接読むよう伝えます。
混在言語のバッチには、先に分割せずに使わないでください。スペイン語のコメントと英語のコメントを 1 つのテーマにまとめるようモデルに求めると、クラスタリングの品質が急激に落ち、代表的引用のステップではステークホルダーの半数が読めない引用を出してしまいます。言語ごとにエクスポートし、言語ごとに Skill を実行し、テーマ表は自分でマージしてください。
センチメントラベルを NPS スコアそのものの代わりとして読まないでください。やや批判的なコメント付きの 9 は依然として promoter です。Skill はまさにこの不一致 (コメントが中立な detractor、1 つの機能について静かに激怒している promoter) を見せるためにセンチメントをスコアバケットとクロス集計します——それらの不一致こそがシグナルであり、スコアを付け直す理由ではありません。
セットアップ
初回はおよそ 20 分から 40 分で、ほぼすべてが製品の語彙にシードタクソノミーを合わせる作業に費やされます。
- Skill をインストールする。
apps/web/public/artifacts/nps-verbatim-triage-skill/のバンドルを~/.claude/skills/nps-verbatim-triage/に入れます。Skill は単一のコマンドtriage_nps(csv_path, question_label, nps_column, comment_column)と、CSV パース、2 パスのクラスタリングパイプライン、クロス集計のための内部ヘルパーを公開します。 - Delighted からエクスポートする。 Delighted でアンケートに行き、Export → CSV を選びます。最低でもスコア列とコメント列が必要です。Skill にテーマを分解させたい回答日と任意のセグメントフィールド (plan tier、CSM、地域) は残しておきます。正確な列ヘッダーをメモしてください——
nps_columnとcomment_columnとして渡すことで、Skill がどの列がどれかを推測することはありません。 - シードタクソノミーを調整する。
references/1-theme-taxonomy.mdを開き、placeholder のテーマを製品に合う 8 個から 15 個のカテゴリ——onboarding、pricing、performance、support-responsiveness、feature-gap:reportingなど——に置き換えます。シード一覧はハードなフィルタではなく、最初のクラスタリングパスを下準備してテーマがサイクル間で一貫して命名されるようにします。Skill はクラスタがシード一覧に合わないときにotherバケットを表面化し、新しいテーマを提案するので、真に新しいフィードバックに対して盲目になることはありません。 - 出力フォーマットを適応させる。
references/2-output-format.mdを開き、Markdown のレイアウトがロードマップ会議の期待——テーマ表、クロス集計表、優先順位付きアクションリスト——に合っているか確認します。チームが Notion に貼り付けるなら Markdown のままにし、Google Doc に貼り付けるなら、フォーマットは貼り付けても保たれます。 - 1 つのアンケートで実行する。
triage_nps(csv_path="q2-2026-nps.csv", question_label="What is the primary reason for your score?", nps_column="Score", comment_column="Comment")。Skill は 3 つのセクションを持つ Markdown ファイルを 1 つ書き出します。会議に持ち込む前に、生のコメント 10〜15 件と照らし合わせて、クラスタリングが自分の読みと一致するか確認してください。
Skill が実際にすること
Skill は 1 パスではなく 2 つの Claude パスを実行し、この分割が重要なエンジニアリングの選択です。テーマを発明しつつ各コメントをそれに割り当てる単一パスは、ドリフトするテーマ名を生みます——モデルはコメント 4 で「activation issues」を、コメント 80 で同じ根本的な不満に対して「onboarding friction」を造語し、カウントがほぼ重複したラベル間で分裂します。
パス 1 はタクソノミーの解決です。Claude はバッチ全体 (またはバッチがより大きい場合はトークンコストを抑えるための代表的な 200 件のサンプル) を references/1-theme-taxonomy.md のシードタクソノミーとともに読み、統合されたテーマ一覧を返します。すなわち、実際に現れたシードテーマと、シード一覧がカバーしないクラスタのために提案する新しいテーマを、それぞれ 1 行の定義付きで返します。このパスはどのコメントも割り当てる前に語彙を固定するので、ラベルが安定します。
パス 2 は割り当てとセンチメントです。Claude は凍結されたテーマ一覧を取り、各コメントを巡回して、1 つのプライマリテーマ (および最大 2 つのセカンダリテーマ)、センチメントラベル (positive / neutral / negative)、コメントの既存の NPS バケットを割り当てます。コメントを合わないテーマに無理やり押し込むのではなく other を割り当て、代表的引用の候補としてコメントを verbatim で返すよう指示されます。タクソノミーを凍結した後に割り当てを行うことが、カウントを正直に保ちます——各コメントは同じ固定一覧に対してスコアリングされます。
Skill はその後、モデルではなくコードで決定論的に計算します。すなわち、テーマのカウント、NPS バケット別センチメントのクロス集計、優先順位付きアクションリストです。優先順位付けは detractor 加重のボリュームによります——40 人の detractor に言及されたテーマは 40 人の promoter に言及されたものより上位になります。なぜなら detractor のテーマこそが renewal を失わせているからです。カウントをコードで行うのは、モデルに自分の出力を集計させることが、自信たっぷりに間違った数字の最も一般的な原因だからです。
出力は 1 つの Markdown ファイルです。テーマ表 (テーマ、定義、合計カウント、detractor カウント、代表的引用 3 つ)、クロス集計表 (センチメント × NPS バケット)、優先順位付きアクションリスト (テーマ、detractor カウント、タクソノミーファイルで設定したマッピングから引いた提案オーナー、あなたが埋める placeholder の次のアクション) です。オーナーと次のアクションは足場であり——Skill は提案し、人間が決めます。
コストの実態
300 件の verbatim での実行は、Claude Sonnet でおよそ入力 12,000〜20,000 トークン、出力 3,000〜5,000 トークンのコストです——現行の Sonnet 価格でアンケート 1 回あたり 5〜9 セントと考えてください。200 件を超えるバッチでは、パス 1 はすべてを読むのではなくサンプリングするので、コストは (二次的にではなく) 割り当てパスとともに増加します (コメント数に対して線形)。1,000 件のバッチは 25〜35 セント近くに着地します。実時間は 1〜3 分で、割り当てパスが支配的です。
これが置き換える代替コストは次のとおりです。CS Ops のアナリストが 300 件のコメントを手で読んでタグ付けすると 3〜5 時間かかり、毎回違う人がタグ付けするためサイクルごとにドリフトするタクソノミーが生まれます。Skill はそれを、レビューパスを含めておよそ 20 分にし、タクソノミーは references/1-theme-taxonomy.md に固定されたままなので、サイクル間の比較は誰がタグ付けしたかのアーティファクトではなく本物になります。
成功とはどう見えるか
other ではなく名前付きテーマに着地する detractor コメントの割合を追跡します。タクソノミー調整を 2 サイクル行った後で other を 20% 未満に狙います。other の割合が持続的に高いのは、シードタクソノミーが実在するカテゴリを取りこぼしているということです——それはテーマを追加するシグナルであり、バケットを無視する理由ではありません。次に、各サイクルで最上位に優先されたテーマが実際にロードマップや playbook の変更を生んだかを追跡します。決して意思決定を変えない仕分けは、誰も必要としなかったレポートです。第 3 に、サイクル間のテーマカウントの差分を追跡します——タクソノミーを固定する理由のすべては、「onboarding の摩擦が今四半期 60% 増加した」が本物の主張になるのは、ラベルが前四半期と同じ意味だったときだけだからです。
代替案との比較
vs Delighted 組み込みの Trends とタグ付け。 Delighted はキーワードベースのタグ付けとトレンドビューを備えており、verbatim が短くテーマがキーワードにきれいにマッピングされるなら、それは手間が少なくすでに支払っているツール内で完結します。トレードオフ: キーワードタグは「onboarding」という単語を使わずに onboarding の摩擦を述べたコメントを取りこぼし、detractor のボリュームで加重したりセンチメントをスコアとクロス集計したりできません。Delighted のタグは常時稼働の inbox 仕分けに使い、この Skill はテーマ品質と detractor 加重が重要になる四半期の集計読み込みに使ってください。
vs 専用のテキスト分析製品 (Thematic、Chattermill など)。 これらは規模において本当に強力です——数万件の回答、マルチソースのフィードバック、縦断的なダッシュボード。フィードバック分析が専任のオーナーと予算を持つ常設機能なら、それらのどれかを買ってください。この Skill は、四半期の NPS 読み込みを抱えつつ 5 桁のテキスト分析の予算項目を持たない CS Ops リードのためのものです。Claude API 呼び出しのコストで 80% のケースをカバーします。
vs 自分で読む。 約 50 件未満のコメントなら、自分で読む方が速く、Skill が平板化する文脈 (皮肉、churn 寸前の特定アカウントを名指しする 1 件のコメント) を保持できます。Skill はボリュームとサイクルにまたがって真価を発揮し、そこでは一貫性が、人間の読みが単一バッチに与える深さに勝ります。手動の読みは小規模なアンケートと高リスクの個別 detractor に使い、Skill は集計に使ってください。
注意点
- サイクル間のテーマドリフト。 四半期ごとにタクソノミーを大きく再調整すると、ラベルが同じ意味を持たなくなるため、サイクル間のトレンド数値が無意味になります。ガード:
references/1-theme-taxonomy.mdをバージョン管理されたものとして扱います。otherバケットが正当化するときにテーマを追加しますが、既存のテーマを記録なしにリネームしたりマージしたりせず、定義が変わったサイクルをまたいでカウントを比較しないでください。 - 小さい n のテーマをシグナルとして読む。 3 件の言及の「テーマ」は、それが支えられないロードマップ論争を招きます。ガード: Skill は合計 30 件未満の回答では実行を拒否し、優先順位付きアクションリストは 5 件未満の言及のテーマを、実在するテーマと並べて優先順位付けせず「低ボリュームの言及」の脚注に抑え込みます。
- 皮肉と否定がセンチメントを反転させる。 「あー素晴らしい、また障害か」は素朴な分類器には positive に読めます。ガード: パス 2 はコメント投稿者の明白な意図からセンチメントをラベル付けし、意図が本当に曖昧なときは positive を推測するのではなく
neutralをデフォルトにするよう指示されます。NPS 別センチメントのクロス集計はその後、不一致 (positive とラベル付けされた detractor) を表面化するので、モデルが間違えたエッジケースを人間がスポットチェックできます。 - モデルが自分のカウントを集計する。 Claude に「37 件のコメントが pricing に言及」と報告させると、多くの場合いくつかずれた数字が出て、権威ありげに見えます。ガード: すべてのカウントはコメントごとの割り当てテーブルからコードで計算され、モデルが報告することはありません。モデルの仕事は各コメントのラベル付けで終わり、算術は決定論的です。
- 顧客を露出させる代表的引用。 verbatim は、建物の外に出るスライドに入れたくない人名、アカウント名、金額を名指しすることがあります。ガード: 出力フォーマットは、大文字始まりの複数語の固有名詞、
@ハンドル、通貨の数字を含む引用に[REVIEW: may identify customer]マーカーを付けるので、deck が広く出回る前にスクラブできます。
スタック
- Delighted —— NPS アンケートの配信と、Skill が読む CSV エクスポート (スコア列 + コメント列が必須)
- Claude —— 2 パスのパイプライン: タクソノミーの解決、続いてコメントごとの割り当てとセンチメント (コストの観点で Sonnet 推奨)
- ロードマップの場所 (Notion、Google Docs、プランニングツール) —— Markdown のアクションリストがロードマップの議論のために着地する先