開発者自身がユーザサポートを1年半即レス対応する中で気をつけていること・取り組んでいること・メリット

boardをリリースしてから約1年半、問い合わせは全て自分で対応してきました。

基本的には在席していれば即レスするようにしていて、初回回答時間の中央値を公開しています。（12月は6分！）

この即レス対応はユーザの方からはかなり好評で、また自分にとっても非常にメリットがありましたので、この取り組みで気をつけていることやそのメリットを紹介したいと思います。

なお、問い合わせの仕組みは、intercom.ioというサービスを使っています。
intercomは、問い合わせフォームというよりは、チャットをイメージして頂いた方が近いです。

まずは気をつけていること・取り組んでいることから。

安易な一次回答はしない

数字の力は強いですよね。

「初回回答時間○分」という数字を公開していると、この数字のために動いたり、これを少しでも短くしようという心理が働いてしまいがちです。
ユーザサポートの結果であるべきなのに、それが目的化してしまうというか。

例えば、一次回答として、「確認します」や「お問い合わせありがとうございます。」などの一言をすぐに返してしまいがちです。

もちろん、「お問い合わせ拝見しました」ということは伝わるのでそれはそれでメリットがあると思いますが、「初回回答○分」と公開している以上、上記のような一言は初回回答とは言わないですし、実態とずれている数字を公開してアピールするのは個人的にすごく嫌いだったりします。
＊公開している初回回答の時間は問い合わせ管理で使っているintercom.ioというサービスで計測してくれるのですが、最初に回答したものまでの時間なので、一言でも返せば初回回答になってしまうため。

そのため、「質問に対しては、初回の回答の1回で済むことを目指して、スクリーンショットなどをつけて丁寧に回答する」ようにしています。

問い合わせの返信は画面上に表示されるので、ユーザさんにとっても、一回で回答が返ってきた方が業務の邪魔にならないと思いますし。

もちろん全てがそうなりませんが、過去のやり取りを振り返ると、
質問→回答→「わかりました。ありがとうございます。」
と3回のやり取りで終わるパターンが多く、問い合わせ対応としても手離れがよく、すぐに他の仕事に戻れます。

掛け持ちでサポートをやっている場合、手離れの良さは非常に重要なポイントだと思います。

ちなみに、操作を文字で説明するは難しいことが多いので、データが整っているデモアカウントは常に用意しておき、スクリーンショットを撮って、そこにコメントを入れて、それを説明とともに送る、ということをよくやっています。 

打ち合わせ中や移動中は回答しない

一人でユーザサポートをやっていると、当然回答できないタイミングがあります。

私の場合、board以外にも、受託の営業やプロマネなどの仕事もしているため、半分以上はboard以外の仕事をしています。
例えば、社内で打ち合わせしている時や移動中などは、何かクリティカルな障害でもなければ、基本的に対応しないようにしています。

これは、「継続可能なペースでやる」というポリシーのもと、このようにしています。
無理してやると続けるのがきつくなりますからね。

ヘルプやFAQを充実させる 

リリース当初はヘルプすらなかったのですが、可能な限り細かい機能を含め整備し、また問い合わせがあったものを随時FAQに反映していくなど、ヘルプ・FAQを充実させる取り組みをしてきました。（現在ヘルプ・FAQで200記事を超えてました）

そして、お問い合わせの回答の際、「簡単な説明＋詳しくはヘルプをご覧ください」という形で回答するようにしてします。

ヘルプは、スクリーンショット付きで丁寧に解説しているので、そちらの方がわかりやすいためそのようにしているのですが、ヘルプの存在に気づいていない方もいるため、毎回そのように回答していたら、「ヘルプを見たけどなかったので質問させてください」みたいな形で、ヘルプを見てから問い合わせしてくれる方がかなり増えた印象です。

実際、アカウント数・アクティブユーザ数・PV数も増え続けているのですが、問い合わせ件数は、直近3ヶ月はピーク時から半分程度になりました。

要望はその背景をヒアリングする 

多くのご要望を頂くのですが、弊社では発生しない業務で詳しくわからない場合や、こちらが全く想定していなかったような要望、背景にある業務が見えないような要望を頂くことも多くあります。

もちろんすべてを対応することはできませんが、わからないものは詳しくヒアリングしてその要望の背景にある業務を理解するように務めています。その結果、必要性を理解して実装することにしたものもあります。
また、実装するタイミングで、再度こちらから連絡して、詳しく確認するケースもあります。

こうすることで、弊社ではやっていない業務でも、実態とかけ離れた使い勝手になってしまわないように気をつけています。

次にメリットです。

ユーザとの距離感が縮まる（気がする） 

こちらの勝手な思い込みかもしれませんが・・・。

即レス対応していると、ユーザさんとの距離感が縮まる気がします。

面識がない人でも、気軽に問い合わせしてくれたり、意見を言ってくれたり、要望に対してディスカッションしたりしています。

これは、本当にありがたいことだなあと思います。

ユーザの反応を肌で感じることができる 

サービス開発において、非常に重要な点だと思います。

例えばサポート専任メンバーがいる場合、開発者自身は1つ1つのやり取りを見ることは少なく、定期的にサポートメンバーから共有してもらうなどで、ユーザの声や反応を把握していることが多いのではないでしょうか。

もちろんそれでもある程度は把握できると思いますが、実際に問い合わせに対応していると、肌感覚や微妙な変化を感じることができます。

その微妙な変化にはかなり注意を払っています。
例えば、問い合わせ内容の微妙な変化はユーザ層の広がり・変化だったりします。
また、リリースした機能がわかりにくかったり、業務の実態とずれていたり、反応薄かったりした場合は、何かしら課題があります。

そういうものをリアルタイムに感じて開発に反映することができます。

boardでは、開発ロードマップを公開していて、ある程度の開発予定を決めていますが、最近は特定の要望が多いということは少なくなってきたので、こういう肌で感じた変化をロードマップに反映するようにしています。

使いにくい機能をリリースしたら自分がサポート業務で大変になる 

boardは、今のところ、多くの方に「非常に使いやすい」「今まで見てきた業務システムの中で最高」などと大変評価して頂いているのですが、うちはUI/UXの専門家でもなければ、事前にユーザビリティテストをやっているわけでもないので、機能追加のたびに不安です。

ただ、使いにくい機能や業務の実態に合わない機能をリリースすると、自分のサポート業務が大変になります。
それは、すなわち自分の開発時間がなくなるということを意味します。

だから必死になりますよね。
UI/UXについて勉強もするし、何度も何度も頭の中で業務をシミュレーションしています。移動中はだいたい使い勝手のことを考えています。

そうすることで、自分自身のそういうスキルが伸びて、良い循環が生まれる気がします。

開発の方針をすぐに回答できる 

頂いた要望に対して、単に「開発チームに伝えます」ではなく、初回の回答から、「ロードマップに入っている」「開発の候補には入っていて、どの程度の位置づけになっている」など具体的な方針を回答できます。

おそらく、これはユーザさんにとっては、対応するのかしないのかわからないよりも、ずっと良いのではないかと思います。

もっとも、「対応しない」「対応する可能性は低い」ことも素直に伝えているので、それが6分で回答返ってきたらちょっと嫌ですよね・・・。

boardの問い合わせ対応を全て私がやっているのは、単純にリソースの問題という点もあり、現実的には、サービスの成長とともに、全てを開発者自身が回答するということは難しいと思います。
ただ、一部でもいいので、開発者が実際に問い合わせ対応してみると、学ぶことが多いと思うのでオススメです。

こういうブログを書いておきながらあれですが、4月からサポートメンバーが一人入る予定です。

現時点ではまだ一人で対応できていますが、今後さらにユーザ数が増えた場合、さすがに一人でやっていると限界があるので、数年後を見据えて、今から準備をしていこうと思います。

ただ、企画者・開発者自身がユーザサポートをやることのメリットは本当に大きいと思っているので、要望系は引き続き私が問い合わせ対応しますし、もう一名が入った状態で、また新しい形のユーザサポートを見つけたいと思います。