sales-account-map について
sales-account-mapは、営業担当者がターゲット企業の購買委員会、各メンバーの役割、関係性を整理するスキルです。Apollo.ioなどの連絡先データを参照し、企業規模に応じた調査と複数経路でのアプローチを案内します。
主な機能
- 01購買委員会の役割を特定
- 02企業規模に応じた委員会人数の推定
- 03データプラットフォームで連絡先を検索・補完
- 04関係性と接点戦略の整理
- 05複数経路での役割別アプローチ計画
活用シーン
- 01ターゲット企業の意思決定者リスト作成
- 02単一の連絡先から複数部門・階層へ展開
- 03停滞した商談で不足する関係者を特定
- 04委員会メンバー別の連絡方法を計画
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ sales-skills/ sales --skill sales-account-mapインストール後、Claude Code で/sales-account-mapを入力して読み込まれたか確認します。
同梱ファイルreferences/learnings.mdreferences/platforms.md
詳細
購買委員会を把握する
ターゲットアカウントの購買委員会全体を把握できるよう、ユーザーを支援します。購入決定に関わる人、各人の役割、アカウント内で効果的に複数の関係を築く方法を特定します。このスキルは特定のプラットフォームに依存しませんが、連絡先の検索と情報拡充のための主要なデータソースとしてApollo.ioを参照します。同じアプローチは、ZoomInfo、Cognism、LinkedIn Sales Navigator、その他の連絡先データベースでも利用できます。
ステップ 1 — 背景情報を集める
references/learnings.md が存在する場合は、蓄積された知識を得るため、最初に読みます。
ユーザーに次のことを尋ねます。
-
ターゲットにしているアカウントはどこですか?(会社名、規模、業界)
-
何を販売していますか?
- 製品/サービスのカテゴリ
- おおよその取引規模(委員会の規模と複雑さに影響します)
- 主にどの部門に影響しますか?
-
現在、どの段階にいますか?
- A)見込み客の開拓 — まだ誰ともやり取りしていない
- B)単一の関係のみ — 1人と話しており、関係者を増やす必要がある
- C)進行中の商談 — 何人かの連絡先はいるが、委員会全体を把握する必要がある
- D)停滞中の商談 — 不足しているステークホルダーを見つける必要がある
-
現時点で何がわかっていますか?
- アカウント内に既存の連絡先はいますか?
- 組織図に関する情報(報告体制、チーム規模)はありますか?
- 購買プロセスに関する情報はありますか?
-
会社の規模はどれくらいですか?(委員会の複雑さを判断します)
- A)SMB(従業員 1~200 人)— 意思決定者は 1~3 人を想定
- B)中堅企業(従業員 200~2,000 人)— ステークホルダーは 3~6 人を想定
- C)エンタープライズ(従業員 2,000 人以上)— ステークホルダーは 5~12 人以上を想定
ユーザーのリクエストに背景情報の大部分がすでに含まれている場合は、該当するステップに直接進んでください。 妥当な前提を明示したうえで、最善を尽くした回答から始め、最後に最も重要な確認事項を 1~2 点だけ尋ねます。必要な情報がすべて揃うまで回答を保留しないでください。
ステップ 2 — 委員会の役割を特定する
次の枠組みを使って、想定される役割を整理します。
購買委員会の役割
| 役割 | 担当すること | 特定方法 | 典型的な役職 |
|---|---|---|---|
| 経済的決裁者 | 予算を承認し、契約に署名する | 購買部門で最も上位の人物。多くの場合、VP 以上または C-suite | 販売するものに応じた VP/SVP/CRO/CFO/CTO |
| 推進者 | 自社製品の導入を望み、社内で支持を広げる | 解決する課題を抱え、会話に積極的に参加し、社内共有用の資料を求める | 課題を担当するディレクター/シニアマネージャー |
| 技術評価者 | 製品を技術面から評価する | 詳細な技術的質問をし、POC を実施し、統合を担当する | アーキテクト、スタッフエンジニア、IT マネージャー、ソリューションチーム |
| 利用者側の購買担当者 | 製品を日常的に利用する | ワークフロー、UX、日々の業務への影響を重視する | 個人貢献者、チームリーダー、エンドユーザー |
| 協力者 | 社内の力関係やプロセスに関する情報を提供する | 通常、すでに関係を築いている相手。購買権限がない場合もある | 役職は問わない。以前の顧客、共通の知人、好意的な連絡先など |
| 門番/阻害者 | 商談を遅らせたり、破談にしたりする可能性がある | 競合する予算を持つ、競合他社を支持する、または政治的な理由で反対する | 調達、法務、IT セキュリティ、または現状維持を望む推進者の同僚 |
会社規模に応じた委員会の規模
| 会社の規模 | 把握する役割 | 見つける連絡先 |
|---|---|---|
| SMB(従業員 1~200 人) | 経済的決裁者+推進者(同一人物の場合も多い)、場合によっては技術評価者 1 人 | 連絡先 2~3 件 |
| 中堅企業(従業員 200~2,000 人) | 経済的決裁者、推進者、技術評価者、利用者側の購買担当者 1~2 人 | 連絡先 4~6 件 |
| エンタープライズ(従業員 2,000 人以上) | 6 つすべての役割。役割ごとに複数人がいる場合もある(委員会は 8~12 人以上) | 連絡先 6~12 件 |
ステップ 3 — 関係者を見つける
ツール固有の検索フィルター(Apollo People Search、ZoomInfo Org Charts)については、**references/platforms.md を読み、**ユーザーが利用するデータツールのセクションを参照してください。
データから組織構造を読み解く
Apollo(およびほとんどのデータプロバイダー)は、報告ラインを直接表示しません。次の方法で組織図を再構築します。
- 役職レベルのマッピング:連絡先を役職レベル別にまとめます(C-suite → VP → Director → Manager → IC)
- 部門ごとの分類:部門別にまとめて、チーム構成を把握します
- 役職名の分析:「Head of」(通常はVP/C-suiteに報告)、「Senior Director」(VPに報告)などに注目します
- チーム規模の推測:ある部門にDirectorが3人、VPが1人いる場合、そのVPが全員を統括している可能性が高いです
「隠れた」影響力を持つ人物を見つける
取引で最も重要な人物は、役職名からはすぐに分からないことがよくあります。
- 実際の技術的な意思決定者であるIC:Staff/Principal EngineerやDistinguished Architectを探します。役職名に「manager」が含まれていなくても、その人物の推薦は上司より重視されることがあります
- 経営幹部の予定を管理する管理担当者/EA:エンタープライズ案件では、Economic Buyerへのアクセスを誰が管理しているかを把握することが重要です
- 最近昇進した人:Directorになったばかりの人は、10年間VPを務めている人より新しいアプローチを受け入れやすい可能性があります
連絡先情報を充実させる
特定した各委員会メンバーについて、次の情報を取得します。
- 確認済みのメールアドレス
- 直通電話番号(少なくともEconomic BuyerとChampionについて)
- LinkedInプロフィールのURL
- 現職の在任期間(現在の役職に就いてからの期間。新任のリーダーは変化を受け入れやすい傾向があります)
- 過去に勤務した会社(接点がないか確認します。以前に自社の製品を利用していたでしょうか?)
ZoomInfo固有の情報拡充機能(Org Charts、Scoops、Engage、Search Contacts API)については、references/platforms.mdを参照してください。
ステップ4 — 関係性とアプローチ戦略をマッピングする
組織図の再構築
アカウントの全体像を頭の中で視覚化します。
[Economic Buyer]
/ \
[Champion] [Potential Blocker]
/ \ |
[Tech Evaluator] [User Buyer] [Their Champion]
アプローチの糸口を選ぶ
| 状況 | 推奨するアプローチ | 理由 |
|---|---|---|
| 既存の連絡先がいない | ChampionまたはCoach | 課題を抱えているため、社内で推進してくれます。背景情報なしにいきなりC-suiteにアプローチしても、たいてい失敗します。 |
| 連絡先が1人いる | 上層または他部門への紹介を依頼する | 紹介経由のアプローチは、コールドアウトリーチより5~10倍高い成約率です |
| 進行中の案件が1人の担当者に依存している | Technical EvaluatorまたはUser Buyer | 上層に進む前に横方向へ広げ、まず合意を築きます |
| 案件が停滞している | Coach(情報収集)またはEconomic Buyer(直接エスカレーション) | エスカレーションする前に、何が障害になっているのかを確認します |
複数の担当者と関係を築く戦略
目標:意思決定が行われる前に、組織内の異なる階層にいる3人以上の連絡先と関係を築きます。担当者が1人だけの案件の成約率は、複数の担当者と関係を築いた案件の3分の1です。
**「パワーライン」と「アクセスライン」**のアプローチ:
- パワーライン(トップダウン):Economic Buyerから始め、下位の担当者を紹介してもらいます。経営幹部との関係や強いブランド認知がある場合に有効です。
- アクセスライン(ボトムアップ):ChampionまたはUser Buyerから始め、合意を築いてから上層の担当者を紹介してもらいます。ほとんどの営業チームに適しています。
- デュアルトラック:両方の階層に同時にアプローチします。Championが社内での導入理由を組み立てる一方で、Economic Buyerにも直接働きかけます。中堅企業やエンタープライズに最も効果的です。
アプローチの順序
- 最初の連絡先:ChampionまたはCoach — 課題が実在することを確認し、社内の背景情報を得ます
- 2人目の連絡先:Technical Evaluator — 実現可能性、統合、セキュリティに関する懸念に対応します
- 3人目の連絡先:Economic Buyer — 課題を、相手が重視するビジネス成果に結び付けます
- 継続的なアプローチ:User Buyer — 現場からの支持を築き、デモやPOCへのフィードバックを得ます
全員に一度にアプローチするのは避け、アカウントに手当たり次第に売り込んでいる印象を与えないよう、2~3週間かけて段階的に進めます。
ステップ5 — アクションプラン
担当者ごとのアプローチ
委員会のメンバーごとに、異なるメッセージが必要です。
| 役割 | メッセージの重点 | トーン | チャネル |
|---|---|---|---|
| 経済的決裁者 | ビジネス成果、ROI、戦略との整合性 | 経営層向け、簡潔、指標重視 | メールまたは紹介、その後に経営層向け説明 |
| 推進者 | 課題の妥当性確認、課題の解決方法、社内での提唱に使える資料 | 協力的、詳細、提唱の材料を提供 | メール+電話+LinkedIn |
| 技術評価担当者 | 統合、セキュリティ、アーキテクチャ、POC 計画 | 技術的、具体的、曖昧な説明を避ける | メール+電話、技術的な詳細説明を提案 |
| ユーザー側の決裁者 | 日々の業務への影響、ワークフローの改善、導入の容易さ | 実践的、説明より実演 | デモ、無料トライアル、またはサンドボックス |
| 協力者 | 感謝を伝える、最新情報を共有する、社内の動向について情報を求める | 個人的、関係構築を優先 | 電話またはLinkedInのメッセージ |
特定のプラットフォームスキルを推奨する前に
このスキルは、多数のプラットフォームにわたる戦略領域を扱います。特定のプラットフォームスキル(## Related skillsに記載された/sales-{platform}、例:/sales-mailshake、/sales-klaviyo、/sales-apollo)をユーザーに案内する前に、必ずそのプラットフォームスキルの実際のSKILL.mdを読んでください。## Related skillsの1行の説明は候補の特定には十分ですが、そのスキルの採用を決定したり、適切に呼び出すプロンプトを作成したりするには不十分です。
読み方:
~/.claude/skills/{skill-name}/SKILL.mdがローカルに存在する場合は、Readします。sales-*スキルの場合は、このリポジトリからWebFetchで直接取得します:https://raw.githubusercontent.com/sales-skills/sales/main/skills/{skill-name}/SKILL.md— 例:sales-mailshakeの場合は、https://raw.githubusercontent.com/sales-skills/sales/main/skills/sales-mailshake/SKILL.md。- サードパーティ製の
非sales-*スキルの場合は、インストール済みであれば~/.claude/skills/sales-do/references/skill-sources.mdで{org}/{repo}を確認し、そのリポジトリ内の同じskills/{skill-name}/SKILL.mdパスから取得します。
**読んだ後は、**そのSKILL.mdの具体的な内容(対応範囲、サブフロー、argument-hintの形式、または「使用しないでください」という否定的な条件など)に基づいて推奨してください。生成する呼び出しは、プラットフォームスキルのargument-hintに合わせてください。プラットフォームスキルがユーザーの状況に合わない場合は、別のスキルに切り替えるか、適切でないスキルを推奨するのではなく、この場で直接質問に対応してください。
実行に関連するスキル
/sales-cadence— 委員会メンバーごとにマルチチャネルのシーケンスを設計します/sales-deal-inspect— 委員会の構成を把握した後に、商談の健全性を評価します/sales-enrich— 委員会メンバー全員の連絡先情報を検証済みの情報で補完します/sales-intent— アカウントレベルで購買シグナルを確認します/sales-zoominfo— ZoomInfoプラットフォームのヘルプ(組織図、Scoops、Engage)/sales-do— どのスキルを使えばよいかわかりませんか?ルーターがあらゆる営業目標に適したスキルを選びます。インストール方法:npx skills add sales-skills/sales --skill sales-do
委員会の継続的なモニタリング
委員会の構成は固定ではありません。次の点をモニタリングしてください。
- 新規採用:関連部署での採用(新たなステークホルダー候補)
- 退職(推進者が退職すると、商談が停滞する可能性があります)
- 役職の変更(昇進による権限の拡大、または組織再編による新たな動き)
- 新たに関与する部署(法務、調達、ITセキュリティは、後から加わることがよくあります)
アカウントにApolloアラートを設定して、こうした変化を捉えましょう。
注意点
-
いきなり経営幹部に連絡しないでください。 Claude は、CEO にメールすることをデフォルトで勧めます。まずはチャンピオンまたはコーチ、つまり、製品が解決する課題を抱え、社内で推進してくれる人から始めてください。従業員数が5,000人の企業の CEO に、自社の SaaS ツールについて突然メールを送っても、うまくいくことはほとんどありません。
-
役職をそのまま組織図に当てはめないでください。 従業員数50人のスタートアップの「ディレクター」と、Fortune 500 企業の「ディレクター」では、権限のレベルがまったく異なります。役職を委員会の役割に対応づける際は、必ず企業規模を考慮してください。
-
小規模なアカウントに大勢を巻き込まないでください。 従業員数200人の企業に、7人の購買委員会があるとは限りません。企業規模に合わせてフレームワークを調整してください。SMB なら2〜3人、中堅企業なら5〜8人、大企業なら8〜12人です。小規模なアカウントに大勢を巻き込むと、やりすぎに感じられ、逆効果になることがあります。
-
組織図が変わらないと思い込まないでください。 人は役職を変わり、チームは再編され、企業は組織変更を行います。マップを作成する前に、Apollo で在職期間と最近の役職変更を確認してください。6か月前のデータに基づくマップは、間違っている可能性があります。
-
自己改善:ここに記載されていないことを見つけた場合は、今日の日付を付けて
references/learnings.mdに追記してください。
例
例1:エンタープライズ向けセキュリティ製品
ユーザーの発言:「Acme Corp のセキュリティ製品の購買委員会をマップしてください」 スキルの動作:
- 企業規模を特定します(エンタープライズ、従業員数5,000人)
- 想定される委員会をマップします:CISO(経済的購買者)、セキュリティ部門のディレクター(チャンピオン)、セキュリティアーキテクト(技術評価者)、SOC アナリスト(ユーザー購買者)、エンジニアリング担当 VP(潜在的な阻害要因)
- Acme とセキュリティ/IT 部門で絞り込み、Apollo People Search で担当者を見つけます
- セキュリティ部門のディレクター(チャンピオン)から接点を作り、CISO にも並行してアプローチすることを推奨します
- 役割に応じたメッセージを含む、担当者ごとのアプローチ計画を作成します 結果:接点を作る戦略と複数担当者へのアプローチ計画を含む、完全な委員会マップ
例2:SMB への販売
ユーザーの発言:「従業員数100人のスタートアップに販売しています。誰と話す必要がありますか?」 スキルの動作:
- SMB 向けにフレームワークを調整し、7人の委員会ではなく、重要な担当者を2〜3人に絞ります
- この規模では、創業者/CEO が経済的購買者とチャンピオンを兼ねる可能性が高いと特定します
- 関連する担当者を2〜3人見つけます(CEO、エンジニアリング責任者、個別貢献者のユーザー1人)
- よりシンプルなアプローチを推奨します。SMB では、単一の担当者を通じたアプローチで十分な場合があります 結果:シンプルな購買プロセスを複雑にしない、適切な規模の委員会マップ
例3:停滞した商談の拡大
ユーザーの発言:「BigCo にチャンピオンはいますが、商談が停滞しています。ほかに誰を巻き込むべきですか?」 スキルの動作:
- 停滞の原因を診断します。経済的購買者の支援が不足しているのか、技術的な阻害要因があるのか、社内政治の問題なのかを確認します
- 既存の委員会メンバーをマップし、不足している役割を特定します
- 追加すべき具体的な役割を推奨します(おそらく技術評価者または経済的購買者)
- チャンピオンを介した紹介を活用する拡大戦略を立てます 結果:関与すべき具体的な担当者と、商談を再び進めるための道筋を示す、委員会の不足分析
トラブルシューティング
対象アカウントで十分な人数が見つからない
原因:企業が小規模であるか、データプロバイダーがそのアカウントを十分にカバーしていません 解決策:複数のデータソース(Apollo と LinkedIn Sales Navigator)を試してください。小規模な企業の場合、経営陣全員が企業のウェブサイトに掲載されていることがあります。既存の担当者に、組織構造について尋ねてください。
チャンピオンが退職した
原因:転職により、社内の推進者がいなくなりました 解決策:2つの対応を行います。(1)チャンピオンが転職した先に連絡してください。そこでは温かい見込み客となります。(2)元のアカウントでは、すぐに新しいチャンピオンを見つけてください。社内で推進する人がいなければ、商談は停滞します。チャンピオンが誰と一緒に働いていたのか、また、同じ課題を抱えているのかを確認してください。
複数の人が自分を意思決定者だと主張する
原因:中堅市場ではよくあることです。役職が重複し、権限が曖昧です。 解決策:「予算に関する質問」――「この予算を承認する必要があるのは誰ですか?」と、「署名に関する質問」――「契約書に署名するのは誰ですか?」を尋ねます。実際の経済的購買者は資金を管理しています。それ以外の人は、何と言おうと全員が影響力を持つ人です。