HubSpotのライフサイクルステージ - 設計プロセス
By
HubSpotのライフサイクルステージ（Lifecycle Stages、略称LCS）は、企業とコンタクトや会社との現在の関係を示すプロパティーです。
これにより、対象者（または企業）が購買プロセスのどの段階にいるかを把握できます。
ライフサイクルステージの重要性
ライフサイクルステージはHubSpotのCRMにおいて、非常に重要な役割を持っています。各ステージにどれくらい分布しているのか、次のステージに進むのにどれくらい時間がかかっているのかなど。
過去、私が担当していた企業様（BtoB）ではMarketing HubとSales Hubの両方を利用してリード獲得から顧客になるまでのアクションを管理、その成果をレポートで計測していました。
営業としてアクションを行うのは商談に近いQL（Qualified Lead）に絞り、その前の人にはシナリオメール・週次メールでアプローチを行う。ライフサイクルステージのカスタマイズによって、手当たり次第ではなくセグメントを切って効率的にアプローチができるようになりました。
不完全なライフサイクルステージの初期設定
HubSpotを有効活用する重要なライフサイクルステージですが、初期設定のままだと運用時に困ってしまうことがあります。
担当者レベルが手動で編集できてしまう
担当者各自が各人の判断で更新してしまうと、データの整合性が取れなくなり今後のアクションに支障をきたす恐れがあります。
これに関しては、Enterpriseプランを契約いただくことでプロパティーごとにアクセス権限を編集できるので、ライフサイクルステージを手動で変えられなくすることができます。
ただそのためにEnterpriseを契約することはないと思うので、触らないように工夫する必要があります。
初期状態の自動化が微妙
微妙という言葉以外にあまりいいものが浮かばなかったのですが、初期の設定は実際微妙だと個人的には思ってます（変更は設定＞データ管理＞オブジェクト＞コンタクト＞ライフサイクルステージから）。
- コンタクト or 会社が作られた＝リード
- 取引が作成された＝商談
- 取引が成立した＝顧客
この設定しかないので、リード〜MQL・SQL間のステージ滞在時間などが分からない。どれくらいリードから取引作成までかかっているのか、何がダメで詰まっているのか等が判断しづらいです。
なので「ライフサイクルステージを使うぞ！」となったら、基本的に初期設定は全てOFFにしてワークフローを使った自動化を行います（利用可能なプランはPro以上から）。
◼︎ステージ名のカスタマイズもお勧め
ライフサイクルステージの名称は初期設定から自由に変えて問題ありません。関係者全員で話し合い、自社に合ったそれぞれのステージ名を決めたほうが納得感が生まれるはずです。
定義を決める際の注意点
組織としてHubSpot（のライフサイクルステージ）を活用していくと決めた場合、営業、マーケティング、カスタマーサポートの関係者全員の意見が入っているかは考慮すべきでしょう。
例えば、以下はマーケチームが独断で定義を決めた場合に起こりうるセールスチームとの軋轢の例です。
- SQLの質が低下し、セールスの負担が増加
MQLからSQLへの基準が緩く、適切に絞り込まれていないリードがセールスチームに渡され、その結果、セールスが不適格なリードに時間を費やすことになり、商談の成功率が下がる。 - マーケティングとセールスの間で不満が生じる
マーケティング側は「MQLを十分に送っているのに成果が出ない」と考え、セールス側は「質の悪いリードばかり来る」と感じる。チーム間の信頼関係が損なわれ、連携がうまくいかなくなる。 - データの不一致によるパフォーマンス分析の困難化
ライフサイクルステージの定義がセールスの実態と乖離しているため、適切なKPI分析ができない。例えば、SQLが多く創出されているのに商談化率が極端に低い場合、どこに課題があるのか判断しづらくなる。
軋轢が生じると修正には時間と労力がかかります。特に信頼関係が損なわれた場合、意見を尊重し協力する姿勢が必要です。問題の根本原因を特定し、関係者全員が関与して改善を図ることで、持続可能な改善が可能となり、同じ問題の再発を防げます。
ライフサイクルステージの遷移条件
以下の表は、HubSpotでライフサイクルステージの遷移条件の例です。トリガー条件は、次のステージに移動するために必要な要素となります。
| ライフサイクルステージ | トリガー条件（例） | 前ステージへの返送条件 |
|---|---|---|
| 登録読者 | メールアドレスのみ | |
| リード | 登録読者の条件＋姓、名、会社名 | 商談失注時、失注理由が
|
| MQL | リードの条件＋30日以内にフォーム送信1回（資料請求or ウェビナー参加） | |
| SQL | MQLの条件＋50日以内にフォーム送信3回以上（資料請求or ウェビナー参加） or サービスページ経由のお問い合わせ |
|
| 商談 | オンラインミーティングの予約が完了 | |
| 顧客 | 成約 |
|
| その他 | 自社社員・競合他社のメールアドレス、苦情のお問い合わせ、配信カテゴリーを全て解除など | |
ライフサイクルステージは基本、登録読者〜顧客までの一本線のように書かれることが多いですが、実際の運用では、商談で不成立だった相手が時間が経って改めてアプローチしたら契約に至ることもあります。
そのような場合、前ステージへの返送条件を設定しておくことで、商談が不成立になったとしてもアプローチを中断せず、継続的なコミュニケーションを維持することができます。
とはいえ、前ステージへの返送条件は必須ではありません。場合によっては、商談を不成立とせず、取引パイプラインのステージを戻すことで管理をする方が有効なこともあります。
時代はダブルファネル？
ライフサイクルステージはリードから顧客になるにつれて段々対象となるコンタクトの数が少なくなることからファネル型を形成します。レポートでもファネル型が標準で用意されています。しかし、実際の企業活動では顧客の数はどんどん減っていくのではなく、増えていくはずです。サブスクリクションサービスでは、契約後どれくらい長く契約し続けてくれるかが大事です。
そういった意味では、ライフサイクルステージの顧客は終点ではなく、新たな逆ファネルへの入り口なのかもしれません。
ライフサイクルステージの設定
定義が決まれば、あとはワークフローで自動化設定をして、計測環境を整えるだけです。設定時の注意点は以下の３点です。
- 初期設定をOFFにしておく
ワークフローで自動化を行う場合は、設定画面で行われている初期設定はOFFにしてください。 - 一度全てのコンタクトのステージを初期化する
ライフサイクルステージを変える時は、レポーティングで差異が出ないよう、初期化してから定義したステージに移動させてください。 - 前のステージを飛んで遷移しないようにする
初期化の移動では、ファネルレポート・ジャーニーレポートでの遷移が綺麗に出せるよう、SQLであれば、登録読者（あるいはリード）から全てのステージを踏ませてください。
初期化以降も、前のステージを飛ばさないようにするワークフローの設定に注意が必要です。
特定のステージになったら、内部通知を送る・タスクを作成するといったアクションを設定することも今後あるでしょう。
ワークフローはシンプルであった方が良いと思っているので、そういった時にはライフサイクルステージのワークフローにアクションを追加せず、別で内部通知用（シナリオメール用）のアクションを用意するのがお勧めです。
ライフサイクルステージの計測
ライフサイクルステージの成果を計測する際に見る指標は主に以下の３つです。
- 各ステージの件数
- ステージ間の移行率
- ステージ移動にかかった時間（滞在時間）
ファネルレポートがHubSpotでは用意されていますが、利用することで各ステージにどれくらいの件数が存在しているのかがわかります。
また、各ステージの移動にかかった時間に関するプロパティーを利用すれば、どこのステージで躓いているのかがわかるようになります。
一度ダッシュボード・レポートを作成したらそこで終わり...ではありません。
過去、商談が進んでいるのにSQLに残っているコンタクトがあった際に原因を調査すると、ステージ「商談」のトリガー条件がHubSpotのミーティングリンクで予約が完了でしたが、そのコンタクトにはHubSpotのミーティングリンクを使わず商談を進めていた、みたいなことがありました。
レポートの数値が正しいものかは、定期的に確認する必要があります。
まとめ
ライフサイクルステージの利用が定着化するまで社内でのトレーニングや継続的なサポートが必要です。時間をかけて作ったはいいものの運用し始めるとなんかしっくり来ないというケースもあると思います。そういった時に迷わず相談できる体制でありたいですね。
