障害より沈黙が解約を呼ぶ ― SaaSサポートのインシデントコミュニケーション

皆さんこんにちは、タカシです。今日は SaaSサポートのインシデントコミュニケーションを扱います。PagerDuty のガイドでは、障害の初報は incident call 開始から 5 分以内が目安です。復旧の速さだけでなく、知らせる速さが継続率を左右するテーマですね。

まさにそこです。SaaS では障害そのものをゼロにはできませんが、顧客を放置しない運営は設計できます。今日のポイントは三つで、初報の速さ、見る場所を一つに寄せること、そして誰が説明責任を持つかを平時から決めることです。

インシデントコミュニケーションで重要なのは、正解がそろってから話すことではありません。PagerDuty は、初報からさらに 5 分以内に影響範囲の初期スコープを出し、その後 2 時間は少なくとも 20 分ごとに更新すると示しています。完璧さより、追い続けていることを見せるわけです。

その通りです。Atlassian の Statuspage tips でも、まず早く認知を伝え、状況が続く間は 30 分ごとを目安に更新すると案内しています。更新内容が小さくても、次回更新時刻が書かれているだけで、問い合わせ窓口への同じ質問はかなり減ります。

次の論点は、どこを見れば最新情報が分かるかです。Atlassian は dedicated status page を主軸に置き、X 旧 Twitter やサポートポータルからもそこへ誘導しています。Datadog も、影響コンポーネントと更新タイムラインを status page に集約すると、重複チケットの洪水を防げると説明しています。

さらに重要なのが ownership です。GitLab の customer emergencies workflow では DRI がチケットを持ち続け、広範囲障害では status page と @gitlabstatus へ誘導する統一返信を使います。Intercom も地域別の status page を分け、US、EU、AU で適切な顧客へ通知を出せるようにしています。

よくある失敗は五つあります。原因確定まで黙る、次回更新時刻を書かない、status page とサポート返信が食い違う、DRI が不在、そしてベンダー障害だから自社責任ではないと振る舞うことです。顧客視点では、使えない事実の責任窓口は常に自社です。

その通りです。インシデント中の顧客心理は、怒りより先に不確実性への不安です。だから『今は調査中』『影響はこの範囲』『次は 14 時に更新』の三点があるだけで、受け止め方が大きく変わります。説明の頻度は、そのまま信頼の頻度なんですね。

明日からの実務はシンプルです。第一に、初報、経過報、復旧報、postmortem 案内の四つのテンプレートを作る。第二に、status page を単一の source of truth に据える。第三に、P1 と P2 では Comms DRI を必ず指名する。この三つで初動の質はかなり上がります。

その視点は重要です。SaaSサポートのインシデントコミュニケーションは、広報文を書く仕事ではなく、顧客の意思決定コストを下げる仕事です。だから速度、整合性、ownership の三つを先に設計する。障害が起きてから考えると、必ず遅れます。