問い合わせSLA監視アラート：超過予告、自動エスカレーション、振り返り

問い合わせSLA監視アラート：超過予告、自動エスカレーション、振り返り

1. SLAのカウントダウンはいつから始まるか

多くのチームでSLAが形骸化する最大の原因は、カウントダウンの起点が間違っていることだ。営業が問い合わせを「見た」瞬間から数えているが、営業が半日CRMを開かなければ、そのリードは永遠に超過しない。

正しい起点は問い合わせがCRMに入った瞬間で、営業がオンラインかどうかは関係ない。フォーム送信、メール転送、WhatsAppメッセージの3つの経路すべてにタイムスタンプを打ち、その時刻からカウントダウンする。複数経路をまとめて取り込む方法はマルチチャネルの問い合わせ統合。

カウントダウンのしきい値は問い合わせの階層ごとに変える。Aクラスは5分、Bクラスは1時間、Cクラスは24時間で、前回解説した入口の階層分けに対応する。階層の分け方は問い合わせファネルの間引きと品質階層化。

週末や夜間の問い合わせはどう扱うか。午前3時にカウントダウンで営業を起こしてはいけない。夜間の問い合わせには「営業時間内に優先して返信します」と自動返信し、カウントダウンは翌営業時間から始める。タイムゾーンをまたぐ対応策は時差をまたぐ問い合わせフォロー。

2. 4段階のアラートを無視されないように設計する

アラートは4段階に分け、いきなりSMSや電話を鳴らしてはいけない。通知の手段が重いほど、営業は免疫をつけてしまう。

第1段階は残り時間80%の予告で、担当営業に個人チャットを送り「このAクラス問い合わせはあと1分で期限です」と伝える。これは催促ではなくリマインドだ。第2段階は実際の超過で、営業と上長の両方に同時に通知する。

直感に反する判断：アラートは多く出すほど無視される。毎日10件を超えるアラートが届く営業は、すべてを一括既読にする習慣がつき、本当に緊急の1件も埋もれてしまう。だからL1の警告は控えめに。A類にだけ送り、B類とC類は個人チャットに送らない。

場面例：ある営業がビデオ会議に対応中で、スマホはサイレント。そこにA類の問い合わせが入る。システムは4分目にIMを送ったが、彼は気づかない。10分目に上司がアラートを受け、電話をかける。会議を終えた彼はすぐ返信し、この案件はまだゴールデンタイム内に収まった。このエスカレーションの連鎖がなければ、この問い合わせは午後まで気づかれなかったかもしれない。

三、自動エスカレーション：上司が代わりに返すのではなく、担当を変更する

タイムアウトが2倍に達したら、システムはこの問い合わせを現在の負荷が最も低い営業に自動で付け替えるべきで、上司が自分で返信を代筆するのではない。

上司による代返は最もよくある誤りだ。問題は解決したように見えて、実際には二つの本当の問題を覆い隠している。一つは元の営業の負荷が過剰だったこと、もう一つは上司の時間が現場の仕事に奪われたこと。来週も同じことが起きる。

付け替え後、元の営業には説明を1件送る。「この問い合わせはタイムアウトのため、同僚に引き継ぎました」。元の営業を何も知らないままにせず、システムの不具合だと思わせてもいけない。

エスカレーションの仕組みと負荷分散はセットだ。誰に付け替えるかは、現在手がけている進行中の問い合わせが最も少ない人で決める。負荷分散アルゴリズムは問い合わせ営業の負荷分散を参照。本記事では付け替えのトリガー条件だけを扱う。

四、振り返り：毎週何を見て、毎月何を変えるか

監視アラートは導入して終わりではない。毎週タイムアウトのデータを見て、毎月根本原因を振り返る。

週次のダッシュボードでは三つの数字を見る。A類の初回応答タイムアウト率（目標5%未満）、B類のタイムアウト率（目標15%未満）、アラートによる付け替え回数（5回を超えたら原因を調べる）。この三つの数字は日次のデータダッシュボードに入れる。問い合わせデータダッシュボード。

毎月のタイムアウト率が2か月連続で最下位の営業担当は、原因を個別に確認する。担当している問い合わせが多すぎるのか（割り当てルールの変更）、処理の習慣に問題があるのか（研修）、休暇中なのか（一時的な負荷調整）。いきなり評価を下げず、まず原因を切り分ける。

シナリオ例：ある月、A類のタイムアウト率が3%から12%に上昇。ダッシュボードを見ると、営業3人のうち1人が2週間休暇を取り、残る2人が倍の問い合わせを抱えていた。これは営業の姿勢の問題ではなく、シフトの問題だ。次回の休暇前に、あらかじめ負荷をバックアップ担当へ切り替えておく。

振り返り会議では、特定の1件のタイムアウトを名指しで批判しない。傾向と分布を見る。単発のタイムアウトは偶然かもしれないが、2週間連続で同じ担当者のタイムアウト率が高いなら、それが本当の問題だ。

SLAデータとその後の成約結果の相関分析は、こちらを参考に問い合わせ対応時間と成約率の相関。あの記事は対応の速さが成約に与える影響を扱い、本記事は監視体制で対応時間を守る方法を扱っている。両方を合わせて見るとよい。

FAQ よくある質問

最後に

SLAは社員ハンドブックに書いたスローガンではなく、タイムスタンプから始まり、レベル別アラート、自動再割り当て、週次・月次振り返りまでを含む完全な監視システムです。監視のないSLAでは、営業はタイムアウトをまったく恐れません。

導入の3ステップ。まずカウントダウンの起点を問い合わせがCRMに入った瞬間に統一し、A/B/Cで5分/1時間/24時間の3段階に設定する。次にアラートを4段階のエスカレーションにし、80%で本人に通知、タイムアウトで上司に通知、2倍のタイムアウトで自動再割り当て。最後に毎週タイムアウト率を確認し、毎月根本原因を振り返る。上司は代理返信せず、再割り当てを行う。

覚えておきたい一言。SLAはシステムで守るもので、自主性に頼らない。タイムスタンプを正確に打ち、アラートを段階的にエスカレーションし、タイムアウトは自動再割り当て。これでA類の問い合わせが営業の受信トレイに埋もれることはない。