送られてくるすべてのリクエストに対応する必要はありませんが、Pendo Feedbackをアイデア探索やデータ主導のプロダクトの決定を行うためのデータライブラリとして利用することをお勧めします。
この記事では、リクエストを確認および管理する方法、リクエストを拒否するタイミング、サポートチームへのリクエストの処理方法、およびリクエストに対する役に立たないコメントへの処理方法についてまとめています。
リクエストの確認とグループ化
リクエストをグループ化する方法は複数あり、以下の組み合わせも可能です。
- アプリ。 リクエストが関連付けられているアプリケーション。
- プロダクトエリア。 アプリ内の具体的な場所または機能。プロダクトエリアの作成と使用方法については、Feedbackのプロダクトエリアを参照してください。
- ステータス。 Feedbackワークフロー内のリクエストの位置。ステータスの使い方やカスタマイズ方法については、リクエストステータスの更新とステータス名のカスタマイズをご覧ください。
- タグ。リクエストを分類するために与えられるラベル。タグの作成と使用方法については、Feedbackでのタグ付けを参照してください。
- 担当者。リクエストを処理または所有する人。リクエストを割り当てる方法については、 リクエストのトリアージを参照してください。リクエストを割り当てる方法としてプロダクトエリアを使用することもできます。
- 可視性。リクエストに与えられる可視性のレベル。
参照(Browse)ページ は、リクエストを表示し整理するのに最適な場所です。参照ページでは、すべてのリクエストを表形式で表示しています。このビューを編集して自分に関連するリクエストを表示し、作成したビューを保存して再確認することができます。
参照ページから、リクエストのグループを操作することもできます。リクエストのステータスを一括更新し、複数のリクエストの詳細を編集し、複数のリクエストにタグを追加し、チームメンバーに所有権を割り当てます。詳細については、参照(Browse)ページでのリクエストの管理を参照してください。
新しいリクエストへの対応
新しいリクエストを確認および管理するためのいくつかの方法として、リクエストのモデレーション、アプリ内通知、ベンダーダッシュボード、類似性レポート、参照ページを使用できます。
リクエストのモデレーション
リクエストのモデレーションを有効にして、レビューされていない新しいリクエストを顧客に対して非表示にすることができます。これにより、顧客からのフィードバックを受け取る前に、リクエストの処理とトリアージを行う時間を確保することができます。詳細については、 リクエストのモデレーション の記事をご覧ください。
また、顧客のサブセットに対してFeedbackを起動し、新しいリクエストが入らないようにし、タイムスタンプを非表示にし、Feedbackメールからログインリンクを削除することで、可視性が制限されている顧客にFeedbackを起動することもできます。詳細については、 顧客にFeedbackへのアクセスを許可するの記事をご覧ください。
アプリ内通知
Feedbackの通知ページには、まだ返信していないすべてのリクエストとコメントが一覧表示されます。これらのリクエストやコメントには、このページから返信できます。詳細については、アプリ内フィードバック通知の管理の記事を参照してください。
類似性レポート
重複したリクエストや類似のリクエストがないか、受け取ったフィードバックを定期的に確認することをお勧めします。類似性レポートでリクエストをマージして、これを確認することができます。また、参照ページや、個々のリクエストからマージすることも可能です。詳細については、類似するリクエストの処理の記事を参照してください。
参照ページ
デフォルトでは、リクエストは新しいものから順に並べられます。上部のフィルターとキーワード検索を使用して、リストを絞り込むことができます。たとえば、担当者またはプロダクトエリアと同時にステータスでリストをフィルタリングして、自分と自分の担当に関連するリクエストを見つけることができます。詳細については、参照(Browse)ページでのリクエストの管理を参照してください。
ダッシュボード
ベンダーの(社内)ダッシュボードページの[ダッシュボード(Dashboard)]タブには、顧客フィードバックをリアルタイムで管理および対応するためのさまざまな機能が備わっています。最も緊急性の高い顧客のリクエストを特定し、それらの解決に向けた進捗状況を追跡するのに役立ちます。ベンダーダッシュボードで提供される情報の一覧については、Pendo Feedbackの社内ビューをご覧ください。
ベンダーダッシュボードには、カスタマーインサイトタブもあり、エンゲージメントや解約など、顧客のリクエストや行動の傾向を確認できます。詳細については、Feedback内のカスタマーインサイトを参照してください。
対応規模が大きいリクエストの編集
時にはリクエストの対応規模が大きく、開発するには段階的にリリースするしかない場合があります。以下はその例です。
「フィーチャーについてコメントしたり、他のユーザーにタグを付けてコメントで言及したりできるとよいのですが。」
また、すでに一部がリリースされているような大規模な依頼を受けることもあります。これに対処するには、新しいリクエストを作成して元のリクエストにリンクし、リクエストを分割します。
すべての機能ではなく一部の機能が既にリリースされているリクエストがある場合は、次のことができます。
- リリースされていない機能ごとに新しいリクエストを作成します。
- 元のリクエストを[リリース済み]に設定し、プロダクトにすでに追加されている機能を説明するカスタムレスポンスを記述します。他の部分はまだ作業中であることを説明し、「#」の後にリクエストIDを入力して新しいリクエストにリンクします。
- 元のリクエストに興味を持った訪問者を新しいリクエストに追加して、自動的に最新の情報を得られるようにします。
リクエストの却下
機能に対するリクエストの中には、自社の戦略に合わないために、決して開発されることのないものもあります。このような場合は、リクエストを却下することをお勧めします。ステータス更新メッセージで、リクエストされた機能を作る予定はないが、興味はあり、今後のためにそのリクエストをPendo Feedbackに保存しておくことを説明してください。
リクエストを却下しても、そのリクエストはFeedbackから削除されません。チームユーザーは、却下されたリクエストを閲覧ページで見ることができ、リクエストに登録したり、コメントしたり、訪問者を追加したりすることができます。訪問者も、引き続きリクエストに登録し、コメントすることができます。リクエストは訪問者ダッシュボードと優先順位リストからは消えますが、訪問者は類似のリクエストを送信または検索するか、直接のURLがわかれば、リクエストにアクセスすることができます。
却下されたリクエストは、透明性と理解度を高めるために使用できるため、自動的には削除されません。たとえば、同様のアイデアがすでにロードマップにあるためにアイデアを却下した場合、ステータス更新メッセージでこれを伝えることができます。リクエストを却下することで、今後の予定を説明する機会が得られ、同じようなリクエストが行われるのを避けることができます。
却下されたリクエストは、将来、需要の高まりやプロダクト戦略の変更、あるいは満たされていないニーズがある証拠として、関連性が高くなる可能性もあります。たとえば、別の訪問者が、却下されたアイデアの別の使用例を提案し、その提案が将来、より現実的な選択肢となる可能性があります。
以下は、リクエストを却下する場合の例です。
需要が少なく、特別なケース
リクエストされた機能の需要が低い場合、またはリクエストがまれな問題の解決策である場合は、その旨を伝え、最も多くの顧客に役立つ機能に焦点を当てていることを説明します。リクエストがより主観的なもの (ボタンの位置の好みなど) であることもあり、その場合はより詳細な説明をしてください。これにより、他の要件とどのようにバランスを取っているのか、顧客に理解してもらうことができます。
今後のリリースでリクエスト内容が解決される
時には、特定のリクエストを却下しても、リクエスターに対して肯定的な回答ができることもあります。必ずしも要求されたとおりの解決策を提供できなくても、そのニーズを解決するための改良が進行中であることを伝えましょう。
価値が低い、または手間がかかる
リクエストの中には、見た目よりもはるかに複雑で、価値や需要が低いものもあります。その場合、リクエスターが考慮していない影響、またはそれが不可能な理由を説明してください。可能であれば、回避策を提供します。
漠然としている
リクエストの中には、一般的な使い勝手に関するコメントなど、具体的でないものや、その意味が明確でないものもあります。リクエスターには、具体的な使用例と要望を含む、より詳細なリクエストを送信するよう促してください。
サポートのリクエスト
時には、バグレポートや使用方法に関する問い合わせのリクエストを受けることがあるかもしれません。これらは、対応時間や対応策が異なるサポートチームに回してください。サポートチケットのような、すぐに対応しなければならない時間的制約のあるものとは異なり、Feedbackのリクエストは将来を見据えたものであり、組織の内部プロセスに適した周期でレビューすることができるため、規模に合わせて対応できます。
サポートに関連するリクエストは却下して削除し、ステータス更新メッセージでリクエスターにサポートチームを紹介してください。また、プロダクトフィードバックポリシーで、このような問い合わせの送信先を訪問者に知らせることをお勧めします。
役に立たないコメント
削除したくないリクエストに対して役に立たないコメントが寄せられた場合は、コメントを編集または削除した上で、リクエストページから順応性のあるメールを送り、該当するユーザーに通知することができます。
フィードバックがメール内で参照され、リンクされていることを確認するには、コメントが残されているリクエストの詳細ページの[リクエストアクション(Request actions)]の下にある[メールを送信(Send email)]オプションを使用します。
以下は、返信の構成例です。
先日、Feedbackに寄せられたお客様のコメントを削除しました。Feedbackは、ユーザーの皆様から、機能リクエストや解決してほしい問題点などのフィードバックを集めるためのツールです。
お客様のニーズをより深く理解できるように、お客様にはユースケースの投稿、投票、優先順位付け、他のユーザーとの共同作業をお願いしています。このような貢献をしていないコメントや、否定的または軽蔑的な目的で作成されたコメントは、システムをどのように改善すべきかを理解する助けにならないため、削除されます。
また、プロダクトのフィードバックポリシーに注意事項を記載し、役に立たないコメントは削除されることを顧客に知らせることもできます。
よくある質問
フィードバックが多すぎる場合はどうすればいいですか?
Pendo Feedbackでは、「フィードバックが多すぎる」ということはありません。
Pendo Feedbackは、日々のリクエストのバックログを管理するのに役立つように設計されているため、Feedbackレポートの上位に表示されるアイデアに集中できます。バックログの他のリクエストは、将来的に重要になるかもしれませんが、それまでは時間と労力を費やす必要はありません。
収集したフィードバックの管理に時間がかかりすぎると感じている場合は、Feedbackワークフローで、プロセスを効率化するアイデアをご覧ください。また、受信したリクエストはすべて「フィードバック待ち」に移動し、後で処理するようにして、今優先すべき課題に集中することをお勧めします。
もし悪いリクエストを出されたら?
Pendo Feedbackは、良いアイデアは優先順位が高くなり、悪いアイデアはバックログに残るように、リクエストの管理を支援するように設計されています。悪いアイデアは、判断するためのデータが増えるまで「フィードバック待ち」ステータスのままにしておくことができます。リクエストをこのステータスに移行するときは、ステータスメッセージやコメント欄で具体的な質問をすることで、チームや顧客にユースケースを追加するように促してください。詳細については、リクエストステータスの更新およびカスタムレスポンスを保存するをご覧ください。
顧客フィードバックを受け入れると、実装するつもりのないリクエストが寄せられることもあります。リクエストされた機能を開発するつもりがないことが分かっている場合は、この記事のリクエストの却下のガイダンスに従ってください。リクエストが実際はバグレポートや使用方法の問い合わせである場合は、サポートのリクエストのガイダンスに従ってください。