Hubspotのライフサイクルステージのデータフロー。MAツールでのMQLとSQLの運用。

マーケティングオートメーションツールのHubspot Marketing Hubでは、”ライフサイクルステージ”という既定の項目（プロパティ）があります。このライフサイクルステージは、コンタクト（リード）や企業がマーケティング/セールスファネルのどの段階にいるかを示すための項目です。

MAの真髄は、顧客の意向度を管理し、意向度によって、コンテンツやアプローチ方法を変えて、育成を効率化するというのにあります。そのため、ライフサイクルステージを上手に運用するというのは、Hubspot活用で外すことができない重要な事項です。

今回は、この”ライフサイクルステージ”を、Hubspotでどう運用設計するとうまくまわるか考察してみます。

Hubspotの”ライフサイクルステージ”の定義を確認する

まずは、本家本元の、ライフサイクルステージの定義を確認してみましょう。

下記、公式のドキュメントを要約したものです。

ーーーーーーーーーーーー

ライフサイクルステージには、次の値が含まれています。

サブスクライバー：ブログまたはニュースレターに登録することにより、さらに多くの情報を受け取ることをオプトインしたコンタクト。
リード：ウェブサイト、または何らかの他のやり取りを通じて、サブスクライバー以降の段階へとコンバージョンしたコンタクト。
MQL（マーケティング活動で獲得した見込み客）：マーケティングチームにより営業チームへの引き渡しが可能と判断されたコンタクト。
SQL（営業がフォローすべきと認定された見込み客）：営業チームにより可能性のある見込み客と判断されたコンタクト。
商談：取引に関連付けられているコンタクト（自社との潜在的な取引に関わっているなど）。
顧客：少なくとも1つのクローズ済み取引のあるコンタクト。
エバンジェリスト：自社の支持者となった顧客。
その他：上記のどのステージにも当てはまらないコンタクト。

ーーーーーーーーーーーー

この中で、サブスクライバー・リード・商談・顧客については、自動的にシステム設定がなされるので、どのタイミングで更新するか等、運用ルールはそこまで迷いません。

一方で、MQL・SQL・エバンジェリストは、定義に曖昧さがあり、詳細は運用者に任されているため、運用ルールを独自で決めてあげる必要があります。

特に、MQL・SQLは、マーケからセールスにリードをパスするタイミングとMAの中でも重要なので、運用ルールをしっかり決めて回したいところです。（エバンジェリストは受注した企業の中でもよりロイヤリティの高い企業の管理項目なので最初は特に触らなくてもよいかもです。今回は、スルーします。）

ライフサイクルステージの運用フロー図

定義を踏まえて、ライフサイクルステージのデータ更新フローを図解してみます。

菱形図形がトリガー（発火条件・イベント）を表しています。それぞれのイベントを発火条件にして、ワークフロー機能でライフサイクルステージの値を自動的に更新します。

‍

MQLへの更新条件の検討

MQLはマーケティングチームにより営業チームへの引き渡しが可能と判断されたコンタクト。なので、商談に繋がりやすいホットリードをできるだけ抽出したいところです。考え出すといろんなパターンがありますが。

今回は、トリガーとしては下記2つ。

・”問い合わせ、または資料ダウンロード”のコンバージョンをしたリード。

・スコア60以上。

スコアはHubspotに用意されているスコアリング機能で計算します。過去のフォーム送信数やWEB閲覧履歴などの行動データや役職や企業規模などの属性データで設定します。なお、スコア60でMQLというのは、決め打ち。仮設定です。実際は、インサイドセールスからのフィードバックを受けながらスコアを適正な状況へ調整をかけるのが重要です。

SQLへの更新条件の検討

SQLは、営業チームにより可能性のある見込み客と判断されたコンタクト。

なので、インサイドセールスはじめ、営業がフォローを開始しタイミングで更新することとします。

使うプロパティーは”リード状況（ステータス）”。この値が、Workingになったタイミングでトリガーすることとします。

なお、筆者の環境では、SFAにSalesforce Cloudを採用し、Hubspotと連携しているため、ここでいう”リード状況”という項目は、Salesforceリードオブジェクトの項目です。

新規リードが発生したら、インサイドセールスがSalesforce Cloudで”リード状況”を更新するというオペレーションフローを組むことで、ライフサイクルステージを回すと想定しています。

SFAもHubspotで回す場合は、Hubspotの既定プロパティに”リードステータス”があるので、例えば、値が"In Progress（進行中）"に変更になったらSQLに変更するなどの運用をすると良いと思います。

リードへの繰戻し/Dead Leadの更新条件の検討

MQLやSQLに昇格したコンタクトでも一度アプローチした結果、時期が会わずに再度ナーチャリングが必要と判断される場合や、そもそもまったく見込みがなく後追いが不要なコンタクト（Dead Lead）も発生します。これらが、MQLやSQLに滞留し続けるのは好ましくないので、適切に、再度ライフサイクルステージを更新してあげるような条件をいれてあげると良いです。

今回の想定では、再ナーチャリングが必要なものは、”リード”に。見込みなしのDead Leadは”その他”というライフサイクルステージの値に再振り分けするようにします。

発火条件は、

・リードへの繰戻し＝リード状況が”Nurturing”に変更

・その他への変更＝リード状況が”Unqualified”に変更。または、メルマガ解除された。

とすることとします。