同じ顧客が育成フローへ戻るときは？重複タスクを防ぐ確認表

春野ラボの加藤は資料請求から始まる育成シナリオを社内台帳で設計しています。岡さんは10月1日に資料R64を請求し、佐々木の確認タスクT64が進行中です。10月10日に同じ資料を再請求したため、同じ質問のタスクがもう一件できそうになっています。

請求のたびに最初から開始すると、進行中の担当への確認が重複します。逆に人物ごとに生涯一度だけとすると、前の問い合わせが終わってから別の用途で相談した記録まで止まります。シナリオの目的と一回の範囲を先に決めます。

育成シナリオは開始条件、進行中の再請求、終了条件、再開始できる条件を別に設計します。同じ人物の同じ用件が進行中なら履歴を追加し、営業タスクの重複を避けます。 参照資料「HubSpot: Workflow enrollment settings」で確認した範囲は、参加・再参加・終了・除外を別条件として設計する考え方。 この節の会社・担当・社内基準は架空の教材です。

この章の根拠：出典1

「岡さん・10月1日」の入力は、R64請求、T64進行中です。ここでは担当が条件確認中という状態を基準にします。記録の判断欄には「現在のシナリオを続ける」と残します。

「岡さん・10月10日」の入力は、同じR64を再請求です。ここでは再請求だけでは同じタスクを新規作成しません。記録の判断欄には「T64へ追加履歴を渡す」と残します。

「岡さん・11月の別用途」の入力は、T64完了後に用途変更の相談です。ここでは前回完了と今回の目的の違いを確認します。記録の判断欄には「新しい用件として開始を検討」と残します。

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

加藤は開始を資料請求受付、最初の工程を重複照合、次を営業への条件確認依頼、終了を質問対応と結果受領に定めます。再開始には前回が終了していることと新しい相談の根拠を置きます。人物ID、用件ID、実行回のIDを分けて保存します。

架空の岡さんの請求は2回でも、進行中の用件と営業タスクは各1件です。履歴2件を消して1件にするのではなく、履歴2件が同じ用件へ結び付く形にします。新しい用途が確認されたときは人物は同じでも用件を増やせます。

同じ請求でも実行回を増やすかは、前回の状態と今回の目的で決めます。T64が進行中の10月10日の請求は履歴追加で、11月の別用途は旧用件の完了を確かめてから判断します。

途中で停止の意思や営業の直接対応が確認されたら、育成の候補処理を止め、終了理由を残します。前回の完了が不明なまま再開始条件を満たしたように見える場合は、加藤がT64の担当へ確認し、二重開始を保留します。

製品によって再登録、進行中の再登録、終了や除外の条件は異なります。台帳の設計がそのまま実装できるとは限りません。この記事は架空のシナリオを検証する手順で、配信の実行や効果の保証は含みません。

加藤はT64の担当と完了状態を照合します。前回終了が不明なら再開始を保留し、終了の理由が案内停止だった場合は請求が来たことだけでその状態を解除しません。

加藤は三つの架空入力を使って開始、履歴追加、新しい用件の判定を試します。佐々木はT64へ再請求の情報が届き、新規タスクが増えないことを確認します。実際に採用する機能や自動化は製品別の条件を確認してから決めます。

吉田は台帳で岡さんの履歴が2件、用件が1件、進行中タスクが1件であることを照合します。終了後の別用途テストでは旧用件の終了理由が残り、新しい用件の目的が空欄でないことを完了条件にします。

吉田は開始と履歴追加の試験で同じ人物ID、用件ID、タスクIDを追います。タスクが二重にできたら今回の依頼が同じ質問か確認して訂正し、二回の請求履歴は残します。

開始、進行中、終了、再開始を別に定義します。育成シナリオを一回の用件としてどこまで扱うかを決めます。

請求履歴二件と営業タスク一件は矛盾しません。履歴を削って重複を防ぐのではなく、同じ用件への関係を整理します。

加藤が三つの入力を試し、佐々木がT64を確認します。製品別に実装できた条件だけを試験結果として残し、未確認の自動動作を確定しません。