← エピソード一覧に戻る Episode 245 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング
タカシ
今日は SaaS サポートの優先度設計です。GitLab では、回避策なしで二割以上のユーザーに影響する問題を severity 1 とし、八時間以内の緩和と四十八時間以内の解決を目標に置いています。急ぎ方を数字で決めているんですね。
ミカ
優先度って、担当者の感覚で何となく urgent を付けるものだと思っていました。でもそれだと、声の大きい顧客ばかり先に見てしまいそうです。
タカシ
その通りです。SaaS は継続課金なので、一件の遅い対応が不満で終わらず、更新率や拡張率にも響きます。だから優先度設計は、単なる並べ替えではなく、経営判断を現場に落とす仕組みなんです。
ミカ
なるほど。今日は、何を基準に急ぐ案件を決めるのか、それをどう制度として回すのかを知りたいです。
Chapter 2 severity と priority と SLA を分ける
タカシ
最初の論点は、severity と priority と SLA を混ぜないことです。severity は障害そのものの深刻度、priority は今どの順番で処理するか、SLA は顧客に約束した応答や解決時間。この三つを一語で扱うと判断がぶれます。
ミカ
たしかに、重大障害だから急ぐのか、大口顧客だから急ぐのか、契約で一時間以内に返す約束だから急ぐのか、理由が全部違いますね。ここを分けないと現場は迷いそうです。
タカシ
Atlassian は SEV1 を全顧客停止やデータ損失、SEV2 を一部顧客停止や重要機能への大きな影響、SEV3 を軽微な不便としています。そして SEV1、SEV2 は時間帯に関係なく on-call が即応する。深刻度が運営ルールに直結しているわけです。
ミカ
つまり、良い優先度設計って、感情で急ぐのではなく、影響の定義と約束の定義を先に決めることなんですね。
Chapter 3 何を軸に優先順位を決めるのか
タカシ
実務では、impact と urgency と customer promise の三軸で設計すると運用しやすいです。impact は影響ユーザー数や本番停止、urgency は期限性や拡大速度、customer promise は Enterprise 契約や法令対応などですね。
ミカ
impact と urgency は分かりますが、customer promise を入れるのが SaaS らしいですね。同じ不具合でも、どんな契約をしているかで運営側の責任が変わるわけだ。
タカシ
そうです。Zendesk は、SLA を適用するにはまず Priority フィールドを設定する必要があると明言しています。Intercom も、高額顧客、解約しそうな会話、一定時間返信待ちの案件に自動で priority を付け、より速い SLA を当てられるようにしています。
ミカ
priority を付けるだけじゃなくて、その優先度が時計を動かすんですね。ラベル遊びじゃなく、応答時間と更新頻度のルールまで連動して初めて意味があると。
Chapter 4 先進事例に学ぶ
タカシ
GitLab の基準はかなり具体的です。回避策なしで五から二十パーセントのユーザーに影響しても最低 priority 1 ですし、Customer Support Operations では Severity 1 を一から二時間で解決目標、十分で未解決なら次段階へ上げると決めています。
ミカ
そこまで明文化されていると、現場の迷いが減りますね。誰かの経験値ではなく、影響率と回避策の有無で話せるのが強いです。
タカシ
Atlassian の support services も示唆的です。L1 の初回応答は Standard で二営業時間、Premium で一時間、Enterprise で三十分。L4 は二営業日や二十四時間です。つまり契約階層と影響度に応じて、期待値と運営負荷を先に設計しています。
ミカ
なるほど、優先度設計って社内効率だけじゃなく、何を売っているかにも関わるんですね。速い対応そのものが、高単価プランの価値になるわけだ。
タカシ
さらに Zendesk の Benevity 事例では、ネガティブ感情のチケットを上位スキルの担当者へ優先配分し、応答を五十八パーセント高速化、手動分類を年間三百六十四時間削減しました。大量流入の SaaS ほど、優先度を自動でそろえる価値が大きいんです。
Chapter 5 失敗しない作り方
タカシ
よくある失敗は、severity と priority の混同、high と urgent の乱発、回避策を見ない判定、契約プランだけで順番を決めること、そして上書き運用を放置することです。これをやると、制度がすぐ形骸化します。
ミカ
明日から始めるなら、impact、urgency、customer promise の三軸で priority matrix を作る。次に、優先度ごとに first response と next update と resolve の目標を置く。さらに override 率も見る、この順番が良さそうです。
タカシ
その順番が堅実です。優先度設計は、サポートの現場ルールでありながら、実際には継続率と単価を守る経営設計です。皆さんの組織でも、急ぎの基準が人によって違っていないか、ぜひ点検してみてください。それではまた次回。