CRM・SFAが定着しない

ライフサイクルステージと取引ステージを混同したまま設計した結果

公開 2026年7月25日

HubSpotで、ライフサイクルステージ（顧客がどの段階にいるか）と取引ステージ（案件がどこまで進んだか）を、同じ「進み具合」として一本の流れで設計しました。

数週間後、レポートの件数が実態と合わなくなり、自動化のメールが失注済みの相手に配信されました。

この2つは似ているだけで、別の指標です。1つにまとめて設計すると、集計と自動化が同時に壊れます。

2つのステージを、同じ「進み具合」として一本化しようとした

情報通信業、従業員数十名規模の会社です。HubSpotを新しく導入し、問い合わせから受注までを1つの画面でたどれるようにしたい、という依頼でした。

担当者の頭の中では「問い合わせ→商談→受注」が一続きで、ライフサイクルステージと取引ステージは、どちらも「どこまで進んだか」を表す同じものに見えていました。

そこで両方を、一本のパイプラインの段階として並べる案が最初に上がりました。

見た目はきれいに一本化されます。問題は、2つが別々の対象に付く指標だという点です。

2つを完全に分けて設計する、と決めました。混ぜない、という判断です。

ライフサイクルステージは、連絡先と会社に付く「状態」です。設計上、基本は前に進むだけで戻りません。

取引ステージは、取引（案件）に付き、パイプラインの中を行き来します。1件の会社が、同時に複数の案件を持つこともあります。

つまり片方は顧客の状態、もう片方は案件の進行で、動く単位も向きも違います。

一本化する案も検討しました。しかしその設計では、案件が失注しても、連絡先のライフサイクルは「顧客」のまま戻りません。

次の集計で母数が汚れます。ライフサイクルを手作業で戻す運用も案に出ましたが、属人化して必ず抜けます。

だから、ライフサイクルは条件で自動更新し、取引ステージは営業が手で動かす、と役割を分けました。入力させる項目は、機械で判定できるものは人に触らせない方針にしました。

分離した後、レポートの件数が実態と一致し、誤配信は止まりました。

HubSpot Japanの調査（2024年、n=1,545、CRMを販売する同社の自社調査）では、79%が「データ活用で何らか困りごとがある」と答え、うち24.4%が「他部署とのデータ連携が進んでいない」を挙げています。

ライフサイクルと取引ステージの混同は、この分断がCRMの内側で起きている状態です。マーケが見る「顧客の状態」と、営業が見る「案件の進行」が同じ列に押し込まれ、どちらの数字も信用できなくなります。

「顧客の状態」と「案件の進行」は、別の軸として設計してください。 1つの流れにまとめると画面は整いますが、片方が戻れない指標であるために、集計の母数がずれ、自動化の条件が誤って発火します。

整った1本より、正しく分かれた2本です。