日本でも、「カスタマーサクセス」という名を冠する組織を持つ会社が増えてきました。
カスタマーサクセスの世界では、
障害とかクレーム対応みたいな、後ろ向きな業務が語られることは少ないです。
でも、実際のところ障害は起きます。
（実際に、私が知る限りこの2年で2回はAWSで大きな障害が起きています。）
もちろん、自社起因でも障害は起きます。
SaaSの障害は基本的に全顧客に影響します。
なので、障害が起きると、カスタマーサクセス部隊はその対応に追われます。
しかも、現状日本のカスタマーサクセスはマーケや営業出身者（しかも若い人）が多く、障害対応にあまり慣れていないことも多い。
なのに、カスタマーサクセスのイベントや本で障害対応が語られることは少ない気がする。
そこで、以下では、「カスタマーサクセスの障害対応」について、
対応ステップとtipsの基本的な整理を試みたいと思います。（サポート領域も含めての話をします）
<目次>
障害対応の基本的なステップ
大枠のステップは、以下の通りです。
-
Step1.現状把握
-
Step2.第一報
-
Step3.復旧報告・事後対応
順に解説していきます。
Step1.現状把握
現状把握で押さえるべきポイントは以下です。
-
事象の概要
-
顧客影響の有無
-
復旧の目処
-
代替策・回避策の有無
-
対応体制
-
（必要に応じて）次回Mtgの日時設定
順に補足していきます。
事象の概要
まず、何が起きているかの概要を把握します。
「XX機能が使えない」とか「ログインできない」とか「表示が遅い」とか。
顧客影響の有無
次に、その事象は顧客にどのような影響があるのかを確認します。
「そもそも顧客に影響あるのか」はもちろんですが、具体的にどういったシステム上・ビジネス上の影響があるのかを確認します。
復旧の目処
その上で、復旧の目処を確認します。
30分程度で復旧するなら、いったん対応を焦ることはないかもしれません。
「わからない」なら、変にエンジニアを拘束せずに、他の項目の確認に移った方が得策かもしれません。
代替策・回避策の有無
例えば、「左メニューから印刷機能は使えないけど、[ctrl]+[P]で印刷はできる」みたいな回避策があるなら、それを確認します。
顧客への影響が大きい障害の場合、ここは重要です。
究極、自分たちのプロダクトを瞬間的に捨ててでも、顧客の成功にコミットする場面です。
顧客と顧客の業務、そして製品を深く理解しているカスタマーサクセスのバリューの発揮しどころです。
対応体制
社内の対応体制を確認します。
-
営業・CS・サポートは誰が動いているのか、エンジニアは誰が動いているのか
-
今後CSは誰に連絡すべきなのか、slackはどのチャンネルで会話すべきなのか
-
開発・営業・CS・サポートそれぞれ指揮は誰がとるのか、誰に情報を集約するのか
などを確認します。
経験上、社内チャットは、障害対応用のチャンネルを新規で立ち上げちゃうのがいい気がします。
Step2.第一報
現状把握ができてら、第一報を上げます。
これは、社内にも社外にも出します。
コンセプトは「流れている血を少しでも止める」ことです。
顧客向けの一括お知らせ
顧客向けに記載すべき事項は以下の通りです。
-
今、何が起きているのか
-
分かれば原因
-
復旧の目処
-
代替策がある場合、代替策
-
次の続報のタイミングと方法
-
お詫び
-
本件に関する問い合わせ先
これらを流す意図は、以下の通りです。
-
「状況がわからない」こと自体から来る顧客のフラストレーションを止めること
-
代替策や業務スケジュールの変更を促し、顧客ビジネスへの影響を最小限にすること
-
顧客接点への必要以上の問合せを止めること
なるべくシンプルに、素早く上記を押さえた情報を出すことが求められます。
情報が揃わない場合、事象だけでもすぐにお知らせを出し、その後追記していく方針が良いと思います。
ハイタッチ顧客への個別対応
ハイタッチ顧客については、必要に応じて個別にも連絡をします。
意外と、ドタバタでこの指示が漏れるケースもあります。組織的な指示がないと、CSMによって対応がバラついてしまう。
すぐに行動に移れるよう、常にCSMごとの顧客リストをしっかり管理しておきたいところです。
社内向けのアナウンス
社内向けも、内容は顧客向けアナウンスと大枠は一緒です。
ただし、必要に応じて、以下を追加で記載すると良いと思います。
-
社内の対応体制とエスカレ先
-
（顧客からの問合せが多い場合）謝るしかない部分と、エスカレして欲しい部分など、簡単な顧客対応の指示
-
サポートや営業以外に問い合わせが来たときの対応指示（大規模障害でサポートがキャパオーバーするケースでは、溢れた問い合わせが代表電話等に流れるので、代表電話に対応する管理部の人など関連部署に共有必要です）
その他、必要に応じて、社長などの経営陣への報告を別途行う必要があることもあると思います。
これはエンジニアのトップと一緒にやった方がいい。
Step3.復旧報告・事後対応
復旧したら、復旧した旨の連絡を行います。
一括お知らせ
顧客のビジネスへの影響度に応じて
-
軽度
-
障害の一括お知らせの冒頭に「本障害はYY/MM hh:mmに解消しました。大変ご迷惑をおかけしました。」と一言足すだけ
-
中程度
-
原因と再発防止策をセットで丁寧に上げる
-
重度
-
中程度の記載に加えて、補償についても触れる
といったイメージになろうかと思います。
中程度以上の場合、
再発防止策については顧客が納得するレベルで中身・文章共に練る必要がありますので、復旧の第一報と本格的な障害報告は分ける必要があるかと思います。
SaaSで日常的に起こる障害の多くは、軽度で済んでいると思います。
ハイタッチ顧客への対応
これは、もう個別対応です。
菓子折持っていくこともあると思いますし、個別に補償問題になることもあると思います。
放っておいて、契約更新時期に「あの障害の時、一言電話もくれなかったね」とか言われないように、リストチェックはしておいた方がいいと思います。
社内へのお知らせ
これは簡単でいいと思います。
関連部署への対応のお礼をつけると丁寧かと思います。
再発防止と振り返り
ひと段落したら、再発防止を検討します。
と言っても、技術的な再発防止はエンジニアの仕事になると思います。
カスタマーサクセスとしては、障害そのものというよりも、発生後の対応によって顧客に迷惑をかけなかったか、もっとよくするにはどうしたら良いか、という観点の振り返りをしておくべきということになろうかと思います。
tips
エンジニアの邪魔をしない
障害が起きた時は、復旧が最優先です。
なので、復旧にあたるエンジニアの邪魔をしてはいけません。
他方で、CSとしても顧客に対応するために情報が必要なのも事実です。
そこで、以下のような配慮が有効かつ必要かと思います。
-
エンジニアへの連絡窓口を一本化する
-
営業・CS側だけでなくて、エンジニア側のカウンターパートを決めておくことが大切（大体、直接的に復旧作業には当たらないエンジニアのマネージャーがこれにあたることが多い）
-
必要以上に会議でエンジニアを拘束しない
逃げない
「プロアクティブ」を是とするカスタマーサクセスですが、
障害対応やトラブルになると急に弱気になって
顧客に対して誤魔化したり、連絡来るまで知らんぷりしようとする人がいます。
が、その態度は顧客にも同僚にも伝わります。
障害時においても、カスタマーサクセスには攻める姿勢が必要です。
ぶっちゃけ、障害発生自体はカスタマーサクセスのせいではないはず。
ここで責任感を持って攻めた対応をすれば、社内は勿論、顧客にもちゃんと伝わります。
まぁ、障害対応は辛いんでやりたくないんですけど、起きちゃったものは仕方ない。攻めたほうが後で楽。評価を上げるチャンスくらいに思うしかない。
緊急対応（止血）と再発防止を分ける
障害が起きた時、考えるべきは、今発生している顧客のビジネスへの影響を最小化することです。
社内の責任論は当然後回し。原因究明や再発防止も、後回し。
とにかく、まず流れている血を止める。
顧客が正常にサービスを使える状態に戻すことを最優先すべきです。
意外と、この区別を意識的にできない人を目にします。
これは顧客接点だけでなく、「そもそも論」好きな人が多いエンジニアの議論でもよく見られることです。
一定の原因が見えた時点で
「そもそもここの構成って...」「開発プロセスの管理として...」「コード管理の仕方が...」
とか、そもそも論の議論を始めてしまうケース、見たことないですか？
カスタマーサクセスでも、顧客に被害が出ている途中で、そもそも論に入ってしまうケースをたまに見ます。
この辺は、復旧した後でゆっくりやっていただくのが良いと思います。
二次被害を生まない
ここで言っている「二次被害」は、
障害そのものではなく、
障害に関する顧客対応起因で発生する顧客の損害やクレームです。
経験上、二次被害は
-
社内の情報共有（特に、見通し）が十分でないケース
-
顧客に対して誤魔化したり、情報を十分開示しないケース
で起こりがちです。
青臭いですが、とにかく「顧客への影響を最小限にする」を最優先にマネジメントが行動し、適切な情報開示がされていれば二次被害は生まれないと思います。
マニュアル化は無理。それよりゆるい体制と強いコミットメント
障害が起きてひと段落すると、よくあがる議論が「障害対応マニュアルを作ろう」です。
が、私は「マニュアル」と呼べるレベルのものは無理だと思っています。
障害の現象は個別であり、SaaSの組織・人も変わるからです。
仮にマニュアル作ったところで、
組織やシステムが変わってもどうせ更新なんてされません。
そうすると、最新じゃない誤った情報のマニュアルが残ることになる。
実際に障害起きた時はみんな余裕なんてないわけで、古いマニュアルを見て頭の中で更新していく余裕なんてない。苦笑
むしろ大切なのは、
-
障害が発生した時に「対応の核となる人たち」を決めておくこと
-
その人たちが「どんな状況でも責任もって対応する」という強いコミットメントを持つこと
だと思っています。
ブラックっぽく言い換えると
「『障害が起きたら、例え映画の途中でも俺（CS責任者）とお前（開発責任者）はslackに反応する』というカタイ約束」
って感じでしょうか。
一言足すなら
「だから、曜日時間帯問わず、障害が疑われる事象は遠慮なく俺にエスカレしろ。」とメンバーにも落としておくと良いと思います。
それさえあれば、大体のことはうまくいくと思っています。
障害に負けるな
「顧客の成功と自分の成功を重ねる」という素敵なコンセプトに惹かれたカスタマーサクセスにとって、障害対応は辛い仕事です。
でも、そこで障害対応から逃げちゃうと、なんとも後味の悪さが残ります。
楽しくはない、辛い仕事なのですが、ぶっちゃけ障害はどの会社に行ってもある程度起きます。
だったら、先に腹を括って攻めて取り組んだ方が、精神衛生上も良い気がします。
