架電停止リストを漏れなく管理する方法

架電停止リストは、AIテレアポ専用の除外ファイルではなく、営業活動全体が発信前に参照する正本として管理します。停止希望を受けた経路が違っても、同じ電話番号と停止範囲へ集約してください。

停止登録の完了は、リストへ一行追加した時点ではありません。次の発信候補から除外され、すでに作成した架電要求も止まった状態を確認します。フォーム送信直後の即架電も同じ対象です。連携が遅れたり取消しに失敗したりしても、停止希望を発信可へ戻さない設計が必要です。

停止対象と停止範囲を分ける

最初に、何を止める希望なのかを記録します。特定の商品だけを案内しないのか、同じ電話番号への営業電話をすべて止めるのかで対象が変わります。会社の代表番号では、発言した人と停止対象の部署が一致するかも確認してください。

停止理由は、本人の希望と対象外に分けます。対象外には番号違いや退職、閉業や重複登録があります。理由によって再登録の扱いが変わるためです。ただし、理由を集めるために相手へ説明を求め続けないようにします。

消費者向けの電話勧誘販売について、消費者庁の特定商取引法ガイドは契約しない意思を示した相手への勧誘継続と再勧誘を禁止すると説明しています。一方、営業のため、または営業として締結する取引などには適用除外があります。AI電話か人の電話かだけで判断せず、対象者や商材、申込みまでの流れを法務担当者へ示して適用関係を確認します。

運用では「電話しないでください」だけでなく「今後は不要です」も停止候補として扱います。「今は忙しい」のように次回連絡の希望が分からない返答を、自動で再架電予約へ変えないでください。必要な確認ができなければ自動発信を保留し、人が記録を確認します。拒否の理由を聞き続ける必要はありません。

登録経路を一つの正本へ集める

停止希望はAIとの通話だけで届くとは限りません。営業担当者への連絡や問い合わせフォーム、苦情窓口からも受け付けます。各経路の担当者が同じ停止記録へ登録できるようにしてください。

正本をCRMに置く場合は、AI電話サービスへ反映する処理を決めます。AI電話サービスを正本にすると、別のCTIや手動架電が停止情報を参照できないことがあります。営業活動全体が参照できる場所を優先します。

登録時には受付時刻と経路を残します。対象となる電話番号と停止範囲も必要です。受付者または自動処理の識別子を記録し、後から反映経路を追えるようにします。

電話番号を同じ形式へそろえる

停止照合では、見た目が違う同じ電話番号を一件として扱います。ハイフンや空白の有無だけでなく、国番号を付けた形式もそろえます。元の入力値は確認用に残し、照合には正規化した値を使ってください。

TwilioのE.164に関する資料は、国番号を含む国際的な電話番号の形式を説明しています。利用する回線や対象国に合う形式を確認し、CRMと架電ツールで同じ変換を行います。形式が合っていることと、実際に有効な番号であることは別です。入力値が曖昧なら推測で補完せず、照合対象を保留します。

番号の再利用や入力誤りもあるため、電話番号だけで会社全体の停止を推測しません。顧客IDや会社IDがある場合は、電話番号と組み合わせます。番号が変わったときに停止範囲を新しい番号へ引き継ぐ条件も決めてください。

架電候補を作るたびに照合する

停止リストは、CSVを取り込む前だけでなく、架電候補を作るたびに照合します。古い営業リストを再利用すると、停止登録より前の状態が戻ることがあります。元データへ停止情報を書き戻すだけでは十分ではありません。

架電要求を作る直前にも正本を参照します。停止情報を取得できない場合は、発信可能として進めず保留します。復旧後にもう一度照合し、停止中でないことを確認してから要求を作ります。

すでに待機中の要求がある場合は、停止登録と同時に検索して取り消します。再試行待ちも対象です。停止後にCSVを再投入しても要求が作られないことまで確認してください。

即架電の停止と取消しを別々に追う

停止の登録と電話会社側の取消しは、一つの操作で同時に終わるとは限りません。次の表は、フォームから発信要求が作られた直後に停止希望が届いた架空の処理例です。時刻は設計を説明するためのもので、製品の応答時間を表しません。

取消結果が不明な間は、対象を自社の発信待ち処理から隔離します。ただし、すでに提供元へ渡した要求まで自社のフラグだけで止まるとは限りません。提供元の要求IDで状態を照会し、取消し可能な段階を確認してください。すでに発信が始まっていたなら、未発信だったことにせず事実を残し、担当者が対応します。

発信直前の照合を追加しても、その直後に停止が届く競合は残ります。同じ対象の状態変更と発信処理を順序立てて扱い、送信後に届いた停止は取消し経路で処理する必要があります。提供元側で止められない時間帯があるなら、その限界を含めて試験します。

イベント通知も到着順だけで処理しません。StripeのWebhook資料では重複配信と順序が保証されないことが説明されています。これはStripeの仕様であり、すべての電話サービスの仕様ではありません。利用基盤の再送条件を確かめた上で、通知IDの重複処理と現在の停止状態の照合を分けます。古いフォーム通知が遅れて届いても、停止を自動解除しない設計にします。

この例で管理するのは「停止受付済み」と「残存要求の取消確認済み」の二つです。前者が10件、後者が8件なら残る2件は未解決です。登録率100%だけを見て完了とせず、要求IDと担当者を付けて追ってください。

再登録と解除を承認制にする

停止中の相手が新しい営業リストへ入った場合は、自動で有効に戻しません。新しい資料請求や問い合わせがあっても、どの連絡が許されるかを分けて判断します。停止記録を上書きせず、新しい受付との関係を残してください。

解除できる担当者を限定します。営業担当者が架電件数を増やすために解除できる状態では、停止リストが形だけになります。解除理由と承認者、変更時刻を記録します。

削除請求への対応と、営業電話を防ぐための停止記録は同じ処理とは限りません。識別に必要な情報だけを残せるか、法務担当者へ確認します。不要な通話履歴や理由まで無期限に保存しないよう、停止記録の内容と保存方針を分けます。

六つの経路で反映時間を試す

本番と同じCRMや架電ツールを使い、次の六つを試します。

1. AIとの通話中に停止希望を受ける
2. 営業担当者がCRMから停止を登録する
3. 問い合わせフォームから停止を受ける
4. 別表記の同じ電話番号をCSVへ再登録する
5. 待機中と再試行待ちの架電がある状態で停止する
6. 承認を得て停止範囲の一部だけを変更する

各試験では、正本への登録時刻と各ツールの反映時刻を記録します。停止情報が届くまでの間に新しい架電要求が作られていないことも確認してください。連携が遅れる場合は、完了まで発信候補を保留します。

即架電ではさらに、フォームより先に停止が届く順序と、要求作成後に停止が届く順序を入れ替えて試します。同じ停止通知の二重配信、取消結果不明、停止台帳を読めない障害も対象です。失敗した試験で停止が解除されていないことを確認してから復旧します。

最初の作業は、停止希望を受ける経路をすべて書き出すことです。正本へ登録されるまでの担当者と時間を付けます。どの経路からでも次の架電候補へ入らないことを確かめてから、営業リストの追加へ進んでください。