問い合わせ管理がうまくいかなくなる原因の一つは、期限の扱いが曖昧なことです。 担当者の経験や気合いで対応している間は何とか見えても、件数が増えたり、担当者が変わったり、繁忙期に入ったりすると、未対応・遅延・返答待ちが一気に見えにくくなります。
SLA（Service Level Agreement）は、単に「何時間以内に対応する」と決めるだけのものではありません。 問い合わせ種別、優先度、一次回答期限、解決期限、保留中の扱い、担当割当、通知、レポートまで含めて、現場で使えるルールに落とし込む必要があります。
問い合わせ対応で不満が出やすいのは、「返事がない」と「解決しない」が混ざっているときです。 この2つは別の期限として扱った方が、運用が明確になります。
一次回答は、必ずしも解決を意味しません。 「内容を確認しました」「追加でこの情報をください」「担当部署で確認しています」と返すだけでも、相手の不安はかなり減ります。 不足情報の回収が必要な場合は、フォローアップ設計 のように、早い段階で必要情報を取りに行く導線を用意します。
| 期限の種類 | 目的 | 例 |
|---|---|---|
| 一次回答期限 | 相手に「受け付けた」「確認している」と伝える。 | 受付から4営業時間以内に初回返信。 |
| 解決期限 | 問い合わせや依頼を完了させる。 | 通常問い合わせは3営業日以内、障害系は当日中。 |
| 再連絡期限 | 保留中や返答待ちを放置しない。 | 顧客返信待ちが3日続いたら再連絡。 |
優先度を担当者の感覚で決めると、判断がぶれます。 「急いでいます」と書かれているだけで最優先にしてしまうと、本当に影響の大きい案件が後回しになることもあります。
実務では、緊急度と影響度を分けて考えると整理しやすくなります。
| 影響度＼緊急度 | 高い | 中程度 | 低い |
|---|---|---|---|
| 影響度：大 | 最優先 障害・安全・売上影響など。 |
高 複数顧客への影響がある。 |
中 期限を決めて対応。 |
| 影響度：中 | 高 特定顧客の業務に影響。 |
中 通常対応。 |
低 順次対応。 |
| 影響度：小 | 中 急ぎだが影響範囲は限定的。 |
低 通常キューで対応。 |
低 ナレッジ化候補。 |
問い合わせ種別と優先度を連動させる場合は、問い合わせ種別プルダウンの設計パターン と合わせて設計します。 たとえば「障害・停止」「請求」「見積」「一般相談」など、入口の選択肢から初期優先度を付けると、受付直後の判断が短く済みます。
問い合わせ対応では、保留が必ず発生します。 顧客からの返信待ち、外部ベンダーの確認待ち、部品入荷待ち、社内承認待ちなどです。
ここで決めておくべきなのは、保留中にSLAの時間を止めるかどうかです。 これを決めないまま運用すると、期限超過の扱いが人によって変わります。
| 保留理由 | SLAの扱い | 別途持つべき期限 |
|---|---|---|
| 顧客の返信待ち | 時計停止にすることが多い。 | 再連絡期限、最終確認期限。 |
| 社内確認待ち | 原則として時計停止しない。 | 社内回答期限、責任者通知。 |
| 外部ベンダー待ち | 契約・運用方針によって判断。 | ベンダー回答予定日、顧客への次回報告日。 |
| 部品入荷待ち | 業務内容によって停止または別SLAに切り替え。 | 入荷予定日、顧客連絡予定日。 |
ステータス側の基本設計は、ステータス管理の運用ルールと失敗しにくい設計 を土台にできます。 SLAでは、ステータスだけでなく、保留理由と再連絡期限もセットで持つことが重要です。
期限を決めても、誰が対応するかが曖昧だと守れません。 SLA管理では、担当割当とエスカレーションを同時に設計します。
担当の決め方は、担当振り分けルールの設定方法（自動・手動） と連動します。 すべて自動で決める必要はありません。 重要案件や複数部署にまたがる案件は、手動で責任者を決められる余地を残しておく方が実務に合います。
SLAを運用するうえで、ダッシュボードは非常に重要です。 一覧に期限が出ていないと、担当者は自分の記憶やメール通知に頼ることになります。 これでは件数が増えたときに対応が遅れます。
画面例 SLA対応ダッシュボード
期限そのものだけでなく、残り時間・優先度・保留理由を同じ一覧に出すと、次に対応すべき案件が判断しやすくなります。
問い合わせ一覧のカラム設計は、問い合わせ管理ダッシュボードのカラム設計テンプレート と合わせて検討できます。 SLA向けには、最低でも次の列を持たせると運用しやすくなります。
通知をすべて同じタイミングで出すと、担当者が慣れてしまい、重要な通知も埋もれます。 SLA通知は、目的ごとに分ける方が実務に向いています。
| 通知タイミング | 通知先 | 目的 |
|---|---|---|
| 一次回答期限の直前 | 担当者 | 初回返信漏れを防ぐ。 |
| 一次回答期限の超過 | 担当者＋チームリーダー | 早めに補助や担当変更を判断する。 |
| 解決期限の直前 | 担当者＋責任者 | 完了できるか、期限延長や説明が必要か判断する。 |
| 保留が長期化 | 担当者＋管理者 | 顧客再連絡や外部確認の抜けを防ぐ。 |
通知は多すぎても少なすぎても機能しません。 初期設定では重要な通知に絞り、運用後に「見逃しが多い」「通知が多すぎる」といった状況を見ながら調整するのが現実的です。
SLAレポートで見るべきなのは、達成率だけではありません。 達成率だけを追うと、現場が期限内に閉じることだけを優先してしまい、根本的な改善につながらない場合があります。
レポートでは、次のような軸を見ます。
問い合わせレポート全体の考え方は、問い合わせ集計レポートの作り方 と共通します。 SLAでは特に、「どのカテゴリで期限超過が多いか」「どの保留理由が長くなっているか」を見ると、改善ポイントを見つけやすくなります。
初回相談や受任判断では、一次回答の遅れがそのまま機会損失につながります。 士業事務所向け のような相談受付では、一次回答期限を短めに設定し、不足情報がある場合はすぐにフォローへ回す構成が向いています。 相談内容によって担当者が変わる場合は、初期振り分けと担当確定の期限も決めておくと安心です。
整備・タイヤ交換では、部品入荷待ち、顧客承認待ち、保険会社確認待ちなど、保留が多く発生します。 自動車販売・整備・タイヤショップ向け の業務では、保留理由と次回連絡期限を必ずセットにしておくことが重要です。 「部品待ちだから止まっている」で終わらせず、入荷予定日と顧客への次回連絡日を持たせると、店頭対応の抜けを減らせます。
技術問い合わせでは、社内確認や評価待ちが長くなりがちです。 この場合、顧客向けのSLAと社内確認の期限を分ける必要があります。 顧客には「次回報告日」を持たせ、社内には「技術回答期限」を持たせると、外向きの説明と内部作業の両方を管理しやすくなります。
SLAは、期限を設定するだけでは運用に乗りません。 一次回答期限と解決期限を分け、優先度を緊急度×影響度で決め、保留中の時計を止めるかどうかを明確にします。 そのうえで、担当割当、エスカレーション、ダッシュボード表示、通知、レポートまで一つの流れとして設計する必要があります。
株式会社インテンスで問い合わせ管理を設計する場合も、最初から細かいルールを詰め込みすぎるのではなく、まずは「一次回答」「解決期限」「保留理由」「次回連絡予定」の4点を見えるようにすることを重視します。 この4点が画面上で確認できるだけでも、未対応・期限超過・長期保留はかなり減らしやすくなります。