業務アプリの通知文は、短い文章で利用者の行動を変えます。「処理しました」という一言では、申請を受け取ったのか、承認されたのか、相手に届いたのかが分かりません。文章を整える前に、通知が伝える業務イベントと、受信した人に期待する行動を定義する必要があります。
架空の設備貸出アプリを例にします。利用者が会議用機器を申請し、管理者が内容を確認し、倉庫担当が受け渡します。申請直後に「予約完了」と伝えると、まだ在庫を確認していない段階でも受け取れると思われてしまいます。この例は実績の紹介ではなく、通知の意味を点検するための想定です。
イベントごとに文章の責任を決める
受付通知は受け取った事実を、承認通知は承認された対象と条件を伝えます。発送、到着、受渡し完了が別の作業なら、それぞれの意味を区別します。担当者が次に何を待てばよいか、誰が処理しているかが分かる文面にし、状態を表す言葉を画面と通知で統一してください。
最初に作るとよいのは、イベント、対象者、必須情報、次の行動を並べた表です。すべての変更を全員へ送る必要はありません。閲覧だけで十分な記録と、対応が必要な通知を分けることで、重要な依頼が大量の更新報告に埋もれるのを防ぎやすくなります。
古い通知から最新状態へ戻れるようにする
通知は必ずしも作成順に読まれません。承認後に取消が行われ、その後で古い承認メールが届く可能性もあります。文面に対象番号や確定時点を示し、リンク先では現在の状態を表示します。古いメッセージだけで実行が確定するような導線は避け、必要な操作の直前に最新条件を確認します。
リンクには対象を開くための情報を持たせても、権限の代わりにはしません。別の利用者がリンクを受け取っても、ログインした人に許可されていない申請を表示しないようにします。通知タイトルやロック画面へ出す内容も検討し、詳細な個人情報や機密の申請内容を不用意に載せない方針を決めます。
配信状況と仕事の結果を区別する
送信サービスが受け付けた状態、相手のサーバーに届いた状態、利用者が必要な操作を終えた状態は別です。送信成功を申請対応済みの根拠にしないでください。逆にメールが届かなかっただけで、成立済みの貸出予約を取り消すのも適切ではありません。配信側の失敗は独立して記録し、対応する担当者を決めます。
再送では同じ業務イベントを識別し、無制限に同文を増やさないようにします。通知が使えないときも、アプリ内の未対応一覧から仕事を続けられる構成が必要です。期限や催促の頻度は業務に合わせて設定し、すでに完了した依頼へ古い催促が送られないかも確認します。
文章と操作を一緒に受け入れる
テストでは、通知を読んだ担当者が対象を特定し、迷わず次の操作へ進めるかを確認します。通信の遅延、取消後の古い通知、再送、権限のない受信者、画面読み上げも含めてください。色やアイコンだけで重要度を伝えず、件名やリンクの言葉でも目的が分かるようにします。
Brainbaby Labsには、現在の通知例と「この時点で実際に何が確定しているか」を共有してください。文面、状態管理、配信処理、未対応一覧をまとめて設計することで、見た目のよい通知から、現場が仕事を進められる通知へ改善できます。