「MQLの定義が曖昧で、マーケと営業の間で認識がずれている」「パイプラインのステージ定義が担当者によってバラバラ」——CRM運用で頻出するこれらの課題は、パイプラインとライフサイクルステージの設計が不十分であることに起因している。
パイプラインは「商談の進捗」を管理する軸、ライフサイクルステージは「顧客との関係性の進捗」を管理する軸だ。この2つを正しく設計し、自動化で連動させることで、マーケティングから営業、カスタマーサクセスまでの一気通貫のプロセス管理が実現する。
本記事では、パイプラインとライフサイクルステージの設計思想から、HubSpotでの具体的な実装パターンまでを解説する。
本記事は「CRMデータベース設計の基本｜オブジェクト・プロパティ・関連付けの設計思想」シリーズの一部です。
本記事はStartLinkの「BtoBマーケティング完全ガイド」関連記事です。
本記事を読むことで、HubSpotを活用した営業プロセスの改善ポイントが明確になります。現場で「何から手をつければいいか」がわかる実践的な内容ですので、ぜひ最後までご覧ください。
パイプラインとライフサイクルステージは、しばしば混同される。この混同が運用の混乱を招く原因になるため、まず2つの概念の違いを明確にしておく。
ライフサイクルステージ: コンタクト（個人）や会社と自社の関係性がどの段階にあるかを示す。Webサイトの訪問者→リード→MQL→SQL→商談中→顧客→プロモーターといった流れを管理する。マーケティングから営業、CSまでを横断する概念だ。
パイプライン: 個別の商談（取引）がどのステージにあるかを示す。初回接触→ヒアリング→提案→交渉→受注/失注といった、商談固有の進捗を管理する。主に営業プロセスの管理に使う。
両者の関係: ライフサイクルステージが「コンタクトの旅の全体像」だとすれば、パイプラインはその旅の中の「商談フェーズの詳細地図」だ。コンタクトのライフサイクルステージが「SQL」に遷移するとき、パイプラインに新しい取引が作成される、というのが一般的な連動パターンだ。
HubSpotには以下の標準ライフサイクルステージが用意されている。
MQLの定義は、マーケティングと営業の間で最も摩擦が生じやすいポイントだ。以下のアプローチで定義する。
定量基準（スコアリング）: コンタクトの行動にポイントを付与し、閾値を超えたらMQLとする。
定性基準（フィット）: 企業属性がターゲットICP（Ideal Customer Profile）に合致するかを評価する。
スコアリングの「行動スコア」と「フィットスコア」の組み合わせでMQLを定義することで、「行動は積極的だがターゲット外の企業」「ターゲットだがまだ興味が薄い企業」を区別できる。
SQLは、営業がMQLをコンタクトした結果、「商談化する価値がある」と判断したリードだ。
BANT基準: Budget（予算がある）、Authority（意思決定権がある）、Need（明確なニーズがある）、Timeline（導入時期が明確）の4項目のうち、少なくとも3項目が確認できたらSQLとする。
MEDDIC基準: より高度な判断基準として、Metrics（効果指標）、Economic Buyer（経済的意思決定者）、Decision Criteria（評価基準）、Decision Process（意思決定プロセス）、Identify Pain（課題の特定）、Champion（社内推進者）の6項目を確認する。
Sansanのような企業では、名刺データとCRMを連携し、コンタクトの役職や部署情報を自動取得することで、SQLの判断に必要な情報を効率的に収集している。
MQL→SQLの定義だけでなく、「MQLが発生してから営業が対応するまでの時間」をSLA（Service Level Agreement）として設計することが重要だ。
このSLAを設計し、遵守状況をダッシュボードで可視化することで、マーケと営業の連携精度が大幅に向上する。
原則1：ステージは5-7個に収める
多すぎると管理が煩雑になり、少なすぎると商談の進捗が見えなくなる。5-7個が運用しやすい範囲だ。
原則2：各ステージに客観的な完了条件を設定する
「提案中」「検討中」のような主観的な名称ではなく、「何が完了したらこのステージに入るのか」を明確にする。
原則3：ステージは「営業のアクション」ではなく「顧客の状態」で定義する
「提案書を送った」（営業のアクション）ではなく「提案内容を顧客が評価している」（顧客の状態）で定義する。これにより、顧客視点でのパイプライン管理が可能になる。
原則4：受注確率を各ステージに設定する
過去の実績データに基づいて、各ステージの受注確率を設定する。これにより、パイプラインの加重金額（Weighted Pipeline）を算出でき、売上予測の精度が向上する。
原則5：失注理由を構造化する
失注ステージに「失注理由」のドロップダウンプロパティを設定し、構造化して記録する。「予算不足」「競合に負けた」「ニーズが消滅した」「意思決定の延期」などの理由を分析することで、営業プロセスの改善に活用できる。
BtoB SaaS企業を想定した標準的なパイプラインステージ例を紹介する。
ステージ1：アポイント確定（受注確率10%）
ステージ2：ヒアリング完了（受注確率20%）
ステージ3：提案・デモ実施（受注確率40%）
ステージ4：見積・条件交渉（受注確率60%）
ステージ5：最終承認待ち（受注確率80%）
ステージ6：受注（受注確率100%）
ステージ7：失注（受注確率0%）
事業が複数ある場合や、新規と既存で商談プロセスが異なる場合は、複数のパイプラインを運用する。
新規商談パイプライン: 新規顧客の獲得プロセス。上記の7ステージ構成。
アップセル・クロスセルパイプライン: 既存顧客への追加提案。ヒアリングのステージが簡略化され、「活用状況の確認→追加提案→受注」の3-4ステージ構成になることが多い。
パートナー経由パイプライン: 販売パートナーを通じた商談。パートナーとの情報共有ステージが追加される。
HubSpotのワークフロー機能を使って、ライフサイクルステージとパイプラインを自動連動させる。
パターン1：MQL→SQL遷移時に取引を自動作成
リードスコアが閾値を超えてMQLになり、営業がコンタクトしてSQLに遷移したタイミングで、取引（Deal）を自動作成する。取引にはコンタクト情報と会社情報が自動で関連付けられる。
パターン2：取引の受注時にライフサイクルステージを「顧客」に自動変更
取引のステージが「受注」に変更されたとき、関連するコンタクトと会社のライフサイクルステージを自動的に「顧客」に変更する。
パターン3：失注時のリサイクルフロー
取引が失注になった場合、失注理由に応じてコンタクトをナーチャリングリストに戻すか、一定期間後に再アプローチのタスクを自動作成する。
現実の商談では、ステージが逆戻りすることがある。提案まで進んだが、顧客の予算が凍結されて検討が止まる、といったケースだ。
HubSpotでは取引のステージを前後自由に変更できるが、後戻りのルールを事前に定義しておくことが重要だ。「どの条件で後戻りするか」「後戻りした場合のアクションは何か」を明確にし、パイプライン分析の精度を維持する。
パイプラインの各ステージ間のコンバージョン率を測定する際は、「期間」を統一して比較することが重要だ。月次でのステージ遷移率を追うことで、「どのステージにボトルネックがあるか」を正確に特定できる。
パイプラインとライフサイクルステージの設計を実務に落とし込むには、CRMツールの活用が不可欠です。詳しくは「CRM導入の進め方完全ガイド｜準備・ツール選定・データ移行・定着化の全ステップ」で解説しています。
パイプラインとライフサイクルステージは、CRM運用の背骨だ。ライフサイクルステージで「顧客との関係性の全体像」を管理し、パイプラインで「商談の進捗の詳細」を管理する。この2つを正しく設計し、自動化で連動させることで、マーケティングから営業、CSまでの一気通貫のプロセス管理が実現する。
設計のポイントは、MQL・SQLの定義をマーケと営業で合意すること、パイプラインステージに客観的な完了条件を設定すること、そして自動化によって運用負荷を最小化すること。これらを押さえることで、データに基づいた精度の高い営業マネジメントが可能になる。
いいえ、定期的に見直すべきだ。MQLの定義は仮説であり、運用データに基づいて継続的に調整する必要がある。「MQLからSQLへの遷移率」を定期的にモニタリングし、遷移率が低すぎればMQLの基準を厳しくし、高すぎれば緩和する。四半期ごとの見直しを推奨する。
過去6-12ヶ月の商談データから、各ステージからの受注率を算出するのが最も正確だ。データが不十分な場合は、業界の一般的な数値（アポイント10%、ヒアリング完了20%、提案40%、交渉60%、承認待ち80%）を出発点として設定し、データが蓄積されるに従って調整する。
HubSpotの設計上、ライフサイクルステージは基本的に前進方向のみの遷移が推奨されている。「顧客」から「リード」に戻すような操作は、データの一貫性を損なう。既存顧客に再度アプローチする場合は、ライフサイクルステージは「顧客」のまま、新しい取引をパイプラインに作成するのが正しいアプローチだ。
必要だ。むしろ、小規模なうちにパイプラインを正しく設計しておくことで、チーム拡大時にスムーズにスケールできる。3名以下であればステージを4-5個に絞ったシンプルな構成で十分だが、「各ステージの完了条件」と「必須プロパティ」は最初から明確にしておくべきだ。
カテゴリナビゲーション: