複数の案内条件に入る顧客は？案内停止と配信候補の優先表

春野ラボは案内の候補をCRMで整理し、別の配信管理台帳へ写しています。加藤は岡さんが10月10日9時に製品案内の停止を選んだ記録を見つけました。CRMは停止ですが、前日に作った説明会候補一覧L63にはまだ岡さんが残っています。

候補一覧に載っていることを優先すると、最新の停止意思が古い抽出結果に負けます。一方、製品案内の停止を理由に依頼済みの仕様回答まで同じ欄で消すと、何が停止されたか追えません。内容の種類と状態の確認が必要です。

CRMの配信停止を同期するときは人物、案内種類、状態、変更時刻、反映先を対応させます。古い候補より新しい停止を優先し、未反映は候補から除外して確認します。 参照資料「HubSpot: Set up email subscription types」で確認した範囲は、案内種類別の状態があり、Subscribed、Unsubscribed、Not specified を区別することと、対応するプロパティの確認方法。 この節の会社・担当・社内基準は架空の教材です。

この章の根拠：出典1

「岡さん・製品案内」の入力は、9時に停止、CRM反映済みです。ここでは古い一覧の作成時刻より新しい停止記録を優先します。記録の判断欄には「L63の候補から除外」と残します。

「岡さん・仕様回答」の入力は、本人の質問F62が未回答です。ここでは製品案内の候補へ戻す理由にはしません。記録の判断欄には「依頼対応として別管理」と残します。

「橋工場・説明会案内」の入力は、状態未指定、連携未確認です。ここでは空欄を許可に変えず、原記録と運用条件を確認します。記録の判断欄には「候補確定を保留」と残します。

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

加藤は案内種類の対応表を作り、CRMの製品案内と反映先のどの区分が同じかを確定します。同期票には人物ID、変更前後の状態、受け付けた時刻、同期した時刻、照合した担当を記します。営業用の興味分野は配信可否の代わりに使いません。

L63は前日18時の抽出、岡さんの停止は翌日9時です。一覧の対象条件が正しくても、状態の新しさは保証されません。架空の候補10件に岡さん一人が含まれていた場合、停止反映後の候補は9件ですが、その9件が全員確定済みかは個別の状態で確かめます。

停止の同期は人物だけでなく案内種類まで一致させます。岡さんの製品案内が停止でも、仕様回答の依頼が消えるわけではありません。ただし依頼を理由に製品案内の停止を解除しません。

CRMと反映先の状態が食い違う場合は、加藤が該当人物と案内種類の行を保留します。連携を再実行できても停止を解除する操作は原因確認の代わりにしません。人物の重複が原因なら、統合先の確認と停止履歴の照合を先に行います。

案内種類、同意や停止の扱いには利用製品と会社の運用条件が関わります。この例は法的な送信可否の判断を説明しません。未指定をどう扱えるかを一般化せず、記録を保留して責任者が確認する工程までを示しています。

加藤はCRMと反映先で人物ID、案内種類、変更時刻を並べます。不一致の原因が重複人物なら、統合前後で停止履歴を保持できるか確認し、最新の意思が古い候補へ上書きされない形にします。

加藤はL63を再照合し、吉田が岡さんの製品案内行が除外されたことを確認します。佐々木には停止された案内種類と、F62への回答は別の依頼であることを引き継ぎます。実際の送信可否は会社の運用責任者が確認します。

完了条件は同期処理の成功表示だけでなく、岡さんの人物IDと案内種類でCRM、反映先、候補一覧の状態が一致することです。加藤は停止時刻9時が古い抽出で上書きされていないか、再抽出した候補でも確かめます。

吉田は再抽出したL63に岡さんが入らないことを確認します。同期完了表示があっても一覧へ残るなら完了にせず、加藤が反映先の状態と候補条件を確認します。

案内種類の対応表と状態の同期票を作ります。古い候補より最新の停止を優先する確認条件を定義します。

停止済み一人を除いた9人は残り候補で、状態確認済みの人数とは限りません。未指定も別の確認待ちとして記録します。

加藤は三つの台帳を照合し、吉田は再抽出を確認します。法律上の送信可否をこの判定表で代行せず、社内の確認工程へ渡します。