ソフトウェア製品で顧客フィードバックを求める方法と使える質問文

ソフトウェア製品で顧客フィードバックを求めるには、ユーザーがたった今したことについて、それをした場所で、具体的な質問を一つだけ投げる。エクスポートの直後に「このレポートのエクスポートはどうでしたか?」と聞けば答えが返ってくる。フッターに「製品についてのご意見をお聞かせください」と置いても、返ってくるのは沈黙だ。このページの残りは、聞くタイミング、チャネル、そして具体的な文面についてだ。

この話題の助言の多くは、店舗やサービスデスク向けに書かれている。ソフトウェアのチームは、ユーザーが一秒前に何をしたかを正確に知っている。だから質問も、その行動について聞ける。

フィードバックを求める適切なタイミングはいつか

適切なタイミングは、ユーザーが何かを終えた直後で、細部がまだ頭に残っているときだ。行動に続く質問は、その行動についての答えを引き出す。突然届く質問は、そのときの気分についての答えか、答えなしで終わる。

登録時には聞かない。まだ誰も何も使っていないからだ。作業の途中でも聞かない。知りたいことそのものを邪魔してしまう。一度答えてくれた人には、報告できることができるまでそっとしておく。

顧客フィードバックはどこで求めるべきか

体験が起きた場所で聞く。画面についての質問にはアプリ内のプロンプトが合う。修正についての質問にはサポートのスレッドが合う。一週間の利用や、途中でやめたフローについての質問にはメールが合う。予測できない質問には通話が合う。

チャネルごとに得られる答えの種類は違う。

• アプリ内: 短く、即時で、具体的。ただし、その場にいる人からしか返ってこない。去ったユーザーからは何も聞こえない。
• サポートのスレッド: わざわざ問い合わせるほど苛立っていた人からのもの。壊れているものを見つけるには良いが、製品の残りの部分を判断するには向かない。
• メール: 人数は少ないが長い答えが返ってくる。静かになったユーザーに届く唯一の方法でもある。名前のある人からの短いメモとして書き、質問は一つだけにする。
• インタビュー: 人がなぜそうするのかを知る方法。普段の仕事のやり方を見せてもらい、その間は黙っている。

各チャネルの話をどう重み付けるかは、フィードバックのシグナルの質で扱っている。

失礼にならずにフィードバックを依頼するには

対象を具体的にし、なぜ聞くのかを伝え、答えるのに一分もかからないようにする。きちんとした依頼は、タイミングを特定し、誰かが答えを読むことを明らかにし、邪魔したことを詫びない。

実行したばかりの操作を正確に名指し(「先ほど実行したエクスポート」)、聞くのは一つだけにし、必須項目のない自由記述欄を使い、名前で署名する。

フィードバックを求める良い一文とは

良い一文は、特定の場面についての質問で、数語で答えられるものだ。下の二つの列を比べてほしい。左はどれも肩をすくめるだけで答えられる。右は、本当にあったことを思い出してもらう必要がある。

ほとんどどこでも使えるもう一つの質問がある。「これがうまくいかないとき、代わりに何を使っていますか?」本当の競合を浮かび上がらせる質問で、それはたいていスプレッドシートだ。

フィードバックの最悪な聞き方とは

最悪の聞き方は、広すぎる、早すぎる、長すぎる、誘導的である、のどれかだ。共通する問題は、本来あなたがすべき思考を、相手がやらなければ答えられないことだ。

1. 「20問のアンケートにご協力ください。」 最後まで答える人は、時間が最もある人か、意見が最も強い人だ。
2. ログイン後の最初のページに出るポップアップ。 ユーザーは何かをしに来たのに、あなたがそれを妨げた。閉じるのが唯一の賢明な答えだ。
3. 質問のない「ご意見をお待ちしています!」 話題を考えるところからユーザーに頼んでいる。
4. 誘導質問:「新しいダッシュボードはどのくらい気に入りましたか?」 同意は得られるが、何も学べない。
5. フォローアップのない評価。 10点中6点は気分を伝えるが、何を変えるべきかは伝えない。
6. 聞いたきり、沈黙する。 次の回を失うことになる。これは後で説明する。

製品についての顧客フィードバックは何と呼ぶか

製品についてのフィードバックは通常、プロダクトフィードバックと呼ばれ、二つに分類される。バグ報告は、何かが意図どおりに動いていないことを伝える。機能リクエストは、何かが足りないことを伝える。この区別が、誰が最初に見るかを決める。その線引きは機能リクエストとバグ報告の違いで説明している。三つ目の種類である称賛は、取っておいて、許可を得て引用する価値がある。

最初の選択肢として「バグ」と「機能リクエスト」を提示するフィードバックフォームは、この最初の仕分けを代わりにやってくれる。

回答をどうするか

すべての回答を、チームがすでに作業している場所に、本人の言葉のまま置く。引用した一行のテキストは、あなたによる要約より価値がある。種類とおおよその緊急度でタグ付けし、重複をまとめ、決める。作る、保留する、断る、のどれかだ。

断ることも一つの答えだ。「これは作りません。理由はこうです」と伝えれば待たせることが終わる。その言い方は機能リクエストを断るにある。仕組みの面では、機能リクエストの追跡が、5つのチャネルからのリクエストを一つのリストにまとめる方法を説明している。リクエストを文章で受け付けるなら、機能リクエストのテンプレートが、リクエストを比較可能な形に保つ。

Changeloopのウィジェットは、投稿ごとにGitHubのIssueを作るので、フィードバックはそれを直すコードのすぐ隣に届く。どのツールでもルールは同じだ。リストは一つ、担当者は一人、誰かの受信箱に残されたままの回答は作らない。

なぜリリースしたことを伝えるのか

答えることに時間をかける価値があったと、相手に示せるからだ。何かを伝えて、後から「これがリリースされました、ありがとうございます」と聞いたユーザーには、また答える理由ができる。何も聞かなかったユーザーは、あの入力欄は読まれていないと結論づける。

だから聞くことの最後のステップは返信になる。依頼した一人ひとりに、リクエストがリリースされたときに、本人の言葉で、使ったチャネルで伝える。カスタマーフィードバックループを閉じるでは仕組みを説明している。公開されたチェンジログのエントリがメッセージのきっかけになるので、依頼者に伝わるのは変更が実際に公開されてからだ。Changeloopでは、ウィジェットのフィードバックがGitHubのIssueになり、マージされたプルリクエストがそれを閉じた場合、エントリを承認するとそのIssueに「Shipped」のコメントが投稿され、投稿者にはウィジェットの中でそのエントリが表示される。手作業で立てたIssueや、GitLabとBitbucketのリポジトリには、コメントは付かない。ウィジェットとフィードの設定はドキュメントに載っている。

返信は短くていい。「3月にCSVインポートをご要望いただきました。本日公開されました。使い方はこちらです。」それは次の最良の質問、つまり必要なことをカバーできているかどうかを聞く機会にもなる。

最初の計画

冒頭の表から、ユーザーが最も成功するか諦めるかの場面を一つ選ぶ。それ用の質問を一つ書き、一つのチャネルに置き、二つ目のプロンプトを加える前に二週間、すべての回答を読む。具体的なことを教えてくれた人には必ず返信する。

FAQ

顧客にはどのくらいの頻度でフィードバックを求めるべきか? カレンダーではなくイベントに紐づけて聞く。ユーザーに見せるプロンプトは週に一回まで、回答直後には出さない。フィードバックの次に送るメッセージは、それがどうなったかについての返信であるべきだ。

ユーザーを煩わせずにフィードバックを求めるには? タスクの後に聞き、途中では決して聞かない。質問は一つに絞り、簡単に閉じられるようにする。閉じられたら、数週間はその意思を尊重する。

フィードバックにインセンティブを用意すべきか? たいていは必要ない。具体的な質問と目に見える返信のほうが、ギフトカードより重みがあり、インセンティブは報酬が目当ての人を引き寄せる。取っておくのはインタビューで、相手の20分をお願いする場面だ。

誰も答えてくれない場合は? 質問を絞り、場面にもっと近づける。たとえば一つの画面について、使った直後に聞く。それでも静かなら、数人のユーザーに直接メールを送り、その会話を使ってより良いプロンプトを書く。

この記事の技術的な記述は第三者による確認を受けていません。誤りがあればお知らせください。修正します。

changeloopの関連ページ： 開発者向けドキュメント