デリヘルのNG確認フロー｜顧客NG・キャストNGを安全に管理する方法

デリヘルのNG管理は、顧客名の横に「NG」と書くだけでは不十分です。店舗全体で受付しないのか、特定キャストとの組合せだけ避けるのか、確認中なのか、期限があるのかで受付判断が変わります。

自由記述だけに頼ると、検索で見つからない、同姓・同番号を取り違える、詳細理由を不要な人まで読む、解除後も古い表示が残るといった問題が起きます。一方で、理由を細かく構造化しすぎて広く表示すれば、機微な情報の漏えい範囲が広がります。

安全な設計では「受付を続けてよいか」という判定と、「なぜその判定になったか」という詳細を分離します。受付画面や通知には必要最小限の状態を表示し、詳細理由・証拠・履歴は権限のある確認画面だけで扱います。

最低限、適用範囲を次のように区別します。

「顧客NG」という言葉を店舗NGとキャスト別NGの両方に使うと、別キャストなら受付可能な案件まで失注するか、反対に店舗全体で停止すべき受付を通すおそれがあります。種別、対象、店舗、状態をキーとして保持します。

NG確認は、電話番号が一致しただけで確定しません。

1. 着信番号、顧客コード、申告名などから顧客候補を取得する 2. 候補がゼロ・一件・複数かを区別する 3. 本人を確定できない場合は、NG詳細を見せず有人確認へ進む 4. 確定した顧客の店舗NGを確認する 5. 希望キャストがいる場合は、組合せNGを確認する 6. 有効期間、状態、解除・保留を確認する 7. 該当なしなら受付継続、確認中なら引継ぎ、有効NGなら停止する

同じ電話番号に複数顧客が登録されている場合や、別番号・非通知からの着信では、誤った顧客のNGを理由に受付を拒否しないよう本人確認を分けます。同時に、本人未特定を「NGなし」とみなして自動確定もしません。

安全判断に必要な構造と、詳細説明を分離して保持します。

判定に使う項目:

• 店舗
• 対象顧客
• 対象キャスト（店舗NGなら空）
• 種別と適用範囲
• 状態（確認中、有効、解除、期限切れ等）
• 開始日時と終了日時
• 受付時の処理（停止、候補除外、責任者確認）

権限制御する項目:

• 理由カテゴリと詳細
• 情報源と確認状況
• 登録者、確認者、解除者
• 関連する受注・報告・証拠
• 作成、更新、解除の履歴

理由は必要以上に自由記述へ集約せず、受付担当者が見る短い判定と、責任者が見る詳細を別フィールドまたは別権限にします。

NG情報を一度登録したら永久に固定する設計は、古い情報や誤登録を残します。少なくとも状態遷移を定義します。

• 確認中: 情報を受けたが本人、事実、範囲を確認中
• 有効: 承認され、指定範囲へ適用中
• 保留: 追加確認まで責任者判断が必要
• 解除: 理由と承認者を記録して適用終了
• 期限切れ: 終了日時を過ぎ、自動適用しない

有効NGを削除して履歴を消すのではなく、解除状態へ変更し、誰がいつ何を根拠に変更したかを残します。期限切れ後も詳細を無期限保存する必要があるかは、目的・契約・法令・業務上の必要性を確認します。

全スタッフが安全に受付するには判定が必要ですが、全員が詳細理由や証拠を見る必要はありません。

例として分ける閲覧範囲:

• 受付担当: 受付可否、対象組合せ、必要な次の操作
• 管理者: 理由カテゴリ、確認状態、登録・解除履歴
• 限定責任者: 詳細記録、証拠、調査内容
• キャスト: 自分の組合せに必要な業務情報のみ

キャストへ他のキャストのNG状況や顧客の詳細理由を見せず、受付担当へ証拠ファイルを直接渡さない設計にします。検索結果、CSV、通知、メール、ブラウザログ、分析イベントから詳細が漏れないかも確認します。

CTIでは着信番号をきっかけに顧客候補を表示できますが、電話番号そのものを広い通知へ配布しないことが重要です。

• 着信イベントには必要最小限の識別子だけを載せる
• ログイン中スタッフの所属店舗をサーバー側で確認する
• 電話番号と顧客候補は権限確認後にサーバーで照合する
• 別店舗の顧客・NG・メモを返さない
• 候補が複数なら自動的に一人へ決めない
• NG詳細をRealtime payloadやWeb Push本文へ載せない
• 受付継続、候補除外、責任者確認、停止を構造化して返す

画面が「NGあり」と表示するだけでなく、どの組合せへ、どの状態が、どの時点で適用されたかを監査できるようにします。

AI電話受付が顧客候補や希望キャストを取得した場合も、NG判定は業務システムの確定データへ問い合わせます。AIが会話履歴や言葉遣いから独自にNGを推測したり、NG理由を顧客へ説明したりしない境界が必要です。

AIへ返す結果の例:

• 受付継続可能
• この組合せは候補にできない
• 本人確認または責任者確認が必要
• 受付を停止して人へ引き継ぐ

詳細理由、証拠、他のキャスト名、内部メモはAIの発話材料へ渡しません。判定不能、データ取得失敗、店舗不一致、状態競合では「NGなし」に倒さず、安全な有人引継ぎへ進めます。顧客へは内部情報を明かさない定型案内を使います。

NG登録は、受付中の即時安全確保と、後からの事実確認を分けます。

1. 緊急時は受付を止め、確認中として仮登録する 2. 顧客候補、対象店舗、対象キャストを確認する 3. 情報源、理由カテゴリ、関連記録を限定領域へ保存する 4. 権限のある責任者が範囲・状態・期限を承認する 5. 関係する受付導線で判定が反映されるか確認する 6. 変更・解除時は元記録を消さず履歴を追加する 7. 定期的に期限切れ、確認中、長期未確認を見直す

口頭連絡だけ、スタッフ個人のメモだけ、グループチャットだけで完了させず、正式な判定レコードへ反映したことを確認します。

本番前には、単一の登録済み顧客だけでなく次を確認します。

• NGなし、店舗NG、各方向のキャスト別NG、相互NG
• 確認中、保留、有効、解除、期限切れ
• 開始前、終了直前、終了後の時刻境界
• 顧客候補ゼロ、一件、複数、別番号、非通知
• 同じ顧客が複数店舗に存在する場合
• 希望キャストなし、途中変更、2名対応
• 登録直後、解除直後、同時更新
• CTI障害、DB取得失敗、権限不足、店舗不一致
• AIが理由を尋ねられた場合、顧客が人を希望した場合
• 通知、ログ、CSV、分析イベントへの詳細漏えい

negative controlとして、NGのない確定顧客と許可された組合せが通常どおり受付可能であることも確認します。常時停止する検査では安全性を証明できません。

NG件数の多さだけを評価せず、運用品質を分けて見ます。

• 確認中の件数と滞留時間
• 期限切れ前の見直し件数
• 誤った顧客候補を選び直した件数
• 受付後にNG見落としが判明した件数
• NG該当時の有人引継ぎ成功率
• 解除・訂正と、その反映までの時間
• 権限外閲覧や詳細漏えいの検出件数

登録件数を増やすこと自体を目標にせず、未確認情報を放置しない、受付時に正しい範囲へ適用する、不要な人へ詳細を広げないことを評価します。

NG管理の相談で、顧客名、電話番号、キャスト名、具体的な理由を最初から提出する必要はありません。

準備する情報:

• 現在使っているNG種別
• 受付停止、候補除外、責任者確認の条件
• 登録、承認、解除を担当する役割
• 期限や見直しの有無
• 受付時に表示したい最小情報
• 詳細理由を閲覧できる役割

匿名化した例と状態遷移で画面・権限・判定を設計し、安全な取扱経路を確定してから実データへ進みます。