サービスの利用者数が増えれば連動して問い合わせ数も増えていくものですが、boardでは、それを減らすための改善・取り組みを継続的に行っているので、それについて書きたいと思います。
boardについて
boardは、見積書・請求書の作成から業務管理・経営管理などを行うことができるサービスで、主に数人〜数十人規模の小規模な会社をメインターゲットにしています。
2022年12月現在、有料契約社数は4400社弱で、最近は「2ヶ月で純増100社」というペースで成長しています。
＊サービス開始当初からの有料契約社数の変化は、下記のブログに書いています。
弊社は、会社の「規模」の拡大は目指しておらず、「10人で1万社が利用するサービスを」というスタンスで運営しています（今、11人いますが）。
そのような方針で会社を運営しているため、契約社数の増加とともに問い合わせが増えてしまうと、この会社のスタンスを維持できなくなってしまいます。そのため、「提供するシステムやサポートの質を向上させて、利用社数が増えても問い合わせは増えない」という状況を目指しています。
これは「問い合わせをしにくくする」のではなく、問い合わせは気軽にできるものの、問い合わせをしなくても済むようにしていくという取り組みです。
問い合わせ数の増加を抑えられるということは、サポートの品質維持にも繋がるため、少数で質の高いシステム・サポートを提供していくためには、非常に重要なポイントと考えています。
取り組みの成果やその他関連する情報
2018年から2022年の数字を見ていきます。
まず契約社数ですが、2018年1月時点での有料契約数は約1100社でした。2022年12月時点では4400社弱なので、この期間で3000社以上増えている状況です。
以下は、1ヶ月あたりの問い合わせ数の平均です。2020年は、コロナの影響で一時的に多い期間がありましたが、2021年・2022年はそれも一段落し、各種改善の効果から、問い合わせ数の増加は抑えられています。
- 2018年：312件
- 2019年：402件
- 2020年：420件
- 2021年：356件
- 2022年：346件
また、1つの問い合わせの中で、複数回のやり取りが発生しますので、返信数でも見てみます。
- 2018年：734件
- 2019年：1146件
- 2020年：1258件
- 2021年：787件
- 2022年：654件
現在CSチームは3人ですが、とくに残業することもなく、1日中立て込んでいるようなこともあまりなく、3人で余裕を持って運用できています。
回答のスピードに関しても、2015年3月から毎月の回答時間の中央値を公開していますが、直近の2022年11月は23分29秒でしたので、ある程度タイムリーに回答もできています。
問い合わせが減っても退会者が増えていたら意味がないので、有料継続率も見てみます。
ここ1〜2年ほど、有料継続率も改善しています。boardは2014年のリリース当初から、有料継続率が99%台前半でしたが、ここ1年ほどは99.5%前後で推移しており、従来より改善しています。
有料継続率の改善のためにとくに何か対策をしているわけではないので、システムそのものやサポートの質の結果ではないかなと考えています。
以下、問い合わせを減らすための改善として、具体的に行ってきた取り組みを紹介します。
大きく「問い合わせをしなくて済むようにする取り組み」と「問い合わせ時のやり取りを少なくするための取り組み」に分かれるかなと思います。
システム的な改善
boardのシステムそのものの改善は「問い合わせをしなくて済むようにする取り組み」に該当します。
様々な改善をしているため、今回は、細かい改善やちょっとした工夫によって、問い合わせを減らすことができたケースをいくつか紹介したいと思います。
困りそうな箇所に解決への動線を置く
一定数の問い合わせがあるものの、知っていれば簡単に解決できるようなものは、困りそうなシチュエーションに合わせて、解決への動線を用意しておくことで、それ関連の問い合わせがぐっと減りました。
たとえば、boardでは「案件をアーカイブ」する機能がありますが、アーカイブすると、一覧画面には表示されなくなります。
そのため、「アーカイブしたことを忘れていた」「他の人がアーカイブしていた」などの場合に、「案件が見つからない」というお問い合わせが一定数ありました。
そこで、下図のように、案件を検索して検索結果がなかった場合、考えられる可能性を画面上に表示するようにしました。これにより「案件が見つからない」というお問い合わせは激減しました。
なお、新規アカウント登録直後の案件未登録時にこの表示にならないよう、そのような状況では、下図のように「スタートガイド」に誘導しています。
また、お試し期間が終了した際の表示も、下図のように、「継続利用する場合」と「お試しまでで終了する場合」のそれぞれのケースに応じたFAQを表示することで、これ関連のお問い合わせはぐっと減りました。
このように、困りそうなシチュエーションに合わせて、説明・ヘルプへのリンク・FAQなどを表示することで、問い合わせをせずに、ユーザーさん自身で解決できるようになります。
細かい画面文言の変更による改善
全員がヘルプをしっかり読んで利用するわけではないので、画面上の文言・説明文は非常に重要です。
システム全体での用語の統一などは当然として、「こういう用語を見たら、多くの人はこういう用途を連想するだろう」というものに関してギャップが多かったり、多様な解釈があり得る用語を使っていると、問い合わせが増える結果に繋がります。
たとえば、boardでは「定期請求」という、「毎月」「3ヶ月ごと」「毎年」のように決まった間隔で繰り返し請求する機能があります。この定期請求の設定項目として「請求期間」というものがあり、これは「いつからいつまで請求するか」という情報を登録するための項目です。
「請求期間」は、以前は「契約期間」という項目名で、これが「用語から連想する用途と仕様のギャップ」を生んでいました。
「請求期間」は「いつからいつまで請求するか」という請求サイクルを示すための項目なのですが、「契約期間」は契約上の期間をイメージします。この2つが一致している場合は問題ないのですが、たとえば先払いのケースでは、契約期間よりも請求期間の方が前にずれることになります。
このような場合、以前の「契約期間」という項目名のときは契約上の期間を登録してしまい、「意図したタイミングで請求書が生成されない」という状況が発生し、問い合わせに繋がっていました。
そのため、より意味が明確になるよう「請求期間」に変更したところ、このギャップによるお問い合わせは激減しました。
同じ用語でも、それからイメージする内容は会社・業種・業界によって本当に様々で、完璧にギャップがないということは難しいですが、こういった細かい改善をしていくことで、認識のズレを減らすことができます。
ヘルプ・FAQの拡充と改善
ヘルプ・FAQの拡充・改善は、「問い合わせをしなくて済むようにする取り組み」と「問い合わせ時のやり取りを少なくするための取り組み」のどちらにも該当します。
ヘルプに関しては過去にもこういったブログを書いているように、かなり力を入れています。
＊少し内容が古く、現在は、CircleCIではなくGitHub Actionsでやっています。
以前は僕がヘルプを書き、元編集者をやっていたCSメンバーが校正する、という体制でやっていましたが、最近は、CSチームがサポート対応の中で気づいた点などを随時改善するようになっています。
上記の記事にも書いている通り、boardのヘルプはすべてGitHubで管理されており、「プルリクエスト→他のメンバーがチェック→マージしたら自動的に本番に反映される」という仕組みになっています。
そのため、スムーズにプルリクエストへ繋げられるよう、サポート対応の中で「ここのヘルプ、ちょっとわかりにくそう」「こういうFAQがあったら良さそう」といったことに気づいたら、各CSメンバーが随時GitHubのissuesに登録します。
サポート業務は忙しさの波があるので、問い合わせが落ち着いた時に、GitHubのissuesに登録されているものをピックアップして、修正のプルリクエストを出します。
日々のサポート業務の現場は、ヘルプ・FAQのわかりにくさや改善点に最も気づきやすい場です。
このように、日々のサポート業務の中で気づいたことが、CSチームトリガーでどんどん修正されていくようになっているので、ユーザーさんがヘルプ・FAQだけで解決できることも増えていきますし、「ヘルプを見たけどわからない」というのも減らしていけます。
また、特定のシチュエーションに限定した、少し説明が大変なもの、順を追っていく必要があるものをFAQとして用意するといったこともよくやります。
これにより、サポートの説明コストが下がるのに加えて、少し込み入った内容の説明がCSメンバーの個人依存にならず、1つのFAQを繰り返し改善していくことで、よりわかりやすい説明にしていくことができます。
現在、ヘルプ・FAQは500記事弱ありますが、この蓄積は、非常に大きな役割を果たしています。
サポートの質の向上
これは、「問い合わせ時のやり取りを少なくするための取り組み」に該当します。
CSチームによる回答の質の向上は、解決までのやり取りを減らせるため対応時間の短縮に繋がりますし、ユーザーさんのサポートの体験にも直結するため、かなり力を入れている部分です。
回答前のレビュー
回答する前に他のメンバーによるレビューを入れることがよくあります。
すべての回答をレビューしていたら時間がかかりすぎてしまうというのと、過剰なレビューによりレビューコストがかさんでしまうので、以下のようなケースで、レビューするようにしています。
- 質問の解釈や扱っているトピックが難しいもの
- センシティブな内容なもの
- 料金・お試し期間・退会など契約に関するもの
- その他、何か引っかかりがあるもの、気になるもの
Slackのワークフロー機能を使ってレビュー依頼を出し、それが専用のチャンネルに流れるので、対応できる人がレビューします。トピックとして明らかに誰かの得意分野の場合は「これは○○さんにお願いします」というかたちで指名することもあります。
もし、さらに他の人の意見を聞きたい場合はさらに別の人にレビューしてもらうこともありますし、僕にエスカレーションして確認することもあります。
このレビュー・エスカレーションの中では、主に以下のようなポイントをチェックします。
- 質問の解釈や、相手の関心ごととのズレがないか
- 説明すべきことの過不足はないか
- 文章的な観点で修正すべき箇所はないか
CSチームの3人はみんな文章力が高く、そこにレビューコストをかけなくても済むため、「質問の解釈や、相手の関心ごととのズレがないか」をもっとも大事にしています。
レビューは、サポートそのものとは別のスキルになると思うのですが、これを続けていくことで、チーム全体のレビュースキルが向上し、レビュー段階でかなり改善できるようになりました。
振り返り
サポート時間終了後、15分〜30分ほど、CSチーム内でその日の振り返りをやっています。
事前に他の人の回答を一通り目を通しておき、気になった点・改善点などを共有します。その上で、もし回答に補足が必要であれば翌朝に補足するための方針を検討したり、ヘルプやFAQの改善点が必要ないかなどを話します。
振り返り自体はもう何年も続けているのですが、以前は回答そのものの改善の話がメインでした。しかし最近は、みんなのスキルが向上した結果、そういった話よりも、方向性・考え方・スタンスなどの共有の場になっているように感じます。
これにより、誰が対応しても、大きくスタンスが異なるようなことはなく、またズレが発生していたら、早期に発見・軌道修正できるようになっています。
また、僕自身は振り返りには参加していませんが、サポート時間終了後、その日の問い合わせはすべて目を通しています。その中で、気になるところがあればSlackに流しておき、翌朝、CSチームが確認できるようにしています。
これは、主に業務理解や仕様理解などを深める役割を担っています。
文章講座
CSメンバーの1人が、うちに入社する前は本の編集者をやっていて文章のプロなので、そのメンバーが「文章講座」を実施しました。
全員きちんとした文章は書けるのですが、これまでプロにしっかり習うという機会はなかったため、サポート業務で役立ちそうな観点から、数カ月間、週1〜数日程度の頻度で、サポート時間終了後に30分ほど実施していました。
これにより、よりわかりやすい、誤解の少ない文章となり、また前述のレビューで文章自体の修正機会も減るため、回答者およびレビュアーは、より「ユーザーさんの関心ごとの本質」や「回答の構成そのもの」に注力できるようになりました。
また、一度しっかり文章講座をやったことにより、普段のレビューの中で「文章講座でやったあれ」みたいなかたちで、改善の方向性・意図の共有もスムーズになりました。
問い合わせの深堀り
これは僕が他のCSメンバーに対して実施していたものですが、主に業務知識や質問の背景の理解度向上を目的にした取り組みです。
問い合わせをいただく方のバックグランドは多様で、経営者・経理・総務・営業など様々な職種の方がおり、また会社規模も業界も多様です。
そのため、質問を適切に理解する上で、背景となる業務などの理解は非常に重要になってきます。
ただ、CSメンバーの全員がバックオフィス業務の経験者なわけではありませんし、経験者であっても、すべての業界をカバーできるものでもありません。そのため、業務知識は課題になりがちです。
そこで、週3日ほどのペースで、過去の問い合わせをピックアップし、「この問い合わせの背景や本質的な関心ごとのは何か」というのを考えてもらい、その後に僕が解説する、ということをやっていました。
これにより、業務的な背景の理解度が向上し、質問の背景・本来やりたいことなどの捉え違いが減り、解決までのやり取りの回数を減らすことができたと考えています。
個別相談会への参加
業務システムである以上、質問者の業務的な背景の理解度は、「質問の中に隠れている本質的にやりたいこと」を把握する上では非常に大事です。
しかし、ユーザーさんの業種・業界・会社規模・職種は様々で、それらが異なれば、質問の背景も異なります。
そのため、CSチームは、1つの分野に深く特化するより多くの引き出しを持っておき、多様なシチュエーションを想像できるようにしておく必要があります。
このための取り組みとして、普段僕がやっている個別相談会に、CSチームから1名参加してもらっています。
これにより、普段のサポートのやり取りでは出てこない、より具体的な業務状況や課題を聞くことができたり、テキストベースのやり取りでは感じることができない温度感を感じたりできます。
また、個別相談会の内容はCSチームに共有され、参加しなかったメンバーも、その内容を把握できるようにしています。そして、その会社さんからお問い合わせがあったら、個別相談会のメモは、質問の意図や背景の理解に役立ちます。
この積み重ねが、CSチームの業務理解度の向上に寄与しており、よりスムーズな対応に繋がっているように感じています。
サポートシステムの自社開発とtextlint
問い合わせ窓口のシステムは、以前はintercomというサービスを使っていましたが、現在は自社開発の仕組みに切り替えています。
自社開発に切り替えた背景・狙いなどは、以前、下記で書いています。
これにより、たとえば、
- 回答の送信前にtextlint（文章校正ツール）でのチェック結果を表示し、必ず機械的なチェックを通すことができる
- ミスを防ぐための仕組みを入れて、機械的に防げるものは気にしなくて済むようになっている
- 自分たちに合った、CS業務効率化のための細かい工夫を色々入れることができている
というように、少ないメンバーで効率よく業務を行い、かつシステム的な補助によりミスを防止できるようにしていくことで、よりサポート業務そのものに集中できる環境を作っていっています。
「11人の会社でここに投資するの？」と驚かれることが多いのですが、実際にやってみて、投資する価値がありすぎでした。
システムでサポートできるところはどんどんしていくことで、より本質的な部分に注力できるようにしていく、という方針は、サポートの品質向上に大きな役割を担っているなと感じています。
＊余談ですが、このブログを書いているShodoも同じことが言えて、個人的に、こういうのがとても好きみたいです。
CSメンバーの構成
これは、取り組みというよりはCSチームの構成の話ですが、サポートキャリアが長いサポートのプロ、元編集者で文章のプロ、文章力が高い経理経験者という3人で構成されていて、それぞれサポートで必要な要素に強みがあります。個人ごとでも十分なレベルですが、チームとして非常にバランスが良い強いチームになりました。
しかも、みんな文章力は高く、元編集者に依存せずにも十分なレベルの文章を書け、元編集者は、それをより向上させる役割を担っています。
そのため、最近僕はすっかりお役御免になっていて、チーム内でより質を上げていけるサイクルが回っているので、今後もまだまだ良くなっていきそうだなと感じています。
まとめ
何か秘訣のようなものがあるわけではなく、基本的に「システムとサポートの質を上げて問い合わせ数の増加を抑える」ための取り組みを継続的に行っているというだけではあります。
弊社の「会社規模を大きくしない」という方針が前提としてあるのはもちろんですが、
- 問い合わせをせずに使えること
- ヘルプ・FAQが充実していてわかりやすいこと、自己解決できること
- サポートの質がよく、知りたいことがわかりやすく返ってくること
はユーザーさんにとってもメリットが大きいと考えていますので、当然目指していくべきところだと思っています。
また、boardは非常に安いサービスで、提供している機能等から考えると「安すぎて不安になる」「桁が1つ足りない」と言われることも度々あるのですが、低価格でも質の高いサポートを提供していくためには、こういった「問い合わせを増やさない取り組み」は非常に大事だと考えています。
というように、今後も継続して、「問い合わせをしなくてもスムーズに使えるシステム」「質の高いサポート」にしていくため、継続的に改善していきたいと思います。
