Feature / Message 15

FW JS 管理側 公開側

通知停止・再開

顧客や案件ごとに、不要な通知を止めたり再開したりできます。

通知停止・再開は、顧客、会員、案件、予約、問い合わせなどの単位で、メールやメッセージ通知を一時的に止めたり、必要になったタイミングで再開したりするための機能です。Roundtableでは「どの通知を止めるか」「誰が変更できるか」「再開条件をどう扱うか」「停止中でも送るべき重要通知をどう分けるか」を先にそろえると、発注者、実装者、AIに指示する人が同じ前提で通知設計を進められます。

顧客詳細で通知種別ごとの停止状態、停止理由、再開予定を確認して通知を再開する業務画面例

この機能でできること

顧客、案件、予約、契約、問い合わせなどのレコードに対して、通知種別ごとに停止中、再開済み、一時停止、重要通知のみ許可といった状態を管理できます。停止理由、停止した担当者、停止日時、再開予定日、再開時の確認メモを残せるため、不要な案内や重複連絡を避けながら、必要な通知だけを運用に残せます。

通知しない判断も、業務状態として管理するための機能です。 配信停止の希望、案件休止、担当者判断、一時的な連絡不要などをデータとして残し、通知処理側で毎回同じ条件を見て除外できる形にします。

よくある利用場面

顧客から案内停止の希望があった メール案内やリマインドを止めつつ、契約や支払いに関わる重要通知だけは送れるようにします。
案件が一時保留になった 案件単位で進捗通知や催促通知を止め、再開予定日になったら担当者が通知再開を確認します。
重複連絡や過剰通知を防ぐ 同じ顧客に複数の案件や予約がある場合、対象ごとに通知可否を分けて誤送信を減らします。

プロンプト例

停止対象、通知種別、停止理由、再開方法、重要通知の扱い、通知ログとの関係をまとめて伝えると、実装範囲を決めやすくなります。

プロンプト 顧客詳細と案件詳細に通知停止・再開機能を追加してください。メール通知、リマインド通知、担当者向け通知を個別に停止できるようにし、停止理由、停止した担当者、停止日時、再開予定日を保存します。停止中でも契約、支払い、セキュリティに関する重要通知は除外しない設定にしてください。通知送信処理では送信前に停止状態を確認し、除外した場合は通知ログに「停止中のため未送信」と残してください。再開時は確認モーダルを出し、現在の停止理由と再開後に送られる通知種別を表示してください。

この機能を使うときのポイント

停止単位を決める顧客全体、案件単位、予約単位、通知種別単位のどこで止めるかを運用に合わせて決めます。
重要通知を分ける支払い、契約、本人確認、セキュリティなど、止めてはいけない通知を通常案内と分離します。
理由と期限を残すなぜ止めたのか、いつ見直すのか、誰が判断したのかを残すと、属人的な判断を減らせます。
送信ログとつなげる停止中で送らなかった通知もログに残すと、問い合わせ時に「送っていない理由」を説明できます。

この機能を実装するときのコツ

通知停止の状態管理、通知種別の定義、送信直前の除外判定、再開操作、通知ログを分けて設計すると安定します。管理側では詳細画面やサイドパネルに停止状態を表示し、変更時は確認モーダルで影響範囲を見せます。公開側で顧客自身が配信停止を選ぶ場合は、本人確認済みの導線に限定し、管理側の担当者判断による停止と区別します。送信処理では画面表示だけに頼らず、メール送信、リマインド、定期実行、一括送信の直前にサーバー側で停止状態を再確認する形にすると、後から通知経路が増えても同じルールを使い回せます。