原因が分からなくても先に伝える、サービス障害のお客様向け告知5段階

まず顧客が知るべき四つのこと

決済画面でエラーが続くと、顧客がまず知りたいのは何ができないか、注文は残っているか、次にいつ案内されるかです。初報は原因報告書ではありません。確認済みの影響、まだ不明な点、今できること、次回の案内時刻を短く示します。復旧時刻が不明でも、この四点は伝えられます。本文の決済と注文はすべて架空の例であり、オフィシャルメールで実際に発生した障害ではありません。

初報から復旧確認までの流れ

顧客が見たエラーから影響を確認し、初報を出し、次回の案内時刻を守り、最後に実際の操作で復旧を検証する流れです。

1. エラーコードより顧客が止まった操作を書く

管理画面の500エラーだけでは、顧客は注文の状態を判断できません。「一部の顧客が決済を完了できません」のように止まった操作を書きます。範囲が未確認なら「全顧客」に広げず、確認済みの影響を「一時的な不便」と小さく見せないでください。次は架空の文例です。

実際の告知では観察した範囲と時刻に置き換えてください。

2. 初報では五つの欄を埋める

長い謝罪より必要な情報を先に示します。1）影響を受ける機能、2）顧客に見える現象、3）確認済みの事実と調査中の点、4）安全な行動と避けるべき再試行、5）次の案内の時刻と場所を記載します。注文が受け付けられ、完了画面だけ失敗した可能性があるなら、再決済を促すと二重決済の危険があります。注文状態が分かる前に再試行を勧めず、問い合わせ先を示します。

これは架空の文例です。実際の範囲、連絡先、更新時刻に置き換えてください。

3. 次回案内の時刻は復旧の約束ではない

「午後3時に再度案内」は、その時刻までに復旧する約束ではありません。未解決でも確認したこと、影響の変化、次の案内時刻を守って伝えます。一人で運営する場合は状況に応じて30分や1時間など守れる間隔にします。新事実がなくても「影響範囲は変わらず、調査を継続中」と更新できます。現場対応者と告知担当者は同じ事実一覧を見るべきです。ステータス画面、メール、SNSを併用する場合は公式告知一か所を基準とし、チャネル間で「復旧」と「調査中」が食い違わないようにします。

4. 顧客の操作を確認してから復旧を知らせる

エラー通知が消えただけで正常化を宣言しないでください。顧客が失敗した操作を再実行します。決済なら承認済みの試験手順で注文受付、完了画面、通知、記録反映を順に確認します。実際の金額や顧客データが必要な場合は許可された環境と手順を使います。復旧案内には影響した機能、正常動作を確認した時刻、残る対応、連絡先を記します。原因が未確定なら分析継続と別に書きます。機能の復旧と原因の確定は別の状態です。

5. 次に備えて告知と検証の記録を残す

最初の報告、影響確認、初報、約束した更新、復旧検証の時刻をまとめて残します。責任逃れではなく、次回の顧客の待ち時間を減らす記録です。初報が遅れたなら、技術原因とは別に告知権限、範囲が未確定だと話せない思い込み、公式送信アドレスと状況記録の準備を確認します。通常の問い合わせと緊急連絡が受信箱で混ざらないよう、顧客への返信時間を前もって決める基準も用意できます。

先に保存しておく初報のひな形

未確認の欄があっても初報を無期限に延ばさず、推測せず調査中と書きます。公開前に角括弧を実際の事実に置き換えてください。

よくある質問

原因が分からなくても告知できますか？

顧客への影響が確認されていれば、原因や復旧時刻が不明でも、現象、確認済みの範囲、次回案内時刻を伝えられます。

全顧客にメールを送るべきですか？

影響範囲と顧客が取る必要のある行動で判断します。公開ステータスと影響顧客向けメールの役割を分け、内容を一致させます。

復旧後も原因が未確定なら？

正常動作を確認した結果と原因調査の状態を分けて知らせます。推測を確定事実として書かないでください。