カスタマーサクセスロールの標準化 Part 2の前に、つい最近私が経験した出来事から一つBlogを書こうと思います。

テクニカル系のカスタマーサクセスにとって避けられないのは、重大障害対応。重大障害とは、システムがストップして運用できなくなるなどの障害で、一言で言うと大変です。

他のロールの人からは、カスタマーサクセスをやっている人は重大障害対応ばっかりで大変だからやりたくない。とか本当に大変ねぇ。とか言われたりします。

実際に私も何年かカスタマーサクセスをやっていると、そういう場面に何度も出会い、その度に辛いなぁと思います。

ただ、そこには重大障害対応でお客様がが学んだことが次の第一歩になると思っているのです。

最近の事例を紹介します。戻る事2023年8月2日。お客様から切羽詰まった感じで「システムダウンが起こっています。なんとかしてください」と連絡があったのが事の始まりでした。調べてみると、他の環境や他のお客様はどこもダウンしていない、そのお客様の環境だけがどうやらダウンしているようでした。そこから調査を行い、解決したのが9/1。調査に1ヶ月間かかりました。

と言うのは、お客様環境が複雑で、ソリューションが複数、その間にインターネット通信、VPNで繋げていてどこが問題か特定するのが非常に困難だったからです。お客様からは、なんでこんなに時間がかかるのか？なんでたらい回しになるのか？御社の製品はもう使えない契約やめるぞ、まで言われました。

このような時によくやる対策として、調査人員を増やす、問題の解決に向けてサポートチケットが早く解決するためにエスカレーションをする人員を手配する、エグゼクティブまでエスカレーションをするなどと言う方法があり、今回は全部の対策をしました。

ですが、ちょっと待ってください。これはベンダー側の問題でしょうか？このようなお客様(ほとんどそうなのですが）責任がベンダー側にあると主張して、さらには賠償問題だとお話しになります。ただお客様のシステム構成はお客様が把握するものですし、複数のソリューションがある場合の問題の切り分けはお客様です。サポートチケットでは、一つ一つの問題を解決するのがミッションなので、複数あるソリューションの問題切り分けは行いません。チケットをみるとSLA(サービスレベルアグリーメント）には問題なく動いていました。

重大障害対応中も、サポートはこう動くものだ。お客様がオーナーシップをとる、お客様側で切り分けやログ調査などをする、さらにクラウド製品は100%のSLAではないので、あらかじめそれを踏まえて設計をする。などをお伝えしていきました。調査結果が出たのが8/30。結果は我々の製品は問題なく、それをお客様にお伝えすることができたのが9/1です。

100%の保証がないという事を理解いただき、お客様の方で対応する事になり、お客様からクローズして下さいと言われました。ほっとしました、大騒ぎしてすみませんと。

大騒ぎした後にお客様が学んでいただいたことは大きかったと思います。サポートはこう動くものだ。お客様がオーナーシップをとる、お客様側で切り分けやログ調査などをする、さらにクラウド製品は100%のSLAではないので、あらかじめそれを踏まえて設計をする。お客様の重役レベルまで上がっていたので、そちらもご理解いただけたと思います。

これからはこのような重大障害が起こった場合も想定して、体制と教育を提案する予定です。でも今後はまずお客様で考えて行動をとっていただけるものだと思います。

もし自社製品側の問題だった場合、解約はできるのでしょうか？ERPの場合契約期間が長くて3~5年です。この間は解約ができません。また実装期間がとても長く(日本の場合は特に）今回障害があったお客様も5年という長い実装期間を経ていますので、費用も莫大にかかっています。簡単にやめられないですよね。なのでクラウドの特性を理解して合わせていく方が長期間を考えるとそちらの方がいいんです。

このような場合多く聞かれるのは、他社はどうなっているのか？自分たちだけがおかしいのだろうか？他社はどんなサポート体制なのだろうか？

お客様事例は今後のBlogでお書きしたいと思います。お楽しみに。

customer success