顧客を失わずに機能リクエストを断る方法とは
1分で読めます
ループを閉じるとは通常、誰かに彼らのリクエストが出荷されたと伝えることを意味する。ほとんどの追跡システムがまったくプロセスを持っていない難しい半分は、ノーと言うことだ。ほとんどの機能リクエストは決して出荷されず、それは製品が利用者に本当に負っているループの閉じ方のほとんどが、発表ではなく拒否であることを意味する。そして下手に扱われた拒否は、沈黙が費やしたであろうより多くの好意を費やす。うまく扱われれば、ほとんど何も費やさないかもしれない。なぜなら、リクエストした人がほとんどの場合最も望んでいるのは、自分が聞き届けられたと知ることであり、機能そのものではないからだ。
なぜうまく断ることは、うまく出荷することと同じくらい重要なのか
沈黙は説明のない拒否として読まれ、説明されたノーは配慮として読まれるからだ。何も聞かない人は、リクエストが無視されたか失われたかのどちらかだと想定し、どちらの結論も、彼女にわざわざ尋ねるのをやめるよう教えてしまう。それは製品が本物の拒否から得るのと同じ結果であり、ただより遅く、途中でより多くの恨みを伴って到達するだけだ。明確に、理由とともにノーと言う返答は、出荷された機能と同じくらい完全にループを閉じ、それをより速く行う。
| 返答 | リクエストした人が学ぶこと | 関係へのコスト |
|---|---|---|
| 沈黙 | 誰も読まなかった、あるいは誰も気にしない | 高く、今後のリクエストごとに積み重なる |
| 理由のない自動返信 | どこかのキューに無期限に入っている | 中程度、時間は稼ぐが信頼は稼がない |
| 理由付きの拒否 | 読まれ、検討され、返答された | 低い、理由が誠実であれば |
| 代替案付きの拒否 | 本当の必要が本当に聞き届けられた | 最も低い、しばしば信頼を築く |
何が拒否を悪い着地にするのか
ほぼ常に三つのことが組み合わさっている。一般性。実際に何が求められたかに言及しない定型の「フィードバックをありがとう」は、実際には読まれていたとしても、まったく読まれなかったように読める。遅延。リクエストした人がすでに尋ねたことを忘れた頃、リクエストの六か月後に届く拒否は、迅速なノーよりも悪く感じられる。なぜなら、それは検討されて拒否されたのではなく、リクエストが手をつけられずに放置されていたことを示唆するからだ。そして持ちこたえない理由。「私たちのロードマップにはない」は何にも答えていないが、「それは今年触れる予定のない権限の仕組みの再設計を必要とする」は、リクエストした人に、実際に評価でき、十分重要ならエスカレートしたり回避したりできるものを与える。
良い拒否は実際に何を言うべきか
この順序で四つのこと。一般的な言い換えではなく、具体的なリクエストを名指しする承認。正直な理由。たとえ正直な理由が「これは製品の向かう方向に合わない」というより柔らかい言い訳であっても、正直に述べられたもの。ドアが閉じているのか、それとも今はただ開いていないだけなのか。これらは非常に異なるトーンを必要とするからだ。そして存在するなら、文字通り求められた機能ではなくても、根底にあるニーズに応える代替案。
こんにちは、Jamie
チームの招待にCSV一括インポートを追加するリクエストをありがとう
ございます。検討しましたが、それは構築しません。私たちの招待フロー
はセキュリティ上の理由から各新メンバーの個別レビューを中心に構築
されており、一括インポートは見落としではなく設計上それに反する
ことになります。
もし本当の問題が大きなチームを素早く招待することなら、APIはスクリプト
化された個別招待をサポートしていて、レビューを回避することなく
ほぼすべての速度を提供します: [リンク]。設定のお手伝いが必要なら
お知らせください。これがテンプレートにできないことをしている点に注目してほしい。実際の機能を名指しし、あいまいな方針ではなく実際の設計判断に結びついた理由を与え、単にチケットを閉じるのではなく根底の問題を解決する道を提供している。
これは出荷された機能でループを閉じることとどう違うのか
仕組みは似ているが、トーンは違う。顧客とのフィードバックループを閉じるは出荷されたケースを扱っていて、そこではメッセージは良い知らせであり、主なリスクは送るのを忘れることだ。拒否は悪い知らせ、あるいは少なくとも望まれない知らせであり、与えられる理由により多くの注意を、配信においてより少ない自動化を必要とする。出荷された機能の通知は、ステータス変更によってトリガーされる定型のコメントで構わないが、定型として読める拒否は、このアプローチ全体が避けようとしているまさにその失敗モードだ。それでも両者は一つの要件を共有している。元のリクエストはリクエストした人と結びついたままでなければならず、それは機能リクエストの追跡が扱っているのと同じ追跡の規律であり、そうでなければどちらのメッセージも個別に送る方法がない。
拒否は公開ロードマップ上のステータスのように公開されるべきか
通常は具体的な理由ではなく、ステータスはそうかもしれない。公開ロードマップは、リクエストした人が再度尋ねることなく確認できるステータスラベルを扱っていて、「拒否済み」や「計画外」というステータスはそのシステムの一部になり得る。しかし詳細な理由は、特に内部の優先順位や好ましくない文脈に触れる場合、通常は公開のステータスページよりも個別の返答の方が価値がある。そこでは同じ言い回しが、実際に尋ねたただ一人ではなく、すべての読者に対して機能しなければならないからだ。
拒否されたすべてのリクエストは個別の返答に値するか
名前のある、連絡可能な人からのすべてのリクエストは、少なくとも短いものでも値する。大量、重複、匿名のリクエストは例外だ。類似のリクエストをグループ化してグループごとに一度返答すること、あるいは共有のステータスラベルを更新することは、個別の返答が本当にスケールしないときには理にかなっている。守るべき境界線は、「全員に個別に返答することはできません」が、実際の量に照らして確認された本物の運用上の制約であるべきで、二分で済んだはずの返答を飛ばすためのデフォルトの言い訳であってはならないということだ。
FAQ
弱い理由で素早く断るのと、良い理由のために時間をかけるのとではどちらが良いか? 正直な理由で素早く、が両者を別々に上回る。たとえ短くても本物の理由を伴う素早い返答は、磨き上げられた理由を伴う遅い返答より優れている。遅延そのものが信頼を損なうものの一部だ。
拒否はリクエストを後で再検討すると約束すべきか? それが本当にありそうで、計画サイクルでそれを再浮上させるラベルのような、実際に再検討する仕組みがある場合に限る。そのような仕組みなしの曖昧な「心に留めておきます」は、機能的には沈黙と同じであり、より親切に言い換えられているだけだ。
正直な理由が競争上の懸念のような、会社が共有できないことである場合はどうか? より柔らかい理由をでっち上げるのではなく、それを直接言うこと。「ここでは具体的な理由をお伝えできませんが、これは私たちが構築を計画しているものではありません」は、フォローアップの質問で崩れるでっち上げの説明より、より正直で、より尊重される。
リクエストを拒否することは、それを追跡から削除すべきことを意味するか? いいえ。理由とともに拒否済みとラベル付けして保持しておくこと。それが次の類似リクエストがグループ化されるパターンの一部になるようにし、後で変わった文脈(新しい統合、新しいチームの優先順位)が評価をゼロから始める代わりにそれを再浮上させられるようにするためだ。
この記事の技術的な記述は第三者による確認を受けていません。誤りがあればお知らせください。修正します。