HubSpotの「ライフサイクルステージ」の基本と実践的な活用法
みなさん、こんにちは。
予実管理クラウドを提供するDIGGLEというスタートアップでマーケティングを担当していますYoshiこと、瀬川（@motoyoshi）です。
弊社では、CRMとしてHubSpotを利用しています。入社以降はアドミン的な仕事で、よりHubSpotを使いやすくなるように改善を積み重ねています。
その中で取り組んだ1つが、ライフサイクルステージのリストラクチャーです。ライフサイクルステージは、CRM管理において重要な考え方である一方、意外と扱うのが難しいプロパティーであり、「なかなか上手く使えてないです…！」という方も多いようです。
そこで、この記事では、HubSpotのライフサイクルステージについて解説しつつ、弊社で実際に運用している定義と運用を紹介していきます。個人的にはまだ改善の余地はあると思いますが、困っている方には役立つ部分もあるかと思い、公開することにしました。
HubSpot運用にお悩みのアドミンの方は、ぜひ参考にしてみてください。
ライフサイクルステージとは？
ライフサイクルステージの定義と重要性
そもそもライフサイクルステージとは、どういったプロパティーなのでしょうか。一言で言うと、お客様と企業が関係性を構築するプロセスにおける段階を表すものです。
特にB2Bにおいては、その性質上、衝動買いということはなく、比較的長い検討プロセスを経て、商談が生まれ、受注する傾向が高いです。
言い換えれば、顧客は階段を登るように上がっていき、最終的には顧客やその先にある推奨者（エバンジェリストなど）になっていきます。
その過程をきちんと定義し、可視化するのが、まさにライフサイクルステージです。このステージをきちんと管理することで、お客様の状態やニーズにあったコミュニケーションが可能になるのです。
デマンドウォーターフォールを理解する
ここでライフサイクルステージを考える上で重要な概念を紹介します。その概念とは、デマンドウォーターフォールです。
デマンドウォーターフォール（Demand Waterfall）は、企業のマーケティングやセールスのパイプライン管理において、潜在顧客がどのようにして実際の顧客に変わっていくプロセスを段階的に示す概念です。アメリカのシリウスディシジョン社が2006年にこの概念を発表しており、B2Bマーケティング界ではとても有名なフレームワークとなっています。
リードが入ってきてから受注するまでをステップに区切り、滝のように上から下に落ちていくことから、その名前がつけられました。
ライフサイクルステージは、まさにこのデマンドウォーターフォールを想定して作られたプロパティーなので、この概念をきちんと理解することが、正しい運用をするのに不可欠なのです。
デマンドウォーターフォールは、最初に発表されてから、社会変化などもあって、2回のバージョンアップが行われています。
どのモデルがよいかは目的次第なので一概に言えませんが、シンプルに考えるなら2006年、より組織が拡大してきたときは2012年モデルをベースに考えるのがよいのかなとは思っています。
なお今回、私がライフサイクルステージを検討する際は、2012年モデルをベースにアレンジしてつくっています。
なおデマンドウォーターフォールについては、尊敬するマーケターの上村さんがとても分かりやすくまとめてくださっているので、もっと深く知りたい方は、ぜひご覧ください。
HubSpotにおけるライフサイクルステージの性質
ここからは、HubSpotにおけるライフサイクルステージの性質について見ていきましょう。この性質をうまく理解することが、このプロパティーの活用の近道です。
知っておきたい性質は、以下の3つです。
1. ライフサイクルステージの不可逆性
2. コンタクトと会社のライフサイクルステージは、同じ設定になる
3. 特定の条件下で、ライフサイクルステージは自動で更新される
1. ライフサイクルステージの不可逆性
1つ目のポイントは、ライフサイクルステージにはステージが進む向きがあり、不可逆であることです。
例えば、HubSpotのデフォルトのライフサイクルステージは以下の通りです。
これらのステージは、下向きに進むような挙動になっています。「リード」→「MQL」とか、「MQL」→「SQL」みたいな感じですね。
一方で、「SQL」→「MQL」という逆行するようには進みません。実際、ワークフローなどでこのライフサイクルステージを逆行させる設定をしてしまうと、実行時にエラーが出ます。
なぜこのような仕様になっているかと言えば、逆行を許してしまうと、ステージ管理が複雑になってしまうからだと思っています。例えば、とある契約している顧客に対して、アップセル商品を提案することなり、商談が立った時を考えてみましょう。
もともとは「顧客」のステージですが、商談が発生することで「商談」と逆戻りしてしまうと、この会社が既存顧客なのか、新規商談している顧客なのか、分かりづらくなりますよね。こういった意図せぬ変更を防ぐため、一方通行になっているんだと思います。
ここで、ちょっとHubSpotに詳しい方だと、「でも、自分で変更したらステージを戻せるよね？」という質問があるかもしれません。しかし実際の挙動のところ、一度ライフサイクルステージがリセットされて、その上で新しいステージが設定されているので、やはり逆行しているわけではないのです。
2. コンタクトと会社のライフサイクルステージの設定は、同じになる
2つ目のポイントは、コンタクトと会社のライフサイクルステージの設定は、全く同じ内容にしかできないことです。それぞれに別のステージを割り当てることができません。
実際に設定画面で「会社」のページを見てみると、編集できないと書かれていますね。
これは私の推察ですが、HubSpotにおいては会社との取引が想定されていて、コンタクトはその会社に紐づくものであるから、それぞれが同期を取れるようにこのような設定になっているんだと思います。
このように設定できる項目が同一であるため、のちほど触れますが、コンタクトと会社の状態をそれぞれ想定して設計する必要があります。
3. 特定の条件下で、ライフサイクルステージは自動で更新される
3つ目のポイントは、特定の条件下で、コンタクトと会社のライフサイクルステージは自動で更新される点です。
HubSpotでは、デフォルトの設定であれば、以下のような挙動が起きます。
コンタクト or 会社が作成された時 →「リード」に設定される
取引が作成された時→「商談」に設定される
取引が成立された時→「顧客」に設定される
なお、これらの設定はあくまでHubSpot側がプリセットしているだけなので、必要に応じてオプトアウトすることも可能です。とはいえ、こちらの設定はそのまま使うのが個人的にはよいのではないかと思っています。
弊社での運用方法
ここからは、弊社で運用しているライフサイクルステージについて具体的に紹介していきます。
なお先にお伝えしておくと、ライフサイクルステージは、会社のステージや業種や商材の特性によって変わってきます。ぜひ参考としてご覧いただけますと幸いです。
全体像としては、上記の運用になっています。ポイントとしては、インバウンドとアウトバウンドを分けて2系統で運用している点です。
インバウンド系統
インバウンド系統は、主に検索広告や自然検索といったWeb施策や、展示会などのオフライン施策から発生するリードの流れです。
リード、MAL（Marketing Accepted Lead）、対象外
まずは「リード」として作成されたのち、コンタクトとしての適格性を判定しています。具体的には、ターゲットとなる企業規模や部署の条件に合致するかを自動的に判定して、「MAL（＝Marketing Accepted Lead）」になります。
また「リード」のうち、競合他社や学生などの営業対象から外れるコンタクトは、「対象外」のステージに自動で除外されます。
弊社では、この「MAL」がマーケティングチームのKPIとなっているので、ただコンタクトが増えればよいのではなく、きちんと正しいターゲットを獲得できるように施策を考えて運用しています。
MQL（Marketing Qualified Lead）
「MAL」となったコンタクトは、Webアクティビティの有無をチェックします。具体的には、Webサイトの閲覧履歴もしくはメールの開封が複数回あるかを判定して、条件を満たしたものが「MQL（=Marketing Qualified Lead）」 になります。言い換えれば、アクティブ化したかを判定していると言えます。
展示会などでは短期間で大量のコンタクトが増加します。しかし、実際は熱量が高い人から低い人までさまざまいます。そこで、デジタルマーケティングに反応があったかをチェックポイントにすることで、優先度をつけられるようにしている訳です。
【ひとことポイント】実務的には、HubSpotにある「セッション数」「開封されたマーケティングEメール」のいずれかが2以上であることをトリガーとして、ワークフローで判定しています。
SAL（Sales Accepted Lead）
「MQL」になったコンタクトは、インサイドセールス（以下、IS）に引き渡すコンタクトになります。ISがコールや個別Eメールを送り、アプローチを開始したことをトリガーとして、「SAL（＝Sales Accepted Lead）」になります。
【ひとことポイント】実務的には、HubSpotにある「連絡の回数」が1以上であることをトリガーとして、ワークフローで判定を行っています。
SQL（Sales Qualified Lead）
そしてISがコールして顧客の課題感などをヒアリングし、自社サービスで解決できる課題を持っているかを確認します。コールの中で、一定以上の課題があると認められた時には、「SQL（=Sales Qualified Lead）」になります。
具体的には、顧客の課題レベルを記録するプロパティーを用意しておき、コールの中でISが記録した内容に基づき、自動で判定を行っています。
「SQL」のうち、アポの日程が取得できたものを「商談」として、さらにステージが上がるようなフローです。
実際には、適格性がない（＝ターゲット顧客外）のコンタクトや、アクティビティの履歴がない「MAL」からアポが取れることもあるので、ファストパスの動線も設けており、ISが課題ありと判定すれば、「SQL」に上がるような運用になっています。
アウトバウンド系統
アウトバウンド系統は、アウトバウンド施策を行う際のフローになります。インバウンドとアプローチが異なるので、別の系統として用意しています。
SGL（Sales Generated Lead）
主にエンタープライズ企業を狙っていく場合、バイネームが分かっている状態でコールを行うことが多いので、コンタクトは「SGL（＝Sales Generated Lead ）」がスタート地点になります。
SQL（Sales Qualified Lead）
そこでBDRチームがコールしてお話をする中で、先方に自社が解決できる課題があれば、「SQL」に上がります。そしてアポが取れたら、「商談」になるというフローです。
商談後の流れ
商談になったあと、受注できれば「顧客」になります。しかし当然、失注してしまうこともあります。そこで案件が失注した場合は、「失注顧客」というステージを設けており、通常のコンタクトとは別に扱っています。
また顧客のうち、契約終了してしまうケースもあるので、こういった場合は「過去顧客」というステージを設けています。
なお「失注顧客」「過去顧客」については、会社単位で取り扱うので、会社のライフサイクルステージに合わせて、関連付けられたコンタクトのライフサイクルステージが変更されるワークフローを組んでいます。
ライフサイクルステージの設計・運用で大事なこと
ここからは、私がライフサイクルステージの設計・運用をする上で大事だと思っていることを3点紹介します。
ライフサイクルステージは、できるだけ機械的に判定させる
上記のライフサイクルステージを運用に載せる上で大事にしたのは、できるだけ機械的に判定できるようにしたことです。
人間が目視でチェックして更新するような運用にすると、日々大量に増えるコンタクトを捌ききれず、またリアルタイムに状態を把握できなくなります。また人によって判定の基準が変わってしまうと、本来の目的からズレてしまいます。
そこで、ステージごとの定義と判定条件をあらかじめ決めておき、ワークフローを使って自動で処理させることで、オペレーション負荷を最小限にしつつ、実効性を担保できるのです。
新しいプロパティーを作りすぎない
CRMやSFAでありがちですが、運用を改善していくと、新しいプロパティーを作ってしまう傾向があります。もちろんそれ自体は悪いことではないですが、次第に入力工数が増えていき、本来お客様にかけるべき時間が減ってしまうのは本末転倒です。
そこで、まずは普段からオペレーションで使っている項目をうまく活用できないかを考えるべきです。そうすれば、オペレーションの大きな変更なしに、ライフサイクルステージの運用が回るようになるからです。
既存項目を使ってもどうしても実現できない場合に、新規のプロパティーをつくるといった順番で考えることがオススメです。
事前にセールス側ときちんと共有・協議しておく
最後は、きちんとセールス側と話しておくことです。ライフサイクルステージの運用は、マーケだけでなくセールスにも密接に関係します。ステージの定義や運用の流れなどをきちんと説明して、認識をそろえておくことが重要です。
弊社の場合、ライフサイクルステージの運用案について共有する説明会を開催しました。当日は、セールスメンバーが全員参加してくれて、運用上の懸念点などをフィードバックしてもらいました。そして実際に出てきた意見を踏まえて、運用やステージを修正していきました。
このようにセールス側ときちんと協議したことで、ライフサイクルステージを変更した後に、大きな混乱もなく、運用に乗って今に至ります。
おわりに
この記事では、HubSpotのライフサイクルステージと弊社での運用事例について紹介しました。
ライフサイクルステージは非常に奥が深いプロパティーです。事業のフェーズや商材特性でも運用が変わるかと思うので、ぜひ自社にあった運用スタイルを見つけてみてください。この記事がアドミンのみなさまの何かお役に立
てば嬉しいです。
最後までお読みいただき、ありがとうございました！
記事に対するご意見や感想などありましたら、ぜひX（Twitter）でお知らせください。
→https://twitter.com/motoy0shi
また弊社DIGGLEや、私たちマーケチームについてご興味がありましたら、ぜひユートラのカジュアル面談からご応募ください！
この記事が気に入ったらサポートをしてみませんか？