HubSpotライフサイクルステージの設計・設定・運用ガイド。MQL→SQLの遷移設計と計測

ライフサイクルステージ（Lifecycle Stages、略称LCS）は、コンタクトや会社が購買プロセスのどの段階にいるかを示すプロパティーです。正しく設計すれば、マーケティングからセールス、カスタマーサクセスまでのデータ連携とパイプライン予測の精度が劇的に変わります。

この記事では、ライフサイクルステージの定義・設定・運用までを実務目線で解説します。

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

ライフサイクルステージは、見込み客が自社を知ってから顧客になり、さらには推奨者になるまでの旅路を段階的に分類したものです。HubSpotではデフォルトで以下のステージが用意されています（公式ナレッジベース: ライフサイクルステージの使用）。

ポイントは「MQLはマーケティングが判断し、SQLは営業が判断する」という役割分担です。Lars Helgeson著『CRM for Dummies』（Wiley, 2017）では、MQLを「チャネルを通じて興味を示し、自ら購入の適格性を選択した（self-selected）リード」、SQLを「営業担当者との会話を経て、見込みありと確認されたリード」と定義しています。この区別が曖昧だと、後述する遷移条件やレポートの設計が全て崩れてしまいます。

ライフサイクルステージの重要性と設計原則

ライフサイクルステージはHubSpotのCRMにおいて、非常に重要な役割を持っています。各ステージにどれくらい分布しているのか、次のステージに進むのにどれくらい時間がかかっているのかなど。

過去、私が担当していた企業様（BtoB）ではMarketing HubとSales Hubの両方を利用してリード獲得から顧客になるまでのアクションを管理、その成果をレポートで計測していました。

営業としてアクションを行うのは商談に近い QL（Qualified Lead） に絞り、その前の人にはシナリオメール・週次メールでアプローチを行う。ライフサイクルステージのカスタマイズによって、手当たり次第ではなくセグメントを切って効率的にアプローチができるようになりました。

マクロとミクロを混同しない

ライフサイクルステージの設計で最初に理解しておくべきなのが、マクロ（バイヤージャーニーの大枠）とミクロ（日々の営業活動）の分離です。

ライフサイクルステージはあくまで「この人は今、購買プロセスのどこにいるか」を示すマクロな指標です。「電話をかけた」「ミーティングを設定した」といったミクロな営業活動の進捗は、HubSpotのリードオブジェクトやリードステータスで管理します。

この区別をつけずにライフサイクルステージに細かい営業活動を組み込もうとすると、ファネルレポートが汚れて使い物にならなくなります。

「ライフサイクルステージ」と「リードオブジェクトのステージ」、「リードステータス」の概念の違いに関する記事「HubSpot SalesHubの「リードの管理」で見込み顧客に対する活動を見直す- 混乱しないための概念理解」を書いています。もしよければご覧ください。

定義を決める際の注意点

組織としてHubSpot（のライフサイクルステージ）を活用していくと決めた場合、営業、マーケティング、カスタマーサポートの関係者全員の意見が入っているかは考慮すべきでしょう。

定義の基準は、主観的な判断ではなく測定可能なデータポイントに基づくことが大切です。「営業担当者が興味を持っていると感じた」ではなく、「HubSpotスコアが100pt以上に到達した」「デモ依頼フォームを送信した」のように、誰が見ても同じ判断ができる条件にすることで、データの整合性が保たれます。

例えば、以下はマーケチームが独断で定義を決めた場合に起こりうるセールスチームとの軋轢の例です。

• SQLの質が低下し、セールスの負担が増加
  MQLからSQLへの基準が緩く、適切に絞り込まれていないリードがセールスチームに渡され、その結果、セールスが不適格なリードに時間を費やすことになり、商談の成功率が下がる。
• マーケティングとセールスの間で不満が生じる
  マーケティング側は「MQLを十分に送っているのに成果が出ない」と考え、セールス側は「質の悪いリードばかり来る」と感じる。チーム間の信頼関係が損なわれ、連携がうまくいかなくなる。
• データの不一致によるパフォーマンス分析の困難化
  ライフサイクルステージの定義がセールスの実態と乖離しているため、適切なKPI分析ができない。例えば、SQLが多く創出されているのに商談化率が極端に低い場合、どこに課題があるのか判断しづらくなる。

一度こじれると立て直しにはかなりの時間と労力がかかります。なので最初から全員を巻き込んで決めるのが、結局は近道です。

ライフサイクルステージの遷移条件

以下の表は、HubSpotでライフサイクルステージの遷移条件の例です。トリガー条件は、次のステージに移動するために必要な要素となります。

ライフサイクルステージは基本、登録読者〜顧客までの一本線のように書かれることが多いですが、実際の運用では、商談で不成立だった相手が時間が経って改めてアプローチしたら契約に至ることもあります。これは再活性化（リアクティベーション・掘り起こし）と呼ばれています。

ステージを戻したくなった時の運用

商談が不成立になった時や、MQLからSQLへの昇格に失敗した時、ライフサイクルステージを前のステージに戻したくなる気持ちは分かります。ただし、これはお勧めしません。

そもそもHubSpotのライフサイクルステージは前進のみを前提に設計されています。前のステージに戻すには一度値をクリアする必要がありますが、その瞬間に「Became an Opportunity Date（商談化日）」等のタイムスタンプが消えます。つまり、ファネルレポートやステージ滞在時間の分析データが壊れてしまうのです。

推奨は「ステージは維持して、現在の状態は別のプロパティで管理する」方法です。

• ライフサイクルステージは到達した段階のまま残す（履歴として保持）
• 「今追っているか」「失敗した理由」はカスタムプロパティ（例：qualification_status = 対応中 / 保留 / NG）や取引のステージで表現する
• 再アプローチの判断も、これらのプロパティを基にワークフローやリストで管理する

これがまさに前述した「マクロとミクロの分離」の実践例です。マクロなライフサイクルステージは履歴として保持しつつ、ミクロな営業活動の状態はカスタムプロパティや取引で管理するわけです。

失注理由で担当者を分ける

もう一つ重要なのが、失注理由によって「誰が担当するか」を分けることです。

この分岐を自動化するには、取引を失注に移動する際に失注理由を必須入力にするのがポイントです。自由入力ではなくドロップダウン形式にしておけば、ワークフローのトリガーとして使えます。

商談前の脱落も同じ原則

この「戻さない」原則は、失注だけでなく、MQLやSQLの段階で脱落したケースにも当てはまります。

共通する原則は、ライフサイクルステージは「どこまで到達したか」の最高到達点として残すということです。「失敗した」「今は追っていない」という現在の状態は、カスタムプロパティや取引など別の軸で表現します。

なお、1人のコンタクトに対して別プロダクト・別キャンペーンで並行して追客するような運用が出てきた場合は、HubSpotのリードオブジェクトの導入を検討してください。リードオブジェクトを使えば、コンタクト単位ではなく「追客の単位」ごとに独立したサイクルを回せるようになります。

ワークフローでレポートを守る

ライフサイクルステージの運用で意外と見落としがちなのが、ステージをスキップするとファネルレポートが壊れるという問題です。

例えば、初めてサイトに来た人がいきなりデモ依頼フォームを送信した場合を考えてみてください。本来は「登録読者→リード→MQL→SQL」と段階を踏むところを、一気に「SQL」に飛んでしまう。するとHubSpotのファネルレポートでは、このコンタクトは「リード」も「MQL」も通過していないことになり、各ステージのコンバージョン率が正しく計算されなくなります。

これを防ぐためにワークフローでシステム上は全ステージを通過した記録が残るように設定することができます。

見た目は一瞬ですが、ファネルレポート・ステージ滞在期間のレポートが正確に機能するようになります。ファネルレポートの数値がおかしいと思ったら、まずこのウォーターフォール設計ができているか確認してみてください。

ワークフローの設計について詳しくは、こちらの記事「 HubSpotワークフローの設計・設定ガイド」でも解説しています。

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

定義が決まれば、あとはワークフローで自動化設定をして、計測環境を整えるだけです。

ワークフローを使うときは初期設定はOFFにする

微妙という言葉以外にあまりいいものが浮かばなかったのですが、初期の設定は実際微妙だと個人的には思ってます（変更は設定＞データ管理＞オブジェクト＞コンタクト＞ライフサイクルステージから。公式: ライフサイクルステージの自動設定と同期）。

初期状態の設定（ステージは変更可能）

• コンタクト or 会社が作られた＝リード
• 取引が作成された＝商談
• 取引が成立した＝顧客

この設定しかないので、リード〜MQL・SQL間のステージ滞在時間などが分からない。どれくらいリードから取引作成までかかっているのか、何がダメで詰まっているのか等が判断しづらいです。

なので「ライフサイクルステージを使うぞ！」となったら、基本的に初期設定は全てOFFにしてワークフローを使った自動化を行います（ワークフローの利用可能なプランはPro以上から）。デフォルトの自動化とカスタムワークフローが同時に動くと競合が起き、予測不能なデータの上書きが発生するためです。

その他の設定ポイント

• 担当者レベルの手動編集を制限する
  担当者各自が各人の判断で更新してしまうと、データの整合性が取れなくなります。Enterpriseプランではプロパティーごとにアクセス権限を編集できますが、そのためにEnterpriseを契約することはないと思うので、触らないように工夫する必要があります。
• 一度全てのコンタクトのステージを初期化する
  ライフサイクルステージを変える時は、レポーティングで差異が出ないよう、初期化してから定義したステージに移動させてください。初期化の際は、全てのステージを順に踏ませてファネルレポートの遷移を綺麗に残します（前述のウォーターフォールWF）。
• ステージ名は自社に合わせてカスタマイズする
  ライフサイクルステージの名称は初期設定から自由に変えて問題ありません。関係者全員で話し合い、自社に合ったそれぞれのステージ名を決めたほうが納得感が生まれるはずです。

隠しフォームフィールドでルーティングを効率化

フォームの裏側にConversion_Typeなどの非表示フィールドを設定しておくと、ワークフローのトリガーがフォーム名の変更で壊れるリスクを回避できます。

「最近のコンバージョンが〜を含む」というトリガーは脆いので、可能であれば隠しフィールドの値でルーティングする方が安全です。

フォームの設定について詳しくは、こちらの記事「HubSpotフォームの設定・活用ガイド」もご覧ください。

ワークフローはシンプルに保つ

特定のステージになったら、内部通知を送る・タスクを作成するといったアクションを設定することも今後あるでしょう。

ワークフローはシンプルであった方が良いと思っているので、そういった時にはライフサイクルステージのワークフローにアクションを追加せず、別で内部通知用（シナリオメール用）のアクションを用意するのがお勧めです。

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

ライフサイクルステージの成果を計測する際に見る指標は主に以下の3つです。

• 各ステージの件数
• ステージ間の移行率
• ステージ移動にかかった時間（滞在時間）

ファネルレポートがHubSpotでは用意されていますが、利用することで各ステージにどれくらいの件数が存在しているのかがわかります。

ステージ滞在時間の計算プロパティ

HubSpotは、すべてのライフサイクルステージに対して以下の計算プロパティを自動生成しています。

これらを使ってカスタムレポートを組めば、平均セールスサイクルの長さや、どのステージで勢いを失っているかをデータに基づいて把握できます。

監視すべきレポート

ダッシュボードには以下のようなレポートを入れておくと、異常値やデータ品質の問題を早期に発見できます。

レポートは作って終わりじゃない

一度ダッシュボード・レポートを作成したらそこで終わり...ではありません。

過去、商談が進んでいるのにSQLに残っているコンタクトがあった際に原因を調査すると、ステージ「商談」のトリガー条件がHubSpotのミーティングリンクで予約が完了でしたが、そのコンタクトにはHubSpotのミーティングリンクを使わず商談を進めていた、みたいなことがありました。

ステージ移行の前提条件と実際のオペレーションがちゃんと実行されているかを確認、その後レポートの数値が正しいものか、定期的に確認する必要があります。

執筆後記：時代はダブルファネル？

ライフサイクルステージはリードから顧客になるにつれて段々対象となるコンタクトの数が少なくなることからファネル型を形成します。レポートでもファネル型が標準で用意されています。

しかし、実際の企業活動では顧客の数はどんどん減っていくのではなく、増えていくはずです。サブスクリプションサービスでは、契約後どれくらい長く契約し続けてくれるかが大事です。

そういった意味では、ライフサイクルステージの顧客は終点ではなく、新たな逆ファネルへの入り口なのかもしれません。

もしHubSpotの使い方や運用についてお悩みがあればぜひお気軽にご相談ください。