ヴェルク - IT起業の記録

受託開発と自社サービスの両立への取り組み

初めてのカスタマーサポートからサポートが評価されるまで:小さな会社のSaaSの育て方(第4回)

小さな会社のSaaSの育て方」と題して、boardの10年を振り返っていく企画の第4回目です。

今回は「カスタマーサポート」について書いていきたいと思います。

初めてのカスタマーサポート

ずっと受託畑でしたので、SaaSのサポートは未経験でした。そもそも自分で何かしらのWebサービスに問い合わせをしたことがあったかな?というくらい、いちユーザーとしてもほとんど縁がない状態でした。

そのため、「SaaSのサポートというのはこういうもの」という事前知識がまったくなく、手探りの状態からスタートしました。

最初は、とりあえずサポート用のメールアドレスを用意して公開していただけで、感覚としてはコーポレートサイトのお問い合わせに近いものでした。

Intercom導入とチャットサポート

ベータ版を公開した直後、知り合いから「メールで問い合わせするのは面倒だから、これ導入して」と教えてもらったのが、当時日本ではまだ珍しかったIntercomでした。

すぐにIntercomを導入を決定し、ベータ版公開の1週間後には切り替えました。理由は「よくわからないけど、なんか良さそう」くらいでした。何も考えてない。

IntercomのUIは「チャット」なんですよね。

SaaSのサポートとはどういうものかまったく分からない状態でチャットサポートを導入した結果、自分自身に「チャットだから早く回答しないと」というプレッシャーがすさまじくのしかかりました。やはりチャットというUIには、リアルタイム性の高さを感じさせる印象があります。

当時はフルタイムで受託をしていましたが、打ち合わせ中以外はboardの問い合わせがあれば、他の手を止めて対応を最優先にしていました。

小さな無名の会社のサービスなので、お試し登録をしてくれる方がたくさんいるわけではありません。その会社の業務に合わないのであれば仕方ないですが、フィットするはずなのに、サポートがイマイチで機会を失うのは避けたかったんです。数少ないチャンスですから、本当に最優先で対応していました。

その結果、「boardのサポートが即レスですごい」と話題にしてくださる方が現れ、それをきっかけにboardを知ってくださった方もいました。また、他のSaaSの方から連絡をいただき、「どういう感じでやっているのか」などをお話しする機会もあり、初期のころ、思いがけずboardを知ってもらうきっかけになっていました。

また、Intercomで回答時間の中央値の集計ができるようになってすぐ、サポートの回答時間の中央値を公開するようにしました。これは即レスサポートをアピールする狙いではなく、「電話サポートでないといつ返事が返ってくるかわからない」と度々言われたので、「すぐ返信してます」ということを証拠として示すために始めたものでした。

ちなみに、最初の公開は2015年3月だったようです。ちょうど10年前ですね。

ざっと見る限り、2016年3月の中央値が最短のようなのですが、「5分」っておかしいですね……。しかも基本的には一次回答せず、1回の返信で完結させていました。

サポートの実績報告(2016年3月) - board

 

当時のboardは今よりずっとシンプルでしたし、ヘルプもまだまだ少なかったので、質問内容も今と比べてシンプルなものが多かったと思います。

コードの隅から隅まで把握していて、仕様を考え、経営者でバックオフィスも担当し、ある程度会計も分かる自分が回答していたので、回答のクオリティーもちゃんとしていたはずです。それが即レスで返ってくるので、かなり驚かれたようです。

要するに、boardの即レスサポートは、「チャットUIだから早く返さないと」というプレッシャーを、自分自身が勝手に感じていたことによって生まれたものでした・・・。

※ちなみに、回答時間の中央値の公開は今でも続けています。現在はCSチーム内で別のメンバーによるレビューを経て回答することも多く、スピードより質を重視しているため、中央値は25分前後が多いです。

受託のお客さんへの対応との違い

ずっと受託をやってきた自分がSaaSのサポート対応をする中で、「どこまで踏み込んでやり取りするか」というのは、とても悩んだ部分でした。

受託の仕事では、お客さん側の状況をがっつり把握した上で進めていきます。

ただ、月額1,980円のサービスでそこまで踏み込んで時間をかけることはできませんし、かといって、表面的な対応はしたくないという思いもありました。

試行錯誤の結果、表面的・形式的な対応よりも少し踏み込んだ、とはいえ一定の線を引いたバランスの取れた対応ができるようになってきました。

そんなかたちで約4年間、1人でサポート対応を続けた結果、boardとしてのサポートスタイルができあがりました。

CSチームの立ち上げ

4年間ほどサポートを1人で続けていたのですが、そのころの有料導入社数は1,000社ほどでした。それだけの数に使ってもらっている状態にも関わらず、まだ1人でサポート対応をしていて、しかもboardの開発も受託もやっていたので、まあまあ死にそうでした。若かったからできましたね・・・。

そのため、CSメンバーの採用は急務だったのですが、なかなか採用がうまくいかず、採用できてもフィットしないという状態で、かなり絶望的な状況でした。

そんな様子を見かねた @voluntas がいい人を紹介してくれ、ようやく2人体制になり、本格的に「CSチーム」が立ち上がりました。

その後はブログやTwitter経由で採用ができ、現在は自分を除いて4人体制になっています。

CSチームがboardの思想を理解する

もともと自分が1人で対応していたものを他のメンバーに引き継いでいく過程も、なかなか大変でした。

即座に同じクオリティーや速度を求めることはできませんが、明らかな品質低下があれば、ユーザーさんの期待を裏切ることになります。

そのため、1人で対応していたとき以上に、自分の時間をサポート関連に割くようになりました。

現在はCSメンバー間でレビューをしていますが、最初の2人目までは基本的に僕がすべてレビューしていました。

その際、回答の正確さはもちろんですが、レビューを通じて、boardの設計思想やスタンスを繰り返し伝えていきました。

僕のサポートに対する考え方として、単に仕様や手順を説明するだけではなく、「きちんと理解して使ってもらう」ことをとても大事にしています。「そんなのはいいから手順だけ簡潔に回答してほしい」と言われることも稀にありますが、それをしてしまうとうまく使えず、業務効率化の効果が限定的になってしまいますし、うちとしても将来的なサポートコストもかかり続けることになります。

そのため、サポートチームがboardの設計思想や意図を理解した上で対応できることは非常に重要だと考えていました。

また、レビュー以外にも、サポート時間終了後に「振り返り」の時間を設けて、いくつかピックアップして解説し、CSチームにboardを理解してもらう、boardのサポートとして適切な対応を伝えるという取り組みを継続していました。

CSチームの人数が増えてきた後は、自分が直接それを行うのではなく、CSチーム内で伝えていくかたちになり、僕は毎日の問い合わせに目を通して、気になったものだけにフィードバックするようになりました。

振り返っての考察

boardのサポートを評価していただくことがたびたびありますが、まったく知識・経験がない状態から「たたき上げ」スタイルでできあがったものです。

おそらく、最初にIntercomを導入していなかったらこのスタイルにはならなかったと思いますし、受託の経験があったからこそ、なるべく踏み込んだ対応を模索していたのだと思います。

当時、「カスタマーサクセス」という言葉が流行り始めたころでしたが、boardのサポートは完全に受け身のカスタマーサポートです。

今でこそ「これでいい」と思っていますが、最初のころは、SaaS界隈のカスタマーサクセスの流れを見て、どうすべきか相当悩んだ時期がありました。

ただ、本質的に「長く・効果的に使ってもらうための対応」が大事なのであって、受け身のスタイルでもそれは十分に実現できる、ということに気づきました。

自分自身、おそらくSaaSの社長としては珍しいほどサポート対応をしてきたと思っています。そして、サポートチームを作り上げるのにも、相当な時間をかけてきました。

後付けの解釈ですが、知名度も資金力もない会社が戦う方法は、「サービスとサポートの質」なんですよね。

「サポートに力を入れる」と口で言うのは簡単ですが、サポートに全力で取り組んだ結果、サービスの評価を上げる非常に強い武器になったと感じています。