%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}
この記事の結論
営業プロセスを取引ステージで可視化し、受注確度・定義・必須項目をそろえてフォーキャストと日々の判断に生かします。
営業プロセスを取引ステージで可視化し、受注確度・定義・必須項目をそろえてフォーキャストと日々の判断に生かします。
「案件の一覧をスプレッドシートで管理しているが、更新のたびに担当者へ確認が必要になる」「取引ステージの名前は決めたものの、どの状態で次に進めるかが人によって違う」「営業担当者が報告する見込み金額と、実際に受注する金額の差が大きい」——こうした課題は、ステージ名だけを並べても解消しません。
HubSpotのパイプライン設計とは、商談の進行段階を取引ステージとして表し、各段階の受注確度、判定基準、必要な入力情報を定めることです。これらを営業プロセスに沿って設計すると、取引データを案件管理だけでなく、フォーキャストや受注後の請求情報の確認にもつなげやすくなります。
本記事では、HubSpotのパイプラインを設計する際の考え方と具体的な設定方法を解説します。取引ステージの分け方、受注確度の設定、必須プロパティ、パイプラインルールまで、順を追って見ていきます。この分野の体系的な情報はHubSpot機能ガイドでまとめています。
本記事は「AI × CRMで企業価値を上げる設計思想｜経営者が知るべきAI CRM戦略」シリーズの一部です。
本記事はStartLinkの「AI活用完全ガイド」関連記事です。
この記事でわかること
HubSpotのパイプラインを、案件の進捗管理から営業プロセスの共有、フォーキャストまで結び付けて設計する方法を解説します。現在の取引ステージや入力項目を見直す際の参考にしてください。
- パイプライン設計の基本 — 取引ステージを使って商談の状況をどのように可視化するかを整理します。
- 4つの設計要素 — ステージ、受注確度、ステージ定義、必須プロパティの役割と組み立て方を説明します。
- HubSpotへの設定手順 — 設計案をパイプライン設定へ反映し、段階的に運用を始める方法を紹介します。
- 運用ルールと見直し方 — 入力を仕組みに組み込み、レポートの前提となる取引データを保つ考え方を解説します。
パイプラインを営業プロセスの共通基盤にする
HubSpotのパイプラインは、取引を営業プロセスの段階に沿って整理する仕組みです。
取引ステージで商談の現在地を共有する
次の画像は、パイプラインのボード表示を示します。
取引ステージは、商談が営業プロセスのどの段階にあるかを示します。例えば、BtoBの商談なら「アポ取得」「初回提案」「見積もり提示」「受注内示」「受注」のような段階を設け、取引が進むにつれて左から右へ移動する形で表せます。受注に至らなかった取引は、失注として記録します。
この一覧によって、各段階にどの取引があるかをチームで確認できます。ただし、ステージ名だけでは案件の実態まではわかりません。「見積もり提示」と表示されていても、提案内容の説明が終わった状態なのか、顧客が社内検討を始めた状態なのかが人によって異なれば、一覧やレポートの解釈も揺れます。
営業の進捗と経営の判断をつなぐ
パイプラインの設計では、営業担当者が次の活動を決めるための情報と、マネージャーや経営層が営業状況を把握するための情報を同じ取引に結び付けます。例えば、進捗を左右する顧客の意思決定状況を営業が記録し、その取引ステージと受注確度を使って見込みを確認します。
HubSpotでは、取引をコンタクトや会社のレコードに関連付けられます。関連付けは双方向で、各レコードの右側のサイドバーで確認できます（出典：HubSpotのレコード関連付け）。
既定設定を出発点として現状を棚卸しする
HubSpotの既定のステージをそのまま使うと、自社の営業プロセスと名前や区切りが一致しない場合があります。既定の構成を基準として、実際に商談が進むときの判断や記録を洗い出し、自社の業務に必要な段階へ調整します。
まず、営業担当者が案件を報告するときに使っている言葉を集めます。次に、各段階で顧客に対して何を実施したのか、次へ移る判断材料は何かを確認します。営業担当者の経験だけに依存している情報があれば、取引レコードの項目やステージ定義として共有できる形に置き換えると、新しいメンバーへの引き継ぎにも使えます。
パイプラインの4要素を設計する
HubSpotへ設定する前に、スプレッドシートなどで設計案を整理します。押さえる要素は、取引ステージ、受注確度、ステージ定義、必須入力プロパティです。4つを関連付けて決めると、単なる案件一覧ではなく、営業プロセスを運用するための土台になります。
取引ステージは受注率が変化する節目で分ける
ステージを分けるときは、どの段階に何件の取引があるかを見たいのか、どの段階を越えると受注の見込みが変わるのかを考えます。顧客との接点や社内での案件確認のたびにステージを増やすと、入力や更新が煩雑になり、段階ごとの件数も読み取りにくくなります。
一方、商談期間が長く、顧客の決裁や導入準備に複数の節目がある場合は、粗いステージだけでは進捗の停滞箇所を把握しにくいことがあります。どこまで分けるかは、営業担当者が判断に使う粒度と、レポートで確認したい粒度をすり合わせて決めます。
| 検討する視点 | 設計時に確認すること |
|---|---|
| 商談の現在地 | 各段階にある取引数を見て、営業活動の状況を把握できるか |
| 受注見込みの変化 | ステージを越えると、受注可能性の見立てが変わるか |
| 次の営業行動 | ステージが変わったとき、担当者が次にすべきことを判断できるか |
| 更新の負担 | 商談の実態に合った段階で、担当者が無理なく更新できるか |
受注確度を加重金額に反映する
次の画像は、受注確度（角度）の考え方を示します。
受注確度、ここでいう「角度」は、各ステージの取引が受注に至る見込みを表す割合です。取引金額にステージの確度を掛けた加重金額を、フォーキャストの考え方として使えます。
| 取引金額 | ステージの確度 | 加重金額の例 |
|---|---|---|
| 100万円 | 20% | 20万円 |
| 3,000万円 | 10% | 300万円 |
金額の大きな案件が初期段階にある場合、取引金額の合計だけでは受注見込みを読み違える可能性があります。ステージに応じた受注確度を掛けると、進捗の違いを加味した見込みを確認できます。ただし、確度は受注を保証する値ではなく、営業判断をそろえるための見立てです。
運用開始時は、営業チームで合意した仮の確度を置きます。その後、HubSpotに取引データが蓄積したら、各段階から受注や失注に進んだ実績と照らし、値が実情に合うか見直します。ステージ別の過去実績を確認できるまでは、細かい確度の違いを作り込みすぎず、チームが説明できる設定から始めます。
ステージ定義で判断のばらつきを減らす
次の画像は、ステージ定義の例を示します。
各ステージの定義には、その段階に該当する顧客の状態や完了している活動を書きます。「アポ取得」なら「ミーティングが設定されている状態」、「見積もり提示」なら「顧客へ提案内容と見積もりを提示し、導入判断の検討に進んでいる状態」のように表現できます。
定義を作ったら、営業メンバーが同じ案件例を見たときに同じステージを選ぶかを確認します。解釈が割れる場合は、ステージ名を増やす前に定義の条件を具体化します。判定基準が共有されれば、マネージャーが毎回口頭で確認しなくても、取引一覧の進捗を共通の基準で読めるようになります。
必須プロパティは次の判断に必要な項目に絞る
次の画像は、必須入力プロパティの設計を示します。
必須入力プロパティは、ステージの移行時に情報を記録する仕組みです。項目を増やせば情報量は増えますが、各項目が次の営業行動や分析に使われないなら、入力負担だけが残ります。ステージごとに「この情報がないと何を判断できないか」を確認して、必要なものから設定します。
例えば、次のような設計が考えられます。これらは設計例です。実際に必須化する項目は自社の営業プロセスに合わせて選びます。
- 見積もり提示の段階 ── 金額やクローズ予定日、顧客の予算、決裁に関わる人、ニーズ、導入時期といった情報が検討材料になる
- 受注に進めるとき ── 受注理由を記録する
- 失注時 ── 失注理由を記録する
HubSpotでは、条件付きステージプロパティを使ってステージ移行時にプロパティ入力を求められます。設定する項目を絞り、受注理由や失注理由のように後の分析で使う情報は、選択肢の分類と詳細記述を分ける方法もあります。分類項目で傾向を集計し、詳細欄で個別の背景を残せば、全体と個別の両方を確認しやすくなります。
HubSpotへの設定前に運用案を固める
設定画面へ進む前に、設計したステージと項目が担当者の実際の業務に沿っているかを確認します。HubSpotの画面で項目を追加すること自体より、何を記録し、どの条件で案件を進めるかを決めることが重要です。運用案は小さく始め、現場で使った結果を見ながら調整します。
設計シートで4要素を並べる
次の画像は、パイプライン設計テンプレートを示します。
設計シートには、ステージ名、受注確度、ステージの定義、移行時に求めるプロパティを列として並べます。さらに、情報を入力する担当者と、その情報を営業判断やレポートのどちらに使うのかを記載すると、入力項目の必要性を見直しやすくなります。
次のように、ステージごとの要件を同じ行にまとめます。
| ステージ | 定義 | 確度の考え方 | 移行時に記録する情報 |
|---|---|---|---|
| アポ取得 | ミーティングが設定されている | 初期段階として見立てる | 顧客、担当者、予定日 |
| 見積もり提示 | 提案内容と見積もりを顧客へ提示している | 提示後の検討状況を踏まえる | 金額、クローズ予定日、検討情報 |
| 受注内示 | 顧客から受注に向けた意思表示がある | 受注に近い段階として見立てる | 受注予定や判断の根拠 |
| 受注 | 取引が受注として確定している | 受注として扱う | 受注理由などの振り返り情報 |
表の例は設計の考え方を示すもので、確度や必須項目をそのまま採用するための標準値ではありません。自社の営業プロセスに当てはめ、担当者が迷う段階や使われない項目がないかを確認します。
HubSpotのパイプライン設定でステージを登録する
次の画像は、パイプライン設定画面を示します。
次の画像は、角度設定画面を示します。
設計案が固まったら、HubSpotの設定画面で取引パイプラインを編集します。画面表示やメニュー名はアカウントの状態により異なることがあるため、現在の設定画面で対象の取引パイプラインを選びます。
- 設定を開く ── 取引画面の歯車アイコンから設定に入り、「取引」セクションの「パイプライン」タブで編集します
- ステージと確度を登録する ── ステージ名を登録し、各ステージの確度を設定します
- 必要な項目を指定する ── 条件付きステージプロパティを使って、移行時に必要な項目を指定します
- 設計シートと照合する ── ステージ名と順序、定義、必須項目をHubSpotの設定と照合します
- 実際の取引で確かめる ── ステージを変更して必要な情報が記録できることを確かめてから、営業チームへ運用を広げます
HubSpot公式ドキュメントでは、パイプラインのステージはレコードのプロセス上の段階を示し、取引ではステージごとに確度を設定できると説明されています（出典：Set up and manage object pipelines）。
まず一つの営業プロセスで使い始める
最初から例外的な商談や部門ごとの細かな違いをすべて設定に取り込むと、設計と説明が複雑になります。まずは対象を絞り、主要な営業プロセスでステージと必須情報が役に立つかを確認します。
運用中は、ステージの意味が伝わらず更新されない取引、入力されないプロパティ、ステージと顧客の実態が合わない案件を記録します。その結果をもとに、ステージ定義を修正するのか、項目を外すのか、ステージを分けるのかを判断します。使われる設計を保つには、設定の追加だけでなく、不要になった入力要件を見直すことも必要です。
ステージ移行の情報を次の営業行動へつなげる
必須プロパティは、レポートのためだけに設ける項目ではありません。取引を次へ進めるために必要な確認事項を示し、営業担当者が取るべき行動を明確にする役割も持ちます。個人の記憶や経験に頼るのではなく、取引レコードの入力とステージのルールに手順を組み込むことで、引き継ぎや新人の立ち上がりにも活用できます。
見積もり提示の段階で判断材料をそろえる
次の画像は、BANT情報のプロパティ例を示します。
見積もりを提示する前後では、顧客が何を基準に検討するのか、誰が意思決定に関わるのか、導入時期にどのような条件があるのかを確認します。BANTは予算、決裁権限、ニーズ、導入時期を整理する考え方です。これを取引プロパティとして管理すると、担当者ごとに異なる形式のメモを探す作業を減らせます。
BANTの各項目をすべて必須にするかは、営業プロセスと顧客との会話の進み方に応じて決めます。例えば、初回提案の時点ではニーズと検討時期を記録し、見積もり提示の段階で予算や意思決定者を補う設計もあります。各段階で答えられる情報だけを求め、未確認の内容を推測で入力しない運用にします。
受注と失注の理由を次の改善へ戻す
受注理由と失注理由は、営業活動の振り返りや商材・マーケティングへのフィードバックに使えます。自由記述だけでは分類して傾向を見つけにくいため、価格、競合、機能、時期、社内決裁など、自社で分析に使いたい分類を選択式で記録し、必要に応じて詳細欄を併設します。
蓄積した失注理由を営業チームや関連部門で確認すると、どの課題が繰り返し表れているかを議論できます。理由の分類が粗すぎて複数の背景が一つにまとまる場合は選択肢を見直し、細かすぎて担当者が選びにくい場合は統合します。分類は一度決めて終わりではなく、レポートで判断に使える粒度を保ちます。
入力項目を育成と引き継ぎに活用する
必須項目は、入力を強制するだけではありません。例えば、見積もり提示前に決裁者や顧客の検討条件を記録する運用なら、新しいメンバーは次の段階で何を確認すべきかを項目から学べます。項目名や説明が曖昧な場合は、具体的な判断や会話に結び付く名称へ整えます。
入力項目を増やしすぎると、担当者が必要な情報を見つけにくくなり、記録のための記録になるおそれがあります。入力率だけを目的にせず、次の営業行動、マネジメント上の判断、受注・失注分析のどれに使うのかを説明できる項目を残します。
パイプラインルールでデータの整合性を保つ
ステージと入力項目が実務で使われ始めたら、パイプラインルールでレコードの移動や編集を制御できます。ルールは運用を支える一方、強く制限しすぎると例外対応が難しくなります。まずは実際に防ぎたい問題を特定し、必要な制御だけを選びます。
ステージの飛び越しや逆行を制御する
次の画像は、パイプラインルール設定を示します。
HubSpotのパイプラインルールでは、ステージの省略や逆方向への移動を制限する設定などを利用できます。公式ドキュメントに記載されている主な制御には、新しい取引を作成できるステージの指定、ステージの省略制限、逆方向への移動制限、特定ステージでの編集制限があります（出典：Set up rules for object pipelines）。
どの制御を使うかは、記録のずれがどこで起きているかで決めます。取引が途中段階を飛び越えて登録されるなら作成ステージを絞り、進行状況の履歴が追えないなら省略制限を検討します。顧客の状況変化で前の段階へ戻ることが実際にあるなら、逆行を一律に制限する前に例外時の処理を決めます。
受注後の変更がレポートに与える影響を確認する
受注後に金額や受注日が変更されると、過去のレポートと現在の取引情報が一致しないように見えることがあります。受注後の編集制限を設ければ、変更できる担当者を限定する運用が可能です。変更が必要な場合の担当者や記録方法を定め、正当な修正まで止めないようにします。
プランと運用上の例外を見てルールを選ぶ
次の画像は、パイプラインルールの詳細設定を示します。
パイプラインルールは、デスクトップやHubSpotモバイルアプリでレコードを手動で作成・更新する場合と、ユーザーIDを渡す連携やHubSpotの公開APIを通じて作成・更新する場合に適用されます（出典：オブジェクトのパイプラインルール）。
ルールを適用する前に、取引の作成・変更経路と担当者を確認します。
パイプラインをデータに合わせて見直す
パイプラインは一度設定すれば完成するものではありません。営業プロセスや取引データの蓄積に応じて、ステージや確度、入力項目が現状を表しているかを確認します。変更時は、過去データとの比較や担当者の更新負担も含めて影響を判断します。
ステージ別の滞留と受注結果を見比べる
ステージ別の動きを見ると、営業プロセスの詰まりや確度のずれを検討できます。確認する点は次のとおりです。
- 滞在 ── 各ステージに取引がどれだけ滞在しているか
- 進行 ── どの段階から受注や失注に進んでいるか
- 件数以外の指標 ── ステージごとの件数だけでなく、取引が次へ進んだ割合や失注理由も合わせて確認する
HubSpotの加重パイプライン予測では、各取引の金額に、その取引ステージに基づく確度を掛けて集計します（出典：HubSpotの営業分析レポート）。
変更は目的と対象を限定して行う
ステージや必須プロパティを変えるときは、どの業務上の問題を直すのかを明確にします。例えば「見積もり提示後の案件が停滞している」なら、顧客の意思決定者や次回アクションが記録されているかを確認し、ステージ定義の不足か入力項目の不足かを分けて考えます。
変更後は、担当者に変更理由と記録方法を共有し、実際の取引で迷わず更新できるかを確かめます。項目を足した場合は利用状況を見て、使われないなら必須化の範囲や項目自体を再検討します。こうした見直しを繰り返すことで、パイプラインを現場と管理の両方で使える状態に保ちます。
受注後の業務とのつながりを確かめる
パイプラインの終点は、営業の受注報告だけとは限りません。契約や請求に必要な情報が後続の業務へ引き継がれるなら、受注時にどのプロパティを確定させるかを営業と請求担当の間で整理します。取引の情報を一元管理し、受注後の対応に活用できる状態を作ることが、営業プロセスを事業運営につなげるポイントです。
ただし、パイプラインに請求や契約の全工程を詰め込むと、営業進捗が見えにくくなることがあります。取引ステージは営業判断に必要な区切りとして保ち、受注後の情報は適切なオブジェクトや連携先で管理する設計を検討します。
よくある質問
パイプラインのステージはいくつに分けるのがよいですか？
一律の適切な数はありません。どの段階で商談の見込みが変わるか、営業担当者が次の行動を判断するためにどの粒度が必要かを基準に決めます。
- 細分化して更新されなくなる場合は、まとめます
- 段階ごとの滞留を把握できない場合は、節目を分けます
受注確度はどのように設定すればよいですか？
まず営業チームで説明できる仮の確度を設定し、運用後にステージごとの受注・失注実績と比べます。実績と見立てにずれがあれば、確度だけでなくステージ定義や更新タイミングも確認します。確度は見込みを整理するための値として扱います。
必須プロパティはどの項目でも設定できますか？
ステージ移行時に求める項目は、実際のHubSpot設定画面で条件付きステージプロパティとして指定できるものから選びます。まず次の営業判断やレポートに必要な項目を絞り、入力するタイミングと担当者を決めます。利用可能な設定や項目の条件は、アカウントの画面と公式ドキュメントで確認します。
パイプラインルールを使えば取引の変更をすべて防げますか？
防ぎたい操作と実際の更新経路を確認し、対象ポータルでテストしたうえで、必要に応じて変更履歴を確認します。
スプレッドシートで設計してからHubSpotへ移すのはなぜですか？
ステージ、確度、定義、必須項目の関係を一覧で見て、設定前に矛盾や不足を見つけやすくなるためです。設計案を営業メンバーと共有し、実際の案件例で同じ判断になるかを確かめてからHubSpotへ登録します。運用後は、利用状況や取引実績を見て調整します。
まとめ
HubSpotのパイプラインは、取引ステージだけでなく、受注確度、各ステージの定義、必要な入力項目を一体で設計することで、営業の共通基盤として機能します。取引データをコンタクトや会社情報と関連付け、商談の進捗から受注後の引き継ぎまで活用できる状態を目指します。
まずは、現在の営業プロセスをスプレッドシートなどに書き出すところから始めてください。
- 商談が進む節目と、受注見込みが変化するポイントを洗い出します。
- 各ステージの定義、確度、次の判断に必要なプロパティを並べます。
- HubSpotで小さく運用を始め、更新状況や受注・失注の実績に応じて調整します。
営業担当者の経験だけに頼らず、ステージ定義や必須項目に必要な確認を組み込むと、案件の引き継ぎや新人の育成にも役立ちます。CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
このテーマと関連する内容を、次の記事でも詳しく解説しています。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
