CSとQA

最近はカスタマーサクセスが主流っぽいが、僕が今回書くのはカスタマーサポートとQAの話。

これまた、とあるベンチャー企業で働いていたときの話。

自前で開発した、ECサイトのQAを担当していた。
ある程度、ユーザーが増えてくると、ユーザーからの問い合わせも比例して増える。

FAQなども用意していたが、必要最小限の内容。

ある日、休憩しているとき、CSの人と何気なく雑談。
話を聞くと、問い合わせを管理するToolを導入したが、そもそもの件数が多すぎて大変だ！っと。

どれくらい大変かというと、どんなに頑張っても返信に5日近くかかっている状態。
土日き来た問い合わせの返信が、良くて木金くらいになるということ。

他部署からのヘルプや、そもそも増員すべき採用活動も動いているらしいが、完全に後手になっている。

そこで、僕は問い合わせ内容を閲覧出来るようにしてもらい、勝手に問い合わせ内容の分析をしてみることにした。

CSメンバーは多忙なので、みんなのヒアリングの前に、まずは自分なりにどんな問い合わせが多いのかを把握し、コミュニケーションを円滑にする必要もあった。

問い合わせ内容をスプレッドシートにして、まずはラベリング。
正直、読んでもよくわからない内容はあったが、ひとまずそれらはスキップ。

目的は、問い合わせで、特に多いものの中から、ユーザーが自己解決出来るようなものが無いかを探す旅。

とにかく膨大な量あったので、ほぼ流し読み。
2ヶ月分くらいの問い合わせにざっとラベリングし、今度はラベリングが多い順にフォーカスしてまた見ていく。

最終的なアクションとしては、
問い合わせ件数現象に効果がありそうな要件をまとめる。
まとめた要件の中で、システム開発が軽微ですむものをピックアップ。
プックアップした要件をCSメンバーに説明し、本当に効果が出そうかをヒアリング。
ここで、微調整し、開発バックログに積み、隙間にねじ込んでもらうよう調整。
QAして、リリース。

こんな感じ。

規模の大きくない会社ということもあり、CSのリードが要件を作成する時間も無かったことや、そもそも開発要件を作成するということを経験したことなかったため、僕が首を突っ込めたというのはある。

ユーザーが日々増えていく中、2、3ヶ月かけて、問い合わせ件数は徐々に減り、問い合わせが来た当日か、遅くとも次営業日には返信が出来るくらいになった。

なぜ、僕がこんな余計なことをしたのか？

僕に求められる役割に無いし、そもそもそういった改善をした経験があったわけでもない。
「よかれと思って」
で起こした行動は、実は全然良くないケースがほとんどだ。

でも、僕は行動した。

なんで？

正直あまり覚えてないが、たぶん

• シンプルに仲間が大変だったから力になりたい

• ユーザーにもっと、サービスを満喫して欲しい

そんな想いから、行動に移したような気がする。

結果的には、問い合わせ内容から、改善につながる要件作成までの簡単なフローを確立したし、問い合わせも減り、本当に寄り添って対応すべき問い合わせに時間を使えるようになった。

僕が勝手に行った余計なことは、結果オーライ。

ちなみに、僕の中で学びも多かった。
問い合わせをひらすら読み、要件を考えていく中で、以下のことを学んだ

•  購入後、ユーザーがどのような部分で問い合わせしてくるのかのリアルをしれた

• 問い合わせ対応する際、対応に時間がかかるものと、そうでないものを明確に理解できた

• 機械的に返信して良い問い合わせと、親身になって対応すべき問い合わせを理解できた

• ユーザーが実際にミスしやすいポイントが問い合わせから多くのパターンを理解できることを実体験として知った

• 改善要件を考える中で、CVに影響が出るかどうかの視点は必ず持つようにした（バランス大事）

これは、QAだけをやっていたら、学べなかったこと。

要件通り動くからOK
仕様通り動くからOK
影響範囲を加味して動作確認したからOK
ユーザーを想定したシナリオテストを通して問題ないからOK

これらでは発見出来ないことを多く学んだ。

CSには、プロダクトの成長に欠かせない情報が山のように眠っている気がする。
QAする上でも、ユーザーのリアルな声は、何よりリアルな期待結果につながる。
CSとQA。
お互い持っている情報とスキルは、お互いの業務を高め合える存在なんじゃないか。
そんなことを気づかせてくれた大事な思い出。

この経験と、考え方は、僕の現在のQAに間違いなく活きている。