リクエストのステータス（フィードバック待ち、計画済み、リリース済みなど）を使って、計画と進捗状況をすばやく伝えることができます。ステータスごとにカスタムメッセージを作成できます。こうしたメッセージを使うことで、お客様に今後の予定を正しく把握していただけます。
リクエストのステータスはPendo Feedback全体で、社内チームと訪問者に対して表示されます。Feedbackでリクエストのステータスが更新されるたびに、自動通知メールを送信することもできます。詳細については、Feedbackの通知メールを参照してください。
この記事では以下について説明します。
- 付随するメッセージを含む、リクエストステータスの更新に関するベストプラクティス。
- リクエストのステータスと更新に対するレスポンスを変更する方法。
- ステータスラベルを組織の言語に応じて変更する方法。
Feedbackのデフォルトステータス
Feedbackでは、リクエストに対して6つのステータスオプションがあります。各ステータスには、Feedback内でそれぞれの機能と色があります。デフォルトのステータスは次のとおりです。
- 未レビュー（Not Reviewed）：ライトグレー。これは、新規リクエストのデフォルトのステータスです。
- フィードバック待ち（Awaiting Feedback）：ダークグレー。このステータスで、ユーザーはリクエストを受け取ったことを認識できます。
- 計画済み（Planned）：ブルー。作りたいアイデアに付与されるステータス。
- 開発中（Building）：イエロー。現在取り組んでいるアイデアに付与されるステータス。
- リリース済み（Released）：グリーン。開発され、展開されたアイデアに付与されるステータス。
- 却下（Declined）：レッド。開発する意思のないアイデアに付与されるステータス。
これらのステータスの名前を変更して、フィードバックワークフローに合わせることができます。ステータス名の変更の詳細については、後述のステータス名のカスタマイズを参照してください。
新しいリクエストに関するベストプラクティス
受信したリクエストを発見と調査に使用できるデータのライブラリとして扱うことで、プロダクトに関するデータ駆動型の意思決定が行えます。
リクエストが届くと、自動的に未レビューというステータスが割り当てられます。リクエストが大量にある場合は、リクエストをフィードバック待ちに一括更新し、プロダクトフィードバックポリシーへのリンクを含むステータスメッセージで対応状況を表示することをお勧めします。
新しいリクエストをフィードバック待ちに移動し、 プロダクトフィードバックポリシーにリンクすることで、お客様はフィードバックが受領されたこと、リクエストが投票やその他のデータ収集のためにオープンであることを知ることができます。これによりプロダクトチームは、大きな問題や機会についてより明確なインサイトと展望を持ってユースケースを構築し、意思決定することができます。
新しいリクエストがエンドユーザーに表示されないようにするために、未レビューのステータスに対してリクエストのモデレーションを有効にするか、新しいリクエストに対する会社の同等の文言を有効にすることができます。リクエストのモデレーションを有効にしている場合、リクエストがフィードバック待ちステータス、または次のステータスに相当する会社の文言に進むと、リクエストは再び表示されます。この設定の詳細については、リクエストのモデレーションを参照してください。
ステータスの公開範囲
社内ユーザーには、次のようなリクエストが見つかった場合は、ステータスは常にFeedback全体で表示されます。
- チームと訪問者のダッシュボード。
- 参照ページとレポートページ。
- ステータス更新時に送信されるメール通知。
- Salesforceインテグレーションを含む、設定されているすべてのインテグレーション。
未レビュー、フィードバック待ち、計画済み、開発中のステータスのリクエストは、訪問者ダッシュボードを含む、アプリ全体で確認することができます。これらのステータスのリクエストは、デフォルトでレポートに含まれています。
［今後の予定（What's Coming）］レポートには、計画済み（Planned）や開発中（Building）のリクエストが自動的に入力されるので、おおまかなロードマップを簡単に伝えられます。詳細については、今後の予定（What's Coming）レポートを参照してください。
リリース済み（Released）や却下（Declined）のリクエストは、デフォルトではレポートに表示されませんが、オプションで含めることができます。リリース済みリクエストは訪問者ダッシュボードから［リリースログ（Release Log）］に移動します。詳細については、リリースログを参照してください。却下リクエストは、訪問者ダッシュボードに表示されず、エンドユーザーは投票ができなくなりますが、コメントを追加することはできます。
リクエストのステータスの変更
社内ユーザーはリクエストのステータスを更新するための適切な権限を持っている必要があります。権限の詳細については、チームの管理：Feedbackでの役割と権限を参照してください。
リクエストのステータスは、［参照（Browse）］ページもしくは［レポート（Reports）］ページのどちらからでも更新することができます。これらのページのいずれかに移動した後、次の2つの方法のいずれかでリクエストのステータスを変更できます。
- ページ上のリクエストリストで直接行います。該当するリクエストの横にある［ステータス（Status）］列のドロップダウンメニューから、新しいステータス値を選択します。
- リクエスト自体で関連するリクエストを選択し、右上の ［リクエストステータス（Request status）］ドロップダウンメニューを使用して、新しいステータス値を選択します。
新しいステータスを設定すると、保存されたメッセージを選択するか、その理由をカスタムメッセージユーザーに記入してユーザーに知らせるように促されます。 レスポンスをカスタマイズした場合は、［今後使用するためにレスポンスを保存する（Save response for future use）］を選択して、今後使用するために保存できます。
JIRAアドオンがインストールされている場合は、［JIRAのプロジェクトの下に作成（Create under project in JIRA）］を選択することも可能です。JIRAとPendo Feedbackのインテグレーションについては、JIRAとPendo Feedbackを参照してください。
準備ができたら、［次へ（Next）］を選択して変更を確認します。
ステータスの更新に保存済みのレスポンスを使用する
保存済みのレスポンスを使用すると、リクエストのステータスを更新するときに、更新ごとにレスポンスを入力するのではなく、事前に入力したステータスメッセージを使うことができます。Feedbackには、あらかじめ入力されたレスポンスがいくつか用意されており、そこから選択や編集ができるので、すぐに訪問者のリクエストの更新を開始できます。
警告：ローカライズされた言語（フランス語、オランダ語、ドイツ語）でFeedbackを使用している場合、アプリ内で各言語用のカスタムステータスを定義することはできません。必要な場合は、Pendoサポートまでお問い合わせください。セットアップのお手伝いをいたします。
保存済みレスポンスの追加
複数の保存済みレスポンスを追加するには：
- 左側のメニューで、［設定（Settings）］>［プロダクト設定（Product Settings）］>［カスタムレスポンス（Custom Responses）］を選択します。
- ［カスタムレスポンス］で［カスタムレスポンスの作成（Create a Custom Response）］を選択します。
- 該当するステータスを選択します。
- ステータスに追加するメッセージを入力します。
- ［作成（Create）］を選択して、メッセージを保存します。
保存済みレスポンスの編集
保存済みレスポンスを編集するには：
- 左側のメニューで、［設定（Settings）］>［プロダクト設定（Product Settings）］>［カスタムレスポンス（Custom Responses）］を選択します。
- ［カスタムレスポンス］で［カスタムレスポンスの作成（Create a Custom Response）］を選択します。
- ［ステータスレスポンスのメッセージ（Status responses for）］で、対応するステータスの横にある［編集（Edit）］を選択します。
- メッセージを更新します。
- ［更新（Update）］を選択して、メッセージを保存します。
保存済みレスポンスの無効化
独自のカスタムレスポンスを追加した後に、Feedbackのデフォルトレスポンスを無効にできます。これで、レスポンスのステータスを更新した時に、カスタムレスポンスのみがユーザーに表示されます。これは、保存済みレスポンスがすでに設定されている場合にのみ有効です。
Feedbackのデフォルトのレスポンスを無効にするには：
- 左側のメニューで、［設定（Settings）］>［プロダクト設定（Product Settings）］>［カスタムレスポンス（Custom Responses）］を選択します。
- ［デフォルトレスポンス（Default Responses）］セクションで、［デフォルトレスポンスの非表示（Hide default responses）］の横にあるボックスを選択します。
ステータス名のカスタマイズ
Pendo Feedbackが提供するデフォルトのステータス名を使用する必要はありません。各ステータスはFeedbackの中で特定の機能を持つため、リクエストのライフサイクルは変わりませんが、組織の用語に合わせてステータスの名前を変更することができます。
ステータス名のカスタマイズに関するガイダンスと推奨事項については、ステータス名の変更に関するベストプラクティス を参照してください。
前提条件
Feedbackワークフロー（特に、レビューとトリアージフェーズ）は、ステータスの表現方法に影響します。ステータスの名前を変更する前に、チームにとって最も意味のあるワークフローを決定し、このプロセスをプロダクトフィードバックポリシーに明確に文書化する必要があります。 送信者とのやり取りにポリシーへのリンクを追加することを強くお勧めします。
プロダクトライン全体で一貫したメッセージを発信するためには、ワークフローを明確に定義した上で、それぞれのステータスが何を意味し、どのような場面で使われるのかを社内で調整してください。
リクエストステータスの名前の変更
警告：このプロセスに従うと、ステータスは、アクセス権を付与したユーザーを含め、Pendo Feedbackにアクセスできるすべてのユーザーに表示されます。
Feedbackアカウントでリクエストステータスの名前を変更するには：
- ［設定（Settings）］>［プロダクト設定（Product Settings）］>［リクエストステータスのカスタマイズ（Custom Request Statuses）］に移動します。
- ［リクエストステータスのカスタマイズ］で、Feedbackのワークフローに従ってステータス名を編集します。
- ［変更を保存（Save Changes）］を選択します。
- 確認ウィンドウで［確認して適用（Confirm & Apply）］を選択します。
ステータス名の変更がアプリ全体に反映されるまで、数秒かかることがあります。
ステータス名の変更に関するベストプラクティス
このセクションでは、Feedbackで確立されたリクエストのトリアージ（優先順位付け）のプロセスに基づき、ステータスの名前を変更するためのいくつかのガイダンスを提供します。詳細については、Feedbackのワークフローを参照してください。
ステップ1：レビューとトリアージのプロセスを確立する
ステータスにどのように名前を付けるかはFeedbackのワークフロー、特にレビューやトリアージのプロセスに依存します。レビューとトリアージのプロセスを確立するためには、次のことを決定する必要があります。
- 誰がどのプロダクトエリアを担当するか。
- プロダクトエリアに対応するリクエストを誰がレビューするか。
- アカウントを所有し、トリアージを行う専任のプロダクトオーナーやFeedbackマネージャーを置くかどうか。
レビューやトリアージのプロセスの設定など、Feedbackのワークフローの作成に関する詳細については、Feedbackのワークフローを参照してください。プロダクトエリアの設定や使い方に関する詳細は、Feedbackのプロダクトエリアを参照してください。
ステップ2：ステータスを定義する
このセクションでは、レビューやトリアージのプロセスで定義された方法に基づいてステータスの名前を変更するためのベストプラクティスのアドバイスを提供します。
未レビュー
未レビュー（Not Reviewed）のステータスは、リクエストがまだレビューされていないことをユーザーに示し、チームにレスポンスが必要であることを知らせます。
このステータスの一般的な代替名には、レビュー待ち（Awaiting Review）や新規（New）があります。しかし、これらのステータス名は、あなたがすべてのリクエストを定期的にレビューし、あなたの側でアクションが取られることを意味しています。
大量のフィードバックがあった場合は、次のような方法があります。
- 新しいリクエストは、十分な投票数を得るまでこの初期ステータスのままにしておき、ステータスの名前を変更することで、ユーザーと異なる期待水準を設定することができます。たとえば、ステータスを未レビュー（Not Reviewed）ではなく、投票受付中（Open for Voting）に変更することができます。
- Feedbackのワークフローに基づいた高水準の期待を設定するために、リクエストのステータスをフィードバック待ち（Awaiting Feedback）に更新するか、保存したカスタムメッセージを添えて、このステータスに対応する組織の用語に一括で更新することができます。
フィードバック待ち
フィードバック待ち（Awaiting Feedback）のステータスは、リクエストを受け取り、決定を行う前にさらにデータを収集していることをユーザーに示します。このステータスは、需要を測定中で、そのリクエストが投票やコメントを受付中であることを示します。
これらのリクエストは毎日チェックする必要はありません。 フィードバック待ち（Awaiting Feedback）のすべてのリクエストは、データ、ストーリー、ユースケースのライブラリとして扱うことができ、プロダクトに取り組む準備ができたときに再訪することができます。フィードバックは長期間このステータスのままにしておくことができるので、名前の変更には意味があります。
このステータスの一般的な代替名には、投票受付中（Open for Voting）や承認済み（Acknowledged）、データ収集中（Gathering Data）があります。このステータスを明確にするために、このステータスに対するレスポンスを設定し、このメッセージにプロダクトフィードバックポリシーを記載することをお勧めします。
計画済み
計画済み（Planned）ステータスの使用は、慎重に行うことをお勧めします。このステータスを使うのは、何かを確実に開発することがわかっていて、ロードマップでそれを示すことが確実である場合のみにしてください。
このステータスにあまり明確な意味がない場合は、その意味を明確にするためにステータスの名前を変更することができます。たとえば、あるアイデアを調査し、その調査結果に基づいてアイデアの優先順位を下げたい場合があります。この場合、このステータスの名前を検出時（In Discovery）に変更するのが有効な場合があります。また、あるアイデアはビジョンに合致していても、優先順位が低い場合もあります。この場合、ステータスの名前をビジョンとの一致（Aligns to our Vision）に変更することをお勧めします。
このステータスをどのような目的で使用するにしても、チームは このステータスを一貫して使用し、その意味がユーザーにとって明確になるようにする必要があります。このステータスの一般的な代替名には、ビジョンとの一致（Aligns to our Vision）やコミット済み（Committed）、ロードマップにあり（On the Roadmap）があります。
このステータスについては、プロダクトフィードバックポリシーへのリンクも含んだステータスメッセージで、より詳しい情報を提供することをお勧めします。
開発中
開発中（Building）のステータスは、現在取り組んでいるものを示します。このステータスは、開発者が何かの作業に着手し、最終的にユーザーがその機能を使えるようになることがわかっている場合にのみ使用します。
開発中の機能と完全には一致していないが、同じ問題を解決したり、同じニーズを満たしたりできる場合は、関連するすべてのリクエストをこのステータスに移行することをお勧めします。また、ステータスレスポンスでこの理由を説明することをお勧めします。
計画済み（Planned）やリリース済み（Released）の中間的なものとしての、ステータスの一般的な代替名には、開発中（In development）や進行中（In Progress）、設計中（Under Construction）などがあります。
リリース済み
リリース済み（Released）のステータスは、プロダクトにリクエストが反映されたことを示します。このステータスは、エンジニアがその機能の作業を完了し、その機能が使用可能であることを知らせる場合に使用します。また、すでに存在する機能に関するリクエストを受け取ったときも、このステータスを使用できます。
いずれの場合も、ユーザーを教育し、定着化を促進するために、ステータスレスポンスをカスタマイズすることをお勧めします。その機能が何であるか、どこにあるか、どのように使うかを説明します。
このステータスの一般的な代替名には、完了（Done）や提供済み（Delivered）、利用可能（Available）などがあります。
拒否
却下（Declined）のステータスは、リクエストを実装する予定がないことを示します。これは、リクエストがプロダクトのビジョンと合致していない、すでに回避策がある、あるいはリクエストがアイデアや提案ではなくバグである、などの理由が考えられます。
理由の如何にかかわらず、次を推奨します。
- 機能を開発できない、もしくは開発しないことがわかっている場合に、ユーザーに対する透明性を確保します。
- リクエストに価値を認められない理由について、ステータスレスポンスにできる限り詳細を追加します。
- 却下したリクエストを削除しないでください。あるユーザーから問い合わせがあった機能は、他のユーザーも同様の経験や要望を持っている可能性があります。
却下したリクエストについて透明性を保つことには、いくつかの利点があります。
- 規模が設定される。すべてのお客様がプロダクトのビジョンを理解し、特定のプロダクトエリアや問題領域に投資しない理由を理解できるようにします。あるユーザーにとって有益な情報は、他のユーザーにも役立つ可能性があります。
- 摩擦が低減する。ユーザーは、確実に開発されていないものが何かを知りたがっています。意思決定を説明し、代わりに投資している分野に注意を向けることで、関係者を味方につけることができます。
- 継続してデータが収集される。議論を続けることを許容することで、リクエストが突然再浮上して大量のトラフィックを得た場合に、リクエストを再検討するという選択肢を残しておくことができます。
このステータスの一般的な代替名には、クローズ済み（Closed）や検討外（Not being considered）、非対応（No action）などがあります。