パイプラインとライフサイクルステージの設計｜MQL→SQL→顧客の定義と自動化

「ライフサイクルステージを設定したが、リードとMQLの違いを誰も説明できない」「パイプラインのステージが形骸化していて、正確な予測が立てられない」「マーケと営業で"商談化"の定義がずれていて、いつもMTGで揉める」

CRM導入支援の現場で、パイプラインとライフサイクルステージの設計に関する相談は極めて多く寄せられます。そして、これらの課題に共通する根本原因は、「なぜこのステージ構成にするのか」という設計哲学が曖昧なまま運用を始めてしまっているという点にあります。

パイプラインとライフサイクルステージは、CRMにおける「顧客の旅路」を可視化する仕組みです。前者は商談プロセスのステップを管理し、後者はコンタクトが認知から顧客化に至るまでの段階を示すフラグとして機能します。この2つの設計が的確であれば、マーケティングから営業、カスタマーサクセスまでのプロセスが一気通貫で可視化され、チーム間の連携が円滑になります。

本記事では、CRM導入支援の現場で培った知見をもとに、パイプラインとライフサイクルステージの設計哲学を解説します。MQL・SQLの定義方法、ステージ設計の判断基準、自動化による運用効率化、そしてHubSpotでの具体的な実装パターンまで、CRM設計者・運用担当者がすぐに実践できる内容をお伝えします。なお、CRMデータベース設計の基本（オブジェクト・プロパティ・関連付け）についてはS-1の記事で解説していますので、あわせてご参照ください。

この記事でわかること

• ライフサイクルステージとパイプラインの違いと、それぞれの役割
• MQL・SQLの定義方法と、ステージ間の移行基準の設計
• BtoB企業における典型的なライフサイクルステージ設計パターン
• パイプライン（取引ステージ）の設計方法と、業種別の考え方
• ワークフローを活用したステージ自動遷移の実装
• 失注後のナーチャリング設計と、掘り起こしフェーズの組み込み方
• よくある設計ミスとその回避策

ライフサイクルステージとパイプラインの全体像

ライフサイクルステージとは何か

ライフサイクルステージとは、コンタクト（個人）や会社が、自社との関係においてどの段階にいるかを示すフラグです。マーケティングの認知段階から始まり、商談化を経て顧客になるまでの「旅路」を可視化するために使います。

このフラグは、コンタクトレコードに1つだけ設定されるプロパティです。つまり、1人のコンタクトは常に「リード」「MQL」「SQL」「顧客」などのいずれか1つのステージに属します。ライフサイクルステージを正しく設計・運用することで、以下のメリットが得られます。

• マーケティングチームが「いま何人のMQLがいるか」を即座に把握できる
• 営業チームが「対応すべきSQLの数」をリアルタイムで確認できる
• 経営層が「認知から顧客化までのファネル全体」をダッシュボードで監視できる
• マーケと営業の「引き渡し」タイミングを明確に定義できる

パイプライン（取引ステージ）とは何か

パイプラインとは、商談（取引）の進行状況をステージごとに管理するかんばん方式の仕組みです。ライフサイクルステージがコンタクトの「全体的な段階」を表すのに対し、パイプラインは取引オブジェクトに紐づく「商談プロセスのステップ」を管理します。

HubSpotでは、取引をパイプラインのボード上でドラッグ＆ドロップしてステージを進めることができます。各ステージに確度（受注確率）を設定することで、加重パイプライン金額の算出やフォーキャスト（売上予測）にも活用できます。

ライフサイクルステージとパイプラインの関係

この2つは混同されがちですが、明確な役割の違いがあります。

重要なのは、ライフサイクルステージとパイプラインは「連動するが別の概念」であるという点です。コンタクトのライフサイクルステージが「SQL」になったタイミングで取引レコードが作成され、その取引がパイプライン上で進行していく――この一連の流れを設計段階で明確にしておくことが、スムーズな運用の前提条件になります。

ライフサイクルステージの設計

設計の前提：「なぜステージを分けるのか」

ライフサイクルステージを設計する前に、まず「なぜステージを分けるのか」という根本的な問いに答える必要があります。

その答えは明快です。ステージを分けることで、各段階に最適なアクションを定義できるからです。リードには認知拡大のコンテンツを、MQLにはウェビナー招待を、SQLにはISや営業からの直接アプローチを、商談中には提案資料を——このように、ステージごとに「何をすべきか」が明確になることで、マーケティングと営業の連携が機能します。

逆に言えば、「ステージは分けたけれど、各ステージに対応するアクションが定義されていない」状態は、設計として不完全です。ステージの数だけでなく、各ステージで「誰が」「何を」するかまでセットで設計することが重要です。

BtoB企業の典型的なステージ設計

CRM導入支援の現場で最もよく使われるBtoB企業向けのライフサイクルステージ構成を紹介します。

ここで重要なのは、最後の2つ「アプローチNG」と「社内」は、本来の購買プロセスのステージではなく、ノイズを除外するためのステージであるという点です。CRMに入ってくるコンタクトの中には、競合企業の担当者や自社社員など、マーケティング・営業の対象外となるレコードが一定数含まれます。これらを明確にステージとして定義しておくことで、マーケティングのKPI計測やレポートの精度が向上します。

BtoCにおけるステージ設計の違い

BtoCビジネスの場合、MQLやSQLという概念はそのまま適用しにくい場合があります。BtoCでは一般的に、ステージ構成がシンプルになります。

• 見込み客（Prospect）：サイト訪問やSNS経由で接点が生まれた段階
• リード：メルマガ登録やLINE友だち追加など、能動的にコンタクト情報を提供した段階
• 顧客：購入が完了した段階
• リピーター：複数回の購入がある段階

ただし、BtoCでも高額商材や長い検討期間がある商材（不動産、保険、教育など）では、BtoBに近いステージ設計が有効です。ステージ設計は業種や商材の性質によって変わりますが、「各ステージに対応するアクションを定義する」という考え方は、BtoBでもBtoCでも共通です。

MQLの定義と設計

MQLとは何か

MQL（Marketing Qualified Lead）とは、マーケティング活動を通じて一定の関心度・適合度を示し、営業アプローチの候補となったリードのことです。「マーケティングが"この人は見込みがある"と判断したリード」と捉えるとわかりやすいでしょう。

MQLの定義が曖昧だと、以下の問題が発生します。

• マーケティングが大量の「まだ温まっていないリード」を営業に渡してしまう
• 営業が「質の低いリードばかり回ってくる」と不満を持つ
• MQLの数をKPIにしているが、MQLの基準が不明確なため、数字に意味がなくなる

MQL定義の設計は、マーケと営業の協業の起点です。この定義を両チームで合意しておくことが、健全なファネル運用の前提条件になります。

MQL判定の2軸：行動スコアと属性スコア

MQLの判定基準は、大きく「行動（Behavior）」と「属性（Fit）」の2軸で設計します。

行動スコアだけで判定すると、「関心は高いが自社のターゲットではないリード」までMQLに含まれてしまいます。逆に、属性スコアだけで判定すると、「ターゲット企業だが全く関心を示していない人」が対象になります。この2軸を組み合わせることで、「自社のターゲットに合致し、かつ関心度が高い」リードだけをMQLとして抽出できます。

MQL判定の具体例

実務では、以下のようなルールでMQL判定を行うケースが一般的です。

行動条件（いずれか1つ以上を満たす）：

• ウェビナーに参加した
• 事例資料やホワイトペーパーをダウンロードした
• 料金ページを2回以上閲覧した
• メールのリンクを3回以上クリックした

属性条件（すべてを満たす）：

• 従業員50名以上の企業に所属
• 自社サービスの対象業種に該当
• 役職が「課長」以上、または「マネージャー」を含む

このような条件を社内で明文化し、マーケティングチームと営業チームの双方で合意しておくことが重要です。なお、条件は固定ではなく、運用データを分析しながら四半期ごとに見直すことを推奨します。

HubSpotでのMQL判定実装

HubSpotでMQL判定を実装する方法は主に2つあります。

方法1：リードスコアリングを使う

HubSpotのリードスコアリング機能を使い、行動や属性に応じてポイントを付与します。合計スコアが閾値（例：50点）を超えたらMQLとする方法です。スコアリングの条件はHubSpotの設定画面で柔軟に定義でき、行動にはプラス点、ネガティブ行動（配信停止など）にはマイナス点を設定できます。

方法2：ワークフローの条件分岐を使う

特定のアクション（例：ウェビナー参加フォーム送信）をトリガーにワークフローを発火させ、属性条件をif/then分岐でチェックし、条件を満たした場合にライフサイクルステージを「MQL」に自動変更する方法です。スコアリングよりもシンプルで、初期段階の運用には適しています。

SQLの定義と設計

SQLとは何か

SQL（Sales Qualified Lead）とは、営業チームが「商談化の見込みが高い」と判断し、直接アプローチすべきと認定されたリードのことです。MQLが「マーケティング視点で見込みがある」という判定であるのに対し、SQLは「営業視点で商談に進む可能性がある」という判定です。

MQLからSQLへの移行は、多くの企業においてインサイドセールス（IS）が担います。ISがMQLに対して架電やメールでヒアリングを行い、以下のような基準で商談化の可能性を判断します。

SQL判定の基準：BANTフレームワーク

SQL判定の基準として広く使われているのが、BANTフレームワークです。

BANTの4要素すべてを満たすことを要件とするか、一部（例：NとTの2つ）を満たせばSQLとするかは、企業の営業戦略や商材特性によって判断します。高単価の商材であれば4要素すべてを厳格にチェックし、低単価の商材であればNeedとTimelineの2つでSQLと判定する、といった調整が実務では行われます。

MQLからSQLへの移行プロセス

MQLからSQLへの移行は、通常以下のプロセスで行われます。

1. ISによるMQLへの初回アプローチ：架電またはメールでコンタクト。課題のヒアリングを実施
2. BANTの確認：ヒアリング内容をもとに、BANT基準での判定を実施
3. SQL認定：基準を満たした場合、CRM上でライフサイクルステージを「SQL」に変更
4. 営業への引き渡し：SQLに認定されたリードの情報を営業担当に引き継ぎ、取引レコードを作成

ここで重要なのは、ISが「SQL認定」の判断をCRM上で記録する運用ルールを明確に定めておくことです。口頭やチャットだけで引き渡しが行われると、データとして残らず、後からの分析やプロセス改善に活用できません。

パイプライン（取引ステージ）の設計

パイプライン設計の基本原則

パイプラインの設計においては、以下の3つの原則を押さえることが重要です。

原則1：顧客の購買プロセスに沿って設計する

パイプラインのステージは、自社の営業プロセスではなく、顧客の購買プロセスを反映させるのが理想です。「顧客がどのような意思決定ステップを踏むか」を起点に考え、そのステップに対応する形で取引ステージを設計します。

原則2：各ステージの「完了条件」を明確にする

「いつこのステージからに次のステージに進むのか」の基準が曖昧だと、営業担当者によってステージの進め方がバラバラになります。各ステージに明確な完了条件（Exit Criteria）を定義しておくことが不可欠です。

原則3：ステージ数は4〜7に収める

ステージが少なすぎると商談の進捗が見えず、多すぎると管理が煩雑になります。実務上は4〜7ステージが運用しやすい範囲です。

BtoB企業の典型的な取引ステージ

上記は汎用的なパターンですが、商材の性質によって調整が必要です。長期の検討期間を要するエンタープライズ向け商材であれば「稟議中」「予算策定中」といったステージを追加する場合もあります。逆に、SMB向けの短期大量販売型であれば「見込み→デモ→受注/失注」の3ステージで十分なケースもあります。

業種別パイプライン設計の考え方

パイプラインの設計は、企業の業種やビジネスモデルによって大きく異なります。以下に代表的なパターンを示します。

ここで鍵となるのは、「自社の営業プロセスの実態」と「理想のプロセス」のギャップを認識した上で設計することです。理想だけで設計すると現場が運用できず、現状のまま設計すると改善が起こりません。両者のバランスを取りながら、段階的に理想に近づけていく設計が現実的です。

複数パイプラインの活用

HubSpotでは、Sales Hub Professional以上のプランで複数のパイプラインを作成できます。以下のようなケースでは、複数パイプラインの設計が有効です。

• 新規営業とアップセル/クロスセルでプロセスが異なる：新規の商談と既存顧客への追加提案では、ステージが大きく異なる
• 商材カテゴリごとに営業フローが違う：プロダクトAは短期決済、プロダクトBは長期検討など
• 部門ごとに営業プロセスが分かれている：事業部制の組織で、各事業部の営業フローが異なる

ただし、パイプラインを増やしすぎるとレポートの統合が難しくなるため、「本当にステージ構成が異なる場合のみパイプラインを分ける」という基準で判断することを推奨します。単にチームを分けたい場合は、パイプラインではなく取引のプロパティ（「担当チーム」など）で管理する方が適切です。

ステージ遷移の自動化設計

なぜ自動化が必要か

ライフサイクルステージやパイプラインの設計がどれほど優れていても、ステージの更新を人力に依存していては、データの正確性は維持できません。営業担当者が商談ステージの更新を忘れる、ISがMQL→SQL変更を後回しにする——こうしたことは日常的に発生します。

ステージ遷移の自動化は、「人が判断すべきところ」と「システムが自動で処理すべきところ」を切り分け、後者をワークフローで実装することで実現します。

自動化すべきステージ遷移

ステージ遷移のすべてを自動化する必要はありません。以下の基準で「自動化すべきもの」と「人が判断すべきもの」を切り分けます。

HubSpotワークフローによる自動化の実装

HubSpotのワークフロー機能を使った、代表的な自動化パターンを紹介します。

パターン1：フォーム送信 → リード設定

ワークフローのトリガーを「フォーム送信」に設定し、アクションとして「ライフサイクルステージをリードに設定」を実行します。これにより、Webサイトからコンバージョンしたすべてのコンタクトが自動的にリードとして登録されます。再登録設定を有効にしておくことで、同じコンタクトが別のフォームを送信した際にもワークフローが再度発火するように設定できます。

パターン2：スコア到達 → MQL設定

トリガーを「HubSpotスコアが50以上になった時」に設定し、条件分岐で属性条件（従業員規模、業種など）をチェックします。条件を満たした場合にライフサイクルステージを「MQL」に変更し、同時に担当ISに通知メールを送信します。

パターン3：取引作成 → 商談ステージ設定

トリガーを「取引が作成された時」に設定し、アクションとして関連コンタクトのライフサイクルステージを「商談（Opportunity）」に自動変更します。これにより、取引レコードの作成とライフサイクルステージの更新が連動します。

パターン4：受注 → 顧客設定 → CS通知

トリガーを「取引ステージが受注（Closed Won）に変更された時」に設定します。アクションとして、関連コンタクトのライフサイクルステージを「顧客」に変更し、CSチームにオンボーディング開始の通知を送信します。必要に応じて、チケット（オンボーディングタスク）を自動作成する処理も組み込めます。

自動化設計の注意点

ワークフローによるステージ自動化を設計する際には、以下の点に注意が必要です。

• ステージの「逆戻り」ルールを定義する：HubSpotのライフサイクルステージはデフォルトで「前に戻さない」設定になっています。顧客から再びMQLに戻す場合など、逆方向の遷移をどう扱うかを事前に決めておく必要があります
• ワークフローの実行順序を意識する：複数のワークフローが同じコンタクトに対して同時に発火すると、ステージが意図しない値に上書きされる可能性があります。ワークフロー間の優先順位を設計段階で整理しておきましょう
• テストコンタクトで動作確認する：本番環境で一斉に適用する前に、テスト用のコンタクトでワークフローの動作を確認することを強く推奨します

失注とナーチャリングの設計

失注は「終わり」ではなく「フェーズの切り替え」

商談が失注に終わった場合、そのコンタクトへのアプローチを完全にやめてしまう企業は少なくありません。しかし、失注した商談の相手は、一度は自社サービスに興味を持ち、商談まで進んだ「最も見込みの高い潜在顧客」です。

失注の理由が「時期が合わなかった」「予算が確保できなかった」「競合と比較した結果」であれば、状況が変わった時点で再度商談化する可能性は十分にあります。だからこそ、失注後のナーチャリング（再育成）フェーズをライフサイクルステージの設計に組み込んでおくことが重要です。

失注掘り起こしフェーズの設計

失注掘り起こしフェーズは、以下の流れで設計します。

1. 失注理由の記録：取引レコードに「失注理由」プロパティを設け、失注時に必ず理由を記録する運用ルールを設定する。理由のカテゴリは選択リスト形式にし、「予算不足」「時期尚早」「競合選定」「ニーズ不一致」「連絡不通」などを設定
2. ライフサイクルステージの変更：取引が失注になったタイミングで、関連コンタクトのライフサイクルステージを「失注掘り起こし」に自動変更するワークフローを設定
3. ナーチャリングシーケンスの登録：「失注掘り起こし」ステージのコンタクトに対して、再ナーチャリング用のメールシーケンスを配信。失注理由に応じてコンテンツを出し分ける
4. 再MQL化の条件設定：ナーチャリング中にウェビナー参加や資料DLなどのアクションがあった場合、再びMQLに遷移させる条件を設定

失注理由別のナーチャリングコンテンツ

このように、失注理由をデータとして蓄積しておくことで、適切なタイミングに適切なコンテンツでの再アプローチが可能になります。失注理由の記録は、営業プロセスの改善にも活用できるため、「失注理由を記録する運用ルール」は必ず設計に組み込むことを推奨します。

ステージ設計のよくある失敗パターンと対策

失敗パターン1：MQLとSQLの定義が曖昧

最も頻度の高い失敗パターンです。MQLの基準が「なんとなくホットっぽいリード」レベルにとどまっていると、マーケティングと営業の間で認識のズレが生じ、「マーケから渡されるリードの質が低い」「営業がフォローしてくれない」という不毛な対立が発生します。

対策：MQL・SQLの定義を文書化し、行動条件と属性条件を明確に定める。定義はマーケティングチームと営業チームの合同ミーティングで合意し、四半期ごとに見直す運用サイクルを設ける。

失敗パターン2：ステージが多すぎる

「細かく管理したい」という意図でライフサイクルステージを10以上に設定するケースがあります。しかし、ステージが多すぎると、各ステージの定義が曖昧になり、正確な分類が困難になります。さらに、営業担当者のステージ更新の負荷が上がり、結果としてデータの正確性が低下します。

対策：ライフサイクルステージは5〜8、パイプラインのステージは4〜7を目安に設計する。それ以上の粒度が必要な場合は、別のプロパティ（「サブステータス」など）で管理することを検討する。

失敗パターン3：失注後の設計がない

パイプラインの最終ステージが「受注」と「失注」だけで、失注後のプロセスが設計されていないケースは非常に多いです。失注したリードが放置され、再アプローチのタイミングを逃してしまいます。

対策：ライフサイクルステージに「失注掘り起こし」を設け、失注理由の記録と再ナーチャリングのプロセスを設計する。ワークフローで失注→掘り起こしフェーズへの遷移を自動化する。

失敗パターン4：ライフサイクルステージとパイプラインが連動していない

ライフサイクルステージは設定しているが、取引ステージの変更と連動していないケースです。取引が受注になっても、コンタクトのライフサイクルステージが「SQL」のままになっているなど、データの不整合が発生します。

対策：取引ステージの変更をトリガーに、関連コンタクトのライフサイクルステージを自動更新するワークフローを設定する。特に「受注→顧客」「失注→失注掘り起こし」の遷移は必ず自動化する。

失敗パターン5：設計後の見直しサイクルがない

ステージ設計を一度決めたら、以後見直しを行わないケースです。ビジネスの変化に伴い、ステージ構成やMQL/SQLの定義は当然変わるべきものですが、設計の見直しがされないまま運用が形骸化していきます。

対策：四半期に一度、ステージ設計の見直しミーティングを設ける。見直しの際は、ステージ間のコンバージョン率、ステージ滞留時間、営業からのフィードバックをデータとして確認し、必要に応じてステージ定義や自動化ルールを調整する。

設計から運用への接続：チーム間連携の設計

SLA（Service Level Agreement）の設計

ライフサイクルステージの設計において見落とされがちなのが、チーム間の引き渡しにおけるSLA（サービスレベルアグリーメント）の設計です。SLAとは、ステージが変わった後に「誰が」「いつまでに」対応するかを取り決めたルールです。

SLAを設定することで、ステージ遷移後の対応速度が可視化され、ボトルネックの早期発見と改善が可能になります。HubSpotでは、SLAの遵守状況をダッシュボードで監視する仕組みも構築できます。

ステージ設計のダッシュボード活用

ステージ設計を運用に落とし込んだら、以下のKPIをダッシュボードで監視することを推奨します。

• ステージ別コンタクト数：各ライフサイクルステージに何人のコンタクトがいるかをファネル形式で表示
• ステージ間コンバージョン率：リード→MQL、MQL→SQL、SQL→商談、商談→受注の各遷移率
• ステージ滞留時間：各ステージにコンタクトがどのくらいの期間とどまっているか
• パイプライン金額：取引ステージ別の金額集計と、加重パイプライン金額
• SLA遵守率：各遷移ポイントにおける対応時間がSLA内に収まっている割合

これらのKPIを定期的にモニタリングすることで、ステージ設計の有効性を検証し、継続的に改善するサイクルを回すことができます。

HubSpotでの実装チェックリスト

ここまで解説した設計内容をHubSpotで実装する際のチェックリストを整理します。

ライフサイクルステージの設定

1. 設定 → プロパティ → コンタクトプロパティ → 「ライフサイクルステージ」を開く
2. デフォルトのステージ（Subscriber、Lead、MQL、SQL、Opportunity、Customer、Evangelist、Other）をカスタマイズ
3. 自社の設計に合わせてステージの追加・削除・並び替えを実施
4. 各ステージの定義を社内ドキュメントとして整備し、チームに共有

パイプラインの設定

1. 設定 → オブジェクト → 取引 → パイプライン で新規パイプラインを作成（または既存パイプラインを編集）
2. 取引ステージを設計書に沿って追加し、各ステージに確度（パーセンテージ）を設定
3. 各ステージの「プロパティ入力必須設定」を活用し、ステージ移動時に必要情報の入力を強制
4. 複数パイプラインが必要な場合は、パイプラインを追加して設定

ワークフローの設定

1. 自動化 → ワークフロー から新規ワークフローを作成
2. トリガー条件（フォーム送信、スコア到達、取引ステージ変更など）を設定
3. 条件分岐（if/then）で属性チェックなどを追加
4. アクション（ライフサイクルステージ変更、通知送信、タスク作成など）を設定
5. 再登録設定の要否を確認（同じコンタクトが再度条件を満たした場合にワークフローを再実行するか）
6. テストコンタクトで動作を検証し、問題がなければ有効化

レポート・ダッシュボードの設定

1. レポート → レポートビルダー でファネルレポート（ライフサイクルステージ別コンタクト数）を作成
2. コンバージョン率レポート（ステージ間遷移率）を作成
3. パイプラインレポート（ステージ別取引金額、加重金額）を作成
4. ダッシュボードにレポートを配置し、チームに共有

まとめ

パイプラインとライフサイクルステージの設計は、CRM運用の根幹を成す要素です。この設計が的確であれば、マーケティングから営業、カスタマーサクセスまでの一連のプロセスが可視化され、チーム間の連携が円滑になります。

本記事で解説した設計のポイントを整理すると、以下の通りです。

1. ライフサイクルステージとパイプラインは「連動するが別の概念」：前者はコンタクトの全体的な段階、後者は商談プロセスのステップを管理する
2. MQL・SQLの定義を明確に文書化する：行動スコアと属性スコアの2軸でMQLを判定し、BANTフレームワークでSQLを判定する
3. 各ステージに対応するアクションをセットで設計する：ステージを分ける目的は、各段階に最適な施策を実行するため
4. ステージ遷移は自動化で正確性を担保する：人が判断すべきところと自動化すべきところを切り分け、ワークフローで実装する
5. 失注後のナーチャリング設計を組み込む：失注は「終わり」ではなく「再育成フェーズへの切り替え」として設計する
6. SLAとダッシュボードで運用を監視する：設計した仕組みが機能しているかを定量的にモニタリングし、継続的に改善する

ステージ設計は一度作って終わりではなく、運用データをもとに継続的に改善していくものです。まずは本記事で紹介した基本パターンをベースに設計を始め、四半期ごとの見直しサイクルの中で自社に最適な形に磨き上げていくことを推奨します。

よくある質問（FAQ）

Q. ライフサイクルステージは、HubSpotのデフォルト設定のまま使うべきですか？

A. HubSpotのデフォルトステージ（Subscriber、Lead、MQL、SQL、Opportunity、Customer、Evangelist、Other）は汎用的に作られており、そのまま使える部分も多いですが、ほとんどの企業ではカスタマイズが必要です。自社のビジネスプロセスに合わせて、不要なステージの削除や、必要なステージ（「失注掘り起こし」「アプローチNG」など）の追加を行うことを推奨します。デフォルトを出発点にしつつ、自社の設計哲学に基づいて調整するのが現実的なアプローチです。

Q. MQLの基準を厳しくしすぎると、リード数が激減しませんか？

A. MQLの基準を厳しくすれば、MQLの数は減ります。しかし、本質的に重要なのは「MQLの数」ではなく「MQLから商談化・受注に至る確率（コンバージョン率）」です。MQLの基準を適切に設定することで、営業チームが効率的にフォローできる質の高いリードが増え、結果としてROIが向上します。まずは少し厳しめの基準で運用を開始し、コンバージョン率と営業からのフィードバックを見ながら調整するのがよいでしょう。

Q. パイプラインは1つで十分ですか？複数必要になるのはどんな場合ですか？

A. 営業プロセスが全社で統一されている場合は、1つのパイプラインで十分です。複数パイプラインが必要になるのは、「新規営業とアップセルでステージ構成が大きく異なる」「商材カテゴリによって営業フローが根本的に違う」といったケースです。単に「チームを分けて管理したい」という理由であれば、取引のプロパティ（担当チーム、担当地域など）で分類する方が、レポートの統合性を維持できるため推奨されます。

Q. ライフサイクルステージを「逆戻り」させるのはよくないのでしょうか？

A. ライフサイクルステージは基本的に「前進する」設計が推奨されますが、実務上は逆戻りが必要なケースもあります。例えば、顧客が契約を解約した場合や、商談が保留になり再ナーチャリングが必要な場合です。HubSpotではデフォルトでライフサイクルステージの後退が制限されていますが、ワークフローを使えば強制的に変更できます。重要なのは「どのケースで逆戻りを許可するか」を事前にルール化しておくことです。

Q. ステージ設計を見直すタイミングはいつが適切ですか？

A. 四半期に一度の定期見直しを推奨します。見直しの際には、ステージ間のコンバージョン率の変化、ステージ滞留時間の異常値、営業チームからのフィードバックを確認します。加えて、ビジネスの大きな変化（新商材の追加、組織変更、ターゲット市場の変更など）があった場合は、定期見直しを待たずに臨時で設計を再検討するべきです。

関連記事

• CRMデータベース設計の基本｜オブジェクト・プロパティ・関連付けの設計思想（CRMの基盤設計から理解したい方はこちら）
• カスタムオブジェクト設計ガイド｜追加判断と設計パターン（カスタムオブジェクトの設計判断についてはこちら）
• CRMデータクレンジング実践ガイド｜データ品質を維持する方法（データ品質の維持・改善についてはこちら）