商談相手は前向きなのに、別の部署の確認で話が止まる。担当者が異動した途端、それまでの経緯が分からなくなる。複数の人が導入に関わる法人営業では、一人の連絡先だけを把握していても、検討の全体像をつかめないことがあります。
キーパーソンマップは、案件の意思決定に関わる人、その役割、関心事項、次に確認することを整理した図や一覧です。組織図を写すだけでなく、今回の案件を進めるために必要な関係を見える形にします。本記事では、表から始める作り方と、情報が少ない段階での使い方を紹介します。
商談相手は前向きなのに、別の部署の確認で話が止まる。担当者が異動した途端、それまでの経緯が分からなくなる。複数の人が導入に関わる法人営業では、一人の連絡先だけを把握していても、検討の全体像をつかめないことがあります。
キーパーソンマップは、案件の意思決定に関わる人、その役割、関心事項、次に確認することを整理した図や一覧です。組織図を写すだけでなく、今回の案件を進めるために必要な関係を見える形にします。本記事では、表から始める作り方と、情報が少ない段階での使い方を紹介します。
組織図は、部署や役職、指揮命令系統を示すものです。一方、キーパーソンマップは、特定の案件について、誰が使うのか、誰が条件を確認するのか、誰が予算を判断するのかを整理します。
役職が上であっても、その案件の承認に関わらない場合があります。反対に、利用環境を評価する担当者が、実行できるかどうかを左右する場合もあります。肩書だけで重要度を決めず、案件との関係を確認しましょう。
決裁者の意味や見極め方の基本は、決裁者とは?意味・役職・見極め方でも解説しています。本記事では、複数の関係者の情報をどう整理するかに焦点を当てます。
Salesforceの学習資料は、関係者を整理する際、意思決定者だけでなく、影響を与える人や関係するグループを特定する考え方を示しています。参考:Salesforce Trailheadのマッピング解説
以下は営業案件向けに整理した役割の例です。企業共通の固定的な分類ではなく、同じ人が複数の役割を持つこともあります。
| 役割 | 確認したいこと | 情報がないと起こりやすいこと |
|---|---|---|
| 意思決定・予算判断 | どの範囲を判断するか、何を重視するか | 最後に予算や優先度が合わないと分かる |
| 社内の推進 | 誰が検討を進め、関係者を調整するか | 好感触でも次の行動が決まらない |
| 利用・運用 | 誰が使い、運用の負担を持つか | 導入後の負担を理由に計画が変わる |
| 専門的な評価 | 技術、契約、購買条件などを誰が確認するか | 提案後に必要条件が追加される |
| 連絡窓口 | 日程や情報を誰とやり取りするか | 連絡できる人を決裁者と取り違える |
「連絡にすぐ返事をくれる人」と「社内で検討を進められる人」は同じとは限りません。協力的な対応だけで推進者と判断せず、実際に社内で担っている役割を確認します。
まず、何を導入・実行する案件なのかを一文で書きます。同じ顧客でも、小規模な試行と全社導入では関係者が変わる可能性があります。
「顧客A社の全員」を網羅しようとせず、「今回の試行を判断する人」を整理するところから始めましょう。調べる対象を絞ると、図を作ること自体が目的になりにくくなります。
名刺や商談で確認できた人を書き出します。氏名が分からない場合は、「予算を確認する人:未確認」と役割だけ残します。公開されている肩書から人物を推測し、確定情報として記録しないことが重要です。
空欄を残すことで、次の面談で確認すべきことが見えてきます。情報が足りない図は失敗ではなく、調べるべき点を示す図です。
「コストを重視している」と記録するなら、どの発言や資料で確認したかも残します。「役員なので売上だけを見ているはず」といった推測は、仮説と表示してください。
提案に対する態度も同様です。質問が厳しい人を、すぐに反対者と分類しないようにします。条件を満たせるか慎重に確かめているだけかもしれません。
図に線を引くときは、何の関係かを明示します。たとえば「申請する」「技術条件を確認する」「検討結果を共有する」という区別です。単に線で結ぶだけでは、誰が何を進めるか分かりません。
一つの図が複雑になる場合は、承認の流れと情報共有の流れを分けると読みやすくなります。
最後に、営業側の担当者と確認方法を決めます。「決裁者不明」で終わらせず、「窓口担当者に、試行予算の確認先を次回面談で聞く」と具体化します。必要な人物への接点を増やす際も、窓口担当者との合意を大切にしてください。
| 氏名・部署 | 案件上の役割 | 確認した関心事項 | 根拠・確認日 | 未確認事項 | 次の行動・担当 |
|---|---|---|---|---|---|
| 【氏名/未確認】 | 【役割】 | 【発言の要約】 | 【打ち合わせ等】 | 【質問したいこと】 | 【行動と自社担当】 |
連絡先を大量に集めることよりも、この6項目が更新されていることが重要です。詳しい連絡先は社内の決められた管理先に置き、閲覧できる人や共有範囲も自社のルールに合わせます。
次の表は、勤怠集計の見直しを検討している架空の企業について、本記事用に作成した例です。
| 関係者 | 案件上の役割 | 分かっていること | 次に確認すること |
|---|---|---|---|
| 人事担当Aさん | 連絡窓口・利用者 | 月末の確認作業を減らしたいと発言 | 課長にいつ相談するか |
| 人事課長Bさん | 部門内の検討 | Aさんから相談する予定 | 試行に必要な条件 |
| 情報システム担当 | 利用環境の評価 | 関与が必要とAさんから聞いた | 担当者名と確認項目 |
| 予算判断者 | 費用の判断 | 未確認 | 試行と本導入で判断者が違うか |
ここから分かるのは、すぐに経営者へ連絡すべきという結論ではありません。まずAさんと相談し、Bさんへの説明に何が必要か、利用環境の確認をいつ行うかを決めることが、現時点の行動になります。
予算判断者が未確認のまま高額な本導入の提案を完成させるより、どの金額・範囲で誰の確認が必要になるかを先に確かめます。
相手の社内事情を詮索する聞き方より、提案の準備に必要な理由を添えます。
今回の検討を進めるにあたり、実際に利用される方のご意見は、どの段階で伺うとよいでしょうか。
試行と本導入で、費用を確認される方や手続きは変わりますか。説明資料の範囲を合わせたいと考えています。
次回までに、社内で確認しやすい資料を用意したいと思っています。どなたが、どの点を確認される予定でしょうか。
情報を話しにくい場合は無理に聞き出しません。氏名まで必要ないなら、役割や確認手順だけでも準備は進められます。
面談後、新しい関係者が分かったとき、検討範囲が変わったとき、担当者の異動があったときに更新します。常に全項目を調べ直すのではなく、変わった情報と確認日を残してください。
共有する記録には、人格を評価する表現や、業務と関係のない個人情報を持ち込まないようにします。「扱いにくい人」ではなく「運用負荷の確認が未完了」のように、案件に必要な事実で記述しましょう。
また、マップを作ったことを理由に、担当者の了承なく関係者へ一斉連絡するのは避けます。整理した情報は、適切な相談の順序と、説明内容を決めるために使います。
関係者を丸で囲んで線を引くだけでは、面識があることと、承認を求める関係が混ざってしまいます。図を使う場合は、線の意味を凡例として残します。
たとえば、承認に関わる流れは実線、情報の共有は点線、関係が未確認の部分は「確認待ち」と表記する方法があります。これは記法の一例です。複雑なルールを増やすより、チーム内で同じように読めることを優先します。
前述の架空例なら、人事担当Aさんから人事課長Bさんへの相談は確認できています。一方、Bさんが予算を承認できるかはまだ分かりません。この段階でBさんを最終判断者に置かず、「予算判断者は未確認」とつなぎ先を残します。
未確認の線が多いときは、すべてを同時に調べる必要はありません。次に判断してもらいたいことに関わる線から確かめます。試行の実施を相談しているなら、まず試行に必要な承認や利用条件を調べ、本導入の全経路の確認は次の工程に分けることもできます。
マップに役割を書いただけでは、提案の内容は変わりません。それぞれが何を確認したいかを整理し、必要な情報に対応させます。以下は、特定の部署が必ず同じ関心を持つという意味ではなく、ヒアリングを組み立てるための例です。
| 確認された関心 | 用意する情報 | 次に確かめること |
|---|---|---|
| 現場の作業が増えないか | 導入前後の作業分担案 | 実際に作業する人が見て問題ないか |
| 全体でいくらかかるか | 初期・継続・追加費用の条件 | 比較する期間と人数が合っているか |
| 開始までに何が必要か | 準備作業と担当者の案 | 顧客側の稼働を確保できるか |
| 今進める理由があるか | 課題、影響、他の選択肢の整理 | 組織の優先事項と一致しているか |
「費用を気にしている」と聞いた場合も、予算上限なのか、他案との比較なのか、更新時の負担なのかで必要な資料が変わります。短いラベルを付けて終わりにせず、具体的な疑問まで確認するとマップが提案に役立ちます。
一人の担当者だけに依存しないことは大切ですが、連絡先を増やすこと自体が目的ではありません。役割に応じて必要な人へ、必要な理由を示して話をつなぎます。
最初に窓口担当者へ、追加の説明が必要な理由を伝えます。「利用開始時の作業を正確に把握したいので、実際に運用する方のご意見を伺えますか」といった聞き方なら、相手が参加者を判断しやすくなります。
次に、面談の目的と扱う範囲を共有します。技術条件の確認が目的なら、経営課題の説明を長く繰り返すより、確認したい条件を事前に送ります。参加者ごとに説明が食い違わないよう、すでに合意していることと未決のことを区別します。
面談後は、元の窓口担当者にも必要な範囲で結果を共有します。誰かを飛ばして話を進めた印象を与えないよう、次の行動や資料の更新をそろえましょう。ただし、他の参加者が共有を認めていない情報まで転送しないよう注意してください。
初回面談で「上司へ相談します」と言われた場合、上司の名前が分からないままでも整理はできます。マップには、窓口担当者から「社内相談先・氏名未確認」への線を置きます。
次の質問は、「上司のお名前を教えてください」だけではありません。「次のご相談では、費用と運用のどちらを中心に確認されますか」と聞けば、必要な資料を準備できます。役割と判断事項が分かった後で、直接説明する必要があるかを相談します。
一方、「関係部署が多く、まだ確認先が決まっていない」と言われたなら、営業側で承認経路を完成させようとしないことです。顧客側で整理するための確認項目を渡し、分かった範囲から更新します。確認できない情報を推測で補うより、空欄に次の確認方法を書いておくほうが実務に役立ちます。
案件会議では、「この人と会えたか」だけでなく、「次の判断に必要な情報がそろっているか」を確認します。次の順序なら、関係者の人数だけで進捗を評価しにくくなります。
第一に、今回進めたい判断を確認します。要件整理に進むのか、試行を始めるのか、本導入を検討するのかが異なれば、必要な関係者も変わります。
第二に、その判断に関わる役割が見えているかを確認します。氏名が分かっていても、その人がどの条件を判断するのか不明なら、役割は確認できたとはいえません。
第三に、各人の未解決の疑問を確認します。営業側が資料を送ったという事実だけでなく、その資料が何の確認に使われるかを把握します。顧客からの回答がない事項は、完了扱いにしないようにします。
最後に、自社の担当者と次の行動を一つ決めます。「関係強化をする」ではなく、「窓口担当者に試行時の承認先を確認する」のように、実行したかどうかが分かる表現にします。マップは会議用の説明資料で終わらせず、次の面談の準備へつなげましょう。
引き継ぎでは、最新の図だけを渡しても、関係者をその位置に置いた理由が分からない場合があります。重要な情報には、確認した日時と会話の要約を添えます。
たとえば「Bさんが判断者」とだけ書くより、「試行費用はBさんが確認すると、Aさんから面談で説明を受けた」と残します。Bさん本人へ直接確認した情報ではないことも分かるため、引き継ぎ後の確認を適切に進められます。
顧客側で異動があった場合は、前任者の役割を新任者へ自動的に移さないようにします。担当業務が変わることもあるため、現在の窓口と検討体制を確認し直します。過去の記録は経緯として保持し、今の情報と区別してください。
小規模な企業への営業でも必要でしょうか。 一人の経営者が利用や予算判断も担うなら、複雑な図は不要です。役割を兼ねていることと、ほかに確認する人がいるかを短い一覧にするだけでも、認識をそろえられます。
ツールを導入しないと作れませんか。 最初は表計算ソフトや社内で使っている案件管理のメモでも始められます。更新担当や共有方法が決まらないまま、新しいツールだけ増やさないようにします。
相手の賛否を色で分けてもよいでしょうか。 使う場合は、何を根拠にその色にしたかを残します。賛成・反対の二択より、「条件の確認中」「今回の範囲に合意」「判断時期は未確認」など、実際の検討状況を言葉で記すほうが誤解を防げる場合があります。
関係者を整理した結果、事業の方向性を判断する人と話す機会が必要だと分かることがあります。その場合は、既存の窓口を通した相談と、新たな接点づくりを状況に応じて検討します。
オンリーストーリーは、決裁者マッチングを基軸としたBtoB営業支援を提供しています。自社が求める役割や企業条件を整理したうえで、サービス内容を確認すると、必要な接点を検討しやすくなります。顧客社内の承認経路を把握する機能を提供しているという意味ではなく、接点づくりの選択肢として考えてください。
キーパーソンマップは、誰に会ったかの記録を、誰に何を確認するかという行動へつなげるための整理です。役割、関心事項、根拠、未確認事項を書き分け、次の面談で確かめることを一つ決めるところから始めましょう。