%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
営業マネジメントを支えるのは、CRMのデータから判断し、行動を振り返る運用です。KPI・フォーキャスト・1on1を同じデータでつなぐことが核心です。
営業マネジメントを支えるのは、CRMのデータから判断し、行動を振り返る運用です。KPI・フォーキャスト・1on1を同じデータでつなぐことが核心です。
「営業マネージャーによってチームの成果が変わる」「経営会議のたびに売上予測が変わる」「1on1が近況確認や雑談で終わる」——こうした課題では、マネージャー個人の力量だけでなく、案件の評価基準や会議後の行動が共有されているかを確認する必要があります。
営業マネジメントの型化とは、KPI設計、フォーキャスト管理、1on1、営業会議を、CRMのデータと営業プロセスに連動させることです。入力、集計、判断、行動を一つの流れにすることで、担当者やマネージャーが変わっても引き継げる運用を目指します。
本記事では、営業マネジメントの柱となるKPI、フォーキャスト、1on1を、CRMとHubSpotで仕組みに落とし込む考え方を解説します。指標の定義をそろえるところから、予測が外れた原因の分け方、案件支援と新規商談の創出を選ぶ条件、次回の会議で確認する内容まで整理します。
本記事は「セールスイネーブルメントの設計と実践｜営業組織を仕組みで強くする方法」シリーズの一部です。
この記事でわかること
営業マネジメントをデータとプロセスに結びつけるために、設計する項目と運用の流れを整理します。KPIを作るだけで終わらせず、数字を比較できる条件をそろえ、会議や1on1で具体的な行動に変えるところまで解説します。
- 営業マネジメントを型化する考え方 — 案件の事実、担当者の見立て、次の行動を分けて記録し、KPI管理、パイプライン管理、コーチングをCRM上でつなぐ方法がわかります。
- 営業KPIの設計方法 — 結果指標、プロセス指標、行動指標の関係に加え、分母・分子・対象期間をそろえ、目標との差を分解する方法を整理します。
- フォーキャストを支えるパイプライン設計 — 取引ステージ、受注確度、必須入力項目を整え、加重金額と案件ごとの受注時期を分けて判断する手順がわかります。
- 1on1と営業会議の運用方法 — CRM上の事実から支援する案件を選び、担当者・期限・完了条件・見直し条件を決めるアジェンダを紹介します。
- 型化の限界と失敗を避ける方法 — 入力不足と営業上の課題を区別し、KPIの増やしすぎやマイクロマネジメントを避けながら運用を修正する視点を解説します。
「CRMを入れたが営業会議が変わらない」「フォーキャストの精度が低い」という課題をお持ちの方に、特に読んでいただきたい内容です。現在の会議で判断できない場面と照らし合わせることで、入力ルール、レポート、案件支援のどこから整えるかを選べます。
営業マネジメントの型化とは
営業マネジメントの型化は、営業活動の事実をCRMに集め、共通の基準で状況を把握し、その情報を育成や意思決定へつなげる設計です。マネージャーの判断を生かすために、判断の前提と根拠を共有します。
データとプロセスを共通言語にする
同じ案件でも、ある人は「受注に近い」と判断し、別の人は「まだ提案前」と判断する状態では、予測を合算しても見通しの根拠がそろいません。まず、案件がどの条件を満たしたら次のステージへ進むのか、各ステージで何を記録するのかを定義します。
その際は、次の情報を分けます。
- 確認できた事実：顧客が伝えた課題、見積の提示内容、合意した次の打ち合わせ、確認済みの決裁手順。
- 担当者の見立て：受注できると考える理由、懸念している点、想定する受注時期。
- 次に確かめること：未確認の決裁条件、提案への評価、顧客側で残っている検討事項。
例えば、「反応がよかった」は担当者の見立てです。「顧客が提案を社内で検討し、回答予定日を共有した」は、案件を評価するための事実として扱えます。見立てだけでステージを進めず、そのステージに必要な事実を確認できた時点で更新するルールにします。
必要な情報を顧客から得られていない場合は、期待する内容で埋めず、未確認であることと確認する行動を残します。これにより、マネージャーは案件の難しさと情報不足を分けて支援できます。
判断が分かれたときは、担当者に結論だけを尋ねず、ステージの条件に該当する顧客側の事実を確認します。事実が不足していれば確認する行動を決め、事実がそろっているのに判断が分かれるならステージ定義を見直します。この順序なら、入力の問題と基準の問題を区別できます。
CRMを営業活動全体の流れに置く
CRMは顧客情報を保存するだけでなく、顧客との接点から商談、受注・失注、その後の対応までを追えるように設計します。KPIとフォーキャストも、この流れのどの場面を測っているかを明確にします。
例えば、活動量だけを別の表で管理し、案件金額だけをCRMに入れていると、どの活動が商談化や受注につながったのかを確認しにくくなります。コンタクト、会社、取引、活動履歴を関連付け、活動した相手と進行中の案件をたどれる状態にします。
ただし、取引に関連する活動をすべて成果として重複集計しないよう、集計単位を決めます。顧客単位で見る接触状況と、取引単位で見る商談の進捗は分けて定義してください。
会議で数字の根拠となる取引を開き、活動履歴と次の行動まで確認できれば、個別の状況判断へ進めます。関連付けや入力が不足している場合は、担当者の成果を評価する前にデータを整えます。
営業活動の記録と案件管理をつなぐ考え方は、営業生産性を向上させる仕組みで詳しく解説しています。
営業マネジメントの型化が必要な理由
型化を検討するときは、情報の入力場所、案件の評価基準、会議での確認方法を点検します。集計の手間が課題なのか、数字は見えていても判断できないのかによって、着手する場所が変わります。
スプレッドシート管理は集計が目的になりやすい
週報をExcelやスプレッドシートで提出し、マネージャーが内容を転記して会議資料を作る運用では、同じ情報を何度も入力することになります。担当者ごとに表記や更新時点が違えば、集計後に数字を確認する作業も発生します。
| 管理の場面 | 手作業中心の状態 | CRMに集約した状態 |
|---|---|---|
| 案件更新 | 複数の表や資料を更新 | 取引レコードを更新 |
| 進捗確認 | 担当者へ個別に確認 | ステージと活動履歴を確認 |
| 会議準備 | 数字を転記して集計 | 保存したビューやレポートを表示 |
| 会議後 | 議事録から別途タスク化 | 取引に紐づけてタスクを記録 |
| 引き継ぎ | 前任者の説明に依存 | 履歴と次の行動をレコードで確認 |
移行時には、会議資料の各項目について、情報を最初に登録する場所と更新する担当者を決めます。同じ案件金額を複数箇所で更新しているなら、どの値を判断の基準にするかを先に統一します。
CRMの集計と従来の資料が一致しない場合は、対象期間、案件の範囲、受注日の扱い、重複の有無を確認します。差の理由を説明でき、会議で必要な案件へたどれる状態になってから、転記する運用の終了を判断します。
CRMへ集約する目的は、会議資料を作るための転記を減らし、マネージャーが案件支援やメンバー育成に時間を使える状態へ移行することです。
マネージャーの経験を組織の知見に変える
マネージャーが顧客の反応や案件の停滞を見抜けたとしても、判断基準が言語化されていなければ、ほかのマネージャーや新人へ引き継げません。
共通化する際は、実際の取引を使って「どのステージに置くか」「何を確かめれば次へ進めるか」を担当者間で照合します。判断が分かれた案件は、担当者の理解だけでなく、定義の曖昧さや必要情報の不足を確認します。
定義を修正したら、進行中の案件でも同じ基準を使えるかを確かめます。例外がある場合は、例外とする理由と判断者を残し、通常の案件へ無条件に適用しないようにします。
失注理由も同じ基準で記録すれば、営業、マーケティング、製品やサービスの改善へ情報を渡せます。理由の分類と、分類した後の活用方法は失注分析の設計と活用が参考になります。
感覚的な売上予測を説明可能な予測へ変える
「今月は達成できそうです」という報告では、どの案件を、どの根拠で予測へ含めたかがわかりません。説明可能な予測にするには、金額だけでなく、対象期間内に受注すると考える条件を示します。
確認する順序は、案件金額の根拠、現在のステージ、顧客側で残っている判断、クローズ予定日の根拠です。見積を提示済みでも、顧客の決裁日程が未確認なら、商談の進捗と受注時期の確かさを分けて扱います。
案件の金額や時期に未確認事項があれば、確認済みの案件と区別して会議に示します。未確認事項を解消する担当者と期限を決め、回答が得られた時点で予測を更新します。予測の変更自体を問題にするのではなく、何が判明して見通しが変わったかを追えるようにします。
例えば、顧客から見積範囲への合意は得られたものの、決裁手順を確認できていない案件では、金額の根拠は残しつつ、受注時期の判断を保留します。決裁に関わる相手と予定を確認できれば、対象期間の予測に含めるかを改めて判断します。このように、未確認事項ごとに次の確認と予測を更新する条件を対応させます。
CRMデータに基づく営業KPIの設計
営業KPIは、結果に至るプロセスと行動をつなげて設計します。指標の増減を見てすぐ施策を変えるのではなく、比較条件を確認してから、どの段階へ介入するかを決めます。
結果・プロセス・行動をつなげる
営業KPIは、結果指標、プロセス指標、行動指標の順に分解すると整理しやすくなります。各指標を個別に並べるのではなく、どの行動がどのプロセスを動かし、どの結果へつながるのかを確認します。
| 区分 | 確認する指標の例 | 主な問い |
|---|---|---|
| 結果指標 | 売上、受注件数、受注金額 | 目標に対してどこまで到達したか |
| プロセス指標 | 商談化率、受注率、営業サイクル、パイプライン | どの段階で案件が進まなくなっているか |
| 行動指標 | 架電、メール、商談、提案書作成 | プロセスを動かす行動を実行できているか |
各指標には、名称に加えて集計対象と計算方法を定義します。例えば、受注率を「対象期間に受注した件数 ÷ 同じ期間に受注または失注した件数」とするなら、進行中の案件は分母へ含めません。この方法は、その期間に結論が出た案件の結果を見るための定義です。
一方、ある時期に作成した商談の成果を追う場合は、作成時期が同じ案件群を追跡します。進行中の案件が残っている段階で、結果が出そろった案件群と単純に比べないようにします。どちらを使うかは、会議で答えたい問いに合わせて決めます。
商談化率も同様です。「接触した会社」を分母にするのか、「接続できた相手」を分母にするのかで意味が変わります。重複する接触の扱い、商談化と認める条件、判定する時点をそろえてから比較します。
率の変化だけでなく、分母と分子の件数を一緒に確認してください。 対象が入れ替わったのか、商談化した件数が減ったのかを分けなければ、行動量と接触内容のどちらを見直すべきか判断できません。
例えば商談化率が下がったときは、まず分母に含む対象と記録方法が前回と同じかを確認します。
- 対象顧客の構成が変わったなら ── 顧客層ごとに分けて比較します
- 同じ顧客層でも下がっているなら ── 接続まで進んでいないのか、接続後に課題を確認できていないのかを活動履歴で調べます
接続が課題なら接触方法を、課題確認が課題なら会話の内容を見直し、変更した行動が記録された案件で結果を確かめます。
指標の定義から比較、案件への掘り下げまでの考え方は、営業データ分析入門をご覧ください。
トップダウンとボトムアップを突き合わせる
KPIの目標は、売上目標から必要な受注、商談、活動へ分解するトップダウンと、現在の案件から着地を積み上げるボトムアップを併用します。
トップダウンで使う受注単価や受注率は、対象とする商材や顧客層に対応する自社データを基にします。受注条件が異なる案件を混ぜた平均値を使うと、必要な商談数を誤って見積もるおそれがあります。比較できる実績がなければ、算出結果を確定目標として扱わず、前提を明記して見直します。
ボトムアップでは、現在の案件金額を合算する前に、対象期間内に顧客の検討が完了する見通しを確認します。そのうえで、目標との差への対応を分けます。
- 既存案件に具体的な障害があり、支援によって解消できる場合：社内調整や提案の補足など、必要な支援を割り当てます。
- 進行中の案件だけでは不足し、新しい商談の検討期間を確保できる場合：商談創出へ活動を配分します。
- 顧客の決裁や導入時期が対象期間に合わない場合：予定日と予測を見直し、当期の不足を明示します。活動量を増やすだけで埋められる差とは分けます。
ここで決めた行動を担当者と期限に結びつけます。予定日を変更しただけなのか、顧客側の判断が進んだのかも区別して振り返ると、見かけの数字の改善を成果として扱わずに済みます。
目標との差が出たときは、先に既存案件の金額と時期の根拠を確かめます。支援によって顧客の判断に必要な情報を届けられるなら案件支援を選びます。既存案件にその余地がない場合は、新しい商談が対象期間内に検討を終えられるかを確認します。どちらも難しければ、予測と必要な次の期間の活動を分けて報告します。
HubSpotでKPIを運用する手順
HubSpotでの運用も、会議で答えたい問いから設計します。レポートを作る前に、次の順序で指標の前提をそろえます。
- 判断する内容を決める：新しい商談を増やすのか、既存案件への支援を優先するのかなど、数字を見た後に選ぶ行動を定めます。
- 集計条件を決める：対象パイプライン、担当者、期間、金額や件数の単位、除外する取引をそろえます。
- 入力する場面を決める：商談の成立、見積の更新、受注・失注の確定など、業務上の出来事と入力を結びつけます。
- 集計結果を取引と照合する：レポートに含まれる取引を確認し、集計条件どおりに含まれているか、必要な取引が抜けていないかを調べます。
- 会議で使って見直す：判断できなかった理由がデータ不足なら入力を整え、表示方法が原因ならレポートを変更します。
売上目標とフォーキャストを見比べる際も、対象のパイプラインと期間をそろえます。目標が受注金額なのか売上計上額なのかを確認し、異なる基準の数字をそのまま差し引かないようにしてください。設定項目の確認には、HubSpot公式のフォーキャストツールを設定するを参照します。
受注金額、受注率、パイプラインなど、会議で行動を決められる指標から始めます。使われなかった指標は、削減する前に「指標が不要なのか」「データを信用できず使えなかったのか」を分けて確認します。
フォーキャストを支えるパイプライン設計
フォーキャストでは、案件の進捗と受注時期を分けて評価します。取引ステージ、受注確度、ステージ定義、必須入力項目を一体として設計し、予測へ含めた理由を取引ごとに説明できるようにします。
取引ステージ・受注確度・定義・必須項目をそろえる
パイプラインを設計するときは、ステージ名と、そのステージに置くための条件をセットで決めます。以下の表の「角度」は、ステージごとの受注確度を指します。
| 設計要素 | 決める内容 | 運用上の役割 |
|---|---|---|
| 取引ステージ | 受注率が変化する営業プロセスの区切り | 案件の現在地を示す |
| 角度 | ステージごとの受注確度 | 加重金額の計算に使う |
| ステージ定義 | どの状態ならそのステージに置くか | 担当者ごとの判断差を抑える |
| 必須入力項目 | ステージ移行時に登録する情報 | 判断に必要なデータをそろえる |
例えば「見積提示」を設計するなら、見積を送付した事実を表すのか、顧客が見積内容を確認して社内検討に進んだ状態を表すのかを決めます。異なる状態を同じステージへ混在させないことが重要です。
仮に「顧客が見積内容を確認した状態」を条件にするなら、見積金額に加え、確認できた相手、顧客側で残っている検討事項、次に回答を得る予定を記録します。送付しただけで確認が取れていなければ、移行条件を満たしたとは扱いません。
また、取引の進捗は確認できても、クローズ予定日は未確認という状態を認める必要があります。進捗を正しく記録したうえで、受注時期には不確実性があると示してください。予定日を営業目標に合わせて埋める運用では、案件の事実と社内の希望が混ざります。
必須入力項目は、そのステージへの移行を判断するために必要な内容へ絞ります。取得できない情報が常に必須となっている場合は、現場へ入力を求め続ける前に、要求する時点が適切かを見直します。
ステージ移行の可否は顧客側の事実で判断し、予定日の確かさは別に確認します。ステージ条件を満たしていて予定日だけが不明なら、進捗を戻すのではなく、予測上の未確認事項として残します。両方の根拠が不足しているなら、必要な事実を取得してからステージと予測を更新します。
加重金額で案件の現在地を捉える
加重金額は、取引金額に受注確度を掛けて考える集計です。パイプライン総額と併記すれば、案件金額を現在の進捗に照らして捉えられます。ただし、その金額が対象期間内に受注することを保証するものではありません。
HubSpotで運用する際は、取引金額とステージの確率をどの基準で設定しているかをそろえます。パイプライン設定の確認先は、HubSpot公式のオブジェクトパイプラインを設定・管理するです。
以下の取引ボードの画面例を見る際は、案件がどのステージに分布しているかを確認します。そのうえで、初期段階の案件への金額の偏りや、見通しを大きく左右する取引を取り出し、顧客側の検討状況まで確認します。
次の画像は、HubSpotの取引ボードビューでステージ別の案件と加重金額を確認する画面を示します。
案件を確認する順序は、次のようにそろえます。
- 金額の根拠を確認する：見積と整合しているか、未確定の追加範囲を含んでいないかを確かめます。
- ステージの根拠を確認する：定義に必要な顧客側の事実が記録されているかを見ます。
- 時期の根拠を確認する：顧客の決裁予定と、受注までに必要な手続きがクローズ予定日に合っているかを確認します。
- 未解決事項を確認する：次の行動、回答を待っている相手、社内支援の必要性を整理します。
金額やステージが誤っていれば取引データを修正します。データは正しくても時期が未確認なら、期間内の受注見通しを保留し、確認する行動を決めます。顧客の判断に必要な支援が明確なら、担当者へ支援を割り当てます。
加重金額が同じでも、顧客の決裁予定が確認できた案件と、次の連絡機会が決まっていない案件では、会議で取る行動が異なります。前者は決裁までに残る障害を確認し、後者は顧客の検討状況を確かめる行動を設定します。いずれも金額だけで予測を確定せず、顧客側の判断が進んだ事実を確認した時点で見通しを更新します。
停滞を判断するときも、経過日数だけで一律に扱いません。顧客と合意した回答予定を過ぎたのか、回答待ちの間に必要な行動を実施しているのかを先に見ます。回答予定を超過した案件や、次の確認機会がない案件を、会議で見直す条件として定めます。
自社の過去案件を比較基準に使う場合は、同じ商材や営業プロセスの取引でステージ滞在期間を比べます。長く滞在する理由が顧客の通常の検討手順にあるなら、営業活動の停滞と区別してください。
入力漏れを人ではなく仕組みで防ぐ
フォーキャストに必要な金額やクローズ予定日が空欄の場合は、「未入力」と「まだ決まっていない」を分けます。前者は更新する行動、後者は顧客へ確認する行動が必要です。
ステージに応じた入力項目や必須化を設計する際は、HubSpot公式のオブジェクトパイプラインを設定・管理するを確認します。必須化は、必要な情報をそろえるために使い、未確認の値を仮入力させる運用にしないことが重要です。
例えば、顧客から日程の回答が得られていない場合は、社内目標の日付で確定扱いにせず、未確認であることと次の確認予定を記録します。会議では、その案件を確定した予定日がある案件と分けて評価します。
入力の見直しでは、空欄を見つけたら直ちに必須化するのではなく、その情報を顧客から取得できる場面を確認します。取得済みなのに記録されないなら入力担当者と更新時点を整えます。まだ取得できないなら、確認するタスクと予測上の扱いを決めます。両者を分けても空欄のために判断できない場面が残る場合に、入力要件を再検討します。
受注後の金額や日付を変更すると、過去に確認した実績との照合が必要になります。変更理由と承認する担当者を定め、誤入力の訂正なのか、契約内容の変更なのかを記録します。過去の数値が変わった場合に、理由をたどれることを運用の完了条件にします。
時点データを残して予測との差を振り返る
現在のレコードだけでは、過去の会議時点でどの案件を根拠に予測したかを再現できない場合があります。振り返りのために、確認時点、対象期間、取引を特定する情報、当時の金額・ステージ・予定日、予測へ含めた理由を残します。
レポートの共有方法は、HubSpot公式のレポートとダッシュボードを共有・エクスポートするを参照します。共有用の画面やリンクと、会議時点の内容を再現できる記録は分けて扱ってください。後から値が変わる資料だけに依存せず、当時の判断理由を会議記録へ残します。
予測と実績を比べるときは、合計の差に加えて、取引単位で次の原因へ分けます。
- 時期の差：受注見込みは継続しているが、対象期間の外へ移った。
- 金額の差：提案範囲や契約条件が変わり、受注金額が変わった。
- 結果の差：予測へ含めた案件が失注した、または継続中になった。
- 対象の差：会議後に新しく加わった案件など、当時含めていなかった取引が受注した。
- 記録の差：更新漏れや誤入力の訂正によって集計が変わった。
失注による不足と、予測に含めていなかった受注が相殺されると、合計だけでは問題を見落とします。時期の差が原因なら日程確認、金額の差なら提案範囲の確認、記録の差なら更新ルールを見直します。原因を分けてから、ステージ定義や確率を変更する必要があるか判断します。
振り返りでは、差が生じた取引について、会議時点で把握できた情報と、その後に判明した情報を分けます。会議時点で確認できたはずの情報が欠けていたなら入力や確認の手順を直します。その後に顧客の条件が変わったなら、当時の判断を入力ミスと扱わず、変化を把握して予測を更新する条件を見直します。
CRMを使った1on1の構造化
1on1では、メンバーが抱える課題を具体化し、本人が実行する行動とマネージャーが提供する支援を決めます。CRMデータは、状況を共有し、本人の考えを聞くための材料にします。
1on1の流れを固定する
1on1のアジェンダは、前回の行動、パイプライン、KPI、課題、次の行動という順序で整理します。案件の緊急対応だけで終わらず、行動から何を学んだかも振り返ります。
| 順序 | アジェンダ | CRMで確認する情報 |
|---|---|---|
| 冒頭 | 前回決めた行動の振り返り | タスク、メモ、活動履歴 |
| 前半 | 注力案件の確認 | 取引ステージ、金額、クローズ予定日 |
| 中盤 | KPIの変化を確認 | 活動、商談化率、受注率 |
| 後半 | 課題や支援事項を整理 | 停滞案件、次の行動、関連履歴 |
| 最後 | 次回までの行動を合意 | 担当者と期限を設定したタスク |
マネージャーは、事前に案件の現在地と前回のタスクを確認します。タスクが完了していても、期待した顧客の反応が得られたかは別に確かめます。未完了なら、行動の理解不足、社内の支援待ち、顧客側の事情を分けて扱います。
例えば、提案を送付済みでも顧客の検討が進んでいないなら、送付の完了だけで評価を終えません。提案が検討相手へ届いているか、回答を得る方法が決まっているかを確認し、次の支援を選びます。
前回のタスクが実施済みで顧客の反応も記録されているなら、その反応を基に次の行動を決めます。実施済みでも反応が不明なら、まず結果の確認方法を決めます。未実施なら、本人が進められる行動か、マネージャーの支援が必要な行動かを確かめてから担当と期限を更新します。
取引ボードを会話の起点にする
担当者の取引を確認するときは、顧客との合意事項が期限を過ぎた案件、クローズ予定日の根拠が不明な案件、次の行動が決まっていない案件から扱います。金額が大きいという理由だけで、支援できる余地のない案件へ時間を集中させないようにします。
問いかけは、事実から始め、本人の解釈と支援へ進めます。
- 「顧客が最後に示した判断や要望は何ですか」
- 「その情報から、どこで検討が止まっていると考えていますか」
- 「次に何を確認できれば、その見立てが正しいと判断できますか」
- 「自分で進められることと、社内の支援が必要なことは何ですか」
顧客の反応が記録されていなければ、まず確認する行動を決めます。事実がそろっていて提案方法に課題があるなら、提案内容のレビューや準備の支援へ進みます。社内判断が障害なら、マネージャーが引き取る事項と回答期限を決めます。
案件を選ぶ際は、売上への影響に加えて、確認すれば判断が進む論点があるかを見ます。顧客の判断待ちで次の確認日も合意済みなら、その日を待って見直せます。一方、合意した日程を過ぎても状況が不明なら、連絡方法や支援の要否を1on1で決めます。
決定事項を取引レコードへ戻す
顧客への連絡、提案内容の修正、社内確認などの行動は、対象の取引に紐づけてタスクやメモへ記録します。担当者と期限に加えて、本人が実行する内容と、顧客から得たい結果を分けて書きます。
例えば「決裁を確認する」なら、「顧客窓口へ決裁手順と判断予定を尋ねる」が実行する内容です。「決裁に必要な関係者と予定がわかる」が得たい結果です。問い合わせを実施しても回答が得られなければ、行動は実施済み、確認事項は未解決として扱います。
さらに、回答が得られない場合や予定が変わった場合に、いつ誰へ相談するかを決めます。次回の1on1では、実行の有無、判明した事実、見立ての変化を確認し、同じ行動を続けるか変更するかを判断します。
案件支援に必要な決定事項を取引へ残し、本人の育成に関する話題は共有範囲を分けます。引き継ぎに必要な情報と、広く共有する必要のない対話を整理して運用してください。
CRMデータを使った営業会議の設計
営業会議では、チームとして判断する案件と論点を選びます。週次・月次は運用を分ける例として、案件への対応と営業プロセスの見直しを整理します。会議の間隔は、顧客の検討や社内判断の進み方に合わせて調整します。
週次会議では変化と停滞を確認する
週次会議では、前回から変化した案件と、予定した変化が起きなかった案件へ焦点を当てます。ステージが動いていなくても顧客の検討が進んでいる場合があるため、更新日だけで停滞と判断しないようにします。
| 会議項目 | 確認するデータ | 会議で決めること |
|---|---|---|
| パイプライン全体 | ステージ別の金額と件数 | 目標との差をどこで補うか |
| 注力案件 | 金額、予定日、活動履歴 | 次の行動と支援担当 |
| 受注・失注 | 結果と理由 | 継続する行動と改善点 |
| 停滞案件 | 最終活動日、次の行動 | 継続、見直し、終了の判断 |
| タスク | 担当者、期限、状態 | 次回までの実行内容 |
停滞案件では、継続、見直し、終了を次のように判断します。
- 継続する：顧客の検討意思が確認でき、次の判断や連絡の予定が合意されている。
- 進め方を見直す：検討は続いているが、提案範囲、関係者、日程などの前提が変わっている。
- 進行中の商談としての扱いを終了する：顧客が検討終了を示した、または社内で定めた終了条件に該当する。
連絡が取れないという理由だけで失注理由を推測せず、確認できた事実と社内の管理上の判断を分けて記録します。
会議の終了時には、誰が何を実行し、何を確認できれば次へ進むのかを残します。マネージャーの支援事項にも担当者と期限を設定し、営業担当者側のタスクだけにしないことが重要です。
次回の会議では、タスクの完了数だけでなく、顧客の判断に必要な情報が得られたかを確認します。得られたならステージや予測を更新し、得られなかったなら連絡方法、確認相手、案件の扱いを見直します。
月次レビューでは構造的な差を分析する
月次レビューでは、目標と実績、予測との差、KPIの推移、失注理由を確認します。指標の変化を営業上の問題と判断する前に、集計条件や対象顧客の構成が変わっていないかを点検します。
例えば、活動量が維持されているのに商談化率が下がった場合は、次の順序で確認します。
- 定義と記録を確認する：活動の重複、商談化の入力漏れ、集計期間の違いがないかを調べます。不整合があれば修正後に比較します。
- 対象の構成を確認する：顧客層、流入経路、商材など、性質の異なる対象が増減していないかを見ます。
- 同じ条件の対象で比較する：全体の率だけが下がったのか、同じ顧客層でも下がったのかを分けます。
- 接触から商談までを確認する：相手と接続できていないのか、会話はできても課題を確認できていないのか、課題はあっても商談へ進まないのかを、活動履歴から調べます。
- 変える行動と判定条件を決める：接触方法、質問内容、提案する次の行動のうち、特定した段階に対応する施策を選びます。
同じ顧客層では商談化率が変わっていないなら、担当者の会話を一律に修正する前に、対象の配分を見直します。同じ条件でも課題確認から先へ進まなくなっているなら、実際のやり取りを確認し、質問や商談への案内を修正します。
接続できていないなら、連絡先や接触の方法を確認します。接続できているのに課題を把握できていないなら、会話で尋ねた内容を確認します。課題を把握できても商談へ進まないなら、顧客が次の検討に必要とする情報と、提示した進め方を照合します。原因に対応する行動だけを変えれば、次回のレビューで何が効いたかを追いやすくなります。
施策を実施した後は、その施策を適用した対象が商談化を判断できる段階まで進んでから比較します。記録が不足していれば判定を保留し、改善が見られなければ、実行されなかったのか、原因の見立てが違ったのかを確認します。
見積提示後の失注も、理由の分類で終わらせません。確認できた顧客の理由と担当者の推測を分け、提案の修正で対応できるものは営業へ、提供内容の検討が必要なものは関係部門へ渡します。再検討の余地がある顧客については、再開する条件と連絡の時点を記録し、継続的な情報提供へつなげます。
ダッシュボードを会議の順番に並べる
営業会議用ダッシュボードには、目標、パイプライン、注力案件、受注・失注、KPIというように、アジェンダの順番でレポートを並べます。集計を見る場所と、根拠となる取引を確認する場所を行き来できる運用にします。
各レポートには、判断する内容を対応させます。パイプラインが不足していれば、まず既存案件の金額と受注時期の根拠を確認します。その結果、対象期間に進められる既存案件があれば支援を検討し、不足が残るなら新しい商談の創出と着地見通しの修正を分けて決めます。
また、入力不足の案件を把握できるようにします。必要情報が欠けている案件を集計から外した場合は、その範囲を明示してください。表示されている金額だけで全体を判断すると、情報不足を営業上の不足と取り違えるおそれがあります。
会議で判断するたびに、原因の見立て、選んだ行動、担当者、期限、見直す条件を残します。次回は同じ数字を眺めるだけでなく、その判断が何を変えたかを確認します。
型化で起こりやすい失敗と限界
営業マネジメントの型は、現場で判断に使えるかを基準に見直します。企業様によって最適な形は異なります。商談の進み方、顧客の決裁手順、担当者の役割を踏まえ、共通化する範囲と個別に判断する範囲を定めます。
KPIと入力項目を増やしすぎる
入力項目を追加するときは、その情報で誰が何を判断するか、どの業務で取得できるかを先に決めます。「あると便利」という理由だけでは、入力を求める場面も使う場面も曖昧になります。
運用中に情報不足で判断できなかった場合は、項目を追加する前に、既存の活動履歴やプロパティで確認できないかを調べます。
新しい項目が必要なら、次の点を決めてから追加します。
- 入力担当者 ── 誰が入力するか
- 入力時点 ── どの場面で入力するか
- 使う会議 ── どの会議で判断に使うか
使われなかった項目は、レポートや自動化、ほかの業務で参照されていないかを確認します。参照先がある場合は、影響を整理してから表示や入力要件を変更します。項目の数ではなく、必要な情報を無理なく更新でき、判断へ使えることを基準にします。
フォーキャストを報告だけに使う
予測が目標を下回った場合は、その差を隠さず示したうえで、支援可能な案件、商談創出で補う範囲、期間内には埋められない範囲を分けます。
受注確度を高く変更するだけで、予測を目標へ近づける運用は避けます。確率の見直しでは、同じステージ定義で運用された案件について、そのステージへ到達した後の受注・失注を確認します。現在そのステージに残っている案件だけを見て、過去の受注傾向と判断しないようにしてください。
受注時期がずれたことと、最終的に受注しなかったことも分けます。時期のずれが主因なら、確率を変更する前にクローズ予定日の確認方法を見直します。ステージ定義を変更した場合は、変更前後のデータを同じ条件の実績として混ぜないようにします。
- 時期の差が続くなら ── 顧客の決裁予定をいつ誰が確認するかを見直します
- 結果の差が続くなら ── ステージ移行時に確認する顧客側の事実を点検します
- 記録の差が続くなら ── 入力の担当者と更新時点を整えます
原因が異なれば、直すべき運用も異なります。
1on1をマイクロマネジメントにしない
活動件数だけを評価すると、何のための行動かが見えなくなります。件数が不足しているように見える場合も、担当する顧客や案件段階、記録の範囲を確認してから話し合います。
本人が実行できる行動、社内の支援が必要な行動、顧客の判断を待つ事項を分けてください。担当者自身が進め方を提案し、マネージャーは障害の解消と必要な判断を担います。
進行中の案件をすべて細かく指示するのではなく、事前に決めた条件へ該当したときに相談する運用も選べます。相談条件は、例えば次のようなものを共有します。
- 顧客との合意日程を超過した
- 提案範囲が変わった
- 社内権限を超える判断が必要になった
システムで扱える範囲を見極める
- システム ── 定義した条件での集計や情報の整理を任せます
- マネージャー ── 顧客の発言をどう解釈するか、案件へ支援を配分するか、メンバーへ何を問いかけるかを判断します
未入力は、顧客の検討が進んでいないことと同じではありません。活動記録がない場合も、活動していないのか記録していないのかを確かめる必要があります。表示された状態と、その原因を分けて扱うことが、CRMを判断に使う前提です。
システムで制御する範囲は、入力経路や利用環境を踏まえて設計します。制御だけで扱えない部分は、確認担当者と見直す場面を運用へ組み込みます。
導入を営業プロセスの改善へ結びつける考え方は、「SFA導入で営業組織はどう変わる？導入メリットと成功のための5つの条件」で解説しています。案件管理や営業施策など、関連するテーマを探す際はセールスマネジメントカテゴリをご覧ください。
よくある質問
営業マネジメントをCRMで型化するときに、設計や運用で迷いやすい点を整理します。着手する順序、データを予測に使える条件、1on1の頻度を見直す場面、CRMへ実装する範囲を確認できます。
Q. 営業マネージャーになったばかりの場合、何から始めればよいですか？
まず、営業会議で何を決めるかを明確にし、現在の案件で判断できない場面を確認します。取引ステージ、金額、クローズ予定日、次の行動を見て、共通の基準で案件を説明できるかを確かめてください。
定義が担当者ごとに違うなら、ダッシュボードを増やす前に基準をそろえます。定義は共通でも未入力なら、更新する場面と担当者を決めます。情報がそろっているなら、パイプライン全体、受注・失注、停滞案件を会議用にまとめます。
会議の最後には、担当者、期限、完了条件を設定したタスクを残します。次回、その行動で何が判明したかを確認できれば、報告から判断・実行へつながる運用を始められます。
Q. フォーキャストの精度を上げるには、商談データをどの程度蓄積すればよいですか？
必要な件数を一律に決めるより、同じ定義で記録された案件を追跡できるかを確認します。ステージへ到達した時点、受注・失注の結果、金額、クローズ日が結びつき、進行中の案件と結果が確定した案件を区別できることが前提です。
比較する際は、商材や営業プロセスが異なる案件を混ぜず、定義を変更した前後も分けます。受注した案件だけが残っていたり、失注の記録が欠けていたりする場合は、そのまま確率の根拠にしません。
比較できる実績が整うまでは、加重金額の前提を明示し、案件ごとの金額・時期の根拠と併せて判断します。予測が外れたら、時期、金額、結果、記録のどこで差が生まれたかを分けてから、確率や入力ルールを見直します。
Q. 1on1はどのような頻度で行えばよいですか？
前回決めた行動を振り返れ、必要な支援が顧客の判断に間に合う間隔で設定します。案件の変化の速さ、本人の経験、マネージャーへ相談する事項の多さを基に決めます。
会議を待つ間に顧客との合意日程を過ぎる、社内の支援待ちが続くといった場合は、間隔を短くするか、随時相談する条件を設けます。毎回新しい情報がなく、本人が合意した範囲で進められている場合は、間隔を見直します。
頻度を変えても、前回の行動、案件、KPI、課題、次の行動というアジェンダを共通化し、実行結果と支援の必要性を確認します。
Q. HubSpot以外のCRMでも同じ考え方を使えますか？
指標の定義をそろえ、案件の事実と見立てを分け、会議で決めた行動を記録する考え方は、CRMを問わず適用できます。判断の基準を文書化しておけば、利用するシステムが変わっても引き継ぐ対象が明確になります。
ただし、必須入力、ステージ移行の制限、フォーキャスト、ダッシュボード配信などの実装方法は製品や契約内容によって異なります。必要な運用を先に定義し、システムで制御する部分と担当者が確認する部分を分けます。
実装後は、通常の案件だけでなく、予定日が未確認の案件やステージを戻す案件でも、必要な情報と判断理由が残るかを確認します。運用上の例外まで扱えることを確かめてから、適用範囲を広げます。
まとめ
営業マネジメントの型化では、KPI、フォーキャスト、1on1、営業会議を、同じCRMデータと判断基準でつなぎます。
- KPIは分母・分子・対象期間を定義し、同じ条件で比較してから改善する段階を選びます。
- フォーキャストは金額、ステージ、受注時期の根拠を分け、未確認事項を明示します。
- 予測と実績の差は取引単位で分解し、入力ルール、日程確認、ステージ定義のどこを見直すか判断します。
- 1on1では本人が実行する行動と必要な支援を分け、実行結果から見立てを更新します。
- 営業会議では担当者、期限、完了条件、見直し条件を残し、次回に判断の結果を確認します。
着手するときは、現在の営業会議で判断できない場面を洗い出し、次の順序で整えてください。
- 会議で決めることを定め、その判断に必要なKPIと案件情報を選びます。
- 指標の集計条件、取引ステージの定義、情報を更新する場面をそろえます。
- ダッシュボードの数字と取引を照合し、説明できる状態で会議へ使います。
- 会議と1on1で決めた行動を取引レコードへ戻し、次回は実行結果と判明した事実を確認します。
- 判断できなかった原因に応じて、入力項目、集計方法、支援の進め方を見直します。
CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのStartLinkまでお気軽にお問い合わせください。
あわせて読みたい
このテーマと関連する内容を、次の記事でも詳しく解説しています。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
