map-contacts

手順

セットアップの状態。 この組織ではまだ設定されていません。Setup サブページを読み込み、ペルソナモデル（購買委員会の構成）が定義されていることを確認し、マッピングを始める前に利用可能な関係履歴データソース（CRM、メール送信者、Fireflies、LinkedIn、見込み顧客検索）を特定してください。（セットアップ後は、swan-update-skill を使ってこの段落を書き換え、現在の状態（ペルソナモデルの読み込み状況、5つのデータソースのうち利用可能なもの、最終更新日）を記述してください。これにより、以降の実行時に再確認しなくても現在の設定を把握できます。）

ステップ 1 — 対象アカウントと目的を確認する

会社のドメインまたは名前を確認します。目的を一行で確認します。新規 ABM マッピング、更新準備、チャンピオンの追跡、または単一の担当者だけで進行している商談の拡大です。目的に応じて優先順位が少し変わります（更新では現行ユーザーと経済的な意思決定者を重視し、チャンピオンの追跡では、転職した過去のコンタクトを重視します）。

ステップ 2 — ペルソナモデルを取得する

組織で定義されたペルソナを読み込みます。マップのスキーマとして、名前が付けられた役割、その役職名の別名、JTBD を保持します。ペルソナを独自に作成しないでください。マップは組織が保存した情報に基づきます。

ステップ 3 — 既知の関係を最初に調べる（最も有力なシグナル）

組織がすでに持つデータを優先します。各データソースは接続されている場合に確認し、接続されていない場合はスキップしてその旨を記録します。

• CRM。 対象アカウントの企業／コンタクト／商談を検索します。役割、最終アクティビティ、担当者、ステータス（在籍中、退職、休眠）を含む、名前が特定できるすべてのコンタクトを記録します。
• 送信済みメール。 接続されている各送信者について、対象アカウントのドメインを送信済みアイテムから検索します。メールを送ったことのあるすべての相手、最終接触日、スレッドのトピックを一行で記録します。
• ミーティングの文字起こし。 FIREFLIES_GET_TRANSCRIPTS を使い、アカウントと一致する参加者のメールドメインで絞り込みます。参加者、日時、話し合った内容を記録します。
• 過去のシーケンス。 swan-search-sequences を使い、対象アカウントで絞り込みます。誰に連絡したか、誰から返信があったか、誰が予約したかを記録します。

先に進む前に、人ごとに集約します。4つのソースすべてに登場する場合でも、一人につき一行にします。

ステップ 4 — 転職した人を見つける（多くのスキルが見落とす重要なポイント）

CRM とメールにある過去のコンタクトのうち、対象アカウントに在籍していない人については、現在の勤務先を確認します。失注した商談のチャンピオンが新たな対象アカウントに移っている場合、その人は今四半期に連絡すべき最も有力な相手です。対象アカウントの現行コンタクトについては、最近入社したかどうかを確認します。新しい役職に就いた人に、他社での過去の関係履歴があれば、これまで存在しなかった温かい接点になります。

既知の LinkedIn URL には swan-linkedin-social-media-presence を使って現在の勤務先を確認します。swan-enrich-contact を使うのは、ユーザーが特定の人物にアクションを起こそうとしている場合に限ります。クレジットは重要です。

ステップ 5 — 新規見込み顧客の検索で不足を補う

既知の関係データをすべて確認した後、マップで不足しているペルソナの役割について swan-search-employees を実行します。新規コンタクトもマップに加えますが、「関係履歴なし」と明示してください。温かい接点とは意味合いが異なるため、次のアクションにもその違いを反映させます。

ステップ 6 — 構造化されたマップを作成する

ペルソナごとに簡潔なセクション（または単一の表）にまとめます。各ペルソナの役割（チャンピオン／経済的な意思決定者／技術評価者／エンドユーザー／反対者）について、名前が特定できる各人物の氏名、役職、現在の勤務先（対象アカウントと異なる場合は明記）、関係の強さ（コールド／X経由で温かい／元Xの現在の勤務先／関係履歴のある現行コンタクト／新規）、最終接触（日時＋チャネル＋相手）、推奨する次のアクションを記載します。

役割の不足（候補者がいない、またはカバーが弱いペルソナ）はマップの最初に明記し、最後に埋もれさせないでください。

名前の羅列にしないでください。マップの価値は人数ではなく、一人ひとりの関係性に関するシグナルにあります。

ステップ 7 — 引き継ぐ

次のアクションを、わかりやすい動詞で提案します。最初に誰に連絡するか（温かい接点を優先）、見込み顧客のさらなる調査でどの不足を補うか、今週どの転職者向け施策を実行するかを、一段落でまとめます。

良い状態とは

• 組織のモデルに含まれるすべてのペルソナの役割に、少なくとも1人の名前付き候補者、または明示的な不足フラグがあります。何も示されないまま欠けていることはありません。
• マップでは、「過去のやり取りがある現在のコンタクト」／「アカウントに在籍している元コンタクト」／「転職した元コンタクト」／「履歴のない新規候補者」を区別します。次に取るべき行動への影響はそれぞれ大きく異なるため、ひと目で分かる形式にします。
• 過去の関係性は、新規見込み客の行よりも前面に表示し、埋もれないようにします。意思決定者探しにとどまらないことが、このスキルの目的です。
• 名前の一覧だけでなく、ペルソナごとに次の行動を提案します。読み手が、もう一度見直さなくても行動を決められるようにします。
• 失注案件のチャンピオンが現在ターゲットアカウントに在籍している場合、最優先のアウトリーチ先として表示されます。表示されない場合、このスキルは検出すべき最も価値の高いシグナルを見落としています。

見落とされがちな点：温度感の高いコンタクトと低いコンタクトを同じように扱うこと、他社に移った元コンタクト（最もシグナルの強いフック）を無視すること、関係性が一切ないことを明示せずに新規見込み客を列挙すること、見つかった情報だけをマップに表示して役割の不足を見逃すこと。

ルール

• 組織で定義されたペルソナモデルを必ず使用します。このスキル独自のペルソナを作成してはいけません。
• 新規候補者の見込み客検索を行う前に、関係性が分かる既知の情報源（CRM、送信済みメール、トランスクリプト、過去のシーケンス）を必ず検索します。
• 各人の関係履歴（強さ、最終接点、担当者）を、脚注ではなく主要な列として必ず表示します。
• 他社に移った元コンタクトの候補者には、必ず明示的なフラグを付けます。通常、これらはマップ全体で最もシグナルの強いフックです。
• 候補者がいない、またはカバー範囲が不十分なペルソナについては、役割の不足として必ずマップの最上部に表示します。
• 新規候補者をすべてエンリッチしてはいけません。ユーザーがすぐに行動を起こそうとしている候補者に限ってエンリッチします。
• ペルソナモデルを置き換えたり、上書きしたりしてはいけません。組織に保存されている購買委員会をスキーマとして使用します。
• 元コンタクトが現在そのアカウントで働いていないからといって、除外してはいけません。このスキルが存在する理由は、まさにそのようなコンタクトにあります。

このスキルに追加予定の個別用途ページ

組織のマッピングの進め方に合わせて、随時追加します。

• RenewalPrep — 更新が近い案件のマッピングです。現行ユーザーと経済的購買者をより重視し、委員会内の解約リスク（チャンピオンの退職、経済的購買者の変更、ユーザー基盤の縮小）を明らかにします。
• ChampionTracker — 既知のチャンピオンが転職したときに追跡します。LinkedInで勤務先の変更を監視し、転職が反映された時点で新しいアカウントを新たなターゲットとして提示します。
• MultiThreadExpansion — 単一の窓口だけで進んでいる既存案件のマップを拡張します。現在のマップとペルソナモデルを比較し、温かい接点がある場合は、それを活用した具体的な複数窓口への拡張候補を提案します。