問い合わせ対応フローを再編！開発の生産性向上を高める3つのアクション
問い合わせ対応は、開発生産性向上の一番初めにぶつかる壁です。
事業成長に伴ってお客様が増えると、要望に応えるため機能や問い合わせの数も増えていきます。
そして、それらの問い合わせの対応には多くの前提知識が必要となり、エンジニアもなかなか速度を出せません。
カミナシでもこれらの壁にぶつかり、開発への工数を捻出できないといった課題に苦戦しました。
今回の記事はこれらの壁とどのように向き合ってきたのか、そして、どのようにして乗り越えたのかについてお話します！
役割の間に落ちるボールが見えたある日
問い合わせ対応は総力戦です。
カスタマーサポートチーム、カスタマーサクセスチーム、エンジニアチーム、PMチームの各メンバーが協力して対応を進める必要があります。
ただし、その間に必要なコミュニケーション量は多いです。これらのコミュニケーションは各メンバーに負荷がかかります。
その結果、エンジニアメンバーは機能開発に時間を取れず開発速度が落ちてしまったり、カスタマーサポートチーム、 カスタマーサクセスチームのメンバーは意図せずお客さんに間違った伝え方をしてしまう可能性があります。
この役割の間に落ちたボールを拾うべく、問い合わせ対応の工数削減プロジェクトを発足しました。
問い合わせ対応の工数削減プロジェクトの発足
当時、エンジニアが問い合わせ対応に時間を取られ、機能開発の時間を取れていない状態でした。
これまでは問い合わせが発生してから、カスタマーサポートチームからエンジニアの各個人に連絡がいき、大小かかわらず調査〜対応までを全て対応してもらっていました。
ここでコミュニケーションの負荷が各メンバーにかかっている状態なのではと感じ、以下3つの対応を行いました。
課題の特定をするための問い合わせ対応内容の分析
問い合わせ対応フローの整備と問題内容の整理
問い合わせ対応時の関係者間連携と学びのシェア
それぞれでどんなことに取り組んできたのかをお話します。
1.課題の特定をするための問い合わせ対応内容の分析
まず初めに取り組んだのは、問い合わせ対応工数が増え始めている要因の分析です。
問い合わせ対応全体でどのくらい時間をかけているか、またどの対応に特に時間がかかっているのか。
そこで今どのくらい問い合わせ対応に時間を使っているのかを明らかにするために、過去1ヶ月分のチケットの整理を行い、スプレットシート上でデータを眺めてみました。
優先順位の見方
highest → お客様の業務が止まるレベルの障害。事業に影響がある
high → お客様の業務に影響が出る不具合。複数のお客様からの要望
medium → お客様の運用によっては回避出来る問題
low → 発生ケースが稀なもの
StoryPointsとは？
エンジニアが作業にかかる工数を見積もりする時に使う数値。
データから、以下の問題が見えていました。
1. 全体のうち、優先度mediumのチケットに対する対応割合は58%を占める
→ 優先順位がmediumとなっている問い合わせ対応にかける工数を削減出来ると大幅に効率化が出来そう
2. mediumに設定されているチケットのうち、「既知の不具合だが回避策が存在する」と「お客様の操作ミスの可能性がある」の2つが開発対応時間の73%を占める
→ mediumの問い合わせのうち73%はエンジニアが調査工数を割かなくても対応できる可能性がある
そこで、ここから問い合わせ対応フローの整備を行いました。
2. 問い合わせ対応フローの整備
前述の通りこれまでだと優先度に関わらず、全てエンジニアチームが一次対応を行っており、作業時間を捻出出来ていない状態でした。
そこで、調査/対応依頼の通知を受け取る一次受けの部分にPMが介在し、情報を咀嚼するフローを入れるような変更を加えています。
変更後の問い合わせ対応フローを見てもらうと、「調査/対応依頼を通知」以降で優先度による分岐が入っているかと思います。
お客様から受け取った問い合わせ内容の情報をPMが咀嚼し、回答ケースを作るように、コミュニケーションのフローを整えました。
個人的には問い合わせ対応に介在することで、お客さんの温度感を知り課題の優先度を正しく把握しておきたかったのも理由にあります。
対応フローの間に介在してみて、開発の生産性が落ちていそうに見える課題としては、以下2つが見えてきました。
1. エンジニアがお客さんの要望と既存のプロダクトの仕様を脳内で合致させる必要があり、そこが時間かかる
2. エンジニアチーム内でもプロダクトの背景情報をキャッチアップするのに時間がかかり、そこで大幅に調査の時間がかかる
この二つを解決させるためにも、関係者間のやりとりをドキュメント化し、チーム横断した学びをシェアするための仕組みを整えていきました。
3. チーム横断した学びをシェアする仕組み作り
BtoBシステムでは、お客様の業務とシステムが密接な関係を持つため、データ間の関連を把握することがとても重要になってきます。
そこでお客さんの業務とシステムの関連の整理を行い、各メンバーと問題の認識を合わせるようなコミュニケーションを取っていきました。
この情報を使うことで、お客さんの業務に専門性の高いメンバーと、システムに専門性の高いメンバーの情報を一つの土台を元に議論を行うことができます。
これらで議論された内容は、次に新しい議論を行う際にはチームの学びとなり、新しくこの課題に取り組んだメンバーが早く問題解決へ動き出すことが出来るようになります。
そして一つ一つの問い合わせ対応をとことん掘り下げ、問題の追求を行います。
これにより、お客様へのコミュニケーションを行う際、間違った伝え方をせず正しい情報の共有を行うことが出来ます。
また、エンジニアチームが問題を解決する実装を考える時、背景情報のキャッチアップ速度を早めることができます。
地道に対応を進めていき、ようやく開発の生産性が上がってきた
11月の開発対応時間を計測した所 (11/29時点で集計) 、今月は機能開発/負債解消に88%の時間を取れる状態を作れました🎉
これはエンジニアチーム、カスタマーサポートチーム、カスタマーサクセスチーム、PMチームが一丸となり実現できた数字だと思っています。これは素直に嬉しい！！！
ただし、今回は問い合わせの一次対応のボリュームを抑えることを目的として動いていたため、根本的な問題はまだ各所で潜んでいる状態です。
この問題にも積極的に飛び込み、問題解決に取り組んでいくぞ〜〜〜🔥🔥🔥
まとめ
今回は問い合わせ対応フローを再編し、開発の生産性を上げた話をしてみました。
プロダクトを利用するお客さんは、会社の身銭を切ってサービスを使ってくれます。
もちろん、そのサービスが不安定だったり問い合わせ対応が雑だと、やはりお客さんも不安になります。
サービスを提供する側の立場として、責任を持ってお客さんと真摯に向き合って壁を乗り越えていきたいですね。
もちろん、既存のサービスが安定する以外にも、新しい価値を生み出すことは重要です。そのためにも、開発の生産性を高める、そんな問い合わせ対応を今回推進していきました。
開発の生産性を高めて新しい価値を生み出しつつ、お客さんに安定したサービスを提供していきたいと思います！
🔈カミナシは全方位的に募集しています🔈
カミナシPMのEntrance Bookはこちら
最後までお読みいただきありがとうございました 😁
この記事が気に入ったらサポートをしてみませんか？