開発・CSメンバー間の問い合わせを分析して業務改善につなげる取り組み
こんにちは、きむたかです。ナビタイムジャパンで店舗管理事業者様向けサービスの開発・マネジメントをしています。
今回は、私の所属するチームで開発⇔CS(※)のメンバー間で発生する問い合わせを分析して、普段の業務改善につなげるための取り組みを行った話についてお話したいと思います。
(※ここでいうCSとは、「カスタマーサポート」「カスタマーサクセス」といった、クライアントからの問い合わせ・要望に対応するチーム・メンバーを指します。)
背景と課題
私が携わっているBtoB(法人向け)サービスを運営していく上で、サービスを利用いただいているクライアントからの問い合わせは常日頃発生しています。内容も、サービスに関する作業依頼であったり、仕様確認・不具合の問い合わせといった具合で多岐にわたります。
私の所属する事業部では、それらをCSチームが確認・対応する体制をとっています。CSチーム内で解決する課題もありますが、完結しないものについては(私が所属している)サービスの開発チームにエスカレーションされます。
一方、開発チームでは、そういった問い合わせに対応するため、曜日ごとに担当を設け、普段の業務と並行して対応にあたっています。(曜日担当の業務は、いわば「割り込み業務」にあたります。)
あるとき、チーム内での振り返りを行った時、多くのメンバーが「問い合わせ対応に時間がかかり本来開発にあてていた時間が取れていない」といった意見を発していたことがありました。
私自身も曜日担当に割り当たることがありましたので、なんとなく対応に時間がかかるケースが増えているのを感じていましたが、ちょうどその頃は(ありがたいことに)新規クライアントも増えていた時期で、単純にそれに関連する問い合わせが増えているといった、一過性のものなのかな？程度に思っていました。
しかし、しばらく経っても曜日担当の負担が減ることはなく、むしろ徐々に増えているという声を聞くように…
この時点で、
問い合わせ対応により、開発メンバーのリソースが割かれ、業務に支障が出ている
負荷となっている具体的な要因が割り出せていない
という部分が明確に課題として浮き彫りとなりました。
どうやって課題解決につなげたか
このような課題を解決するため、現状の問い合わせの内容がどういったものなのかを分析し、アプローチを決定しようと思い、そのための策をいくつか実施しました。
(1) まずは問い合わせを集めて分類する
CSチーム→開発への問い合わせは、主に1つのSlackチャンネル上で行われる運用となっていました。そこで、まずは手始めにそのチャンネル上のやりとりをすべて拾って分類する作業を行いました。
具体的には、以下のような作業を行い、集計を行いました。
SlackのAPIを使って、特定の期間における該当チャンネルの投稿を全件取得する
取得した内容を1つ1つチェックし、それらに対し以下の情報を付与していく
特定個人へのメンションありorなし(=曜日担当が一次請け)
内容の分類(作業依頼、仕様確認、(不具合含む)調査、見積もり、その他)
クライアントからの直接の問い合わせかどうか
(このタイミングでは、およそ6ヶ月分を取得して分類しました。件数としてはおよそ400件程度で、分類にかかった時間は3,4時間程度だったと思います)
これらの集計を行い、問い合わせについて以下のような傾向があることがわかり、それらに対する仮説を立てられる状況になりました。
全体の問い合わせのうち、作業依頼にあたるものが全体の3~4割を占めていたこと
→ 作業に時間を要するものがあり、それらが負担になっていた？特定個人へのメンションがついた投稿が、そうでないものよりも若干多かったこと
→ 曜日担当でない場合でも、割り込み業務が発生しうる状況になっている？クライアントからの直接的な問い合わせが占める割合は、じつはそこまで多くなかったこと
→ 社内に閉じた問い合わせであれば、優先度の調整の融通がきく？投稿の内容の粒度にばらつきがあり、期待値が明確ではないケースがあること
→ これらを明確にするためのコミュニケーションコストも発生している？
(2) 問い合わせの受け方を統一する
ある程度現状が見えてきたところで、より具体的な改善が行えるようにするため、問い合わせの受け方を統一する対応をとりました。
具体的には、これまでSlackチャンネル上でフリーで問い合わせを受けていた部分を、Slackのワークフローを利用して統一したフォーマットで受け付ける形に変更しました。
受け付けた内容は、専用のSlackチャンネルに流しつつ、Googleスプレッドシートとの連携を用いて内容をためていくしくみを整えました。
解決した課題・新たに見つかった課題
ここまでを整えることにより、まず以下の課題を解決することができました。
特定個人へのメンションが減り、メンバーが曜日担当でない日に割り込みに割かれる状況を減らすことができた (特定案件に関連するような内容では、個人メンションが発生することがある)
作業分類・期待値・期限・クライアント問い合わせかどうかを明示されたため、作業の優先度をつけやすくなった
当社ではタスク管理にJiraを用いていますが、Slackとの連携で投稿内容をそのままJira課題として起票することができ、それとの相性も良いです
スプレッドシートに貯めることで、継続的に問い合わせ内容を分析できる環境を整えることができた
主に(1)(2)のおかげで、メンバーの負荷はかなり削減されました。(時間の負荷・心的負荷のいずれも)
また、(3)による分析で新たな課題を見つけることができ、それらに対しての「次の改善の一手」を打てるようになりました。
(新たに見つけた課題の例)
◆問い合わせのうち、作業依頼が全体の4割(ここは変わらず)
→ 作業の自動化で負荷が下げられる見込みがある
◆この作業依頼をさらに細かく見ていくと、特定のプロダクトのS-inに必要な設定作業が多くを占める
→ また、作業依頼以外も、このプロダクトに関する仕様確認や不具合調査といったものが多かった
→ このプロダクトは、ここ数年で運用を開始した新商材。これらに対しての運用コストを下げるための施策が、結果として全体の負荷を下げられそう
まとめ
Slack上での普段の何気ない依頼でも、分析してみると様々な課題が見えてくるということを身を持って体験できたと感じています。
これは私の考えですが、BtoBサービスを運営していく上で、このような問い合わせのやりとりの効率化は、間接的にそのサービス自体の質および顧客満足度の向上につながるものである考えています。そのため、円滑に問い合わせに対応できる体制を整えることも重要だと思っています。
そういった意味では、問い合わせの内容・傾向次第では、いわゆる「CSエンジニア」と呼ばれるような役割のチームをつくり、問題解決に集中できる体制をつくることも今後の選択肢として発生するかもしれません。
そうした判断をするうえでも、問い合わせの分析に着手し、それを継続して行える状況までもっていけたことには大きなメリットがあると感じています。
今回の問い合わせ分析は、着手してからまだ数ヶ月ということもあり、この作業自体にもまだまだ改善の余地があるかもしれませんので、継続してウォッチしながらさらにブラッシュアップしていきたいと思います。