ライフサイクルステージはHubSpotを運用する上でとても重要な位置づけにあるのでオフィシャルに限らず多くのサイトで説明がされているのですが、多くの場合は1から設計する内容が多いように思います。
しかし既にHubSpotの利用を行っているがライフサイクルステージを使いこなせていない場合や、別のソリューションから置換をされるというお客様も多いのではないかと思います。そこでこの記事では既存のビジネスをどうライフサイクルステージに落とし込んでいくかという観点で記載してみようと思います。
ライフサイクルステージはコンタクト/会社が今どのフェーズにいるのかを表す標準プロパティです。昔はカスタマイズが出来ない仕様でしたが現在はカスタマイズも可能になっています。各コンタクトや会社の値はマニュアルで変更する事は勿論可能ですが、基本的には自動化の機能を用いて値を更新していくものです。
HubSpotのデフォルト設定ではコンタクトが作成されるとリード、紐づく取引が作成されると商談、紐づく取引が1つでも成約になると顧客に変わるようになっています。勿論下記の画面でカスタマイズも可能です。
上記に加えフォームの設定や、ワークフローでステージ変更を行う事も出来るようになっています。ライフサイクルステージの説明を始めると長くなってしまいそうなので、これより詳細についてはまた今度別の記事で紹介できたらと思います。
ライフサイクルステージを始める際、最低限抑えておいて欲しい事を記載
真面目なユーザさんほど、「MQLとSQLの違いは何か？」「こんな場合はMQLとSQLどちらになるのか？」と質問を頂く事が多い気がします。しかし。。私個人的な意見ですが、世の中の言葉定義は割とどっちでも良いです。実際にHubSpotを使いこなしているお客様を見ても、各社ごとにMQLやSQL辺りの定義は異なります。
例えば下記の様なポイントはオペレーションを決める上で重要になってきます。
ライフサイクルステージは所詮ツールに過ぎません。ライフサイクルステージを活用し、顧客のステージが見える化されたら、どんなオペレーションを実現したいのか？という点から考えていきましょう。
下記は私の昔の会社のオペレーションをライフサイクルステージに合わせてかいてみたサンプルです。緑がライフサイクルステージ、下の灰色がお客様のアクション、青が担当部署を表しています。
資料ダウンロードは一番温度感が低く、ウェビナー参加、お問い合わせとなると案件化する確率が上がっていくイメージです。インサイドセールスは他業務との兼務1名のみだったので、全件フォローは間に合わなかった為、SQLのみフォローをしていましたが、獲得SQLが少ない時はMQLのうちスコアの高いリードから順にフォローするというフローでした。
上記のように、こんな条件を満たした人はSQL、SQLはインサイドセールスが責任を持つ、という約束事が決まるとライフサイクルステージは機能していきます。
設計を始めるとつい細かく分けすぎてしまう傾向があります。ライフサイクルステージは抽象化するプロパティなので、特に最初は細かくわけすぎないことを心がけ、細かな状況を表したい時はスコアリングやリスト&プロパティを用いたセグメント化などもライフサイクルステージと併用しましょう。
今回はシンプルなライフサイクルステージ設定の流れを紹介しましたが、複数事業がある場合など、お悩みポイントは多いと思います。そのような内容も別記事でまとめていきます。