顧客に聞くべき製品フィードバックの質問(例付き)

聞く価値のある製品フィードバックの質問とは

質問集に入る前に、私が毎回すべての質問にかけているフィルターを紹介します。弱い製品フィードバックの質問には、次の3つの兆候のいずれかがあります。

• 誘導的である。 「新しいダッシュボードをどれくらい気に入っていますか?」という質問は、相手が礼儀正しいということ以外、何も教えてくれません。
• 仮定的である。 「ダークモードを使いますか?」人はほぼどんな機能を挙げても「はい」と答えますが、実際には触りません。表明された好みと実際の行動はほとんど相関しません。
• はい/いいえで終わる。 「役に立ちましたか?」は、まさに面白くなり始めるところで会話を終わらせてしまいます。

それぞれの強い版は同じ動きをします。相手が実際に行った、現実で最近の、具体的な出来事について尋ねることです。「画面がもっと暗ければよかったと最後に思ったのはいつですか?」と聞けば、投票ではなく、開発の土台になる「状況」が手に入ります。

もう1つのルールは、1つの質問につき1つの目的です。「価格についてどう思うか」と「どの機能が足りないか」と「先週のサポートはどうだったか」を混ぜたサーベイは、そのすべてについて浅い答えしか得られません。質問を書く「前」に、その答えがどんな判断に役立つのかを決めましょう。それでは質問集に入ります。

目的別の製品フィードバック質問

ここからが本題です。実際に学びたいことの内容でグループ分けしました。正しい質問は、その裏にある判断次第で完全に変わるからです。

下のセレクターを使って、今取り組んでいる内容に合ったセットに移動してください。

新機能やアイデアの検証

作る前に、その問題が本当に存在するのかを知りたいものです。ここで陥りがちな罠は、自分たちの解決策について尋ねてしまうことです。まだ存在しない機能を使うかどうか、誰にもわかりません。ですが、その機能が解決する問題に前回ぶつかったときに何をしたかなら、相手は教えてくれます。だからすべてを過去の出来事に結びつけましょう。

• 前回[問題]にぶつかったときのことを教えてください。何をしましたか?
• それによって、時間やお金、あるいは精神的な負担として、どれだけのコストがかかりましたか?
• その回避のために、どんなものを組み合わせて対応してきましたか?

もし最後にそれが起きたときのことを思い出せないなら、それが答えです。まだ開発するほど痛みの大きい問題ではないということです。

オンボーディングとユーザビリティ

ユーザビリティに関する製品フィードバックはすぐに古くなるため、摩擦がまだ新しいうちに、できればアプリ内で、その瞬間の直後に捉えたいものです。私が知る限り最も役立つオンボーディングの質問は、地味なものです。「そこで何が起こると思っていましたか?」顧客が期待していたことと、実際にUIがしたことのギャップは、いつでも姿を変えたバグレポートです。

サポート側でよく目にするパターンがあります。会社のヘルプドキュメントは管理者向けに書かれているのに、実際のチケットはエンドユーザーから届く、というものです。私たちが仕事をしている、あるトランジット・テック企業では、ドキュメントはシステム管理者向けに書かれていたのに、実際の質問はすべてバスの利用者から寄せられていました。彼らのオンボーディングの質問は、まったく違う対象者によって答えられていたのです。もしユーザビリティに関するフィードバックが妙に高度に感じられるなら、実際に誰がサーベイに答えているのか確認してみてください。

価値と支払い意欲の理解

ここでSean Ellisテストの質問が力を発揮します。「もしこの製品が二度と使えなくなったら、どう感じますか?」「とてもがっかりする」と答える割合は、プロダクトマーケットフィットを予測する本物のシグナルです。これを価値に関する質問(「これまでに得られた一番の利点は何か」)と組み合わせれば、相手が本当に恋しく思うか「どうか」と、その「理由」の両方がわかります。

支払い意欲に関する質問はそれ自体が難しい技術です。「いくら払いますか?」のような直接的な質問は、事実ではなく作り話を引き出してしまいます。それよりも、現在その問題を別の方法で解決するのにいくら使っているか、あるいは何があればアップグレードが即決になるかを尋ねる方がよいでしょう。

解約の防止

解約のタイミングは、顧客が最も正直になる瞬間です。だからそれを5段階評価のグリッドで無駄にしないでください。最も重要な1つの質問「今日解約する一番の理由は何ですか?」を尋ね、自由回答欄を開けておきましょう。そこから糸をたどります。何を期待していたのか、何がうまくいかなかったのか、何に乗り換えるのか。この内容を捉える構造化された解約フローは、最悪の日を最高のリサーチに変えてくれます。

問題は、多くの解約が静かに起こることです。人は解約せず、ただ来なくなるだけです。そうした顧客は、そもそも尋ねる相手がいないため、決して質問に答えることはありません。これがまさに次のセクションの論拠です。

ロードマップの優先順位付け

ロードマップに関する質問こそ、チームが機能への「投票」に頼りがちな場面ですが、それはこの中で最も弱いツールです。欲しいのは人気投票ではなく、摩擦です。「時間がかかりすぎると感じる作業のうち、一番時間を使っているものは何ですか?」と尋ねれば、本当の仕事が見えてきます。そして私が一番気に入っているロードマップの質問は、実は質問ですらありません。顧客がサポートチームに2回以上頼んだことは何かということです。そのリストは、すでにあなたのヘルプデスクの中にあります。

すでに持っているフィードバックの宝の山、サポートキュー

ここで視点を切り替えます。上に挙げた質問はすべて、あなたが「尋ねに行かなければならない」ことを前提としています。しかしサポートキューは、何千人もの顧客が、求められていないのに、自分の言葉で、日付付きで検索可能な形で、あなたの製品の問題点を教えてくれている場所です。ほとんどの企業が持つ最大かつ最も正直な製品フィードバックのデータセットでありながら、それを掘り起こす企業はほとんどありません。1万件のチケットを手作業で読むのは、誰の仕事でもないからです。

これは何かを送る必要のない顧客の声(VoC)の情報源です。「これをどうエクスポートすればいいですか?」はすべて、発見しにくさの問題です。「〜する方法はありますか?」はすべて、はてなマークを装った機能リクエストです。同じバグについての怒りのチケットはすべて、優先順位付けの材料です。シグナルはすべてそこにあります。あとは集約する作業だけです。

その集約こそ、まさに今のAIが得意とすることです。eeselでは、過去チケットでのトレーニングが、私たち自身のチームが数百件の営業電話を振り返って言うところの、顧客から最も求められている単一の機能です。チームはAIにチケットに「答えて」もらいたいだけでなく、これまで受け取ったすべてのチケットを読み込んでいてほしいと思っています。そしてそれが実現すれば、「請求の混乱」「オンボーディングの離脱」「連携機能の不足」といった繰り返し現れるテーマにチケットをタグ付けすることは、ほぼコストゼロで行えます。

「私たちの各ブランドには、それぞれ独自の製品と顧客がいます。eeselを使って、ブランドごとに専用のAIエージェントをトレーニングしました。それぞれが自分自身のチケットから学ぶことで、支えている製品を本当に理解できるようになっています。」

• 5つのブランド専用AIエージェントを運用する、複数ブランドを展開するヘルス&ウェルネス企業。各エージェントはそれぞれ自社のチケット履歴でトレーニングされている

それぞれの質問をどこで尋ねるか

すべての質問がサーベイに向いているわけではありません。質問とチャネルを合わせることが、成功の半分を占めます。

注目すべきパターンがあります。表の上側はあなたが「尋ねる」ものであり、答えるほど関わってくれている顧客に偏りがちです。下側は顧客が「教えてくれる」ものであり、フォームに決して記入しない静かな多数派を捉えられます。良い顧客フィードバックプログラムは両方を使いますが、ほとんどのチームは「尋ねる」ことに投資しすぎて、「教えてくれる」ことを無視しています。

回答を判断に変える

集めることは簡単な部分です。良い製品フィードバックの墓場は、誰も開かないスプレッドシートです。それを生かし続けるための3つのステップがあります。

1. 機能ごとではなく、テーマごとにすべてをタグ付けする。 「エクスポートボタンが見つからない」と「データをダウンロードするにはどうすればいいですか」は同じテーマです。根底にある仕事でグループ化しましょう。
2. 量だけでなく、影響範囲と売上でランク付けする。 1つの問題を挙げる10のエンタープライズアカウントは、100人の無料ユーザーを上回ることがあります。サポートKPIを重み付けするのと同じように重み付けしましょう。
3. ループを閉じる。 出荷したら、それを挙げてくれた顧客に伝えましょう。前回の意見が実際に意味を持ったという証拠ほど、次のフィードバックを促すものはありません。

これを手作業で行うなら、読み、タグ付けし、集計する、れっきとした仕事になります。もしサポートをヘルプデスク経由で運用しているなら、AIエージェントが全履歴にわたって読み込みとタグ付けを行い、優先順位付けされたリストを渡してくれます。それが「いつかチケットをちゃんと分析すべきだよね」という状態と、月曜日には分析結果がすでに待っているという状態の違いです。

避けるべきよくある間違い

繰り返し目にする罠がいくつかあります。

• 質問数が多すぎる。 12問のサーベイは、4問目で離脱されます。3つの鋭い質問は、12の曖昧な質問に勝ります。
• 尋ねるタイミングが遅すぎる。 オンボーディングから1ヶ月後に集めたオンボーディングに関するフィードバックは、記憶の記憶にすぎません。その瞬間に尋ねましょう。
• 満足した顧客か怒った顧客からしか話を聞かない。 両極端はどちらも過剰に反応します。静かな中間層にこそ解約が隠れているため、受動的なチャネルが重要になります。
• 機能への投票をロードマップとして扱う。 投票は熱意を測るものであり、必要性を測るものではありません。摩擦は人気に勝ります。
• ループを閉じない。 目に見える結果のないフィードバックは、顧客にフィードバックをやめるよう教えてしまいます。

サポートキューからの製品フィードバックにeeselを試す

顧客がすでにヘルプデスク経由であなたに連絡しているなら、サーベイなしで、あなたがこれまでに集める中で最大の製品フィードバックの山の上に座っていることになります。eeselはZendesk、Freshdesk、Gorgiasといったヘルプデスクと連携し、チケット履歴全体を読み込んで、繰り返し現れるテーマ、二度尋ねられている質問、言及される回避策、繰り返しリクエストされる機能を浮かび上がらせます。実際の会話に触れる前に、過去のチケットに対してシミュレーションできるので、パターンを先に確認できます。「次に何を作るべきか」という問いに、すでに持っているデータで答える、私が知る限り最も速い方法です。無料で試せます。