何をつくるのか決めるためにお客さまから直接声を集める、バベルの要望回収ワークフロー

Web会議の録画・音声認識・文字起こしを一つで行える営業支援クラウドサービスaileadを運営するバベルで、プロダクトマネジメントを担当している日高です。

今回は、バベルでNotionを使って運用している「プロダクトを活用しているお客さまから直接要望を集めるフロー」についてまとめていきます。

「お客さまからの要望が集まらず、プロダクト改善の方向性に迷ってしまう」という課題を持つ方にとって1つの参考になればと思います。

プロダクトの改善に取り組むために必要な、お客さまからの要望が十分に集まっていなかった

バベルが運営しているaileadは、営業における商談を振り返り、営業現場で働く方の業務効率化や営業スキルアップを実現することができるtoB向けSaaSサービスです。

営業支援クラウドサービス ailead

私はaileadのプロダクトマネジメントを担当しているのですが、その中で、お客さまからの要望が十分に集まりきっておらず、プロダクトの改善をうまく進めづらいという問題がありました。

バベルではお客さまとのやりとりは、個別のSlackチャンネルで行っています。

これまでは、お客さまから要望を伝えていただいても、その声をPdM(プロダクトマネージャー)が全て収集し、優先順位を付けて改善に取り組むフローがうまく構築できておらず、理想とするプロダクト改善からは程遠い状況でした。

お客さまからの要望がそれぞれ別の方法で共有されるため、PdMはすべての声をまとめてプロダクトの改善に反映することが難しかった。

また、社内メンバーから「お客さまからこういう声をもらった」という情報が共有されることもありましたが、それも社内のSlackにバラバラに投稿されていたため、どこにどんな声があるのか誰も把握しきれていない状態になっていました。

社内メンバーから共有される要望も、Slackにバラバラに届くので把握できない

そのような状況を踏まえて、お客さまからの要望が多く集まり、プロダクトの改善に取り組みやすくなる仕組みをつくりはじめました。

社内メンバーが回収できるお客さまの要望には、偏りがあった

まずは、お客さまと普段から接しているCS(カスタマーサクセス)などの社内メンバーから情報を引き上げるために、Notion Formsを利用した社内向けの要望回収フォームを作りました。

Notion Formsを活用してつくった、社内向け要望回収フォーム

フォームから「事実としてもらった声」「課題や背景」「解決できないと何が起こるのか」などを入力すると、自動的にNotionのデータベースに要望が反映される仕組みになっています。

Notion Formsでは、Notionのデータベースと連動させて項目をつくることができるので、改めて編集する手間をかける必要もありません。

フォームで回収した声は、Notionのデータベースに自動で反映

社内向け要望回収フォームを導入したことで、社内メンバーを通して一定数お客さまからの要望が集まるようになったのですが、一つ問題が残りました。

それは、社内メンバーが直接やり取りすることが多いマネージャーや営業部長からの声は多く集まるようになった一方で、実際に日々プロダクトを使っている現場の営業担当の方からの声は集めきれなかったことです。

導入担当者からの声は集まったが、現場の利用者からの声は集まりきらなかった

SaaSプロダクトでは、導入担当であるマネージャーと現場の利用者が求めるものは違っていることがあります。

aileadの場合でも、導入を担当する営業マネージャーは管理のための機能を求めていましたが、実際にプロダクトを日々使う現場の営業担当者は営業が行いやすくなるための機能を求めていました。

社内メンバーが声を聞きやすい営業マネージャーからの要望だけ考えてプロダクトを作っても、現場で日々プロダクトを使う営業担当の方に本当に使われるかはわかりません。なので、現場の営業担当の方からも声をもらえる仕組みをつくろうと考えました。

現場でプロダクトを利用する方から声を直接集める、要望回収フォーム

そこで、現場でプロダクトを日々利用している営業担当の方から声を直接集められる要望回収フォームをつくりました。

現場でプロダクトを利用している営業担当者から声を集める要望回収フォーム

お客さまにGoogleフォームを渡し、現場の営業担当の方からもプロダクトを日々利用する中で気になったことや、要望を直接共有してもらえるようにしています。

項目は社内向けのフォームと同じく、「改善要望(事実)」「なぜ改善が必要なのか(背景)」などを書いてもらうようにしています。

お客さま向けの要望回収フォームにも「事実」「背景」を項目として設定

aileadを使う現場の営業担当の方も、よりサービスが使いやすくなることで活用度が上がり、さらに効果が高まるため、積極的にこのフォームに要望を記入してくれています。

とはいえ、フォームをただ渡すだけでは要望を書いてもらえないので、浸透の方法は試行錯誤しています。

例えば、お客さまとやりとりするSlackチャンネルの一番目立つところにフォームを貼り付けたり、社内メンバーとも連携して、導入後のキックオフミーティングや、顧客からチャットでレビューをもらった時に、「このフォームを通して言ってもらえると、早く要望が解消されます」ということを都度伝えることで浸透するように働きかけています。

お客さまにご要望フォームの存在を都度伝えて浸透するよう働きかける

結果として、運用開始から2ヶ月弱で、現場の営業担当の方からの声も含めて累計150件以上の要望が集まる結果になりました。

運用開始から2ヶ月弱で、累計150件以上の要望が集まるように

現場の営業担当の方から、生の声が集まっている

現場でプロダクトを実際に触っている営業担当の方からも不満や要望が直接集まるようになったことで、より使われるシーンをイメージしながらプロダクトの改善に取り組めるようになりました。

集まった要望をもとに、プロダクトの改善を進められるように

要望回収フォームに投稿された要望は、Notionのデータベースに自動的にまとまるようにしています。

お客さま向け要望回収フォームの回答も、Noitonデータベースに自動でまとまるように

PdMの私は毎週、あがってきた要望に対して、解決する優先度をつけています。

扱う要望の優先度は「OKR達成のために本当に必要か」「より多くのお客さまのご要望とご期待に添えそうか」「今やるべきか」の3つの観点から主に考え、一つ一つ要望を見ながら設定していきます。

その上で、優先度高く解消する声をプロダクトバックログに直接リレーションさせて、開発において前提が抜け漏れないようにしています。

プロダクトバックログには、データベースから要望を直接リレーションして、前提が抜け漏れないように

バックログに要望を紐づけることで「この案件の中でこの要望も解消するべきだった！」といった要件の検討漏れを防げるようになりました。

さらに、要望リストでは「要望一つ一つの対応状況」を追いかけることができるビューも用意しています。

社内メンバーが要望の解消度合いを知りたい時に、一目でわかるビューを用意

例えば、お客さまからいつ要望が反映されるのか聞かれた時にも、開発の状況を見て正確な情報を伝えることができるようになっています。

導入担当者・利用者、それぞれの前提を考慮してプロダクトをつくる

今回の仕組みを導入したことで、営業マネージャー、日々プロダクトを利用する営業担当者から声が届くようになり、仕様を検討する時にもさまざまなケースを想定しながらプロダクトを設計できるようになりました。

特にtoBサービスは関わるお客さまが多く、設計が難しいと思います。

導入担当者が求めるもの、現場で利用する人が求めるもの、情報システム部が求めるものなど、お客さまの役割・役職ごとにそれぞれ違うニーズを持っていることを踏まえて、それぞれの声を集められる仕組みが必要です。

バベルでも、今回つくった要望回収の仕組みを通してその問題を解決していきたいと思います。今後はさらに、優先度の付け方など主観で行っているプロセスを仕組みで行えるようにしていきます。