速く返すだけでは足りない ― SaaSサポートのSLA設計

今日は SaaS サポートの SLA です。Atlassian の Premier Support では、最重要の Level 1 に三十分で初回応答すると案内しています。SLA は単なる速さ自慢ではなく、顧客への約束そのものなんですね。

その理解が大事です。SaaS のサポート SLA は、初回応答、次回応答、途中更新、解決までの時間をどう設計するかの話です。最初の一通だけ速くても、その後に沈黙すれば信頼は落ちます。

Zendesk は SLA を response と resolution の合意として定義し、first reply time、next reply time、periodic update、resolution を分けています。つまり顧客が本当に見ているのは、返事の速さではなく、放置されないことなんです。

その通りです。経営目線では、SLA は現場をせかすための数字ではなく、顧客期待値をそろえる設計です。だから公開する約束と、社内で守る運営ルールを分けずに作る必要があります。

Intercom の説明が分かりやすくて、平日九時から十七時の体制で二十四 office hours の初回応答 SLA を置くと、金曜夕方の問い合わせは実際には翌週水曜までの扱いになります。数字だけ見て一日ではないんです。

だから SaaS では、営業時間、祝日、待ち状態でタイマーが止まるかまで決めておく必要があります。Intercom では waiting on customer の間は SLA を止められますし、実態に合わせて期待値を表示する仕組みもあります。

優先度設計の例では、Atlassian が Level 1 を三十分、Level 2 を二時間、Level 3 を八時間と分けています。GitLab も Emergency 三十分、High 四時間、Medium 八時間、Low 二十四時間という形です。全部を最速にしないのが現実的なんです。

国内ではサイボウズが参考になります。通常サポートは平日十時から十七時半、でも夜間休日の障害は事前申込制の時間外障害窓口を別で用意し、機能質問や移行相談は対象外にしています。入口を分けて約束を守りやすくしているんです。

よくある失敗は五つです。初回返信しか追わない、営業時間を無視する、優先度で分けない、顧客待ちでもタイマーを止めない、外向きの約束と社内運営がつながっていない。このどれかで、SLA は飾りになります。

その順が堅実です。最後に、SLA 達成率だけでなく、priority 別の未達件数、次回返信の遅延、更新間隔まで見てください。SaaS のサポート SLA は、返答速度の管理ではなく、信頼を再現する経営システムなんです。