ユーザーフィードバックに溺れずに集めて優先順位を付ける方法

SupDesk Team

成長する SaaS には必ず訪れる瞬間があります。フィードバックが個別に返信できる細流ではなくなり、山になる瞬間です。アイデアはサポートメール、アプリストアのレビュー、Discord のスレッド、DM、そして 3 月に誰かが作って放置した表計算に散らばります。この中に本当に重要なものが 3 つあることは分かっている。でも見つけられない。

もっと頑張って全部読もう、というのが最初の反応です。それはスケールしませんし、もっと悪いことに、役に立ちません。必要なのは、生のフィードバックを意思決定に変えるプロセス。あなたが 2 週間忙しくても壊れないプロセスです。

フィードバックを無価値にする 3 つの失敗

いちばん声の大きい人のために作る。 足りないボタンについて 4 回メールしてくる人は、4 人のユーザーではありません。時間のある 1 人のユーザーです。需要を数える手段がないと、接触の量が必要の量と取り違えられ、ロードマップは気づかないうちに、声の大きい 5 人の顧客のための業務委託契約になります。

あらゆる声を機能要望として扱う。 フィードバックの大半は要望ではなく、症状です。「一括エクスポートのボタンを付けてほしい」は、たいてい「同じ作業を 1 日 12 回していて、うんざりしている」という意味です。ボタンを作れば 1 画面は解決します。理由を尋ねれば、その背後にある本当のワークフローの問題が見つかるかもしれません。

集める場所と決める場所が違う。 フィードバックが受信箱にあり、優先順位が非公開のドキュメントにあるなら、両者をつなぐのはあなたの記憶だけです。6 週間後には、なぜその機能がその順位だったのか再現できません。あとから入る人にはなおさらです。

4 ステップのトリアージ

目指すのは完璧な優先順位付けではありません。「誰かが何か言った」から「決めた、そして相手も知っている」までの、繰り返せる道筋です。

1. 集める — 行き先はひとつ、例外なし

フィードバックが着地する場所をひとつ決め、すべてをそこへ流します。他のチャネルが悪いからではなく、あなたのメールにしか存在しない要望は、数えるときに見えないからです。

ユーザーが直接投稿できる公開ボードを用意しましょう。あなたが転記のボトルネックでなくなるだけでなく、もっと価値のあることが起きます。次の人が重複を作らず、既存の要望を見つけられるのです。ひとつの投稿への 10 票はシグナルです。同じ内容の 10 件の投稿は、手作業で重複を潰すノイズです。

本当に別の場所から来たフィードバック — サポートメールや通話 — は、ユーザーの言葉のまま自分で登録し、元へリンクします。今の 2 分が、後の発掘作業を省きます。

2. 分類する — 3 種類を切り分ける

ほとんどすべては 3 つのどれかであり、それぞれ扱い方が違います。

  • バグ — 製品が説明どおりに動かない。票数ではなく深刻度で列の先頭に行きます。修正のために誰かが署名活動をする必要はないはずです。
  • 機能 — まだ存在しないもの。優先順位付けが実際に起きるのはここです。
  • フィードバック — 称賛、混乱、そして「X だと思っていた」という形のすべて。混乱の塊はドキュメントとオンボーディング改善の最良の材料であり、多くのチームが捨ててしまうカテゴリでもあります。

月次の片付けではなく、届いた時点でタグを付けます。タグのないバックログは、誰も開かないバックログです。

3. 優先順位を付ける — 需要を数え、そのうえで重みを見る

投票は需要を教えてくれますが、それは入力のひとつであって答えではありません。票の多い項目は、3 つの問いに照らして読みます。

  • 何人が、そして誰が? 一度も課金しなかったトライアルからの 20 票と、最上位プランの顧客からの 6 票は意味が違います。数だけでなく、誰が投票したかを見ましょう。
  • いくらかかる? 40 票の 3 日でできる機能は、60 票の 2 か月かかる機能に勝ちます。工数は順位付けの一部であって、後日の別の会議の話ではありません。
  • そもそも合っている? 求められても、あなたの製品ではないものがあります。断るのは意思決定であり、それを声に出すほうが、2 年間開いたまま放置するより誠実です。

残ったものをボード上で動かします。オープン、計画中、進行中、完了。ステータスは優先順位付けの出力であり、ユーザーがいちばん気にする部分です。

4. 伝える — 飛ばされる工程

次にまた話してもらえるかどうかを決めるのが、この工程です。8 か月「オープン」のままの要望は、投票した全員に「フィードバックはどこにも届かない」と教えます。

計画したなら「計画中」と言う。しないなら「今はやらない、理由はこれ」と言う。出したら「リリースした」と、頼んだ全員に、その日に、大きな声で言う。ループを閉じるコストはほぼゼロで、プロダクトサポートで最も見返りの大きい習慣です。

SupDesk はどこに入るか

このプロセスが、そのまま製品のかたちです。フィードバックは公開ボードに着地し、ユーザーが投稿・投票・コメントするので、需要は自動的に数えられ、重複はひとつのスレッドにまとまります。投稿はバグ・機能・フィードバックに型付けされ、カンバンボード上をオープン、計画中、進行中、完了と移動します。同じボードが、ポータル上では軽量な公開ロードマップにもなります。

AI を有効にすれば、届いた投稿を分類・要約させたり、会話を開く前に感情を確認したりできます。これはコンソールで受け入れるか上書きするかを選ぶ提案であって、裏で勝手に処理する自動化ではありません。Cloudflare Workers AI で動かすことも、OpenAI・Anthropic・Google の自前のキーを持ち込むこともできます。

そしてループは自動的に閉じます。投稿を完了にし、それをリリースしたチェンジログのエントリに紐付ければ、投票した全員に通知が届きます。あなたが聞いてくれたかどうかを、誰も確認しに戻る必要はありません。

まず「集める」から

この記事からひとつだけ持ち帰るなら、最初のステップにしてください。ユーザー自身が投稿できるフィードバックの公開窓口をひとつ作ることは、どんな優先順位付けのフレームワークよりも多くを解決します。見えないものには、優先順位を付けられないからです。

プロジェクトを作り、ボードを開き、ユーザーにリンクを送る。無料プランはカード情報を求めません。supdesk.app ではじめる