資料DL 無料相談 →

商談管理の基本と実践｜案件の進捗を正しく把握し受注確度を高める方法

  • 2026年3月3日
  • 最終更新: 2026年10月19日
deal-management-best-practices
この記事の結論

商談管理の方法は、ステージ・受注確度・金額・時期・次の行動を同じ基準で更新することです。判断基準をそろえ、入力とレビューを仕組み化することが核心です。

ブログ目次


商談管理の方法は、ステージ・受注確度・金額・時期・次の行動を同じ基準で更新することです。判断基準をそろえ、入力とレビューを仕組み化することが核心です。

「売上の着地が月末まで見えない」「担当者によって受注確度の判断が違う」「重要な案件の停滞を失注後に知る」——こうした状態では、案件が増えても営業組織として状況を把握できません。

商談管理とは、営業案件の進捗、受注確度、金額、受注見込み時期、次の行動を共通の基準で記録し、受注までの判断と行動をそろえることです。方法の要点は、パイプラインの定義と日々の更新、商談レビューを一つの流れにすることにあります。

本記事は「SFA導入で営業組織はどう変わる？導入メリットと成功のための5つの条件」シリーズの一部です。


この記事でわかること

商談管理を属人的な報告から、データに基づいて判断できる仕組みへ変える方法を整理します。設計だけで終わらせず、日々の更新とレビューまでつなげて解説します。

  • 商談管理でそろえる情報 — ステージ、受注確度、金額、時期、次の行動をどのように管理するかがわかります。
  • パイプラインの設計方法 — 取引ステージ、受注確度、ステージ定義、必須入力プロパティを一体で設計する考え方を解説します。
  • 受注確度の判断基準 — BANTとMEDDICを使い、担当者の感覚に依存しない判断基準を作る方法を整理します。
  • フォーキャストと停滞案件の管理 — 予測と実績のずれを見直し、動いていない案件を早めに把握する方法を紹介します。
  • 運用を定着させる進め方 — 入力項目を絞り、商談レビューとSFA/CRMを同じ情報で運用する手順がわかります。

「売上予測の精度が低く経営層への報告に苦労している」「案件の停滞に気づくのが遅れがち」という方に、特におすすめの内容です。

読み終えるころには、自社の商談ステージと必須入力項目を書き出し、パイプラインの最初の設計に進められます。

商談管理の課題ごとに、最初に見直す場所を次の表で選べます。

今の課題 最初に見直すもの HubSpotでの設定場所
月末まで着地が読めない ステージの成約確度とフォーキャスト設定 設定 > オブジェクト > 取引 > パイプライン、フォーキャスト
担当者ごとに確度の付け方が違う ステージの通過条件と必須入力プロパティ パイプラインの各ステージの条件付きロジック
止まっている案件に気づくのが遅い 滞在期間と最終活動日で絞った取引ビュー 取引一覧のフィルター（現在のステージでの滞在時間 など）
会議が報告会で終わる ダッシュボードと予測提出の運用 営業 > フォーキャスト、レポート > ダッシュボード

商談管理の方法を理解する｜Excel管理から一元管理へ

Excelやスプレッドシートによる商談管理は、管理項目をすぐに作れる反面、更新の重複や情報の分散が起こりやすい方法です。担当者ごとに別のファイルを持つと、どの情報が新しいのか判断しにくくなります。商談管理を営業活動の基盤にするには、案件情報と活動履歴を同じ場所で更新できる状態が重要です。

Excelや口頭報告だけでは判断が遅れる

Excelで案件名、金額、確度を管理し、メールやチャットで補足を共有していると、情報を集め直さなければ全体像が見えません。更新日が異なる複数の表を照合する作業も発生し、営業会議が現状報告だけで終わりやすくなります。

SFA/CRMに情報を一元化すると、担当者が入力した商談情報と活動履歴を、営業担当者とマネージャーが同じ状態で参照できます。入力先を集約することは、単なる転記作業の削減ではなく、判断に使うデータをそろえる取り組みです。

管理方法 起こりやすい状態 改善の方向
担当者別のExcel 更新時点や項目がそろわない 案件レコードを共通の入力先にします
メールやチャットでの報告 会話の中に重要情報が埋もれる 商談の活動履歴と次の行動を記録します
口頭だけの確度判断 判断根拠を引き継げない 確度を顧客の状態や確認項目と結び付けます
会議前の集計作業 集計に時間がかかり、議論が浅くなる 会議前にパイプラインを参照できる状態にします

商談ごとに管理する情報をそろえる

商談管理では、案件名だけでなく、どこまで進んでいるか、どのような根拠で受注を見込んでいるか、次に何をするかを一緒に記録します。情報がそろうと、担当者が不在でも状況を読み取りやすくなり、新しい担当者への引き継ぎにも使えます。

管理項目 記録する内容 判断に使う場面
商談ステージ 顧客の検討状況 案件がどこまで進んでいるかを見ます
受注確度 成約可能性とその根拠 売上予測と優先順位を考えます
金額 現時点の見込み受注金額 パイプラインの規模を把握します
時期 顧客の意思決定に基づくクローズ日 売上計上の見込み時期を考えます
ネクストアクション 担当者、行動、期限 案件を前へ進める動きを決めます

入力項目を増やしすぎると、更新そのものが目的になってしまいます。営業会議、フォーキャスト、引き継ぎのいずれにも使わない項目は外し、判断に必要な項目へ絞ることがポイントになってきます。

コンタクトから請求までの流れに商談管理を置く

商談管理は、コンタクトから取引を作成し、受注後に顧客対応や請求へ引き継ぐ一連の流れの中にあります。取引だけを独立して管理すると、誰との会話から案件が生まれ、受注後に何を引き継ぐのかが切れてしまいます。

業務の流れ 主に扱う情報 商談管理との関係
コンタクト 顧客情報、接点、活動履歴 商談化までの背景を取引へつなぎます
取引 ステージ、確度、金額、時期 営業判断とフォーキャストの中心です
顧客 契約内容、対応履歴 受注時の合意事項を引き継ぎます
請求 請求対象、金額、時期 受注情報との食い違いを防ぎます
失注後 失注理由、再接触の条件 掘り起こしの対象と時期を整理します

この流れを同じ基準で管理すると、営業担当者だけでなく、マーケティングや受注後の担当者も必要な情報をたどれます。CRMは案件を保存するデータベースではなく、部門間で顧客情報と判断をつなぐ仕組みとして設計することをおすすめします。


パイプラインを四つの要素で設計する

商談管理の中心となるのがパイプラインです。パイプラインは、取引ステージ、受注確度、ステージ定義、必須入力プロパティを組み合わせて設計します。どれか一つだけを決めても、営業担当者ごとの解釈が残るため、四つを同時に整理することが重要です。以下の画面は、HubSpotの取引をボードビューでステージごとに管理している例です。

要素 管理すべき内容 なぜ重要か
1. 商談ステージ 現在の進捗段階（初回接触〜受注/失注） 案件の進捗を客観的に把握するため
2. 受注確度 受注に至る可能性の度合い（%表記） 売上予測（フォーキャスト）の基礎データ
3. 金額 見込み受注金額 パイプラインの総額把握と優先順位判断
4. 時期 受注見込み時期（クロージング予定日） 月次・四半期の売上着地予測
5. ネクストアクション 次に取るべき具体的な行動 案件を前に進めるための行動を漏れなく実行するため

HubSpotの取引ボードビュー

取引ステージは受注率が変化する地点で分ける

ステージは、営業担当者が作業を終えた時点ではなく、顧客の意思決定が進んだ時点で変更します。「提案書を送付した」だけでは顧客の状態が変わっていない可能性があるため、「顧客が提案内容の評価に入った」といった状態を基準にします。

ステージを細かくしすぎると、更新作業が増える一方で、各ステージの違いが曖昧になります。反対に粗すぎると、停滞箇所や受注率が変わる地点を分析できません。顧客の検討が進み、営業の次の行動が変わる地点を境目にするのが考え方の基本です。

受注確度はステージの事実と結び付ける

受注確度は、担当者の期待ではなく、各ステージに到達した案件がどの程度受注したかという実績と、顧客から確認できた事実をもとに設定します。

HubSpotのパイプライン設定では、ステージ名と取引確度を編集し、特定ステージへ移動するときに表示するプロパティを設定できます。プロパティを必須にすると、値が入力されるまでレコードを更新できない運用も可能です。（出典：HubSpot「オブジェクトパイプラインのセットアップと管理」）

ただし、システムに確度を設定しただけでは判断基準はそろいません。各確度がどの顧客状態を表すのかを文章にし、営業担当者とマネージャーが同じ根拠で更新できる状態まで整えます。

ステージ定義と必須入力をセットにする

ステージ定義には、到達条件、次のステージへ進む条件、その時点で入力する情報を記載します。提案段階であれば、顧客の課題、決裁者、検討時期、提示金額など、次の判断に使う情報を整理します。

設計要素 決める内容 運用で防げる問題
取引ステージ 顧客の状態が変わる地点 担当者ごとの進捗解釈のずれ
受注確度 ステージと確認事実に対応する見込み 楽観的なフォーキャスト
ステージ定義 到達条件と通過条件 ステージの先行変更や放置
必須入力プロパティ 次の判断に必要な情報 金額やクローズ日の欠落

必須項目は、営業担当者を監視するためではなく、案件を前へ進めるための確認事項として設計します。新人でも次に何を確認すればよいかが入力画面からわかるため、個人の経験だけに依存しない商談管理につながります。


商談ステージを顧客の購買プロセスで定義する

商談ステージは、自社の営業作業ではなく、顧客の購買プロセスに合わせて設計します。顧客が検討を始め、比較し、社内の意思決定を経て契約する流れを整理すると、ステージの意味が明確になります。営業担当者が変わっても同じ結論になる通過条件を置くことが、運用の要点です。

ステージ 定義（顧客の状態） 通過条件（ゲート） 営業の主なアクション
1. 初回接触 顧客と初回の対話が成立した 顧客の課題感を確認、次回アクションを合意 アポイント獲得、初回ヒアリング
2. ニーズ把握 顧客の課題とニーズが具体的に明確になった BANT情報のうちN（ニーズ）とT（時期）を確認 深掘りヒアリング、課題の構造化
3. 提案 顧客に解決策を提示し、検討が始まった 提案書/デモを実施、決裁者を特定済み 提案書作成、プレゼンテーション
4. 評価・比較 顧客が自社提案と他社を比較検討している 競合の存在と比較軸を把握、見積書を提出 差別化ポイントの訴求、条件交渉
5. 最終交渉 顧客が最終的な意思決定のプロセスに入った 口頭内諾または社内稟議が開始 契約条件の最終調整、稟議資料の支援
6. 受注/失注 成約または失注で商談が完了した 契約締結、または失注理由の記録完了 契約手続き、オンボーディング準備

主観ではなく客観的なゲートを置く

「感触が良い」「前向きに見える」といった表現では、同じ商談でも担当者によってステージが変わります。「顧客の課題を確認した」「決裁者を特定した」「見積書を提示した」など、記録で判定できる事実をゲートにします。

ゲートを設けるときは、顧客の状態と営業の行動を分けて書きます。営業が資料を送ったことと、顧客が評価に入ったことは同じではありません。顧客側の状態をステージ定義に置き、営業の行動は次のアクションとして管理します。

次の表は、ゲートが曖昧なまま運用した場合に起こりやすい問題と、その原因を整理したものです。

問題 具体的な症状 原因
ステージの曖昧さ 「提案中」と「交渉中」の境目が不明確 ステージの通過条件が定義されていない
確度の属人性 同じ状況の案件でも担当者により確度が50%と80%に分かれる 確度判断の客観的基準がない
金額の不正確さ 見積前なのに受注金額が入力されている 金額更新のルールが不明確
時期の先送り クロージング予定日が毎月先に延びる 予定日が「希望」で設定されている
アクションの不在 次のアクションが空欄のまま放置 商談レビューの仕組みがない

ステージ定義テンプレートを作る

商談ステージは、次のように顧客の状態、通過条件、営業の行動を分けられます。名称はそのまま使うのではなく、自社の購買プロセスで実際に起きる状態に合わせて見直します。

ステージ 顧客の状態 通過条件 営業の主な行動
初回接触 顧客との対話が始まっています 課題の概要と次の接点が合意されています 初回ヒアリングを行います
ニーズ把握 解決したい課題が具体化しています ニーズと検討時期が確認されています 課題と検討背景を整理します
提案 解決策の評価が始まっています 提案内容が顧客へ共有されています 提案とデモを行います
評価・比較 比較軸に沿って検討しています 競合と意思決定基準が把握されています 差異と条件を整理します
最終交渉 社内の意思決定へ進んでいます 契約上の障壁と決裁プロセスが把握されています 契約条件を調整します
受注・失注 意思決定が完了しています 契約または失注理由が記録されています 引き継ぎまたは掘り起こし条件を整理します

自社の営業プロセスに合わせて絞り込む

同じ商材でも、顧客が比較検討する流れや、決裁に関与する人は異なります。パイプラインを作る前に、営業マネージャーと成果を出している担当者の知見を集め、実際の受注案件と失注案件がどのように進んだかを整理します。

最初から細かな分岐をすべて実装するのではなく、主要なステージと管理項目から始めます。運用後に「同じステージなのに受注率や次の行動が大きく異なる」とわかった地点があれば、その時点でステージの分割や定義の修正を検討します。


受注確度をBANTとMEDDICで客観化する

受注確度は、商談管理で属人性が表れやすい項目です。高い確度を入力するには何が確認できているべきかを決め、判断根拠を商談レコードへ残します。BANTやMEDDICは、その確認項目をそろえるために利用できます。

BANT確認状況 確度の傾向 ステージとの対応
0〜1項目確認済み 低 初回接触〜ニーズ把握
2項目確認済み 低〜中 ニーズ把握〜提案
3項目確認済み 中 提案〜評価・比較
4項目すべて確認済み 高 最終交渉
口頭内諾あり 最も高い 最終交渉（契約待ち）
項目 確認内容 確認のポイント
Budget（予算） 予算が確保されているか 予算額の規模感、予算確保の時期
Authority（決裁者） 決裁者は誰か、接触できているか 決裁者の氏名・役職、決裁プロセス
Needs（ニーズ） 解決すべき課題は明確か 課題の具体性、緊急度、解決しないリスク
Timeline（時期） 導入時期の目安はあるか 導入予定時期、検討スケジュール

BANTで商談の基本条件を整理する

BANTは、予算、決裁者、ニーズ、時期の観点で商談を整理するフレームワークです。項目が埋まっているかだけでなく、誰からどのように確認した情報なのかまで記録すると、レビューで確度の妥当性を判断しやすくなります。

項目 確認する内容 商談管理での使い方
Budget 予算の有無と確保時期 提案範囲と金額の前提を整理します
Authority 決裁者と決裁プロセス 誰の合意が必要かを明確にします
Needs 解決したい課題と影響 提案が課題に対応しているかを見ます
Timeline 導入時期と検討予定 クローズ日の根拠を整理します

BANTの項目が未確認であれば、高い確度へ変更する前に、次の商談で何を聞くかをネクストアクションへ落とします。この運用にすると、情報不足を担当者への注意だけで終わらせず、案件を進める行動へ変えられます。

MEDDICで複雑な意思決定を分解する

大型案件や意思決定に複数の関係者が参加する商談では、MEDDICを使って検討構造を詳しく整理します。顧客が効果を評価する指標、最終決裁者、選定基準、決裁手順、解決したい課題、社内の推進者を分けて記録します。

項目 内容 確認すべき情報
Metrics（指標） 顧客が導入効果を測定する指標 「どの数値がどの程度改善されれば導入成功か」
Economic Buyer（経済的決裁者） 最終的な購買決定権を持つ人物 氏名・役職・面談の可否
Decision Criteria（意思決定基準） 顧客が製品/サービスを選ぶ基準 機能、価格、サポート、実績等の優先順位
Decision Process（意思決定プロセス） 稟議・承認のフロー 稟議のステップ数、所要期間、関与者
Identify Pain（課題の特定） 顧客が解決したい具体的な課題 課題の具体的な内容と影響度
Champion（推進者） 社内で導入を推進してくれる人物 自社の提案を社内で推してくれるキーパーソン
項目 確認する内容 不明な場合の次の行動
Metrics 顧客が成果を判断する指標 提案の評価方法を顧客と整理します
Economic Buyer 最終的な購買決定者 決裁者との接点を作る方法を考えます
Decision Criteria 製品やサービスの選定基準 比較項目と優先順位を確認します
Decision Process 稟議や承認の流れ 関係者と予定を商談計画へ反映します
Identify Pain 解決したい課題と影響 課題を放置した場合の影響を整理します
Champion 顧客社内の推進者 推進者が説明に使える情報を用意します

ただし、確認項目を増やすほど入力負担も増えます。商談の複雑さに対してBANTで判断材料が足りるならBANTを使い、決裁構造や評価基準をより細かく管理したい商談ではMEDDICを使うという分け方が現実的です。

フレームワークとステージを連動させる

BANTやMEDDICをチェックリストとして独立させると、入力してもステージや確度に反映されない状態が生まれます。提案へ進む条件、最終交渉へ進む条件などに確認項目を割り当て、ステージ変更と情報更新を同じ操作にします。

MEDDIC確認状況 確度の傾向
Pain（課題）のみ特定 低
Pain + Champion特定 低〜中
Pain + Champion + Economic Buyer特定 中
上記 + Decision Criteria/Process把握 中〜高
6項目すべて確認済み 高
判断結果 選ぶ対応
顧客課題と次の接点が明確 現在のステージで提案準備へ進みます
決裁者や意思決定手順が不明 確度を上げず、確認行動を設定します
クローズ日に顧客側の根拠がない 希望日ではなく、検討予定に基づいて更新します
失注要因が明確になった 失注理由と再接触の条件を記録します

この連動によって、確度は担当者の自己申告ではなく、商談情報から説明できる値になります。マネージャーも「なぜこの確度なのか」を同じ画面で読み取り、支援する箇所を判断できます。


フォーキャストを更新し、予測と実績のずれを学習する

フォーキャストは、登録された商談の合計を見るだけでは作れません。金額、受注確度、クローズ日、顧客の意思決定状況をそろえ、どの案件を売上予測へ含めるかを決めます。さらに予測と実績のずれを振り返り、ステージ定義や確度を更新するところまでが商談管理です。

指標 計算方法 目標値
フォーキャスト精度（月次） 実績 ÷ 予測 × 100% 85〜115%の範囲内
ステージ別の確度精度 各確度帯の案件のうち実際に受注した割合 設定確度±10%以内
クロージング日の精度 予定日と実際の受注日の乖離 ±2週間以内
カテゴリ 定義 期待コンバージョン率
Commit（確約） 口頭内諾あり、契約手続き中 90〜95%
Best Case（最良ケース） 最終交渉中、競合優位 60〜70%
Pipeline（パイプライン） 提案中〜評価中、まだ不確実要素あり 20〜30%
Upside（上積み） 初期段階、楽観的に見れば可能性あり 5〜10%
案件 金額 確度 加重金額
丸山製作所 新規導入 500万円 70% 350万円
日本通信工業 アップセル 300万円 50% 150万円
東邦テクノロジーズ リプレース 800万円 30% 240万円
ライトウェーブ 新規導入 200万円 90% 180万円
合計 1,800万円 — 920万円

加重パイプラインで期待値を見る

加重パイプラインは、案件金額に受注確度を掛けた加重金額を合計する考え方です。案件金額の単純合計よりも、各案件の進捗を反映した予測を作れます。

ただし、受注確度が担当者の感覚で入力されていると、加重金額も同じ偏りを持ちます。先にステージ定義と確度の根拠をそろえ、その後に加重パイプラインをフォーキャストへ利用します。

カテゴリ別に着地の幅を考える

案件をCommit、Best Case、Pipeline、Upsideなどのカテゴリに分けると、どこまでを着地見込みとし、どこからを上積みとして扱うかを整理できます。カテゴリ名だけで判断せず、顧客の合意状況や残っている障壁を定義に含めます。

カテゴリ 定義の考え方 レビューで判断すること
Commit 契約へ向けた手続きと残課題が明確です 未完了の手続きと担当者を決めます
Best Case 最終判断へ進んでいますが障壁が残っています 障壁を解消する行動を決めます
Pipeline 提案や評価の途中です 次のステージへ進む条件を確認します
Upside 商談の初期で判断材料が不足しています 優先順位と情報収集の方法を決めます

カテゴリは楽観的な案件を積み上げるためではなく、予測の前提を説明するために使います。経営層へ報告するときも、単一の合計だけでなく、どの前提までを含めた予測なのかを明らかにできます。

予測と実績のずれから定義を直す

フォーキャストの精度は、予測を作った時点ではなく、実績と比べて検証したときに改善できます。ずれの方向を分けて見ると、どの運用を修正すべきか判断できます。

見つかったずれ 考えられる原因 次に行う修正
予測が実績より高い状態が続く 確度やステージ移行が楽観的です 通過条件を厳しくし、根拠項目を追加します
クローズ日が繰り返し後ろへ動く 顧客の予定ではなく営業の希望日が入っています 顧客側の意思決定予定を入力根拠にします
受注案件が予測に含まれていない 商談登録や更新が遅れています 商談登録のタイミングを明文化します
特定ステージで失注が集中する ステージ内に異なる状態が混在しています 定義の修正やステージ分割を検討します

予測のずれを担当者の能力だけに結び付けると、同じ問題が繰り返されます。入力ルール、ステージ定義、レビュー方法のどこに原因があるかを分け、仕組み側を修正します。


HubSpotでパイプラインとフォーキャストを設定する手順

ここまでの設計を、HubSpotの設定画面に落とし込む順序を示します。メニュー名は公式ナレッジ（パイプラインの設定とカスタマイズ、フォーキャストツールの設定）で確認したものです。

  1. 上部ナビゲーションバーの設定（歯車）から、左サイドバー「データ管理」の「オブジェクト」で「取引」を選び、「パイプライン」タブを開きます。
  2. 対象パイプラインを開き、「ステージを追加（Add stage）」でステージ名と「Deal probability（成約確度）」を設定します。成約（100%）と失注（0%）のステージは、レポートを正しく集計するために両方必要です。
  3. 失注ステージの「条件付きロジックのルール」で、失注理由を必須プロパティにします。商談を進める途中のステージでも、通過条件に当たる項目（決裁者・予算確認など）を必須にできます。
  4. 設定（歯車）の「オブジェクト」から「フォーキャスト」を開き、「Forecast deal amount」で加重金額（金額×成約確度）か合計金額かを選び、予測期間（月次か四半期）を決めます。期間を変えると売上目標と予測提出がリセットされるため、最初に決めます。
  5. 「パイプライン」タブで、各ステージを予測カテゴリ（Not forecasted／Pipeline／Best case／Commit／Closed won）に割り当てます。「Automate forecast categories」をオンにすると、ステージ移動時にカテゴリが自動で更新されます。
  6. 営業 > フォーキャストを開き、チームの売上目標を作成して、毎週の営業会議で使う予測の提出を始めます。

フォーキャストツールは Sales Hub または Service Hub の Professional／Enterprise が対象で、設定には Super Admin 権限が必要です（出典：Set up the forecast tool、Use the forecast tool）。

ステージ設計の例として、次の表のように、成約確度と予測カテゴリを事実で結び付けます。確度の数値は自社の過去の受注率に合わせて調整する前提の例です。

ステージ名（例） 成約確度（例） 予測カテゴリ（例）／通過条件
初回商談 10% Pipeline／課題と検討時期を確認した
ニーズ確認・提案 30% Pipeline／決裁者と予算の目安を確認した
見積提示 60% Best case／見積を提出し、比較検討の条件を確認した
稟議・最終交渉 80% Commit／契約条件と稟議日程を確認した
受注 100% Closed won／契約締結または発注書を受領した
失注 0% Not forecasted／失注理由（必須）を入力した

最初から全パイプラインを設定せず、一つの商材のパイプラインで1か月ほど運用し、予測と実績のずれを見てから確度の数値を直します。後から変えにくい設定（内部名、通貨、パイプライン構成）は HubSpotで後から変えにくい設定 で先に確認してください。


停滞案件と失注リスクを早めに見つける

パイプラインでは、進んでいる案件だけでなく、動いていない案件を見つけることも重要です。長く更新されていない案件が残ると、パイプライン総額やフォーキャストが実態より大きく見えます。ステージごとに停滞条件を決め、該当した案件の次の行動を選べる状態にします。

リスクシグナル 具体的な兆候 対策
コミュニケーション頻度の低下 メール返信が遅い、電話に出ない 別チャネル（手紙、SNS等）での接触を試みる
窓口担当者の変更 キーパーソンが異動・退職 新担当者との関係構築を最優先で実施
競合の台頭 「他社も検討している」という発言 差別化ポイントの再訴求、事例の追加提供
意思決定の先送り 「来期に再検討」という回答 先送りのリスク（機会損失等）を提示
予算の縮小・凍結 「予算が厳しくなった」という発言 スモールスタートプランの提案、ROI試算の提供

ステージごとに停滞条件を決める

停滞の意味はステージによって異なります。初回接触では次回の接点がないこと、提案後では顧客の反応や評価予定がないこと、最終交渉では契約上の障壁が解消されていないことが検知条件になります。

ステージ 停滞とみなす基準 対処アクション
初回接触 2週間以上次のアクションがない マネージャーがフォロー方針を協議
ニーズ把握 30日以上ステージが変わらない 顧客の検討状況を再確認する架電
提案 3週間以上反応がない 別のアプローチ（他部門紹介、事例提供等）を検討
評価・比較 45日以上決着がつかない 決裁者への直接アプローチ、条件見直し
最終交渉 30日以上契約に至らない 契約障壁の確認、特別条件の検討

固定した期間だけで停滞を決めると、商談期間が異なる案件を同じ基準で扱うことになります。ステージ滞在期間に加えて、次のアクション、最終活動日、顧客の検討予定を組み合わせて判断します。

ネクストアクションを実行可能な形で残す

「フォローする」「状況を確認する」だけでは、次に何をするのかが引き継げません。担当者、実施内容、期限、完了条件を記録し、商談レビューでは未完了の理由と次の対応を決めます。

通知を増やしすぎると、対応すべき案件が埋もれます。通知対象は、受け取った担当者が具体的な行動を選べる条件に絞り、行動につながらない通知は条件から外していきます。

失注を掘り起こしへつなげる

失注は、商談管理の終点ではありません。失注理由、再検討の可能性、再接触する条件を記録すると、マーケティングや営業による掘り起こしへつなげられます。

再接触の予定がない案件と、条件が変われば再検討できる案件を分けることが重要です。失注した取引をそのまま受注確度の高いステージへ戻すのではなく、一度失注として記録し、新しい検討が始まった時点で商談を更新します。これにより、過去の失注と新しい商談機会を混同せずに分析できます。


商談レビューとSFA/CRM運用を定着させる

商談管理は、入力ルールを作るだけでは定着しません。営業会議や個別レビューでSFA/CRMのデータを使い、その場で決まった内容を同じレコードへ戻す運用が必要です。入力、判断、行動、振り返りを一つの循環にします。

パイプラインレビューと案件レビューを分ける

パイプラインレビューでは、全体の金額、ステージ分布、フォーキャスト、停滞案件を見ます。案件レビューでは、重要な商談についてBANTやMEDDIC、失注リスク、次の行動を掘り下げます。

アジェンダ 所要時間 内容
パイプライン全体の確認 5分 総額、件数、ステージ別分布
今月のフォーキャスト更新 5分 Commit/Best Case/Pipelineの更新
停滞案件の対応協議 15分 停滞案件のリストを確認、対策を協議
重点案件のアクション確認 10分 今週クロージング予定の案件の最終確認
来週の優先事項 5分 各メンバーの重点アクションを合意
レビュー 主な目的 会議で決めること
パイプラインレビュー 全体の健全性と売上見込みを把握します 優先案件、停滞案件、フォーキャストを決めます
案件レビュー 個別商談の進め方を整理します リスク、支援内容、次の行動を決めます

基本情報の読み上げに時間を使うのではなく、参加者が事前に取引レコードを読める状態にします。会議では判断が必要な差分を扱い、決まったネクストアクションを担当者と期限がわかる形で記録します。

以下の表は、案件レビューで担当者に投げかける質問と、その目的を整理したものです。

質問 目的
この案件のBANT（またはMEDDIC）の状況は？ 確度の客観的な確認
次のアクションは何で、いつまでに実行するか？ 案件を前に進める具体的な行動の確認
この案件を失注するとしたら、どのような理由か？ リスクの先読みと事前対策
競合はどこで、自社の優位点は何か？ 差別化戦略の確認
マネージャーとして何をサポートできるか？ マネージャーの介入ポイントの特定

入力項目を最小限にして仕組みでそろえる

利用目的がないプロパティを増やすと、営業担当者はどこまで入力すればよいか判断できません。営業プロセスの進行、フォーキャスト、引き継ぎ、分析に使う項目へ絞ります。

入力漏れへの対応も、担当者へ繰り返し注意するだけでは定着しにくいものです。ステージ移行時の必須入力、未入力レコードのビュー、停滞条件の通知などを使い、必要な情報が自然にそろう設計へ変えます。

ただし、入力を厳しくしすぎると、確認できていない情報を仮の値で埋める運用が起こります。未確認を選べる項目と、ステージ移行に必要な項目を分け、事実がない段階で推測値を入れなくても進捗を管理できる形にします。

次の表は、商談管理を定着させるための代表的な施策と、期待できる効果を整理したものです。

施策 内容 効果
入力ルールの明文化 商談登録のタイミング、ステージ変更のルール、更新頻度を明文化 運用のバラつきを防止
商談データを営業会議の唯一の情報源にする 「SFA/CRMに入っていない案件は会議で議論しない」ルールを設定 入力のインセンティブを創出
ダッシュボードの全員公開 パイプラインのダッシュボードをチーム全員がいつでも確認できる状態にする 透明性の向上と健全な競争意識
月次の精度検証 フォーキャストと実績の乖離を毎月検証し、フィードバック フォーキャスト精度の継続的な向上
マネージャー自身がSFA/CRMを活用する姿を見せる マネージャーがダッシュボードを日常的に確認し、データに基づく指示を出す 「上が使っているから自分も使う」文化の醸成

小さく始めて運用結果から広げる

商談管理の仕組みを一度に作り込むと、現場が使う前に設定が複雑になります。最初は主要ステージと基本項目をそろえ、営業会議で使える状態を目指します。その後、停滞検知、フォーキャスト、レポート、自動化へ段階的に広げます。

段階 実施すること 次へ進む基準
最初 ステージ定義と基本項目をそろえます 進行中の商談を同じ基準で読めます
次 BANTやMEDDIC、停滞条件を追加します レビューで根拠と次の行動を決められます
拡張 ダッシュボードや通知を整えます 同じデータで予測と振り返りを行えます

SFA/CRMの画面を整えること自体が目的ではありません。営業担当者が案件を進めやすく、マネージャーが支援箇所を判断でき、受注後の担当者が必要な情報を引き継げる状態を運用の完成形として考えます。

BtoBマーケティングの全体像はBtoBマーケティング完全ガイドで体系的にまとめています。また、このテーマのカテゴリ全体はCRM基礎・導入で網羅しています。


商談管理を定着させる支援の進め方

StartLinkはHubSpotゴールドパートナーとして、150社以上のHubSpot支援に携わっています。商談管理では、ツールの設定より先に「営業会議で何を決めるか」を整理するところから始めます。支援の全体像は HubSpot導入・構築支援 に掲載しています。

  1. 現状の整理・要件定義 ── Excelや既存SFAの商談管理表、ステージ、確度、入力項目を一覧にし、会議で使う数字を決めます。
  2. 設計・構築 ── ステージ定義、成約確度、必須入力、予測カテゴリ、ダッシュボードを設計して設定します。
  3. データ移行 ── 既存の案件を移し、件数・金額・クローズ日・担当者を突合します。
  4. テスト・検証 ── 実際の案件数件を使い、ステージを動かして必須入力と予測への反映を確かめます。
  5. 定着・運用改善 ── 週次レビューで予測と実績のずれを見て、定義を直します。

スモールスタートで一つのパイプラインから始め、準委任で運用に伴走します。入力の手間を減らしたい場合は、AI（Breeze・Claude など）を業務設計に組み込む方法も検討します（HubSpot×AI）。週次のレビュー会議の作り方は 週次パイプラインレビューとデータ品質ダッシュボード、分析の進め方は 営業データ分析入門 で解説しています。


よくある質問

商談管理を始める際に判断に迷いやすい点を整理します。ツールの選定より先に、管理基準と利用目的を明確にすることが重要です。

商談管理はExcelのままでも運用できますか？

案件情報を一人で管理し、更新する人と利用目的が限られている間は、Excelでも基本情報を整理できます。複数人での更新、活動履歴との連携、停滞案件の抽出、フォーキャストの集計が必要になった段階では、SFA/CRMへ集約する判断が適しています。

BANTとMEDDICは両方使うべきですか？

同じ商談へ両方を一律に適用する必要はありません。予算、決裁者、ニーズ、時期で判断できる商談はBANTを使い、意思決定者や選定基準、承認手順まで詳しく管理する商談ではMEDDICを選びます。選択基準を商材や営業プロセスと結び付けておくと、担当者が迷いにくくなります。

比較項目 BANT MEDDIC
適した商談規模 中小〜中規模 大規模・エンタープライズ
適した商談期間 1〜3ヶ月 3ヶ月〜1年以上
確認の深さ 基本4項目 6項目で多面的に評価
運用の容易さ シンプルで導入しやすい 理解と習熟に時間がかかる
精度 中 高

受注確度が担当者ごとに違う場合はどう改善しますか？

各確度を顧客の状態、ステージの通過条件、BANTやMEDDICの確認状況と結び付けます。商談レビューでは確度の数値だけを直すのではなく、その根拠が取引レコードに残っているかを見ます。予測と実績のずれが続く場合は、担当者への注意ではなく、ステージ定義と確度基準を修正します。

SFA/CRMで最低限管理する項目は何ですか？

商談ステージ、受注確度、金額、クローズ日、担当者、ネクストアクションから始めます。加えて、受注確度を判断するために必要な顧客課題や決裁情報を、該当ステージの入力項目として設定します。利用目的のない項目は増やさず、営業会議や引き継ぎで使う情報を優先します。

停滞案件はどのように判断しますか？

ステージ滞在期間だけでなく、最終活動日、次のアクション、顧客の検討予定を組み合わせて判断します。条件に該当したら、継続、保留、失注のどれにするかを決め、継続する場合は担当者と次の行動を記録します。

HubSpotのフォーキャストツールはどのプランで使えますか？

フォーキャストツールは、Sales Hub または Service Hub の Professional／Enterprise で使えます。設定には Super Admin 権限が必要で、ユーザーにはフォーキャストの権限が要ります。最新の条件は公式ナレッジで確認してください。

HubSpotで成約確度を設定する場所はどこですか？

設定（歯車）の「データ管理」から「オブジェクト」で「取引」を選び、「パイプライン」タブでステージごとに「Deal probability（成約確度）」を設定します。成約と失注の両方のステージを含める必要があります。


まとめ

商談管理の方法は、情報を集めることではなく、同じ基準で案件を判断し、次の行動へつなげることです。パイプラインの設計と日々の運用を分けず、一つの仕組みとして整えます。

  • ステージ、確度、金額、時期、ネクストアクションを一元管理します。
  • 取引ステージ、受注確度、ステージ定義、必須入力プロパティをセットで設計します。
  • BANTやMEDDICをステージの通過条件と結び付け、確度の根拠を残します。
  • フォーキャストと実績のずれを振り返り、定義や入力ルールを修正します。
  • 停滞や失注を個人の問題にせず、検知条件とレビューの仕組みで対応します。

まずは、現在利用している商談一覧を開き、次の順で見直してください。

  • 現在のステージ名と、顧客側の状態を対応させます。
  • 各ステージで必要な情報と、次へ進む条件を言語化します。
  • 進行中の商談へ新しい基準を適用し、営業会議で差分を見直します。

CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのStartLinkまでお気軽にお問い合わせください。


あわせて読みたい

商談管理の運用ルールやCRMの活用範囲を詳しく検討する際は、次の記事も参考になります。既存の業務とデータをどのようにつなぐかを整理できます。

記事の内容を、そのまま実務に落とし込みたい方向け

HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。

サービス概要を見る 無料で相談する

次に読む

kintoneからHubSpotへの移行手順｜顧客・案件データ設計とCSV取込

Kintoneの複数アプリをHubSpotオブジェクトに再設計する方法｜関連付けはカバー率を実測してから設計する

kintoneからHubSpotへの移行 完全ガイド｜判断基準から手順・帳票・連携まで全体像を整理

あわせて読みたいBtoBマーケ実践ガイド

GTM

GTM戦略の設計ガイド

市場投入の順番、仮説設計、営業連携までを一気通貫で整理できます。

 Law

特定電子メール法ガイド

BtoBメール配信で外せない法対応と実務運用の注意点を確認できます。

 SEO

AIO対策の実践SEOチェックリスト

AI Overview時代に引用される記事構造と改善優先順位を整理できます。

 Service

BtoBマーケとCRM活用を相談する

集客、ナーチャリング、CRM整備まで成果につながる導線設計を支援します。

記事の内容を、そのまま実務に落とし込みたい方向け

無料で相談する 資料をダウンロード

株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。

関連キーワード:
AI HubSpot 取引管理 営業

サービス資料を無料DL

著者情報

7-1

今枝 / Imaeda

株式会社StartLink 代表取締役。累計150社以上のHubSpotプロジェクト支援実績を持ち、Claude CodeやHubSpotを軸にしたAI活用支援・経営基盤AXのコンサルティング事業を展開。
HubSpotのトップパートナー企業や大手人材グループにて、エンタープライズCRM戦略策定・AI戦略ディレクションを経験した後、StartLinkを創業。現在はCRM×AIエージェントによる経営管理支援を専門とする。