ウェブサービスの運営に必要なカスタマーサポートですが、たんなる問い合わせ対応だけが目的ではありません。カスタマーサポートには、プロダクトが持つ仮説を検証したり、ユーザーをファンにするといった重要な側面をもっています。
私はプロダクトマネージャとしてウェブサービスやモバイルアプリの開発に携わってきました。この経験を元に、カスタマーサポートとは何か、目的ややり方について書いていきます。あわせてカスタマーサクセスとの違いについても示します。
テクニカルライター。元エンジニア。共著で「現場で使えるRuby on Rails 5」を書きました。プログラミング教室を作るのが目標です。
カスタマーサポートとは
カスタマーサポートとはユーザーからの問い合わせを起点に、ユーザーが抱える問題の解決をめざすことをいいます。プロダクトに問い合わせ用の窓口を設置して、ユーザーとテキストベースでやりとりをします。
カスタマーサポートと聞くと、マニュアルをもとに機械的に対応するようなイメージがあるかもしれません。ただプロダクト開発におけるカスタマーサポートはむしろ逆で、開発者自身がユーザーと1対1で対応します。とてもコストのかかる、でも重要な役割を果たします。
カスタマーサクセスとの違い
カスタマーサポートとよく似たものとしてカスタマーサクセスがあります。似ていますが、このふたつは明確に異なります。
カスタマーサクセスは、「ユーザーの成功」を目的として、プロダクト側から能動的に実施します。たとえばユーザーが迷わないようなチュートリアルを提示したり、ビデオ通話でトレーニングをしたりします。
一方のカスタマーサポートはユーザーからの問い合わせを起点として、受動的にユーザーの問題を解決するための対応をします。たとえばプロダクトの操作に関する質問やバグ報告などがあります。
カスタマーサポートの目的
カスタマーサポートは、実際にユーザーの声を聞くことで次の2つを達成することを目的とします。
- プロダクトの仮説を検証すること
- ユーザーをファンにすること
1. プロダクトの仮説を検証する
プロダクトの開発初期は、不確実な仮説がたくさんあります。この仮説をひとつひとつなくしていくために、機能をリリースして検証するプロセスをすばやく、たくさん回す必要があります。このためには、ユーザーの声を直接聞けるカスタマーサポートの存在が欠かせません。
プロダクトを積極的に使ってくれるアーリーアダプターに対し、カスタマーサポートをとおして密なコミュニケーションを取ることで、やりとりをしながら仮説検証を行うことができるのです。
2. ユーザーをファンにする
また、このような開発者自身とのコミュニケーションは、問い合わせたユーザーがプロダクトのファンになってくれる可能性が高まります。
プロダクトがProduct Market Fitをめざす上で、プロダクトにたくさんの貴重な意見をあげてくれるファンの存在はとても重要です。いい意見をくれるだけでなく、口コミでほかのユーザーを連れてきてくれることもあります。
カスタマーサクセスではダメなのか
前章で「カスタマーサクセスは能動的にユーザーのために取り組む」と書きました。受動的に行うカスタマーサポートよりもよさそうに聞こえます。もちろんカスタマーサクセスも重要ですが、これはプロダクトのステージによって重要度が異なります。
カスタマーサクセスの目的はプロダクトのグロースです。PMFを達成した後に力を入れると効果を発揮します。ただ、まだPMFを達成していないプロダクトの場合は仮説検証がより重要になります。このステージではカスタマーサポートに集中すべきだといえます。
カスタマーサポートのやりかた
以上でカスタマーサポートの重要性について書きました。次にカスタマーサポートのやりかたについて、次の4つの項目で書いていきます。
- 窓口はどうするか
- 誰が対応するか
- どう対応するか
- いつ対応するか
1. 窓口はどうするか
問い合わせの窓口ですが、開発者自身と1対1でやりとりできる手段を用意します。一般的なのは、ウェブサイトの画面右下にあるチャットの窓口です。これはIntercomやチャネルトークなどが代表的です。
個人開発でコストをあまりかけられないのであれば、Googleフォームや開発者のTwitterへの導線を置くのもよいでしょう。
2. 誰が対応するか
ユーザーからの問い合わせは、PMFを達成するまではサポート専任のメンバーは置かず開発者自身が行うべきです。開発者は仮説検証の知識をもっていますし、なによりプロダクトをつくるプロセスを見ることでユーザーにファンになってもらえる可能性が高まります。
3. どう対応するか
問い合わせには、たとえば次のような問い合わせがきます。
- ◯◯◯が使いづらい
- ◯◯◯のような機能がほしい
- ◯◯◯するにはどうすればいいか
こういった内容への返信例を示します。どんな返信にも共通するのは、相手に返信を要求しないことです。つまり読み切りで大丈夫なように返信します。
- 感謝、あるいは謝罪を伝える
- どう対応するか、あるいは対応しないかをひとことで伝える
- 問題の背景を伝える
- 対応の詳細を伝える
- （必要であれば）問題の背景を聞く
また、もしユーザーがプロダクトを積極的に利用していて、かつ熱量が高ければ、ビデオ通話などによるユーザーインタビューを打診します。PMFをめざす段階では、このようなユーザーの存在はとても貴重です。いいフィードバックをもらえたり、ほかのユーザーを連れてきてくれるかもしれません。
4. いつ対応するか
問い合わせへの返信は、可能な限りはやく回答します。ただし、「確認します」といった無意味な一次回答はユーザーにとって迷惑になります。調査に時間を要する場合のみ一次回答を行い、基本的には「3. どう対応するか」の内容をすばやく行えるようにします。
注意点
カスタマーサポートで注意すべきこととして、ユーザーからの要望を直接実装してはいけません。「プロダクトに機能を追加するかどうかを判断する方法」でも書きましたが、以下のとおりユーザーの課題をもとにゼロベースでアイデアを検討する必要があります。
アイデアの中にあるユーザーの本質的な課題を抽出して、解決しないとプロダクトが成り立たない、あるいは解決すべき課題にのみ焦点をあてます。重要度の高い課題についてゼロベースで解決策を考えることで、シンプルな機能をユーザーにストレートに提供することができます。
いつカスタマーサポートをやるか
カスタマーサポートは、MVPの検証が終わって実際のプロダクトをつくりはじめたらすぐにやるべきです。また、開発者自身が対応するのも、すくなくともPMFを達成するまではやるべきです。
PMFを達成しさえすれば、あとはカスタマーサポートチームをつくったり、グロースのためのカスタマーサクセスチームの構築に移行するとよいでしょう。
まとめ
PMFをめざす段階では、カスタマーサポートは仮説の検証やユーザーをファンにするという面でとても重要な役割を果たします。問い合わせの窓口を設置して、開発者自身が真摯に対応します。ここでファンになってくれたユーザーは、プロダクトを成長させるための大きな力になってくれます。
