SLA・期限・アラート設計｜エスカレーションで対応遅延を防ぐ通知ルールの作り方

期限を設定していても、保留中に時間を数えるか、担当者が不在なら誰が引き継ぐかが決まっていないと、通知後の対応を判断できません。期限の計算条件と、通知を受けた人が行う作業を一緒に決める必要があります。

本記事では、SLAのうち対応時間に関する約束を扱い、「期限を計算する」「遅延を検知する」「通知する」「担当変更や支援につなげる」という流れを設計します。問い合わせ・予約・見積の事務対応を想定し、保留、営業時間外、通知失敗、代理対応の扱いまで確認します。

期限の起点・達成条件・担当者を決める

「受付から何時間以内」という起点と、「一次回答を送ったら達成」という終了条件を分けて定義します。顧客に約束した期限と、社内で確認するための締切も別の項目として扱い、社内通知を延期しただけで顧客への約束が変わらないようにします。

• 一次回答期限：受付を起点に、状況説明や次の対応予定を含む最初の回答までを測ります。自動受付メールだけで達成とするかは、約束した対応内容に合わせて明記します。
• 完了期限：受付など所定の起点から、解決・納品・確認完了など、定義した完了条件までを測ります。一次回答を送っても完了扱いにはしません。
• 次回確認期限：顧客返信待ちや部品待ちの案件を、次に誰が確認するかを決めます。メモの修正だけで確認期限を先送りしないルールにします。
• 責任者：主担当と不在時の引継先を決めます。未割当の案件は受付担当や当番へ通知するなど、通知先が空になる場合の扱いも必要です。

営業時間・保留・担当変更を計算条件に含める

「4営業時間以内」と「受付から4時間以内」では期限が変わります。利用するタイムゾーン、営業日、営業時間、祝日・休業日のカレンダーを指定します。例えば月〜金の9〜17時を営業時間とし、途中に休業日がなければ、金曜16時の受付に対する4営業時間後は月曜12時です。これは計算例であり、推奨する対応時間ではありません。

問い合わせ管理全体の優先度・達成率の扱いはSLAによる問い合わせ管理、状態変更の記録はステータス設計も参照してください。ここでは、これらの条件から「いつ誰へ通知するか」を決めます。

期限、通知、引き上げ先が一画面で見えると、対応判断がしやすくなります

下は、問い合わせや依頼管理を想定した画面例です。件数と通知時刻は説明用で、実績値ではありません。Tは対象の期限を表し、24時間前・24時間後という間隔は通常案件の例です。短時間での回答を約束した案件や重大案件には、その期限と対応体制に合わせた別の通知条件を設定します。

SLAは細かく分けすぎない方が運用しやすくなります

SLAをカテゴリごとに細かく設定しすぎると、説明、保守、見直しが追いつかなくなります。まずは大きな区分だけで始める方が、現場で扱いやすくなります。

• 通常：標準的な問い合わせや依頼
• 急ぎ：期限が短いもの、優先度が高いもの
• 要確認：他部門確認や追加資料待ちが前提のもの

即時・定期・段階通知を使い分ける

重要度は問い合わせの分類とは別に扱います。例えば「重大」は合意した緊急連絡先へ即時通知、「要注意」は担当者へ通知、「情報」は定期一覧に含める、といった区分を設けます。区分数を先に固定するより、誰が何を行うかで通知手段を選びます。

通知が見られにくくなる原因

• 全員通知が多く、誰も自分事として見なくなる
• 通知文面が薄く、次に何をすべきか分からない
• 夜間や休日も同じ通知が飛び、見る側が疲弊する

基本の対策

• 通知対象を絞る（担当者＋バックアップ担当など）
• 件名や本文に、期限、カテゴリ、担当者を入れる
• 夜間や休日は別ルールにし、通常案件は朝にまとめて確認できるようにする

夜間の通知停止と、期限計算の停止を区別する

通常案件を翌朝のまとめ通知にする場合でも、それだけで期限の時計が止まるわけではありません。営業時間内だけを数える条件か、経過時間を数える条件かを期限側で定義します。夜間も連絡が必要な案件は、対応を引き受ける当番と不在時の連絡先を事前に決めます。翌朝に送る際は状態を再確認し、夜間に完了した案件へ古い警告を送らないようにします。

通知文面には案件番号、対象の期限、残り時間または超過時間、担当者、依頼する作業、確認画面へのリンクを含めます。詳細な顧客情報は権限を確認できる管理画面で表示する設計にします。チャネル別の扱いは通知・リマインド設計、顧客への経過連絡は送信後フォローとメール文面が参考になります。

エスカレーションは「誰へ上げるか」だけでなく「何をしてもらうか」まで決めておくと動きやすくなります

期限超過したら上司へ通知する、というだけでは、結局その後どうするかが曖昧になりやすくなります。段階ごとに、通知先と行動を結びつけておく方が現場では扱いやすくなります。

段階の例

以下は通常案件の設定例です。4営業時間以内の一次回答なら、例えば2営業時間経過時と期限到達時に確認するなど、約束した時間内に支援できる間隔にします。重大案件を通常の段階通知に入れ、24時間待ってから管理者へ連絡する運用にはしません。

• T-24h：担当者へリマインド。自分で解消できる段階です。
• T-0：担当者＋受付担当へ通知。支援や優先度見直しが必要な段階です。
• T+24h：管理者へ通知。担当変更、優先度変更、他案件調整が必要な段階です。

1. 担当者へ確認を求める
   期限内に回答・完了できるか、支援が必要かを登録します。
2. 受付やチームで支援する
   期限当日になっても残るものは、優先順位の見直し対象にします。
3. 管理者が再配分する
   期限超過が続くものは、担当変更や対応順序の見直しまで含めて扱います。

代理対応の権限と、引継先が決まらない場合を決める

自動再割当を行う場合は、担当可能な範囲と不在・負荷の条件を担当者割当ルールで定義します。候補者が見つからなければ元の担当情報を保持し、「引継先未確定」として受付・管理者に知らせます。割当処理を実行しただけで対応済みにはしません。

代理者が見られる案件の範囲、回答・期限延長・完了処理の権限を分け、例外対応は必要な承認につなげます。ロールと対象範囲による権限設計に沿って、通知リンクから開いた場合も権限を確認します。担当・期限・状態を変更したときは、変更前後の値、実行者、時刻、理由、承認者を監査ログに残します。

通知失敗と重複送信を確認できるようにする

期限超過の判定、通知の送信結果、担当者の確認、案件の完了は別の状態です。送信に失敗しても期限超過は解消していません。失敗した通知は一覧に残し、再送回数や別の連絡先へ切り替える条件を決めます。メールなどの送信成功だけで、人が読んだ・対応したと判定しないようにします。

同じ案件・期限・通知段階について送信済みかを記録し、定期処理の再実行で同じ警告が連続しないようにします。再送する直前にも状態と期限を確認し、完了済み・期限変更済みなら古い警告を中止します。期限を変更して新たに通知する場合は、変更前の通知履歴と区別します。

業務ごとに、通知に必要な情報を具体化する

次は事務運用を検討するための例です。導入実績や改善効果を示すものではありません。

• クリニックの予約事務：当日・翌日の予約変更や事前確認が未処理なら、予約日時と確認事項を受付担当へ知らせます。予約枠との連動は予約カレンダー連携を参照できます。
• 物流の納品調整：納品予定までに確認が終わっていない場合、納品日時・バース・荷姿・車番のうち判断に必要な項目を示し、現場と調整担当のどちらが回答するかを決めます。
• 自動車整備の入庫・部品待ち：入庫予約とピット割当を確認し、部品待ち・顧客承認待ちの理由と次回連絡日を持ちます。待ち状態にしても、予定した確認や顧客連絡を省略しないようにします。

週次で回すなら、最小ルールから始める方が定着しやすくなります

• 期限は「一次回答期限」と「完了期限」を混ぜない
• アラートは「未対応」と「期限超過」を先に出す
• エスカレーションは1段階だけから始める（担当者から受付または管理者へ）

最初は通常案件の通知経路と、重大案件の連絡先を決めます。週次では、超過件数に加え、通知失敗、引継先未確定、次回確認日の超過を見直します。ダッシュボードKPI設計と同じ条件で集計し、件数から対象一覧を開いて作業できる形にします。

よくある失敗パターン

• カテゴリごとにSLAを細かく分けすぎて、現場が覚えきれない
• 通知の送信数だけ増えて、見返されなくなる
• エスカレーション先は決まっているが、その後の行動が決まっていない
• 保留中の計算条件が曖昧で、超過や次回確認漏れを判断できない

まとめ

期限を守る仕組みは、通知を増やすことより、誰がどの段階で動くかを決めることから始まります。SLA、期限、アラート、エスカレーションを同じ流れで設計し、まずは少ない区分と少ない通知で回す方が、実務では安定しやすくなります。

まず、一次回答と完了の期限、保留中の計算条件、不在時の引継先を確認します。そのうえで、通知に失敗した場合や引継先が決まらない場合も一覧で把握し、担当者が次の作業を判断できるようにします。