ライフサイクルステージが前のステージに戻るときの原因の切り分け方

HubSpotでライフサイクルステージが前のステージに戻っているように見えるとき、原因を推測で判断すると対応が長引きがちです。この記事では、対象レコードのプロパティ変更履歴を起点に、手動変更・ワークフロー・インポート・外部連携のどれが関係しているかを切り分ける手順と、意図的に戻したい場合の正しいやり方を整理します。

ライフサイクルステージは、営業・マーケティングの進捗管理やレポートに関わる項目です。意図しない変更は、案件管理・商談化率・顧客化率などの数値にも影響します。だからこそ、設定画面やワークフロー一覧を先に眺めるのではなく、実際に値を変えた処理を履歴で特定するところから始めます。

HubSpotの仕様：自動更新では直接戻せないい

ライフサイクルステージには、先に理解しておきたい仕様があります。

ワークフロー、インポート、会社とコンタクトの自動同期、取引との連動といった自動更新では、既定のライフサイクルステージを前のステージへ直接戻すことはできません。 たとえば、すでに「顧客」になっているコンタクトを、ワークフローの通常の値設定だけで「商談」に戻すことはできません。これらの自動更新は、基本的に後続のステージへ進めるための仕組みとして扱われます。

ただし例外と、見落としやすい挙動があります。

• 手動操作は例外
  ユーザーがレコードを直接開いてステージを選び直した場合は、前のステージへ戻せます。
• クリア経由は後退して見える
  いったんライフサイクルステージの値をクリアし、その後に別のステージを設定する処理が組まれている場合、結果として前のステージに戻ったように見えます。値が空の状態を経由することで、前進制限を回避できるためです。

この仕様を踏まえると、ステージが戻っている場合に考えられる主な原因は次の3つです。

• ユーザーが手動でステージを変更した
• ワークフローやインポートなどで、一度ステージがクリアされ、その後に別のステージが設定された
• Salesforceなどの外部連携によって値が更新された

「勝手に戻った」ように見える場合でも、HubSpot上では何らかの処理によって値が変更されています。その手がかりは、プロパティ変更履歴に残ります。

確認する場所：コンタクトのプロパティ変更履歴

ステージが戻っているコンタクトを1件開き、ライフサイクルステージのプロパティ変更履歴を確認します。

ここでは、変更日時・変更前後の値・変更元を確認できます。変更元には、手動操作・インポート・ワークフロー・連携など、更新のきっかけが表示されます。表示の細かさは更新元によって異なるので、履歴で大まかな原因を特定したうえで、該当するワークフロー・インポート履歴・連携設定を個別に見ていく流れになります。

確認の手順はシンプルです。ステージが戻った時刻を履歴から特定し、その前後にどんな処理が走っていたかを見ます。

• 同じ時刻にインポートが実行されていれば、そのインポートが原因の候補
• 変更元にユーザー名が出ていれば、手動変更の可能性が高いので本人に確認
• 一度ステージが空になり、その後に別のステージが設定されていれば、前述の「クリア経由」の処理が関係している可能性

原因ごとの確認ポイント

変更履歴でおおよその原因を確認したら、発生源を具体的に見ていきます。

手動変更だった場合

変更元にユーザー名が表示されている場合は、操作した本人に変更理由を確認します。営業担当者が取引状況に合わせてステージを手動で下げている、というケースがよくあります。

これはHubSpotの設定不備というより、運用ルールの問題であることが多いです。誰が・どの条件でステージを手動変更してよいのかを決め直します。特にBtoBではライフサイクルステージが営業管理やマーケティング評価に使われるため、個別判断での変更はレポートの整合性を崩します。手動変更を許可する場合も、対象者と変更条件を決めておくと運用が安定します。

ワークフローにクリア操作が入っていた場合

該当しそうなワークフローを開き、アクションに「プロパティー値をクリア」が含まれていないかを確認します。前述のとおり、値をクリアし目的のステージを再設定の2段階の処理をすると、結果としてステージが後退したように見えます。
意図した処理であれば問題ありませんが、対象条件が広すぎると、本来戻すべきでないコンタクトまで巻き込まれます。 ワークフローはアクションだけでなく登録条件も確認してください。どのコンタクトが対象になるか、再登録が有効になっていないか、想定外のレコードが入る条件になっていないかを見ます。

インポートで書き換わった場合

ステージが戻った時刻の前後に実行されたインポートを開き、アップロードしたCSVにライフサイクルステージ列が含まれていないかを確認します。
特に注意したいのは、過去にエクスポートした古いデータを再インポートするケースです。CSV内に古いステージ値が残っていると、すでに進んでいたステージが古い値で上書きされることがあります。インポート時にステージを更新しないなら、CSVから該当列を外しておくほうが安全です。

外部連携で更新された場合

SalesforceなどとリアルタイムにつないでいるとSalesforce側の情報をもとにHubSpotのステージが更新されることがあります。ただし連携による既定ステージの更新も、原則は前進制限の対象です。後退して見える場合は、連携による値のクリア・連携先データによる上書き・別のワークフロー処理が組み合わさっていないかを確認します。
変更履歴に連携関連の情報が出ている場合は、HubSpot単体ではなく、連携先の設定や同期ルールもあわせて確認してください。

意図的に前のステージへ戻したい場合

ここまでは意図しない後退の話ですが、運用上ステージを戻したい場面もあります。

1件だけ戻す場合は、対象レコードを開き、ライフサイクルステージを手動で変更します。

複数件をまとめて戻したい場合や、ワークフローで戻したい場合は、直接前のステージを設定せず、①値をクリア → ②目的のステージを設定の2段階で処理します。空の状態を経由することで前進制限を回避できます。

ただし、この操作には注意点があります。ライフサイクルステージには、各ステージへの移行日や滞在期間に関するプロパティがあります。ステージを戻す方法によって、これらの値の扱いが変わる場合があります。特に、従来の「Became a [ステージ] date」系のプロパティと、後から追加された計算プロパティでは挙動が異なります。

ファネル分析・商談化率・顧客化率・ステージ滞在期間などをレポートで見ている場合は、どのプロパティを使っているかを事前に確認してください。戻す操作が過去の集計や期間分析に影響することがあります。

まとめ

ライフサイクルステージが戻る問題は、設定が難しいというより、どこを見れば原因が分かるかが整理されていないために長引きます。まず対象レコードのプロパティ変更履歴で変更日時・前後の値・変更元を確認し、手動変更・ワークフロー・インポート・外部連携のどれが関係しているかを切り分けることが基本です。
自動更新では前のステージへ直接戻せず、意図的に戻すなら手動変更か値をクリアし再設定を行います。いずれもレポートやステージ滞在期間に影響しうるため、実行前に使っているプロパティと影響範囲を確認しておくと安心です。
自社のHubSpotで、どの処理がライフサイクルステージを更新しているのかを一度棚卸ししておくと、同じ問題が起きたときの対応がぐっと楽になります。棚卸しや原因の切り分けからご相談が必要な場合は、現状診断としてお声がけください。