育成中に対象条件が変わったら？継続と終了を決める判定表

春野ラボの加藤は設備更新を検討する人向けの案内候補をCRMの条件で作っています。岡さんは資料請求時には未導入でしたが、10月8日に導入済みと佐々木が確認しました。10月10日の案内候補には、作成時点の未導入という状態が残っています。

最初に対象へ入った事実を固定すると、導入済みの相手へ未導入の説明を続ける候補が残ります。最新状態だけを上書きして変更履歴を消すと、過去の案内がどの条件で選ばれたか説明できなくなります。開始と継続の条件を分ける必要があります。

CRMのセグメント配信では対象条件と案内目的を対応させ、候補確定時に継続条件を再確認します。条件が変わった人は変更理由と時刻を残し、古い区分から外します。 参照資料「HubSpot: Workflow enrollment settings」で確認した範囲は、参加・再参加・終了・除外を別条件として設計する考え方。 この節の会社・担当・社内基準は架空の教材です。

この章の根拠：出典1

「岡さん・未導入候補」の入力は、10月1日に未導入として登録です。ここでは導入済みという確認記録を終了理由にします。記録の判断欄には「10月8日で候補を終了」と残します。

「岡さん・導入後支援」の入力は、初回利用の状況は未確認です。ここでは導入しただけで支援案内の条件がそろったとは判断しません。記録の判断欄には「支援候補の条件確認へ」と残します。

「北工場・状態不明」の入力は、申告が古く更新記録なしです。ここでは未導入として自動的に残さず確認日を調べます。記録の判断欄には「案内候補の確定を保留」と残します。

比較表は横に動かして全ての列を確認できます。

加藤は対象条件を未導入、案内の目的を導入前の要件整理と書きます。入口条件に加え、候補作成時点で未導入が確認できることを継続条件に置きます。導入確認、案内停止、対象範囲外への変更を終了理由として別々に記録します。

架空の候補12人のうち導入済み2人を外せば未導入候補は10人です。ただし10人のうち状態不明1人を保留するので、条件確認済みは9人です。12から2を引いた10を、そのまま確定対象人数として説明しないことがポイントです。

候補12人は同じ時点の抽出集合です。その中で終了2人、保留1人、確認済み9人へ区分すると元の数へ戻ります。確認待ちの人を新しい案内区分へ確定移行する操作とは分けます。

条件の更新が営業と案内台帳で食い違う場合は、岡さんの変更記録を根拠に照合します。新しい区分へ移る条件がそろっていなければ、古い区分を残すのではなく確認待ちにします。状態不明の人へ導入済みと推定入力することもしません。

人数は教材の例であり、実際の顧客構成や反応を示しません。CRMで対象へ該当することは案内可能な状態と同義ではありません。利用する配信管理の状態と会社の運用条件は、別の工程で照合してください。

加藤は岡さんの導入確認日と台帳の更新日を照合します。確認日が新しくても対象設備が違うなら同じ導入として扱わず、今回の候補に関わる設備の状態を佐々木へ確認します。

加藤は10月10日の候補を作り直し、佐々木が岡さんの導入確認日を照合します。吉田は未導入候補の終了と、導入後支援の確認待ちが別行で見えることを確認します。案内種類の状態はセグメント条件と別に確認します。

確認済み9人、保留1人、終了2人の合計が元の12人に戻ることを確認します。岡さんの古い区分が終了した日付と根拠が残り、導入後支援へ勝手に確定登録されていないことを、別担当が追えるなら設計の検証は完了です。

吉田は変更前の候補と変更後の三分類を再現します。導入後支援を自動で確定していた場合は開始条件を再確認し、未確認へ訂正して担当を置きます。

セグメントの目的と入口、継続、終了の条件を対応させます。入口の区分を現在の状態として固定しない設計にします。

候補数は条件が変わるたびに更新します。終了理由と変更時刻を残せば、過去の候補の根拠も追えます。

加藤は再抽出を、佐々木は導入確認を点検します。案内種類の状態を別に確認したうえで、対象条件の整理を完了にします。