これが重要な理由
それぞれのリクエストのステータスはフィードバックアプリを通して確認でき、チームや訪問者にも見えるので、それぞれのフィードバックに対する計画が一目でわかります。お客様とチームユーザーは、フィードバックでリクエストステータスを更新するたびに（オプションで）メール通知を受け取ることができます。各ステータスにはフィードバック内で特定の機能を持つため、通常リクエストのライフサイクルは同じですが、組織の言語に合わせてステータス名を編集できます。
ステータスレスポンスを使用して、ステータスに詳細を追加し、お客様に対して適切な期待値を提示できるようにします。ステータスレスポンスの設定および使用方法の詳細については、こちらをご覧ください。
警告：ローカライズされた言語（フランス語、オランダ語、ドイツ語）でフィードバックを使用している場合、アプリ内で各言語用のカスタムステータスを定義することはできません。必要な場合は、help@pendo.ioまでお問い合わせください。セットアップのお手伝いをいたします。
概要
フィードバックのリクエストには6つのステータスオプションがあります。デフォルトのステータスは以下となります：
各ステータスにはフィードバック内でそれぞれの機能と色を持ち、関係者にとって素早く簡単に理解できる必要があります。ステータスは、次のようなリクエストが見つかった場合は常にアプリ全体に表示されます：
- チームダッシュボード＆訪問者ダッシュボード
- 参照ページ＆レポートページ
- ステータス更新時に送信されるメール通知
- Salesforceインテグレーションを含む、設定されているすべてのインテグレーション
フィードバックの更新の消費するユーザーが、自分のリクエストで何が起こっているのかの概要をすばやく確認できるように、各ステータスの意味を明確にすることが重要です。より細かいニュアンスや詳細なステータスレスポンスについては、そのユーザーがリクエストページをクリックして詳細を確認できます。
社内ユーザーがリクエストのステータスを更新する場合、そのユーザーには適切な権限が必要です。権限の詳細はこちらをご覧ください。
ステータス名のカスタマイズ前に必要なもの
1.フィードバックのワークフロー
ステータス名をカスタマイズする前に、フィードバックワークフローがどのように表示されるかを決定します。これは、ワークフローが特定のステータスの表現方法に影響を与える可能性があるためです（例：受信リクエストを定期的にレビューしていない場合など）。
2. プロダクトフィードバックポリシー
フィードバックポリシーでは、お客様がフィードバックを送信した後に何が期待できるかがわかるように、フィードバックのワークフローとリクエストのライフサイクルの概要を提供する必要があります。
3. 社内教育と一貫性
それぞれのステータスが何を意味し、どのような状況で使用されるべきか、チームが一致していることを確認し、お客様と関係者がプロダクトライン全体で一貫した体験とメッセージを得られるようにします。
デフォルトのステータスとその機能
未レビュー（Not Reviewed）
このステータスの意味
これは、リクエストが最初にアカウントに届いたときのステータスです。これは、このフィードバックがまだレビューされていないことを訪問者に示すもので、チームに返答が必要であることを知らせます。
表示場所
新規リクエストや［未レビュー］リクエストは、訪問者ダッシュボードを含め、アプリ全体に表示されます。このステータスのリクエストは、デフォルトでレポートに含まれます。
このステータスは、［リクエストモデレーション（Request Moderation）］設定と関連しています。リクエストモデレーションを有効にすると、このステータスのリクエストはエンドユーザーには表示されず、ステータスが更新された場合にのみ表示されるようになります。この設定の詳細については、こちらをご覧ください。
ベストプラクティス
導入するフィードバックワークフロー、特にトリアージ段階では、このステータスをどのように表現するかに影響します。
トリアージの最も一般的な方法は、新しいリクエストをすばやくレビューし、ステータスを［フィードバック待ち（Awaiting Feedback）］に変更することです。こうすることで、リクエスト送信者にメールが送信され、フィードバックを受け取ったことが通知されます。
大量のフィードバックを受け取り、受信データを定期的にレビューできない場合は、すべてのリクエストを無期限で［未レビュー］ステータスのままにしておくことをお勧めします。
どのワークフローが最も適切かを決定し、それをプロダクトフィードバックポリシーに明確に文書化します。2番目のトリアージ方法がワークフローに適している場合は、ステータス名が関係者に対して適切な期待を示していることを確認します。［新規（New）］または［未レビュー］は、何らかのアクションが必要であることを示しています。この場合は、代わりに［投票受付中（Open for Voting）］などを採用します。
例
新規（New）
レビュー待ち（Awaiting Review）
投票受付中（Open for Voting）
ステータス：レビュー待ち
このステータスの意味
このステータスは、フィードバックを受け取っているが、決定を下す前にさらにデータが必要であることをリクエスト送信者に示すものです。これにより他の関係者は、需要を測定中で、そのリクエストが投票とコメントを受付中であることがわかります。
表示場所
［フィードバック待ち］ステータスのリクエストは、訪問者ダッシュボードをはじめとするアプリ全体で確認できます。この段階のリクエストは、デフォルトでレポートに含まれます。
リクエストモデレーション（Request Moderation）設定をオンにすると、リクエストがこの新しいステータスに進むと表示されます。
ベストプラクティス
［フィードバック待ち］にあるすべてのリクエストは、ライブラリのようなものだと考えてください。各アイテムを毎日チェックする必要はありませんが、製品に取り組む準備ができたとき、ストーリー、ユースケース、データをここで確認できます。
会社にとって、フィードバックのほとんどが［フィードバック待ち］の状態のまま何か月も何年も続いたとしても、想定内であって全く問題ありません。したがって、このステータスの表現がユーザーにとって明確であり、期待値が適切に示されていることを確認してください。ステータスレスポンスを使って、さらに詳細な情報とコンテキストを追加します。
例
投票受付中（Open for Voting）
承認済み（Acknowledged）
データ収集中（Gathering Data）
ステータス：計画済み（Planned）
このステータスの意味
［計画済み］リクエストは、開発対象のリクエストです。お客様のリクエストがプロダクトビジョンに沿っていることをお客様に伝え、次に取り組むべきことをチームに示すことができます。
表示場所
［計画済み］ステータスのリクエストは、訪問者ダッシュボードをはじめとするアプリ全体で確認できます。この段階のリクエストは、デフォルトでレポートに含まれます。
今後の予定レポートには、このステータスのリクエストが自動的に入力されます。これにより、関係者におおまかなロードマップを伝えるための、簡単でメンテナンスの少ない方法が得られます。
ベストプラクティス
「計画済み」の意味について社内で一貫性のある認識を持ち、お客様が何を期待できるかを明確にします。
このステータスは、単にアイデアが気に入っていて、将来のビジョンと一致していることを示しているだけですが、必ずしも優先順位が高いわけではなく、長い間あるいは将来にわたってロードマップに載らない可能性もあります。
これは、このアイデアに興味を持っていて、例えばアイデアを調査するためにリソースを投入しようと計画しているが、調査結果に応じて優先順位が下がる可能性もあることを意味しています。
より慎重なアプローチとしては、何かを確実に開発することがわかっていて、ロードマップでそれを示すことが確実である場合にのみ、このステータスを使用することです。
どのような意味を選択しても、チームが一貫してそのステータスを使用しており、その意味がお客様にとって明確であることを確認してください。ステータスレスポンスとロードマップを使用して、より明確な情報を提供してください。
例
ビジョンとの一致（Aligns to our Vision）
検出時（In Discovery）
コミット済み（Committed）
ロードマップ上（On the Roadmap）
ステータス：開発中（Building）
このステータスの意味
［開発中］リクエストは文字どおり開発中のリクエストであるため、このステータスは通常［計画済み］と［リリース済み（Released）］の間の一時的なものになります。しかし、お客様やチームメンバーに現在作業中の内容を知らせるためには重要なものです。
表示場所
［開発中］ステータスのリクエストは、訪問者ダッシュボードをはじめとするアプリ全体で確認できます。この段階のリクエストは、デフォルトでレポートに含まれます。
今後の予定レポートには、このステータスのリクエストが自動的に入力されます。これにより、関係者におおまかなロードマップを伝えるための、簡単でメンテナンスの少ない方法が得られます。
ベストプラクティス
このステータスは、開発者が何かの作業を開始し、お客様がその結果得られた機能を使用できるようになる場合にのみ使用してください。
リクエストが開発中の機能と正確に一致していなくても、同じ問題を解決できると考えられる場合は、すべての関連リクエストを［開発中］に移行することは問題なく、推奨されることです。ステータスレスポンスにコンテキストや明確な説明を追加してください。
例
開発中（In development）
進行中（In Progress）
設計中（Under Construction）
ステータス：リリース済み（Released）
このステータスの意味
［リリース済み］リクエストは、開発および公開され、製品に実装されたリクエストです。
表示場所
リクエストは訪問者ダッシュボード表示されなくなり、代わりにリリースログに移動します。このステータスのリクエストは、デフォルトではレポートに表示されなくなりますが、オプションで含めることができます。
ベストプラクティス
［リリース済み］は、エンジニアが機能の作業を完了し、関係者にその機能が使用可能であることを知らせる場合に使用します。すでに存在する機能に関するリクエストを受け取ったときも、このステータスを使用できます。
どちらの場合も、その機能がどこにあり、どのように使用すべきかを説明することで、ユーザーを教育し、導入を促進するためにステータスレスポンスを調整してください。
例
完了（Done）
提供済み（Delivered）
利用可能（Available）
ステータス：却下（Declined）
このステータスの意味
［却下］リクエストは、開発する意思のないアイデアに使用されます。これは、リクエストが製品ビジョンとまったく一致していない場合や、すでに適切な回避策を提供できる場合などが考えられます。
表示場所
［却下］リクエストは訪問者のダッシュボードには表示されませんが、同様のリクエストが提示された場合は表示されます。訪問者は投票を追加できなくなりますが、コメントを追加できます。
このステータスのリクエストは、デフォルトではレポートに表示されなくなりますが、オプションで含めることができます。
ベストプラクティス
機能を開発できない、または開発しないことがわかっている場合は、お客様に対して透明性を保つようにします。ただし、リクエストに価値がない理由については、ステータスレスポンスでできる限り詳細に説明してください。
却下したリクエストを削除しないでください。あるユーザーがある機能について問い合わせた場合、他のユーザーも同様の経験や要望を持っている可能性があります。
却下したリクエストについて透明性を保つことには、いくつかの利点があります。
- 規模の設定。すべてのお客様がプロダクトビジョンを理解し、特定のプロダクトエリアや問題領域に投資しない理由を理解できるようにします。あるユーザーにとって良いことであれば、他のユーザーにとっても役立つ可能性があります。
- 摩擦の低減。ユーザーは、何かが確実に開発されていないかどうかを知りたがっています。意思決定を説明し、代わりに投資している分野に注意を向けることで、関係者を味方につけることができます。
- データ収集の継続。議論を続けることを許容することで、リクエストが突然再浮上して大量のトラフィックを得た場合に、リクエストを再検討するという選択肢を残しておくことができます。
例
クローズ済み（Closed）
検討外（Not being considered）
非対応（No action）
リクエストステータス名のカスタマイズ
フィードバックアカウントのリクエストステータスの名前を変更するには、［設定（Settings）］>［プロダクト設定（Product Settings）］へと進みます。
そこから下にスクロールして［リクエストステータスのカスタマイズ（Custom Request Status）］を選択します。
ここでステータス名を編集し、一番下にある［変更を保存（Save Changes）］をクリックします。
変更を保存すると、確認ウィンドウが表示されます。［確認して適用（Confirm & Apply）］をクリックして変更を適用します。変更がアプリ全体に反映されるまで数秒かかります。
警告：［確認して適用（Confirm & Apply）］クリックすると、ステータスがアプリ全体に反映され、Pendoフィードバックにアクセスできる人なら誰でも閲覧できます（アクセス権がある場合はお客様も）。
実践編：ステータスの更新
ステータスがすべて設定され、ワークフローが確立されて、チームのトレーニングが終わったら、リクエストのライフサイクルに沿ってリクエストが移動したことを、独自のステータスでユーザーに知らせることができるようになります。
リクエストのステータスを変更する方法については、こちらをご覧ください。