Web会議の録画・音声認識・文字起こしを一つで行える営業支援クラウドサービスaileadを運営するバベルで、プロダクトマネジメントを担当している日高です。
今回は、バベルでNotionを使って運用している「プロダクトを活用しているお客さまから直接要望を集めるフロー」についてまとめていきます。
「お客さまからの要望が集まらず、プロダクト改善の方向性に迷ってしまう」という課題を持つ方にとって1つの参考になればと思います。
バベルが運営しているaileadは、営業における商談を振り返り、営業現場で働く方の業務効率化や営業スキルアップを実現することができるtoB向けSaaSサービスです。
私はaileadのプロダクトマネジメントを担当しているのですが、その中で、お客さまからの要望が十分に集まりきっておらず、プロダクトの改善をうまく進めづらいという問題がありました。
バベルではお客さまとのやりとりは、個別のSlackチャンネルで行っています。
これまでは、お客さまから要望を伝えていただいても、その声をPdM(プロダクトマネージャー)が全て収集し、優先順位を付けて改善に取り組むフローがうまく構築できておらず、理想とするプロダクト改善からは程遠い状況でした。
また、社内メンバーから「お客さまからこういう声をもらった」という情報が共有されることもありましたが、それも社内のSlackにバラバラに投稿されていたため、どこにどんな声があるのか誰も把握しきれていない状態になっていました。
そのような状況を踏まえて、お客さまからの要望が多く集まり、プロダクトの改善に取り組みやすくなる仕組みをつくりはじめました。
まずは、お客さまと普段から接しているCS(カスタマーサクセス)などの社内メンバーから情報を引き上げるために、Notion Formsを利用した社内向けの要望回収フォームを作りました。
フォームから「事実としてもらった声」「課題や背景」「解決できないと何が起こるのか」などを入力すると、自動的にNotionのデータベースに要望が反映される仕組みになっています。
Notion Formsでは、Notionのデータベースと連動させて項目をつくることができるので、改めて編集する手間をかける必要もありません。
社内向け要望回収フォームを導入したことで、社内メンバーを通して一定数お客さまからの要望が集まるようになったのですが、一つ問題が残りました。
それは、社内メンバーが直接やり取りすることが多いマネージャーや営業部長からの声は多く集まるようになった一方で、実際に日々プロダクトを使っている現場の営業担当の方からの声は集めきれなかったことです。
SaaSプロダクトでは、導入担当であるマネージャーと現場の利用者が求めるものは違っていることがあります。
aileadの場合でも、導入を担当する営業マネージャーは管理のための機能を求めていましたが、実際にプロダクトを日々使う現場の営業担当者は営業が行いやすくなるための機能を求めていました。
社内メンバーが声を聞きやすい営業マネージャーからの要望だけ考えてプロダクトを作っても、現場で日々プロダクトを使う営業担当の方に本当に使われるかはわかりません。なので、現場の営業担当の方からも声をもらえる仕組みをつくろうと考えました。
そこで、現場でプロダクトを日々利用している営業担当の方から声を直接集められる要望回収フォームをつくりました。
お客さまにGoogleフォームを渡し、現場の営業担当の方からもプロダクトを日々利用する中で気になったことや、要望を直接共有してもらえるようにしています。
項目は社内向けのフォームと同じく、「改善要望(事実)」「なぜ改善が必要なのか(背景)」などを書いてもらうようにしています。
aileadを使う現場の営業担当の方も、よりサービスが使いやすくなることで活用度が上がり、さらに効果が高まるため、積極的にこのフォームに要望を記入してくれています。
とはいえ、フォームをただ渡すだけでは要望を書いてもらえないので、浸透の方法は試行錯誤しています。
例えば、お客さまとやりとりするSlackチャンネルの一番目立つところにフォームを貼り付けたり、社内メンバーとも連携して、導入後のキックオフミーティングや、顧客からチャットでレビューをもらった時に、「このフォームを通して言ってもらえると、早く要望が解消されます」ということを都度伝えることで浸透するように働きかけています。
結果として、運用開始から2ヶ月弱で、現場の営業担当の方からの声も含めて累計150件以上の要望が集まる結果になりました。
現場でプロダクトを実際に触っている営業担当の方からも不満や要望が直接集まるようになったことで、より使われるシーンをイメージしながらプロダクトの改善に取り組めるようになりました。
要望回収フォームに投稿された要望は、Notionのデータベースに自動的にまとまるようにしています。
PdMの私は毎週、あがってきた要望に対して、解決する優先度をつけています。
扱う要望の優先度は「OKR達成のために本当に必要か」「より多くのお客さまのご要望とご期待に添えそうか」「今やるべきか」の3つの観点から主に考え、一つ一つ要望を見ながら設定していきます。
その上で、優先度高く解消する声をプロダクトバックログに直接リレーションさせて、開発において前提が抜け漏れないようにしています。
バックログに要望を紐づけることで「この案件の中でこの要望も解消するべきだった!」といった要件の検討漏れを防げるようになりました。
さらに、要望リストでは「要望一つ一つの対応状況」を追いかけることができるビューも用意しています。
例えば、お客さまからいつ要望が反映されるのか聞かれた時にも、開発の状況を見て正確な情報を伝えることができるようになっています。
今回の仕組みを導入したことで、営業マネージャー、日々プロダクトを利用する営業担当者から声が届くようになり、仕様を検討する時にもさまざまなケースを想定しながらプロダクトを設計できるようになりました。
特にtoBサービスは関わるお客さまが多く、設計が難しいと思います。
導入担当者が求めるもの、現場で利用する人が求めるもの、情報システム部が求めるものなど、お客さまの役割・役職ごとにそれぞれ違うニーズを持っていることを踏まえて、それぞれの声を集められる仕組みが必要です。
バベルでも、今回つくった要望回収の仕組みを通してその問題を解決していきたいと思います。今後はさらに、優先度の付け方など主観で行っているプロセスを仕組みで行えるようにしていきます。