%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}
この記事の結論
パイプラインは商談の進捗、ライフサイクルステージは顧客との関係性を管理します。役割を分けて設計すると、マーケティングから営業、受注後までの動きをつなげられます。
パイプラインは商談の進捗、ライフサイクルステージは顧客との関係性を管理します。役割を分けて設計すると、マーケティングから営業、受注後までの動きをつなげられます。
「MQLの条件が曖昧で、営業に渡すタイミングが担当者ごとに違う」
「商談の進捗を表計算シートで管理していて、更新が遅れる」
「パイプラインのステージ名はあるものの、何をもって次に進むかが揃っていない」——こうした状態では、レポートを見ても実際の案件状況を読み取りにくくなります。
パイプライン設計とは、商談の進捗段階と移行条件を定めることです。ライフサイクルステージは、コンタクトや会社と自社との関係がどこまで進んだかを表すため、両者を分けて定義し、必要な箇所を自動化で結びます。
本記事は「CRMデータベース設計の基本｜オブジェクト・プロパティ・関連付けの設計思想」シリーズの一部です。
この記事でわかること
パイプラインやライフサイクルステージを見直す際に、定義の作り方から運用の仕組みまで整理できます。MQL・SQLの基準づくり、HubSpotでの連動設計も扱います。
- 2つの管理軸の違い — 顧客との関係性と個別商談の進捗をどう分けるかを説明します。
- MQL・SQLの定義 — 行動や企業属性、営業の確認内容を基準にする考え方を整理します。
- ステージの設計 — 完了条件、受注確度、必要な入力項目を組み合わせる方法を紹介します。
- HubSpotでの連動 — ライフサイクルステージ、取引、ワークフローをつなぐ設計例を示します。
パイプラインとライフサイクルステージを分ける
CRMではコンタクトや会社、取引などの情報が関連付いて管理されます。表計算シートでこれらを別々に管理すると、同じ会社の情報が複数箇所に分散し、営業の更新とマーケティングの記録がずれることがあります。最初に、どの情報をどの管理軸で追うかを決めます。
関係性と商談進捗の違い
ライフサイクルステージは、コンタクトや会社が自社との関係のどの段階にいるかを表します。リード、MQL、SQL、商談中、顧客といった流れを、マーケティングから営業、顧客対応まで横断して把握するための軸です。
パイプラインは、個別の取引が商談プロセスのどこにあるかを表します。ヒアリング、提案、条件交渉、受注または失注など、案件単位の進捗を記録します。顧客との関係全体と、具体的な商談の状態を同じプロパティで表そうとすると、複数の担当者や取引がある場合に意味が曖昧になります。
| 管理対象 | 主に答える問い | 例 |
|---|---|---|
| ライフサイクルステージ | このコンタクトや会社と、どの段階の関係にあるか | MQL、SQL、顧客 |
| パイプライン | この取引は商談のどこまで進んでいるか | ヒアリング、提案、受注 |
取引を関係性の中に置く
ライフサイクルステージが顧客との関係の全体像を示し、パイプラインがその中の商談を詳しく示します。たとえば、営業がコンタクトを確認して商談化の対象と判断したときに取引を作り、取引の進行に応じて会社やコンタクトのステージを更新する設計が考えられます。
受注後は、取引の情報を顧客管理や請求の流れにつなぎます。HubSpotに記録された取引や顧客情報が後続業務で利用できるよう、どの部門がどの時点で更新するかも合わせて決めます。CRMを入力先で終わらせず、営業プロセスの共通基盤として扱うことが設計のポイントです。
HubSpotの標準プロパティを確認する
HubSpotでは、コンタクトと会社のライフサイクルステージを使って、マーケティングや営業のプロセス上の位置を分類できます。取引のステージは別に管理され、関連付けられた取引の有無と顧客との関係を組み合わせて見られます。（出典：コンタクトと会社のライフサイクルステージを使用する）
導入時には、標準ステージが自社の用語や引き渡し条件と合うかを確認します。標準名をそのまま使う場合も、社内での意味を定義しておくと、担当者によって「SQL」や「商談中」の解釈が変わりにくくなります。
MQL・SQLを部門間で定義する
MQLやSQLの名称だけをCRMに登録しても、担当者がそれぞれ異なる基準でステージを変えれば、引き渡しの質を評価できません。マーケティングと営業が、次の三点を一緒に決めます。
- 判定条件
- 対応する担当
- 結果の返し方
スコアだけで判断せず、行動と顧客適合性、営業との会話で分かった情報を組み合わせます。
MQLは行動と適合性を分けて考える
MQLは、マーケティングの基準で営業に引き渡す価値があると判断したリードです。判断材料は、資料閲覧や問い合わせなどの行動と、業種や役職などの企業・担当者情報に分けて考えます。
例えば、料金ページの閲覧や導入事例のダウンロードなどに行動スコアを付け、企業属性にもフィットスコアを設けます。たとえば行動は活発でも対象外の企業である場合と、対象企業でもまだ検討行動が少ない場合を区別できます。実際の点数や閾値は自社の営業プロセスに合わせて決め、理由を営業側が理解できる形で共有します。
SQLは営業が確認した状態として定義する
SQLは、営業がリードと接点を持ち、商談化の価値があると判断した状態です。予算、意思決定者、ニーズ、導入時期など、営業が確認する情報を判定項目にできます。
- BANT ── 予算、決裁権、ニーズ、導入時期を確認する考え方です
- MEDDIC ── より細かな営業判断をしたい場合に、効果指標、経済的意思決定者、評価基準、意思決定プロセス、課題、社内推進者を確認する考え方として参考にできます
項目を増やすほど記録負荷も上がるため、商談の判断や引き継ぎに使う情報に絞ります。
SLAとフィードバックを決める
MQLからSQLへの引き渡しでは、営業の初回対応までの目安と、SQLに該当しなかった場合の戻し方を定義します。例えば、MQL発生後の初回連絡を24時間以内、SQL判定期限を初回連絡後5営業日以内とします。運用開始前に自社の対応体制に合わせます。
営業が対象外と判断した場合、理由をCRMに記録し、マーケティングへ返します。理由が記録されないままリードを戻すと、スコアや獲得施策の改善につながりません。ダッシュボードでは引き渡し件数だけでなく、対応状況やSQL化の結果も見られるようにします。
ライフサイクルステージを設計する
ステージは、カスタマージャーニーをたどり、顧客との関係が変わる場面から定義します。部署名やツールの都合で区切るのではなく、各段階で誰が何を判断し、次の担当へ何を渡すかを決めます。コンタクトと会社の両方を扱う場合は、個人単位と企業単位で状態が異なる場面も整理します。
カスタマージャーニーから段階を導く
まず、認知や問い合わせから商談、受注、顧客対応までの流れを書き出します。その上で、担当部門、判定者、次の段階へ進む条件を対応付けます。マーケティングから営業へ渡す条件が曖昧なら、そこを先に合意し、後続のステージを追加していきます。
| 設計項目 | 決めること |
|---|---|
| ステージ | 顧客との関係のどの状態を表すか |
| 判定条件 | どの行動や確認をもって移行するか |
| 担当部門 | 誰が判定し、次の担当へ渡すか |
| 記録項目 | 判断や後続対応に必要な情報は何か |
コンタクトと会社の状態を使い分ける
一社に複数の担当者がいると、コンタクトごとの関心や営業対応の進み具合は異なる一方、会社としてはすでに商談中という場合があります。コンタクトと会社のライフサイクルステージをそれぞれ管理すると、個人の反応と企業単位の進捗を分けて確認できます。
会社のステージを関連するコンタクトのうち最も進んだ状態に合わせる設計も考えられます。その場合は、どのコンタクトの状態を会社に反映するのか、複数の取引があるときにどう判断するかを明文化します。集計方法を決めずに自動更新を始めると、会社レコードの表示が担当者の期待と異なることがあります。
失注後の掘り起こしを設計する
失注は顧客との関係終了と同じ意味ではありません。時期や予算、優先度の問題で商談が止まった場合は、取引は失注として記録しながら、理由に応じてコンタクトをナーチャリングへ戻す方法があります。再アプローチの時期や条件を決めておけば、個人の記憶に頼らず次の機会につなげられます。
ライフサイクルステージは、HubSpotの標準プロパティでは原則として前進方向に更新されます。過去の段階に戻す処理が必要な場合、HubSpotの公式説明では、先に現在の値をクリアしてから前の値を設定する方法が示されています。（出典：コンタクトと会社のライフサイクルステージを使用する）そのため、失注した取引を残したまま新しい商談を作るのか、ステージを戻すのかを分けてルール化します。
パイプラインを商談の実態に合わせる
取引ステージは、営業担当が行った作業の履歴だけでなく、顧客側の検討がどこまで進んだかを示すものとして設計します。ステージが細かすぎると更新の負担が増え、粗すぎると停滞箇所や受注見込みを把握しにくくなります。マネージャーや経験のある営業担当者の知見を集め、実際の受注プロセスに沿って段階を定めます。
受注率が変わる点でステージを分ける
ステージを分ける基準は、顧客の状態や受注確度が変わる節目です。アポイント取得、初回提案、見積もり提示、受注内示、契約など、営業プロセスの変化が分かる名称を使います。ステージ数は5〜7個を設計の目安とし、商談の実態に照らして必要な区切りだけを残します。
HubSpotの取引パイプラインでは、ステージごとに受注確率を設定し、取引金額と確率を使った加重金額を扱えます。（出典：オブジェクトのパイプラインを設定・管理する）ただし、確率を設定しただけで予測が実態に合うとは限りません。過去の商談結果が蓄積したらステージごとの実績と比べ、営業判断とずれている箇所を見直します。
完了条件と受注確度を定義する
各ステージには、入る条件と次に進む条件を記載します。「提案中」のような言葉だけでは担当者ごとに意味が変わるため、「提案内容を顧客が評価している」など、確認できる状態として書きます。受注確度は、同じステージ名でも案件の進捗解釈が分かれないよう、条件と合わせて運用します。
| 設計要素 | 決め方 | 記録・活用 |
|---|---|---|
| 取引ステージ | 顧客の検討状態が変わる節目で分ける | 商談の進捗を共有する |
| 受注確度 | ステージごとの実績を基に設定する | 加重金額や売上予測に使う |
| ステージ定義 | 移行条件を観察可能な状態で記述する | 担当者間の判断差を抑える |
| 必須プロパティ | 次の判断や引き継ぎに必要な情報に絞る | データ品質と対応の再現性を保つ |
必須項目で判断を仕組みにする
ステージ移行時に必要な情報を設定すると、記入漏れを個人の注意だけに頼らず防げます。たとえば見積もり提示の段階では金額やクローズ日、受注時には受注理由を記録する設計が考えられます。項目を増やしすぎると現場で使われなくなるため、商談判断や経営レポートに必要なものを優先します。項目の命名やデータ型の決め方はHubSpotプロパティ設計と命名規則を参照してください。
HubSpotでは、パイプラインのステージに条件付きプロパティを設定し、レコードをそのステージに作成または移動するときに入力を求められます。（出典：オブジェクトのパイプラインを設定・管理する）営業プロセス上の情報と、レポートで必要な情報を分けて棚卸しし、使われていない項目は必須化しない運用にします。
事業ごとのパイプラインを検討する
新規商談と既存顧客への追加提案で、確認事項や承認の流れが大きく異なるなら、別パイプラインに分けると進捗を読み取りやすくなります。一方、差が担当者や取引の種類を示すだけなら、取引タイプなどのプロパティで分類する方法もあります。
パイプラインを増やすと、管理対象やレポートの見方も増えます。まず現行のプロセスを一つのパイプラインで表せるか検討し、移行条件や完了条件が異なり、同一の指標で比較しにくい場合に分けます。
HubSpotで自動連動と運用を組み立てる
自動化は、定義した業務ルールを繰り返し実行する仕組みです。設計が曖昧なまま自動化すると、誤ったステージ変更や取引作成を繰り返すため、最初に対象レコード、変更条件、実行後の確認方法を決めます。コンタクト、会社、取引の関連付けを保ちながら、担当者への通知や次のタスクにつなげます。
ステージ移行の条件を決める
MQLへの変更は、合意したスコアやフィット条件に達したときに行います。営業が確認してSQLと判断したら、関連する取引を作成するか、既存の取引に関連付けます。コンタクトが同じでも複数の商談があり得るため、取引を作成する条件や重複を避ける条件を明確にします。
受注時は取引ステージを起点に、関連する会社やコンタクトのライフサイクルステージを顧客へ更新する流れが考えられます。受注が取引に記録され、会社やコンタクトの状態に反映され、その後の顧客対応や請求に必要な情報へつながることを確認します。
ワークフローを段階的に導入する
ワークフローで自動化する内容は、判断ルールと実行アクションに分けて設計します。たとえば、条件を満たしたリードの担当者に通知し、タスクを作成するところから始められます。運用後は、条件に一致したレコードと実行履歴を確認し、対象が広すぎる場合は条件を絞り、対象漏れがある場合は判定条件を見直します。設定画面での組み方はHubSpotワークフローの設定方法にまとめています。
| 業務上の条件 | 実行する処理 | 運用で見る点 |
|---|---|---|
| 合意したMQL条件に到達 | 担当営業へ通知し、対応タスクを作成 | 対応状況とSQL判定 |
| 取引が受注になった | 関連する会社やコンタクトの状態を更新 | 関連付けと受注記録 |
| 取引が失注になった | 理由に応じてナーチャリングや再対応タスクへつなぐ | 失注理由と再接触の条件 |
| ステージが停滞した | 担当者に状況確認を促す | 通知後の対応と停滞理由 |
画面と全体フローを照らし合わせる
以下の画面は、リードから受注までのライフサイクルと各段階で使うツールの対応を示しています。
図に沿って、コンタクトや会社の関係性、取引の進捗、受注後の顧客対応をどこで記録するかを確認します。HubSpotに集めた情報を営業、マーケティング、顧客対応で共有できるよう、担当部門間の引き継ぎ点を対応付けます。図の各項目を自社の業務に当てはめ、使う機能や担当が決まっていない部分を設計課題として残します。
運用データから定義を見直す
設計は、一度HubSpotに登録したら終わりではありません。ステージごとの滞留や遷移、MQLからSQLへの引き渡し結果を見て、基準が現場の実態に合っているか確認します。表計算シートで別の集計表を更新し続ける運用から、CRMの記録を基に判断できる状態へ段階的に移します。
後戻りと再商談の扱いを決める
商談が前の段階へ戻る場合は、何が起きたのかを記録します。提案後に顧客の検討が止まったなら、取引ステージを戻す条件と、次に行う確認を決めます。受注後に新たな提案が生じた場合は、顧客のライフサイクルステージを戻すのではなく、新しい取引として扱う方法を検討します。
HubSpotのライフサイクルステージは、通常の更新では前進方向の遷移を前提としています。
レポートの期間と項目を揃える
ステージ間のコンバージョンを比較する場合、集計対象と期間を揃えます。たとえば月ごとにステージ遷移を見て、どこで商談が停滞するかを確認します。受注確度の加重金額を見る場合も、取引金額、ステージ、受注確率が適切に更新されているかを合わせて点検します。
失注理由は、自由記述だけでなく分類項目を設けると傾向を集計できます。
小さく始めて定着を確かめる
最初から多数のステージや自動化を組み込むと、入力項目と通知が増え、現場が運用意図を理解しにくくなります。まず次の三点を整え、担当者が同じ判断で記録できるかを確かめます。基本の操作から確認したい場合はHubSpotの基本操作ガイドも参考になります。
- MQL・SQLの条件
- 主要な取引ステージ
- 移行時の必須項目
次に、受注時のライフサイクル更新や失注後の掘り起こしなど、効果と確認方法が明確な自動化を追加します。通知が対応につながらない場合は条件や通知先を見直し、入力されない項目があれば、その項目がどの判断に必要なのかを再確認します。
よくある質問
MQLの定義は一度決めたら変えないほうがよいですか？
運用結果を見ながら見直します。MQLからSQLに進んだ割合や営業からの差し戻し理由を確認し、基準を次のように調整します。
- 基準が広すぎる場合 ── 適合条件を追加します
- 対象を取りこぼしている場合 ── 行動条件を調整します
変更時はマーケティングと営業で新しい判定基準を共有します。
パイプラインステージの受注確率はどう決めますか？
取引の実績を基に、各ステージから受注に至った割合を確認して設定します。データが十分でない段階では、ここで示した例を仮置きとして参照し、実績が蓄積したら自社の結果に合わせて調整します。ステージの定義と確率が対応しているかも合わせて見直します。
ライフサイクルステージを後戻りさせてもよいですか？
通常の更新では前進方向で管理する前提を置き、失注後の再接触は取引の状態と分けて設計します。
小規模なチームでもパイプライン設計は必要ですか？
チーム規模にかかわらず、ステージの意味と移行条件を共有すると、引き継ぎや案件状況の確認がしやすくなります。少数精鋭のチームなら、まず主要な進捗だけに絞り、必須項目も営業判断に使うものから始めます。運用が定着してから必要な区切りや自動化を追加します。
まとめ
パイプラインは取引の進捗を、ライフサイクルステージはコンタクトや会社との関係性を管理します。MQL・SQLの条件をマーケティングと営業で合意し、顧客の状態に沿ったステージ、受注確度、必要な入力項目を定めることで、情報を引き継ぎやすくなります。HubSpotのワークフローは、合意したルールを通知や取引作成、受注後の更新に結び付ける役割を担います。
まずは現在の商談プロセスを表に書き出し、次の順に整えます。
- MQLとSQLの判定条件、担当部門、営業からのフィードバック項目を決めます。
- 取引ステージの完了条件、受注確度、各段階で必要な入力項目を揃えます。
- 一つの引き渡しや受注処理を選んでHubSpotに設定し、実際のレコードとレポートで動きを確認します。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。設計から定着までの支援はHubSpot導入・構築支援でご紹介しています。
あわせて読みたい
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
