カスタマーサクセスに最も近いところにいるのがエンジニアだよ ~つよつよSaaSエンジニアへの道~

つよつよSaaSエンジニアへの道のエントリー第2弾です。

SaaSに関わっている人がカスタマーサクセスに関わらなくていいはずがない

カスタマーサクセス（という概念）はカスタマーサクセス（という職種）だけのものじゃないよ、と声を大にして言いたい。

カスタマーサクセスは概念であって、SaaSに関わるメンバーは全員持っておくべきものだと思っています。継続的に利用してもらう事が重要なサブスクリプションのビジネスモデルでは、カスタマーサクセス職は当然ですが、マーケティングもセールスもデザイナーもエンジニアもみんな備えておくべき概念です。

エンジニアはプロダクトを通してカスタマーサクセスに携わる

2019年カスタマーサクセス界隈の展望

上記のブログでも触れられていますが、カスタマーサクセスの文脈の中で多く語られるのが「プロダクトが重要」ということ。SaaSのエンジニアはカスタマーサクセスのためにプロダクト開発をしているはずなのですが、その認識がまだ充分に浸透していないのではないでしょうか。

かく言う私も受託案件をやっていたときにはそのような考え方は持っていませんでした。

エンジニアはプロダクトの改善という形で顧客の成功に貢献をしています。エンジニアはカスタマーサクセスの中の一部だという認識を持つことが重要です。

ではその意識を持つためにはどうしたらいいのでしょうか。

顧客からのメール、チャット、NPSすべてを見られる状態にする

僕たちのチームではユーザーからの問い合わせやNPSの評価の情報をSlackに集約してエンジニアも見られる状態にしています。

カスタマーサクセスのメンバーからエスカレーションされた内容が機能要望や不具合としてチケット化される時には事実や再現手順だけになることが多く、どういうシーンで困っているのか、いつまでに解決しないといけないのかといった目的が抜け落ちてしまいがちです。

やはり顧客の温度感のある生の声を聞かないと、カスタマーサクセスの概念をエンジニアが実感することは難しいです。

例えば勤怠管理システムで問い合わせがあったとしましょう。技術的な内容のためカスタマーサクセスからエンジニアチームへ調査依頼があったケースです。

ユーザーは勤怠管理システムの情報を元にアルバイト代の計算をして支払いをしている。アルバイト代は25日締め月末払いになっている。25日に問い合わせが来た。

このような問い合わせがあったとき、いつまでに問題解決しないといけないでしょうか。

月末までにはすべての問題が解決し、滞りなくアルバイト代を支払うというのが顧客が求めているゴールです。たとえ問題が解決したとしても、翌月に持ち越してしまっていたら、意味がなくなってしまうのです。

このような温度感を肌で感じるためにはエンジニアが直接サポートをするのが一番です。それができない場合には調査を通じてサポートにたずさわる、技術的なものに関しては回答文を作成するなどして関わっていくことでプロダクトの先にいるユーザーのことを意識できるようになっていくと思います。

以下のスライドでもエンジニアがカスタマーサクセスを行う事例が紹介されています。

問い合わせや評価を自分ごと化する

僕たちのチームでもチャットサポートを導入した当初は、問い合わせの量が予測できなかったため全てのメンバーで分担して対応をしていました。

直接ユーザーとやりとりすることによって、顧客の成功のためにプロダクトを作っていることを意識できるようになりました。

今でこそカスタマーサクセスのメンバーがフロントに立って対応してくれるため直接やりとりすることはなくなりましたが、カスタマーサクセスとエンジニアの間で「こういう問い合わせがあったんだけど」ではなく、「あの問い合わせの件だけど」と共通認識があった上で話が進められるのはその後の対応スピードにもつながっていると思います。

顧客からのメール、チャット、NPSの情報にアクセスできる状態にするだけでは不完全であり、エンジニアが自分ごととして捉える文化を作ることが大事です。