boardでは、お問い合わせ窓口のツールとして、これまでIntercomというサービスを使用してきましたが、先日、自社開発のものに切り替えたので、その狙いを書こうと思います。
Intercomについて
海外のチャットサポートのツールで、boardでは、ベータ版リリース直後の2014年5月から使ってきました。
boardのベータ版をリリースした際、知り合いから「メールで質問とかだるいのでこれ使いましょうよ」といって教えてもらったのがIntercomでした。
その1週間後くらいに導入したので、約7年ほど使ってきました。
自社開発に切り替える狙い
ここにコストをかけて開発していくというのは、普通に考えたらやらないかなと思います。ましてや、うちは自分を入れて10人の小さい会社で、エンジニアはその半分。しかも、Intercomで大きな支障があったわけでもありませんでした。
boardでは、サポートの対応もサービスの重要な要素であると考えていて、boardのユーザ層やお問い合わせの傾向などに応じて、画面や機能などを継続的に改善できる環境を整えたいと、ずっと思っていました。
また、CSチーム側の画面においても、サポート業務に応じた改善や、効率化のための工夫をしやすい環境を作れれば、メンバー各自がより本質的な作業に時間を割くことができるようになり、その結果として、より良いサポートを提供できるものと考えてきました。
このような「boardにフィットした継続的な改善」を実現する第一歩として、サポートの仕組みを自社開発に切り替えることにしました。
boardのサポートは、今でこそCSチームができて僕の手からはある程度離れていますが、元々は、僕自身が開発をしつつ、4年ほどはがっつりサポートもやってきたので、それを踏まえて、サポート業務をどう整理して、どういう仕組みを作っていくのが良いか、ということに取り組んだかたちです。
また、boardのサポートは、昨今のカスタマーサクセスの流れとはちょっと違うスタンスでいて、あくまで受け身の「サポート」に徹しています。そのため、最近のカスタマーサクセス寄りのサービスの方向性とはニーズが異なっていて、Intercomの多くの機能のうち、ごく一部しか使っていない状況だったという背景もあります。
もう1点、うちの会社は、会社の規模をどんどん大きくはせず、「10人の会社で有料1万社（現在3400社ほど）が使うサービスを目指す」というスタンスでやっています。しかも、残業をしないのはもちろん、勤務時間を短くしていたりします。
その方針の中で、サポートは、どうしても労働集約的要素が強く、導入企業が増えれば問い合わせも増えます。
board自体の改善で問い合わせが減らせる部分はたくさんあるので、これは継続的に取り組んでいて、その結果、有料2000社→3000社の約1年半で問い合わせ量はほぼ変わりませんでした。
その結果、シンプルな問い合わせは減り、より込み入った内容の割合が増えたのですが、これが後述の「ユーザ向け機能の改善」に繋がってきます。
ユーザ向け機能の改善
具体的な変更点については、boardのお知らせの中で詳しく書いているので、詳細はそちらをご覧頂けたらと思いますが、画面としては、以下のように変わりました。
■Intercomのチャットウィンドウ
■新しいお問い合わせ画面
サポートは、B2BとB2Cではかなり異なると思っていて、boardの場合、以下のような課題感がありました。
- 問い合わせ内容や回答が長くなることがそれなりにあり、Intercomのような細長いチャットウィンドウだと書きにくい、読みにくい
- Intercomは「ユーザ単位」の仕組みだったので、社内での問い合わせ内容の共有ができない
- その結果、社内管理者が意図しない使い方のための問い合わせが、管理者の知らないところで行われているケースがあった
- enterで送信されるチャットは、意図せず細切れにメッセージが送られてきて、慣れていない方だと、それで混乱してしまっているケースも見受けられた
また、Intercomは、海外でよく見かける、ちょっとふざけたGIFアニメを送れるようになっていて、ユーザさんがそれ間違って送ってしまって、大慌てしているケースとか、ほんと申し訳ない感じでした・・・。
＊後から知ったんですけど、GIFアニメは、Intercomの画面上からは無効にできないものの、問い合わせすれば無効にしてもらえたらしい。
Intercomのようなチャットは、気軽にさっと問い合わせができるメリットはあるものの、B2Bの業務系のシステムにおいて、そういうライトな問い合わせは、「〜できますか」というシンプルな機能有無の質問に対してヘルプを送るとかケースなど限定的で、システムの特性上、あまり向いていないように感じていました。
また、これはうちのサポートのスタンスもあるのですが、基本的に、業務システムは、ちゃんと仕組みや思想を理解した上で使わないと、期待した効果を得られないことも多いです。
そのため、boardのサポートでは「とりあえず目の前のことをできるための”操作”を伝える」というスタンスではなく、理解して頂くための説明をしっかりするスタンスでやっています。
そうすると、どうしても回答が長めになるケースもあり、このスタンスもまた、「細長いチャットウィンドウ」というUIがフィットしていませんでした。
このように、
・B2B固有のニーズや課題
・システム特性や問い合わせ内容の傾向
・サポートのスタンス
などを考え、よりboardの状況にフィットしたかたちにしていくことで、問い合わせを通じたユーザ体験を改善していきたいという狙いがありました。
CSチーム側の運用改善
実は自分の中では、こっちの方が比重としては大きかったりします。
サポートは、ツールも大事ですが、何よりも、CSメンバーによる対応・回答内容が本質であり、これがサポートのユーザ体験の大半を占めると考えています。
ですので、これに関しては、たとえば下記のように、今でも僕が継続的に関わりながら、改善を続けています。
では、システム側では何ができるのか。
「CSメンバーが気にすることを減らして本業に集中できるようにする」「機械的にチェックできることは人がやらないようにしていく」ということを目指しています。
情報の集約
サポートの対応の中では、非常に様々な情報を集め、それをもとに素早く状況判断をして、回答していきます。
たとえば
- 問い合わせしてきた方のユーザ権限
- 登録したばかりのアカウントなのか、それともある程度使っているのか
- 長く使っている会社でも、新しいユーザではないか
- 過去の問い合わせを確認して関連がないか、その他、業務において特徴的な点や読み取れる背景はないか
- 何人でboardを使っているのか
- ブラウザやOSなどの利用環境
などなど、問い合わせ内容だけでなく、非常に多くの情報や状況を踏まえて、回答内容を考えていきます。
人は、毎日どの時間でも同じ集中力を維持することはできないので、システム的に補助できることをやっていくことで、品質のばらつきを抑えたり、ミスの防止に繋げていきたいと考えています。
たとえば、回答する画面で、主要な情報が集約されていて、一目で確認できるようになっていれば非常に助かります。
これはある程度Intercomでもできたものの、やはり汎用的な仕組みだと、不要なものがあったり、できないことがあったり。ただ、それを自前で開発したことで、本当に必要な情報だけを集約して、回答する際に確認しながら書いていけるので、見落としも減るし、効率的になります。
要対応や待ち時間が一目でわかるように
下記のスクリーンショットのように、CSメンバーそれぞれごとに「対応済み」「要対応」があります。
これまでのInterecomでも「アサイン」の概念があったので、誰が何件持っているか、というのはわかったのですが、「対応が必要なものが何件あるのか」というのはわかりませんでした。
上図のように、所定のルールに基づいて自動的に「要対応」に振り分けることで、返信が返ってきて対応が必要なものがあれば一目でわかりますし、「回答漏れがないか」を気にしなくても大丈夫になり、また、他のメンバーが忙しそうだったらさっとヘルプに入ることもできます。
また、待ち時間ごとに件数表示やリスト表示できるようになっているので、どの程度待たせている状況かを一目で把握できるようになっています。
現在CSチームは3名で、「1人を余らせる運用」をしているので、この「1人」はここを見て、自分の判断で対応に入ることもできます。
＊「1人を余らせる運用」については以前のブログ参照
受付時の自動返信
これは賛否ありそうなところですが、問い合わせがあると、一旦、自動返信が入ります。
サポート時間内であれば「通常、どのくらいの時間で回答があるか」、サポート時間外であれば「時間外であることと、翌営業日に順次返信すること」を自動返信しています。
また、問い合わせは「質問」「機能の要望」「社印の透過依頼」というかたちでカテゴリを選べるようになっており、それによってCSチーム側の対応が変わるため、それに応じた自動返信をしています。
これまでは、サポート時間内で、混み合っていて即返信できない場合や、回答が長くなりそうで準備に時間がかかる場合は、一時回答をしていました。
ただ、そのためには、CSメンバーは、回答を書きつつ、新規で入ってきたものに対しても気を配っている必要があり、回答に集中しにくい状況でした。
そこで、サポート時間内の自動回答では、
・通常は数十分程度で回答している（目安の案内）
・回答はメールされるので、この画面は閉じてもOK
というかたちで、ユーザさんにとっても、次のアクションを起こしやすい情報を入れるようにしました。
これによって、「いつ返事が返ってくるのかわからない」というのを防ぎつつ、CSメンバーの負担も軽くなり、より回答に集中しやすくなります。
ちなみに余談ですが、Intercomでも当然自動返信の仕組みはあったのですが、欲しいかたちではなかったため、時間外のものだけ、「IntercomのWebhook→AWS API Gateway→AWS Lambda→Intercom API」というかたちで自前で自動返信の仕組みを作っていました。
ユーザ権限が足りないヘルプを送ろうとしていた時にアラート
ここから先は、現時点ではまだ未対応で、この後やっていきたいことの一例です。
boardでは、ヘルプの仕組みも自前で開発しているので、ログインユーザの権限に応じて、以下のようにヘルプ上に利用可否を表示しています。
要するに、ユーザ権限に応じて使える機能が変わってくるため、サポートの対応の中でも、これを考慮して対応する必要があります。
たとえば、権限が足りないユーザからその機能の質問があった場合には、説明をしつつ、「管理者にご相談ください」という一言を入れます。
ただ、これが意外と見落としがちなので、たとえば、権限がないユーザに対して、その機能のヘルプを案内しようとしてたらアラートを出すことで、個人の注意力に依存しないようにしていきたいと思っています。
これに限らずですが、問い合わせや回答しようとしている内容に応じて、システム側で自動的にチェックし注意を促すことができると、助かることも多いはずです。
textlintでのチェック
boardのヘルプは、Githubで管理し、pushするとGithub Actionsでtextlintが動き、表記の統一などのチェックを行っていますが、これを回答時にも適用したいなと思っています。
あとは誤字脱字などのチェックもある程度自動化することで、気にするポイントを減らしていくことができます。
ステージング環境のURLのヘルプを送ってしまうのを防止
過去数回やってしまったことがあるのですが、こういうのは、人が注意することではなく、システム的に弾くべきことですね。
回答例・注意事項の自動表示
回答のマニュアル化は、フィットしない回答に繋がってしまうためやっていないのですが、知見の蓄積として、社内に、回答例とその注意事項・ポイントなどを登録・管理しているデータベースがあります。
これと連動させて、たとえば、問い合わせ内容をもとに、関連しそうな回答例を出すことで、効率的に回答できたり、頭から抜けてたものを拾えたり。
boardのように込み入った問い合わせが多い場合、ユーザさん向けへのbotによる回答はまだまだ厳しいと思っていて、ユーザ体験が悪化しないように導入していません。
しかし、CSチーム向けには、「候補」を出すことでヒントになりますし、ここで精度を上げていくことができれば、将来的に、ユーザさん向けに活用していくことができるようになるかもしれません。
CSチームに対する効果
そういえば、これは社内で言ったことはなかった気がするのですが、この仕組みは、CSチームはユーザでもあるので、ユーザ視点での気持ち・捉え方や要望など、普段と逆の立場を、当事者として経験できる機会になると良いなと思っています。
技術的な取り組み
これは副産物的なものにはなりますが、boardのように6年以上運営しているものだと、今からまったく新しい技術要素を取り込んでいくというのは非常に大変です。
今回、ゼロから作ったことで、社内的に、新しい経験値を得ることができました。
また、今回は、僕は開発自体には直接は関わっておらず、仕様を決めたり、テストをしたり、インフラ周りを少しやったり、そういう役割だったので、メインで担当したエンジニアが、ゼロから作っていくところを全部経験できたのがとても良かったなと思います。
最近のboardの開発スタンスとして、「早くリリースすること」はあまり追い求めていなくて、完成度の高いもの、自分たちの知見が溜まるようにしていくこと、そういう時間の使い方をしていっています。
今回も同様で、「リリースを急がず、時間に追われずじっくり開発していく」ということを求められて、たぶんこれまでと違ったアプローチ・働き方だっと思います。
実際にこれをやってみると、結構アプローチや気持ちの持ち方が違くて、すんなりできないことも多いんですよね。むしろ締め切りがあった方が進めやすいというか。
もちろんリリースまでのスピードも大事なこともあるので、そこは両方できることで、使い分けていけると良いのかなと思っていて、今回は、「じっくりやる」スタンスを経験してもらえたのは良かったなと思っています。
まとめ
長々と書きましたが、簡単にまとめると
- boardのユーザ層や問い合わせの傾向に合わせて、サポートにおけるユーザ体験を改善していきたい
- サポート業務の効率化やシステム的な支援をして、CSメンバーがより本質的な部分に集中できるようにしていきたい
という感じです。
自分自身、boardという業務管理のシステムを作っているわけですが、今までのキャリア的にも、業務を整理してシステムに落としていくのは、ずっとやってきたことで、わりと得意な分野かなと思っています。
その上で、サポートは4年以上がっつりやってきているので、業務もよくわかっていました。
サポートのコアな部分は「人」なので、その向上のための取り組みはずっとやってきていて、それを支援するためのシステムを作ったのが今回という感じです。
まだファーストリリースしたばかりで、やりたいことはたくさんあるので、しばらくは継続的に開発が続きそうですが、ひとまず2営業日ほど、新システムでサポート業務を行って、非常に感触が良いので、まずはひと安心というところです。
