reply-audit

返信監査

LinkedIn とコールドメールを運用するB2Bサービス代理店のクライアント向けに、アウトバウンド返信を分析します。 クライアントは定期的に返信の一括データを提供し、会話で実際に何が起きているのか、なぜ商談が失注するのか、今週何を改善すべきかについて、詳細な監査を求めています。

監査はクライアントの業務言語で作成し、固有名詞、指標名、分類タグ、引用された返信は英語のままにします。

---

Step 0 — データを取得する（入力形式は問いません）

提供された情報からデータソースを特定し、取得してください。形式の変換を依頼してはいけません。

データソース	取り込み方法
Google Sheet / Docs のリンク	URL のファイル ID を使い、Drive 連携経由でファイルを読み取る
CSV / .xlsx ファイルパス	ファイルを直接読み取る
Notion ページ／テーブルの URL	ページを取得する
アウトリーチプラットフォームのキャンペーン（LinkedIn 自動化／コールドメールツール）	そのプラットフォームの MCP を使って会話／返信を取得する
貼り付けられたテキスト	そのまま解析する

シートにキャンペーン指標のブロックと返信ごとの行の両方が含まれている場合は、両方を取得してください。指標ブロックは§1（ファネル）に、返信の行は§3（分類）に使用します。

分析を始める前に、読み込んだ内容（データソース＋返信数＋チャネル）を1行で確認してください。

---

Step 1 — すべての返信を分類する

各返信に、互いに独立した3つの軸でタグを付けてください。これらを1つの列にまとめないでください。このスキルで解決するべき、トラッカーにおける最大の誤りです。

A. 返信の感情 — リードの状態（どのように返信したか）

タグ	判断材料
HIGH_INTEREST / INTERESTED	電話／ミーティングに同意する、状況を共有する、質問を返す、3文を超える
WANTS_PROOF	「サンプル／事例／料金を送って」— 前向きな「見せてください」
WARM_NEUTRAL	丁寧な1～5語の確認（「はい、対応しています」「いいですね」）— 本当の関心ではない
CURIOUS_PROBING	逆質問、「もっと詳しく教えて」、「どのドメインですか」、正当な相手かを確認している
OBJECTION_REFRAMEABLE	乗り越えられる異議（切り口が合っていない、「別の担当者が対応している」、「当社の地域ではない」）
INCUMBENT	「信頼できるパートナーがいる／ベンダーを利用している／長期契約がある」
DEFENSIVE	「どうやって私の連絡先を入手したのか」、「どちら様ですか」
SOFT_NO / SOFT_PUSHBACK	「タイミングが悪い」、「今は無理」、「考えさせてください」、「後日また連絡してください」
HARD_NO / HARD_PUSHBACK	「興味がない」、「連絡をやめて」、「Xを利用しています」
DEAD_DATA	「もうこの会社にいない」、「担当者が違う」、すでにクライアント／リードである

B. 異議の種類 — 理由（集計用）

ピボット集計で傾向がわかるよう、標準化されたタグを使用してください。名前はクライアントに合わせて調整できますが、説明文ではなく、個別のドロップダウン形式のタグとして維持してください。例： WRONG_GEO、WRONG_ICP、WRONG_PERSON、VALUE_CHAIN_MISMATCH、INCUMBENT_LOCKED、 TIMING、STALE_DATA、ALREADY_IN_FUNNEL、PHILOSOPHY_MISMATCH、NO_BUDGET。

C. 事後分析タグ — SDR のミス（幽霊化／失注した会話のみ）

会話が終了した後に、担当者が何を間違えたのかを設定します。責任追及ではなく、コーチングに使用します。 PITCH_DUMP_EARLY（ヒアリングなしに2通目で提案した）、IGNORED_LEAD_QUESTION、 ASSUMPTION_BEFORE_QUALIFY、CALL_PUSH_TOO_EARLY、WRONG_FRAME_VS_PHILOSOPHY、 COMPETITOR_REPLACE_FRAMING、NAME_TYPO、WRONG_LEAD_COPY_PASTE、REPEATED_OWN_QUESTION、 BOUNDARY_VIOLATION、COLD_BOUNDARY_ANSWER、NO_ERROR_EXTERNAL_DQ（担当者に落ち度なし）。

ステップ 2 — 根本原因を診断する（最も重要な判断）

2 つのアウトバウンド施策は、それぞれ正反対の理由で失敗しています。今回のバッチがどちらの状況を示しているのかを判断してください。どのセクションを重視するかが変わります。

• ターゲティング／データ主導の失敗： 返信の大部分が DEAD_DATA + WRONG_ICP + WRONG_GEO + ALREADY_IN_FUNNEL です。「ノイズと機会」の割合を算出してください。返信の約 40% 以上が、そもそもアプローチ可能な見込み客ではない場合、問題はコピーではなくリストにあります。上流から修正してください。データの鮮度と検証、地域および ICP のフィルター、リストのソースを見直します。SDR の返信内容自体は、実際には問題ない可能性があります。
• ピッチ／SDR 主導の失敗： 見込み客は好意的に返信した後、連絡が途絶えています。Post-Mortem タグ（PITCH_DUMP_EARLY、CALL_PUSH_TOO_EARLY、ASSUMPTION_BEFORE_QUALIFY）が大半を占めています。アポイント率（好意的な返信 → ミーティング、標準値は 25～35%）と、SDR のミスによるゴースト化率を算出してください。シーケンスを修正します。提案の前にニーズを掘り下げ、リードマグネットや控えめな CTA を活用し、セグメント別の再エンゲージメント施策を実施します。

ほとんどのバッチは、主にどちらか一方に当てはまります。TL;DR では、割合の根拠を示して、どちらなのかを明記してください。

また、指標がある場合は、必ずチャネル／切り口ごとのファネル分析も行ってください。成果を出している施策と、機能していない施策を特定します（例：つながりのある 1 次コンタクトへの個人的なフックを使った切り口が返信の大半とすべてのミーティングを生む一方、一般的なコールド招待はほとんど成果を上げていない）。予算をどこに移すべきか、クライアントに伝えてください。

---

ステップ 3 — データから最高品質のテンプレートを抽出する

批判するだけでなく、担当者自身の最良の返信を掘り起こしてください。繰り返し出てくる異議ごとに、データ内にある最も効果的な切り返しを 1 つ見つけ、再利用可能なテンプレートとしてそのまま抜き出します（例：第三者ではなく、見込み客自身の予算に問題のコストを結び付ける切り返し）。これを異議対応プレイブックにまとめます。各テンプレートを対応する異議タグに関連付け、強化につながる根拠や導入事例も記載してください。

---

ステップ 4 — 監査レポートを作成する

デフォルトの出力は、単独のページです（例：notion-create-pages を使用）。タイトルの形式：

<Client> — <Channel> Replies/Positive Responses Audit (<Period>) — アイコン 📊

その後、同じ TL;DR と主な調査結果をページへのリンクとともに、チャットの要約として投稿してください。

ページ構成（9セクション。根本原因に応じて重点を調整）

1. ヘッダー — ソース、チャネル、クライアント、期間、分析日。
2. TL;DR — 5～7個の箇条書き：ベンチマークに対するアポイント率／関心率、ノイズ率またはゴースト率、根拠を添えた最大の問題（ターゲティングかピッチか）、機能している点、今週取り組むこと。
3. ファネル（指標がある場合）— キャンペーン／チャネルの表と、機能しているエンジンか、機能していないエンジンかの判定。
4. トラッカーの構造 — 現在のトラッカーで混在している情報／不足している情報、追加すべき具体的なフィールド（三軸分類＋Next Action / Next Action Date / Meeting Outcome / Data Fresh? / Geo / Role）。
5. 返信の分類 — カテゴリ × 件数 × % × 該当するリードの例（実名）の表。
6. 主な構造的問題 — 根本原因の順に3～5項目。それぞれに問題が生じる仕組みと修正策を記載します。
7. 反論対応ガイド／セグメント別の戦術 — ゴールドスタンダードとなる切り返し（Step 3から）＋セグメント別の次のアクション（ホット → 迅速に成約、ソフトノー → 再アプローチか育成、ノイズ → リストの修正／配信停止）。
8. 分類体系 — Reply Sentiment + Objection Type（ピッチが原因の場合は Post-Mortem Tag も追加）。今回のバッチに対応する件数を示し、現在の単一テキストフィールドより優れている理由を一文で説明します。
9. アクションプラン（今週） — 効果の高い順に並べた、具体的なチェックリスト。 末尾に短い 未解決の質問 ブロックを追加します。
10. リードごとの送信可能な返信（必ず含める） — セグメント別の戦術だけでは不十分です。クライアントが必要としているのは、実名が挙がった各リードへの実際の次のメッセージです。各リードについて、次の形式のブロックを出力します。 **名前**（会社）・ + 反論／センチメントタグ + → 一行の理由。その後、引用ブロックに送信可能なメッセージ本文を記載します。メッセージはリード本人の言語（米国のリードなら通常は英語）で、SDRの口調にし、そのリードの実際の返信に即した内容にしてください。
    • 強い拒否／配信停止の場合は DROP（メッセージなし）を使用し、すべてのキャンペーンから除外するよう記載します。
    • STALE_DATA / WRONG_* の場合は、ピッチではなく、紹介依頼または再接続を目的とするメッセージを1つだけ作成します。
    • 送信者をまたぐ重複には「⚠️ DUP — 1通だけ作成し、送信者は1人にする」とフラグを付けます。
    • 誤分類されたリード（例：「ICPではない」とされているが、実際には関心が高いリード）を見つけ、タグを付け直します。
    • 最後に、ホットで成約を目指すリード、配信停止にする相手、除外する相手の数を一行でまとめます。

スタイルルール

• 正直に判定し、冗長な記述は避けます。数値、原因、修正策の順に記載します。
• クライアントがすぐ行動できるよう、リードには実名と会社名を添えます。
• 標準化されたタグは必ず独立した項目（ドロップダウン形式）とし、文章で記述しません。これが標準化の目的です。
• 直接的で、データを重視した口調にします。

---

注意事項

• クライアントがチャットのみの出力や別の深さを明示的に希望した場合は、その意向を尊重します。ただし、デフォルトではページ全体の監査を行います。
• バッチが少数（返信が約10件未満）の場合も、すべての軸を確認しますが、§3～§8は簡潔にまとめます。サンプル数が少ないことも明記します。
• 成果物はこのページです。