通知機能を設計する方法｜メール・アプリ・Slack通知の使い分けと設計ポイント

業務システムを作るとき、

「申請されたら担当者へメールを送ろう」

「期限が近づいたら通知したい」

「Slackにも通知できるようにしたい」

「システム内にもお知らせを表示したい」

といった通知機能が必要になることがあります。

通知機能は、一見すると、

条件を満たしたらメッセージを送る

だけの単純な機能に見えます。

しかし実際に設計すると、

誰に通知するのか
いつ通知するのか
何を通知するのか
メール・アプリ内・Slackのどれを使うのか
同じ通知を何度送るのか
既読にならなかったら再通知するのか
ユーザーが通知を停止できるのか
大量通知が発生したらどうするのか

など、決めることが多くあります。

特に業務システムでは、

通知を増やせば業務が改善するとは限りません。

通知が多すぎると、

「また通知が来た」

と読まれなくなり、本当に重要な通知まで埋もれてしまいます。

そのため通知機能を設計するときは、

何を通知するかではなく、通知を受けた人に何をしてほしいのか

から考えることが重要です。

この記事では、業務システムに通知機能を実装する際の考え方から、メール・アプリ内・Slack通知の使い分け、通知タイミング、再通知、既読管理、通知設定まで具体的に解説します。

通知機能とは

通知機能とは、システム上で特定のイベントや条件が発生したときに、利用者へ情報を知らせる仕組みです。

例えば、

申請登録
↓
承認者へ通知

問い合わせ受付
↓
担当者へ通知

契約期限30日前
↓
営業担当者へ通知

在庫数が基準以下
↓
在庫管理担当者へ通知

といった処理です。

通知手段には、

メール
アプリ内通知
Slack
Microsoft Teams
プッシュ通知
SMS

などがあります。

重要なのは、すべてを同じ通知方法にするのではなく、情報の重要度やユーザーの利用環境に応じて使い分けることです。

通知機能設計の基本は「誰に・いつ・何を・なぜ」

通知機能を設計するときは、次の4点を整理すると考えやすくなります。

誰に

例えば、

担当者
承認者
管理者
申請者
顧客
特定部署

などです。

いつ

例えば、

データ登録時
ステータス変更時
期限3日前
期限当日
期限超過時

などです。

何を

例えば、

新しい申請があります
契約期限が近づいています
問い合わせが登録されました
決済に失敗しました

などです。

なぜ

最も重要な部分です。

例えば、

承認してほしい

期限までに対応してほしい

内容を確認してほしい

という通知後のアクションです。

通知を受け取っても何もする必要がないのであれば、本当にリアルタイム通知が必要なのか検討します。

通知機能で最初に決めるべきこと

通知機能を作る場合、いきなり、

「メールを送るAPIを実装する」

ところから始めない方がよいでしょう。

まず、業務イベントを整理します。

例えば問い合わせ管理システムなら、

問い合わせ受付
↓
担当者設定
↓
対応中
↓
顧客回答待ち
↓
完了

という業務フローがあります。

ここで、

問い合わせ受付

担当部署へ通知。

担当者設定

担当者本人へ通知。

対応期限前

担当者へリマインド。

期限超過

担当者・管理者へ通知。

というように設計します。

つまり通知機能は、業務フローから導き出すことが重要です。

通知手段にはどんな種類がある？

Web業務システムで利用される主な通知方法を整理します。

1．メール通知

最も一般的な通知方法の一つです。

例えば、

件名：
【承認依頼】経費申請が届いています

本文：
田中さんから経費申請が届いています。

申請番号：APP-000125
金額：50,000円
申請日：7月30日

確認する：
システムURL

という通知です。

メール通知が向いているケース

システムへ常時ログインしていない
社外からでも確認したい
後から検索したい
顧客など外部ユーザーにも送りたい

場合です。

メール通知の注意点

メール通知を増やしすぎると、受信トレイが通知だらけになります。

例えば、

申請登録
申請受付
承認待ち
承認
完了

のすべてでメールすると、利用者にとって負担になる可能性があります。

そのため、

メールを送るべき重要なイベントだけ選ぶこと

が重要です。

2．アプリ内通知

システムへログインした際に表示する通知です。

例えばヘッダーに、

ベルアイコン
通知 3件

と表示します。

クリックすると、

新しい申請があります
コメントが追加されました
契約期限が近づいています

などを確認できます。

アプリ内通知が向いているケース

毎日利用する業務システム
通知履歴を残したい
既読・未読を管理したい
メールを増やしたくない

場合です。

アプリ内通知の弱点

ユーザーがシステムを開かなければ通知に気づきません。

そのため重要な通知は、

アプリ内通知
＋
メール

のように組み合わせる場合があります。

3．Slack通知

社内業務でSlackを利用している場合、Slackへ通知する方法があります。

例えば、

#sales-notification

へ、

新しい問い合わせが登録されました
顧客：株式会社ABC
担当：未設定
確認する：URL

と通知します。

Slack通知が向いているケース

社内でSlackを常時利用している
チーム単位で共有したい
即時性が必要
業務システムを頻繁に開かない

場合です。

Slack通知の注意点

通知が多すぎるとチャンネルが埋もれます。

例えば、

すべてのデータ登録

を通知するのではなく、

重要な問い合わせ
期限超過
システム異常

など、対象を絞ります。

4．Teams通知

Microsoft Teamsを社内コミュニケーションに利用している場合は、Teamsへ通知する方法もあります。

考え方はSlack通知と同じで、

社員が日常的に利用している場所へ通知を届ける

ことがポイントです。

5．プッシュ通知

スマートフォンやブラウザへ通知を表示する方法です。

例えば、

「新しい予約が入りました」

とスマートフォンへ通知します。

現場担当者や外出が多いスタッフ向けのシステムで検討されます。

ただしプッシュ通知は強く注意を引くため、頻度を慎重に設計する必要があります。

6．SMS通知

SMSでメッセージを送る方法です。

例えば、

予約前日のリマインド
緊急連絡
認証コード

などです。

即時性がありますが、一般的には送信コストが発生します。

通常の社内通知をすべてSMSにするケースは多くありません。

メール・アプリ・Slack通知の使い分け

通知方法を決めるときは、次のように考えると整理しやすくなります。

通知方法	即時性	システム外で確認	履歴管理	向いている用途
メール	高い	○	○	承認依頼・外部通知
アプリ内	中程度	×	◎	日常業務・履歴
Slack	高い	○	○	社内チーム通知
プッシュ	高い	○	△	現場・モバイル
SMS	高い	○	△	緊急・重要通知

例えば、

重要な承認依頼

メール
＋
アプリ内

チーム全体への新規問い合わせ通知

Slack

普段のコメント追加

アプリ内

緊急障害

Slack
＋
メール

という使い分けが考えられます。

通知機能では「重要度」を設計する

通知をすべて同じ扱いにすると、重要な通知が埋もれます。

例えば通知へ、

INFO
WARNING
IMPORTANT

などの重要度を持たせる方法があります。

あるいは、

通常

コメント追加。

重要

承認依頼。

緊急

期限超過・システム障害。

などに分けます。

重要度によって、

アプリ内だけ

なのか、

メールも送る

のか、

Slackまで通知する

のかを変えることができます。

通知機能の具体例｜承認システム

例えば経費申請の承認フローなら、

申請
↓
課長承認
↓
部長承認
↓
完了

となります。

通知を設計すると、

申請時

課長へ：

「新しい承認依頼があります」

課長承認時

部長へ：

「承認待ちの申請があります」

差し戻し時

申請者へ：

「申請が差し戻されました」

最終承認時

申請者へ：

「申請が承認されました」

という構成です。

ここで、

課長が承認した瞬間に申請者へ

「課長が承認しました」

という通知まで必要かは検討します。

最終結果だけ通知すれば十分な業務もあります。

通知機能の具体例｜問い合わせ管理

例えば問い合わせ管理システムなら、

問い合わせ受付
↓
担当者設定
↓
対応
↓
完了

となります。

通知例は次の通りです。

問い合わせ受付

担当部署へSlack通知。

担当者設定

担当者へアプリ内通知。

対応期限前

担当者へメール。

期限超過

担当者・管理者へメール。

完了

必要に応じて管理者へ通知。

重要なのは、

問い合わせが発生した事実だけではなく、対応が必要なタイミングを通知すること

です。

通知機能の具体例｜契約管理

契約管理では期限通知が重要です。

例えば、

契約終了日：12月31日
解約通知期限：11月30日

という契約があるとします。

この場合、

60日前

担当者へアプリ内通知。

30日前

担当者へメール。

14日前

担当者へ再通知。

期限超過

担当者＋管理者へ通知。

という設計が考えられます。

ただし通知回数を増やしすぎると無視されるため、業務上必要なタイミングに絞ります。

通知機能の具体例｜在庫管理

在庫管理では、

在庫数が発注点を下回った

ときに通知することがあります。

例えば、

在庫数10個
↓
発注点5個
↓
在庫数4個
↓
担当者へ通知

です。

ここで注意したいのが、

在庫4個
↓
通知
↓
在庫3個
↓
また通知
↓
在庫2個
↓
また通知

となることです。

これでは大量通知になります。

そのため、

発注点を初めて下回ったときだけ通知

など、重複通知を防ぐ設計が必要です。

通知機能の具体例｜予約管理

予約管理では、

予約完了
変更
キャンセル
前日リマインド

などがあります。

例えば顧客向けには、

予約完了
→ メール

予約前日
→ メール

キャンセル完了
→ メール

とします。

運営側には、

新規予約
→ アプリ内またはSlack

満席
→ 管理者へ通知

というように、ユーザー側と運営側で通知を分けます。

通知設計で重要な「通知トリガー」

通知機能では、

何が起きたら通知するか

を決めます。

代表的なトリガーは次の通りです。

イベント発生型

例えば、

申請された
コメントされた
予約された
データが更新された

というイベント発生時です。

日時型

例えば、

契約期限30日前
予約前日
支払期限当日

などです。

条件型

例えば、

在庫が5個以下
未対応問い合わせが10件以上
売上が一定値以下

などです。

未対応時間型

例えば、

問い合わせ受付
↓
24時間未対応
↓
リマインド

という方式です。

通知機能を作る場合は、このトリガーを明確にします。

「期限前通知」と「期限超過通知」は分ける

期限通知では、

期限前

と、

期限超過

の意味が異なります。

例えば、

期限3日前

「対応期限が近づいています」

期限当日

「本日が対応期限です」

期限翌日

「対応期限を超過しています」

です。

期限超過の場合は、

担当者だけでなく管理者へエスカレーション

する方法もあります。

エスカレーション通知を設計する

例えば問い合わせで、

受付
↓
24時間未対応
↓
担当者へ通知
↓
48時間未対応
↓
管理者へ通知

という流れです。

これをエスカレーションとして設計します。

例えば、

Level 1

担当者。

Level 2

チームリーダー。

Level 3

部門管理者。

と段階的に通知します。

ただし、すべての業務で必要なわけではありません。

対応遅延による影響が大きい業務で検討します。

同じ通知を何度も送らないようにする

通知機能で非常に重要なのが重複防止です。

例えば、

バッチ処理が毎時実行され、

期限超過案件を検索
↓
通知

する場合です。

何も対策しなければ、

10時：通知
11時：通知
12時：通知
13時：通知

と同じ内容が送られる可能性があります。

そこで、

last_notified_at

などを管理し、

すでにこの条件で通知済みか

を判断します。

あるいは、

notification_events

のような履歴テーブルを持つ方法があります。

通知履歴を保存する

通知機能では、

本当に通知されたのか

を後から確認したい場合があります。

例えば、

「期限通知が来なかった」

という問い合わせです。

そのため、

通知対象者
通知種類
通知日時
通知手段
送信状態

などを記録します。

例えば、

2026/07/30 09:00
対象：user123
種類：CONTRACT_EXPIRE
手段：EMAIL
状態：SENT

という履歴です。

通知ステータスを持たせる

外部サービスを利用した通知では、

待機中
送信中
成功
失敗

などの状態を持たせる場合があります。

例えば、

PENDING
↓
SENT

または、

PENDING
↓
FAILED

です。

送信失敗時に再試行する場合にも利用できます。

通知の再送はどう考える？

メールサービスや外部APIの一時的なエラーによって通知に失敗する場合があります。

その場合、

送信失敗
↓
再試行

を検討します。

例えば、

1回目失敗
↓
1分後再試行
↓
失敗
↓
5分後再試行

などです。

ただし、

システムが失敗したから永久に送り続ける

という設計は避けます。

最大再試行回数を決めます。

アプリ内通知では既読・未読を管理する

アプリ内通知では、

未読
既読

を持たせることがあります。

例えば、

通知一覧

● 新しい承認依頼があります
○ 契約期限が更新されました

という表示です。

ユーザーが通知を開いたら、

read_at

を保存します。

例えば、

read_at = 2026/07/30 10:15

という形です。

「既読」と「対応済み」は別

通知設計で注意したいのが、

既読
＝
業務完了

ではないことです。

例えば、

「承認依頼があります」

という通知を開いただけでは、承認したことにはなりません。

そのため、

通知既読

と、

申請ステータス

は別々に管理します。

通知をクリックしたら対象画面へ移動できるようにする

通知を受け取った利用者が、

それで何をすればよいのか

分からなければ意味がありません。

例えばメール内に、

申請を確認する
→ /applications/123

というリンクを用意します。

Slackでも、

「問い合わせを見る」

から該当画面へ移動できると便利です。

通知機能は、

知らせるところまでではなく、次の操作へ誘導するところまで

設計します。

通知文には必要な情報だけ入れる

例えば、

「データが更新されました」

だけでは何を確認すればよいか分かりません。

一方で、

顧客の個人情報をすべてメール本文へ記載

すると情報管理上問題になる可能性があります。

そのため、

悪い例

データが変更されました。

改善例

ABC社の契約期限が変更されました。
システムから内容を確認してください。

というようにします。

通知本文へどこまで情報を含めるかも設計項目です。

機密情報を通知本文へ載せすぎない

業務システムでは、

個人情報
契約金額
人事情報
機密文書

などを扱います。

メールやSlackは、Webシステム本体とはアクセス権限が異なります。

そのため、

システムでは人事だけ閲覧できる情報を、Slackの全社チャンネルへ投稿する

といったことが起こらないよう注意します。

通知では、

「新しい申請があります」

程度にとどめ、詳細はログイン後の画面で確認させる方法もあります。

通知先の権限も考える

例えば契約データを閲覧できるのが、

営業部長
法務担当

だけなのに、

営業部全員へ詳細通知

すると、システム側の権限設計を通知によって迂回してしまいます。

通知先を決める際も、

そのユーザーが対象データを閲覧できるか

を確認します。

通知対象者は固定メールアドレスだけで管理しない

例えば、

契約期限通知
→ sales@example.com

だけに固定すると、組織変更に対応しにくくなります。

できれば、

契約担当者
↓
担当者ユーザー
↓
登録メールアドレス

という関係から通知先を決めます。

あるいは、

「営業管理者」

というロールに通知する設計もあります。

ロール通知と個人通知を使い分ける

通知対象には、

個人

担当者本人。

ロール

管理者全員。

部署

営業部全員。

チャンネル

Slackの特定チャンネル。

などがあります。

例えば、

新規問い合わせ
→ 営業チームチャンネル

担当者設定
→ 担当者個人

期限超過
→ 担当者＋管理者

というように使い分けます。

通知設定をユーザーが変更できるようにする？

サービスによっては、利用者自身が通知設定を変更できるようにします。

例えば、

メール通知

コメント追加：OFF
承認依頼：ON
期限通知：ON

Slack

問い合わせ通知：ON

という設定です。

ただし業務上必須の通知までユーザーがOFFにできると問題があります。

例えば、

「重要なセキュリティ通知」

は必須とすることがあります。

そのため、

必須通知

ユーザーが変更不可。

任意通知

ユーザーがON/OFF可能。

に分ける方法があります。

通知の頻度をまとめる「ダイジェスト」

通知が大量に発生する場合、

1件ごとにメールする

のではなく、

1日1回まとめて通知

する方法があります。

例えば、

本日の未対応案件

問い合わせ：5件
承認待ち：3件
期限超過：2件

というメールです。

これをダイジェスト通知と考えます。

緊急度が低い通知では有効です。

即時通知とまとめ通知を使い分ける

例えば、

即時通知

セキュリティ異常
重要な承認依頼
期限超過
決済失敗

ダイジェスト

新しいコメント
本日の作業件数
週次レポート

というように分けます。

何でもリアルタイムにすると通知疲れにつながります。

通知機能を設計する7ステップ

STEP1｜業務イベントを洗い出す

まず、

申請
承認
問い合わせ
契約期限
予約
在庫

など、業務上発生するイベントを整理します。

STEP2｜通知が必要なイベントを選ぶ

すべて通知する必要はありません。

通知しないことで対応漏れが発生するイベントを優先します。

STEP3｜通知対象者を決める

例えば、

担当者
管理者
承認者
顧客

などです。

STEP4｜通知タイミングを決める

例えば、

即時
3日前
当日
超過後

などです。

STEP5｜通知手段を決める

例えば、

メール
アプリ内
Slack
Teams
SMS

から選びます。

STEP6｜再通知・エスカレーションを決める

未対応の場合、

いつ再通知するか。

誰へエスカレーションするか。

を整理します。

STEP7｜通知履歴・設定を決める

例えば、

送信履歴を残す
既読管理
通知ON/OFF
送信失敗時の再試行

などです。

【コピペ用】通知機能設計シート

通知名

通知名：

対象業務：

トリガー

イベント：

日時：

条件：

未対応時間：

通知対象

担当者：

申請者：

承認者：

管理者：

部署：

外部ユーザー：

通知手段

アプリ内：

メール：

Slack：

Teams：

プッシュ：

SMS：

タイミング

即時：

期限前：

当日：

期限超過：

再通知

再通知する：

再通知間隔：

最大回数：

エスカレーション

一次通知：

二次通知：

管理者通知：

通知本文

タイトル：

概要：

詳細：

画面URL：

セキュリティ

個人情報を含む：

機密情報を含む：

通知先権限確認：

履歴

通知日時：

通知先：

通知方法：

送信結果：

既読：

ユーザー設定

必須通知：

任意通知：

メールOFF：

Slack OFF：

通知データの設計例

アプリ内通知を作る場合、例えば次のようなデータを管理します。

notifications

id
user_id
type
title
message
target_url
read_at
created_at

さらに外部通知まで管理するなら、

notification_deliveries

id
notification_id
channel
destination
status
sent_at
failed_at

などを持たせる方法があります。

これにより、

通知そのもの

と、

メール・Slackなどの送信結果

を分けて管理できます。

通知処理は本処理と分けることも考える

例えばユーザーが申請ボタンを押したとき、

申請データ保存
↓
メール送信
↓
Slack通知
↓
完了

をすべて同期的に処理すると、メールサービスが遅いだけで画面処理も遅くなる可能性があります。

そこで、

申請保存
↓
通知ジョブ登録
↓
画面へ成功返却

その後、

通知処理
↓
メール送信
↓
Slack送信

と非同期化する方法があります。

通知量が多いシステムでは、キューを利用する設計も検討します。

通知失敗で本業務まで失敗させない

例えば、

申請登録自体は成功

したものの、

Slack APIへの通知だけ失敗

したケースです。

このとき、

Slack通知できなかったので申請登録も失敗

とする必要があるかは検討が必要です。

多くの場合、

業務データ登録
→ 成功

通知
→ 別途再試行

と分離した方が安定します。

ただし、通知が業務成立の必須条件である場合は別です。

通知処理では冪等性も考える

同じイベントを複数回処理した場合、

メールが2通届く

という問題が起こることがあります。

例えば、

申請ID：123
通知種類：APPROVAL_REQUEST

という組み合わせについて、

すでに送信済みか

を確認する方法があります。

特に非同期処理や再試行を利用する場合、重複通知への対策が重要です。

通知テンプレートを管理する

通知文をコードへ直接大量に書くと、変更時の管理が難しくなります。

例えば、

APPROVAL_REQUEST

件名：
承認依頼があります

本文：
{{applicant_name}}さんから申請があります。

というテンプレートを用意します。

必要に応じて、

メール件名
メール本文
Slack本文
アプリ内本文

を分けます。

HTMLメールを作り込みすぎない

業務通知メールでは、デザインより、

何が起きたか
何をすべきか
どこから確認するか

が分かることが重要です。

例えば、

「承認依頼があります」

申請者：田中
申請日：7月30日

[申請を確認する]

程度でも十分なケースがあります。

通知ログと監査ログは目的が違う

通知履歴は、

誰に通知を送ったか

を確認するものです。

監査ログは、

誰がシステム上で何を操作したか

を確認するものです。

例えば、

7月30日 10:00
佐藤へ承認依頼メール送信

は通知ログ。

7月30日 11:00
佐藤が申請を承認

は監査・操作ログです。

混同せずに管理します。

通知機能でよくある失敗

失敗1｜何でも通知する

通知量が増えすぎて、本当に重要な通知まで読まれなくなります。

通知後に行動が必要なものを優先します。

失敗2｜メールだけに頼る

社員がメールをあまり確認しない環境なら、メールだけでは対応漏れにつながる可能性があります。

日常的に利用しているSlackやアプリ内通知も検討します。

失敗3｜Slackへ何でも送る

大量通知でチャンネルが埋もれます。

重要なイベントに絞ります。

失敗4｜同じ通知を何度も送る

期限チェックなどの定期処理では、通知済みか管理します。

失敗5｜通知先を固定する

担当者変更や異動に対応できません。

業務データやロールから通知先を決めます。

失敗6｜通知本文へ機密情報を書きすぎる

メール・Slackの閲覧範囲まで考えます。

詳細はシステム内で表示する方法もあります。

失敗7｜既読を対応済みとして扱う

通知を読んだことと業務を完了したことは別です。

状態を分離します。

失敗8｜送信失敗を確認できない

通知履歴や送信ステータスを残します。

失敗9｜ユーザーが全部OFFにできる

業務上必須の通知は停止できないようにする場合があります。

失敗10｜通知処理の失敗で本業務も失敗する

通知と業務処理を適切に分離します。

通知機能に関するよくある質問

メール通知とアプリ内通知はどちらがよいですか？

利用状況によります。

毎日ログインする業務システムならアプリ内通知が使いやすい場合があります。

システムを開いていないユーザーへ確実に知らせたい場合は、メールなど外部通知を組み合わせます。

Slack通知だけでもよいですか？

社内でSlack利用が定着しているなら有効です。

ただし、通知履歴を業務システム内で確認する必要がある場合は、アプリ内通知も残す方法があります。

通知は何回まで送るべきですか？

一律の正解はありません。

重要度・期限・業務影響から決めます。

通知回数を増やしすぎると読まれなくなるため、必要最低限にします。

期限通知は何日前がよいですか？

業務によります。

例えば契約更新なら30日前、問い合わせ対応なら数時間前など、必要な準備時間から逆算します。

ユーザーごとに通知設定を変更できますか？

システム設計次第で可能です。

ただし重要通知は必須、コメント通知は任意など、通知種類ごとに設定可能範囲を分ける方法があります。

通知履歴は保存した方がよいですか？

重要な業務通知では保存する価値があります。

「通知されていない」という問い合わせや、送信失敗の調査にも利用できます。

メール送信に失敗した場合はどうしますか？

送信結果を記録し、必要に応じて一定回数再試行します。

再試行しても失敗する場合は、管理者へ通知する方法もあります。

hiro-dev-labでは通知機能を含む業務フロー設計から相談できます

hiro-dev-labでは、Webシステムの通知機能を実装するだけでなく、どの業務イベントを誰へ通知する必要があるのかを整理する段階から相談できます。

例えば、

現在の業務フロー整理
通知が必要なイベントの整理
メール通知
アプリ内通知
Slack・Teams連携
期限・リマインド通知
エスカレーション
通知履歴
既読管理
ユーザー通知設定
通知テンプレート
非同期通知処理
権限を考慮した通知先設計
要求整理
業務要件・機能要件整理
Webシステム設計・開発

などです。

例えば、

申請されたら承認者へ自動通知したい

契約期限が近づいたら担当者へ知らせたい

問い合わせの対応漏れをSlack通知で防ぎたい

通知が多すぎる現在のシステムを改善したい

メールとアプリ内通知をどう使い分ければよいか分からない

という場合でも、

業務イベント → 通知対象 → タイミング → 通知手段 → 再通知・履歴

の順番で整理できます。

まとめ｜通知機能は「知らせる」より「必要な行動につなげる」ことが重要

通知機能を設計するとき、

「イベントが起きたらメールを送る」

だけで考えると、通知が増えすぎる可能性があります。

まず、

何が起きたときに通知するのか
誰に通知するのか
通知を受けた人に何をしてほしいのか
どのタイミングで通知するのか
メール・アプリ・Slackのどれを使うのか
未対応の場合に再通知するのか
通知履歴や既読を管理するのか

を整理します。

例えば、

申請登録
↓
承認者へアプリ内＋メール通知
↓
24時間未対応
↓
承認者へリマインド
↓
48時間未対応
↓
管理者へエスカレーション

という形です。

一方、重要度の低い情報は、

アプリ内だけ

あるいは、

1日1回のダイジェスト

でも十分な場合があります。

通知機能で重要なのは、

通知数を増やすことではなく、必要な情報を必要な人へ必要なタイミングで届けること

です。

そして通知を受け取った人が、

何をすればよいのか

迷わないように、対象画面へのリンクなども用意します。

「メール通知を入れたい」

「Slackへ連携したい」

という機能単位から考えるのではなく、

どの業務で対応漏れが発生しており、誰にいつ知らせれば防げるのか

から通知機能を設計すると、実際の業務改善につながるシステムになります。