SLA（期限）で回す問い合わせ管理｜優先度・一次回答・解決期限を運用に落とす

問い合わせ管理が回らなくなる典型は、「期限が無い」または「期限があっても守れない」です。
担当者の頑張りで回していると、繁忙期・担当交代・欠員で崩れます。
そこで使われるのがSLA（Service Level Agreement）の考え方です。
本記事では、SLAを“現場の運用ルール”に落とすために、期限・優先度・保留・割当・表示・集計までを整理します。

1. 期限を2種類に分ける：一次回答期限 と 解決期限

問い合わせで揉めるのは「返事が遅い」か「解決が遅い」かが混ざるからです。
そこで期限を2つに分けます。

• 一次回答期限：受付後、まず状況説明や確認依頼を返す期限
• 解決期限：完了（または完了合意）までの期限

一次回答は「解決」ではありません。
不足情報の回収（フォローアップ設計）を早く回すための期限です。
この分離だけで、相手の不満は大きく減ります。

2. 優先度は “緊急度×影響度” で決めるとブレにくい

優先度は主観だと揉めます。最低限、次の2軸で表にします。

• 緊急度：いつまでに対応が必要か（今日中/今週中/いつでも）
• 影響度：影響範囲（全体/一部/個別）と損失（売上・安全・法務）

問い合わせ種別の切り方（プルダウン設計）と整合させ、
受付時点で優先度が半自動で付くようにすると運用が揺れません。

3. 保留の設計：SLAの時計を止めるかを決めないと破綻する

「顧客の返信待ち」「外部回答待ち」「部品入荷待ち」など、保留は必ず発生します。
ここで決めるべきは、SLAの時計を止めるかどうかです。

保留の理由は固定し、ステータス運用（運用ルール）として落とします。
理由が自由入力だと、集計できず改善につながりません。

4. 担当割当とエスカレーション：期限超過を“個人の責任”にしない

期限があっても、割当が曖昧だと守れません。担当割当は、ルール（自動・手動）を先に決めます。
さらに、期限超過が見えたら“上に上げる”仕組み（エスカレーション）を用意します。

• 一次回答期限を超えそう：担当→チーム内で補助
• 解決期限を超えそう：責任者へ通知、優先度再評価
• 繰り返し遅延：カテゴリ・タグ（タグ設計）で原因を特定

5. ダッシュボード表示：期限管理は“一覧の列”が本体

期限管理は、メールや口頭では回りません。ダッシュボードに出す必要があります。
カラム設計は テンプレート を前提に、SLA用に以下を追加すると回りやすいです。

• 一次回答期限（日時）
• 解決期限（日時）
• 優先度
• 保留理由（停止中かが分かる）

表示が整うと、集計（レポート）につながります。
「遅延が多いカテゴリ」「遅延が多い拠点」「保留が長い理由」を見える化し、改善に回せます。

業種別でのハマりどころ

士業（初回相談・受任判断）

一次回答が遅いと、そのまま他社へ流れます。業務像は 士業事務所向け を前提に、
一次回答期限を短めに固定し、必要情報が不足している場合は即フォロー（回収設計）へ回すのが効きます。

自動車販売・整備・タイヤショップ（入庫・部品・保険修理）

部品待ちなど保留が発生しやすいので、時計停止のルールを決めないと、期限が形骸化します。
業務像は 自動車販売・整備・タイヤショップ向け を前提に、
「保留理由」と「次の連絡期限（リマインド）」をセットにすると運用が安定します。

まとめ

SLAは、期限を置くことではなく、期限で運用を回す仕組みです。
一次回答期限と解決期限を分け、優先度を緊急度×影響度で固定し、保留の時計停止ルールを決める。
割当とエスカレーションを用意し、ダッシュボードとレポートで改善に回せば、問い合わせ管理は崩れにくくなります。