boardのCSチームは、2021年1月現在で3人体制になって、基本的には僕の手から離れた状態なので、現在の体制・運用・取り組みなどをまとめてみたいと思います。
CSチームの体制
boardは、もともと僕の1人プロジェクトとしてスタートしたこともあり、当初は、自分1人で開発からサポートまでをやっていました。
ただ、当然ながらユーザ数の増加とともに問い合わせは増え、2017年ごろには、日中はほぼサポートにかかりっきりで、開発やその他経営タスクは夜か週末にやる、といった状態が続いていました。
そのため、CSメンバーの採用は会社としての最重要課題だったのですが、この時期に採用したメンバーはうまくフィットせず、結局、有料1300社くらいになるまで実質1人体制のまま来てしまい、この頃はだいぶしんどかったです・・・。
その後、2018年に知人からの紹介で1名とTwitter経由で1名、2020年頭にブログきっかけで1名の採用ができて、現在は3名体制になりました。
この3名は、得意分野がそれぞれ違ってなかなか面白いチームになりました。
1人は、とにかく過去の問い合わせなどをよく覚えていて生き字引みたいになっていたり、1人は元編集者なので文章のプロで、もう1人は10年来サポートをやってきていて、しかもテックサポートまでできたり。
現時点でも頼もしいのですが、今後もとても楽しみです。
2:1の運用
現在、有料登録社数がもうすぐ3200社といったところですが、3人フルで稼働するほどの問い合わせ量ではないので、「1人は余らせる運用」をしています。
この「1人」は毎日順番に代わるのですが、1人側の時は、朝一の問い合わせがひと段落したら、基本的には問い合わせ対応から外れて、以下のようなことをやっています。
- 他のメンバーが回答した内容を、第三者視点で「質問の解釈のズレがないか」「回答に間違いや不足がないか」などを随時チェックし、問題があればその場でフィードバック
- 他のメンバーが回答に悩んだときの相談役
- サポートの中で気づいたヘルプ・FAQの追加や改善
- 開発中の新しい機能や、最近リリースされた機能のキャッチアップ
- 業務知識の習得
「1人」の時の時間の使い方は、その時々やメンバーによって様々ですが、基本的には上記のようなことをやっていることが多いです。
なお、問い合わせが立て込んだ場合などには、問い合わせ対応に戻ることもあります。
この1人余らせる運用は、僕がとてもやりたかったことのひとつでした。
サポートは、来た問い合わせに対応していくという特性上、自分のペースで仕事をすることができません。
そのため、どうしても、目の前の問い合わせ対応に追われてしまって、じっくり考えたり、インプットしたり、時間をかけて取り組んだりする時間を安定的に確保することが難しいです。
継続的なインプットの時間が取れない状況は、長い目で見たら非常によろしくなく、また、業務知識などは、あった方が、より早く的確に質問者の意図を把握することができるので、回答の精度やスピードにも直結します。要するに、あればあるほど、より余裕を作れることになります。
そのため、サポートの品質向上や、余裕を持った運用のためには、急がば回れで、こういう取り組みを継続的に行える体制にしておくことは非常に重要と考えています。
また、そのくらいの余裕がないと、休みたいときに休めないという問題もあります。2:1の運用をしていれば、もともと1人は余らせている状態なので、他のメンバーに気を使うことなく、気軽に休むこともできます。
サポートは、どうしても、精神的にツライ時もあるし、タスク量やペースを自分でコントロールできない大変さがあるので、休みたいときにいつでも休める環境にしておくことは、CSメンバーの心身の健康のためにも非常に重要なことだと思っています。
ヘルプ・FAQ
CSメンバーの1人が、入社前はフリーランスで編集者をやっていたので、社内に編集のプロがいる状態で、かつ、なぜかこのメンバーは普通にGitを使えるので、2019年頭頃から、ヘルプはGithubで管理し、プルリクエスト（以下、プルリク）ベースで編集を通すようにしています。
この辺の話は以前下記に書きました。
基本的な運用としては、
・僕がヘルプを書いてプルリクを出す
・編集メンバーが校正
・devにマージしたらステージング環境に自動的に反映
・masterにマージしたら本番環境に自動的に反映
というかたちになっています。
プルリクの中で差分を確認できるし、反映作業は自動なので人為的なミスも防げて、非常に気に入っています。
また、Github Actionsでtextlintを動かしているので、機械的にチェックできるような表記揺れなどはここでチェックしているので、執筆時も編集時も、より本質的な部分に注力することができます。
＊上記の記事を書いたときはCircleCIでしたが、今はGithub Actionsに移行しました
現在でも、この辺の基本的な運用は変わっていないのですが、最近は、CSメンバー起点でプルリクが出ることが増えました。
＊うちのCSメンバーは、3人中2人がなぜか何も教えずに普通にGitを使ってる
サポート対応の中で、ヘルプやFAQの不備や不足、わかりにくい点に気づいたら、その時点でGithubのIssuesに上げて、前述の2:1の「1人」の時や、問い合わせが落ち着いている時などに修正してプルリクを出します。
新規のFAQも、問い合わせ対応の中でよく出てくるもの、FAQがあった方が良いと思うものも同様に、随時Issues→プルリクという流れになります。
サポート起点でヘルプやFAQが改善・追加されていくので、回答時にそのヘルプ・FAQを伝えるだけで済むケースも増えますし、中期的には、事前に見てもらうことで問い合わせの軽減にも繋がります。
また、2:1の運用によって「じっくり取り組むもの」に対して時間を使えるようにもなってきていて、その成果が、ヘルプのひとつとして昨年公開した「お問い合わせのコツ」です。
これは、CSメンバーのうちの1人が中心になって進めました。
ヘルプの検索結果
ヘルプ検索されたキーワード別に検索数を集計して、それをもとに、ヘルプ・FAQの改善・追加を検討しています。
たとえば
・よく検索されているキーワードで、かつ問い合わせが多いものは、ヘルプ・FAQが足りていない可能性を考える
・検索結果が0件のものは、ヘルプ・FAQの追加を検討したり、キーワードの調整を行う
などのように、検索結果から改善点を見つけています。
振り返り
うちの会社の定時は10時〜18時なのですが、サポート時間は17時までで、残りの1時間は、毎日「振り返り」をやっています。
ここでは、主に以下のようなことをやっています。
- 他のメンバーの回答で気になる点等のフィードバック
- その日の回答で訂正や補足が必要なものがあれば、それの議論・準備
- 僕からのフィードバックしたものに対する議論
- 編集者による日本語・文章のレビュー・改善
- CSチームとしての課題や運用改善等の議論
- 新しく入ったメンバーがいるときは、そのメンバーからの質問に答えたり、説明したり
振り返りは、もう2年以上はやっていて、メンバーの状況・フェーズによって内容は変化していますが、短いスパンでフィードバックを繰り返しているので、改善スピードも速く、とても効果的です。
僕からのフィードバック
前述の「振り返り」は僕は参加していないのですが、振り返りで話した内容のメモと、その日の問い合わせは、原則は毎日一通り目を通すようにしています。
僕の方では、主に業務知識的な視点でのコミュニケーションのズレやニュアンスの違いなどを中心に見ています。その上で、補足した方が良いものはSlackに解説を書いて、翌朝に補足してもらうようにしています。
また、そこから拾ったネタで業務的な解説をしたり、boardの仕様の意図を説明したりして、CSチームの業務知識の引き出しを増やしていこうとしています。
「え、まだ全部の問い合わせ見てるの！？」って驚かれることが多いのですが、直接問い合わせを一通り見ることで、ニーズだったり使い勝手だったりユーザ層の変化だったり、そういう部分の「温度感」を感じることができて、それをもとに、改善点を洗い出したり、開発内容を決めているので、僕の中では、極めて重要な位置づけだったりします。
温度感がなくなった「要望リスト」からは良いものは生まれないと思っているので、可能な限り、毎日一通りチェックするというのは続けたいなと思っています。
注力していること
サポートは、直接会ったこともなく相手の背景もわからない中、質問の意図を把握して、素早く的確に回答していく必要があって、恐ろしく難易度の高いコミュニケーションだなと思っています。
正しく理解する・正しく伝えるための日本語力は不可欠ですが、当然それだけではうまくいきません。
多様な業種・業界・職種の方々からお問い合わせを頂くわけですが、それぞれの業務的な背景や「その人にとっての当たり前」は、様々なんですよね。
この手の話でよく聞く例として、
「故郷」という言葉から想像するものは、田舎の風景かもしれないし、都会かもしれない。その人の出身・育った環境によって大きく変わる。
というのがありますが、人は、これまでの経験や知識をもとに言葉を発するし理解をするものだと思うので、それが異なる者同士がコミュニケーションを取る場合、どうしてもズレが生まれてしまうものだと思っています。
サポートの場合、このズレをサポートチーム側が埋めていく必要があって、これがもう本当に難しいので、とにかくここに注力していくべきと考えています。
サポートは、「ユーザさんのやりたいことを正しく理解する」「その上でわかりやすく説明する」というのが本質で、これのスキルが高ければ高いほど、お問い合わせを頂いてから解決までがスムーズになると思っていて、逆にそれ以外のことは、ここが圧倒的に高いレベルになってからで良いかなと思っているくらい重要視しています。
KPI
とくに何も見ていないです。
全回答時間の中央値は公開していますが、これは主に「どのくらいで返信が来るのかわらない」と言われるので実績値として公開しているもので、社内的には、月単位で大きな変化があった時に「何か要因あったっけ？」という確認で使うくらいで、安易にこれを短くすることを目指さないように言っています。
あとは、月々の問い合わせ数・返信数で増加傾向の具合を把握しているくらいです。
まとめ
「カスタマーサクセス」という言葉をよく聞くSaaS界隈にいて、うちの社内では「カスタマーサクセス」という言葉がまったく出てこないなど、昨今のSaaSの主流的なやり方とはだいぶ違うスタンスでやっているなあとは思っているのですが、board本体同様、自分たちにあったやり方を見つけつつ、強くしていければ良いなと思っています。
