サポートチケット対機能リクエスト：どちらを信じるべきか
1分で読めます
機能リクエストボードは、ユーザーが座って何が欲しいかを説明する時間があるときに要求するものを 捉える。サポートチケットは、ユーザーが今まさに行き詰まっていること、しばしばイライラしながら、 しばしば根底にある要求をきれいに説明する語彙もなく、を捉える。どちらも本物のシグナルであり、 片方だけを見るチームは、それぞれのチャネルが異なるタイプのユーザーと異なるタイプのニーズを 体系的に過剰に代表しているため、最終的に自信を持って間違った問題を解決することになる。 機能リクエストの優先順位付けは、すでにボードに あるものをランク付けすることを扱っている。これは、そもそもボードに届くものと、サポート チケットとしてしか決して現れないものとの間のギャップについてだ。
なぜ同じ根底にある問題が一方のチャネルには現れて、もう一方には現れないのか
二つのチャネルは異なる活性化コストを持ち、そのコストの大きさが誰がそれを乗り越えるかを 決めるからだ。機能リクエストを提出することは主体性を要求する。ユーザーはそのリクエストが 言葉にする価値があると信じ、ボードを見つけ、一貫した何かを書かなければならない。それは、 すでに製品に投資している、関与し忍耐強いユーザーを選別する。サポートチケットを提出すること は、それに比べてほとんど主体性を要求しない。しばしばタスクの途中で「ヘルプ」をクリックする だけであり、それはボードを決して使わないであろうユーザーも含めて、その瞬間にイライラして いるユーザーを捉えることを意味する。製品の本物のギャップは、それに遭遇するユーザーが正式な リクエストを提出する可能性が最も低い人々であるという理由だけで、機能ボードでは見えず、 サポートでは騒がしくなり得る。
欠けている機能のチケット量は、それに対する投票数と同じことを意味するのか
いいえ、異なる条件下で異なる母集団を測定しているからだ。百票の機能リクエストは、既存の リクエストを見つけて支持する時間を取った百人を表しており、それは持続的で熟慮された需要の 強いシグナルだ。同じ期間に提出された、同じ根底にあるギャップに関する百件のサポートチケット は、おそらくその瞬間に壁にぶつかっているユーザーを表しており、そのうちの何人かは、直接的な 摩擦が過ぎればすっかり忘れてしまうだろう。両方を「百人がこれを望んでいる」という同等の シグナルとして扱うことは、チケット量を過大評価する。チケットは生成するのが安価で、投票は そうではないからだ。
| 機能リクエストボード | サポートチケット |
|---|---|
| 提出には主体性が必要 | ほとんど必要ない |
| 熟慮された持続的な需要を捉える | その瞬間のフラストレーションを捉える |
| 関与し忍耐強いユーザーに偏る | ボードを決して使わないであろうユーザーを捉える |
| 投票数は本物のコミットメントシグナル | チケット数は摩擦を反映するが、必ずしも欲求ではない |
機能にサポートチケットはあるがボードにほとんど投票がない場合、それは何を意味するのか
多くの場合、リクエストは存在するが、それに遭遇するユーザーがボードの存在を知らない、投票が 何かを変えると信じていない、または問題にあまりに稀にしか遭遇しないため、正式に登録するために チャネルを切り替える手間をかけないということだ。これはまさに機能リクエストボードが構造的に 見逃す母集団であり、ここでの低い投票数は測定ギャップの証拠であり、低い需要の証拠ではない。 欠けている機能を巡るサポートチケットのクラスターは、チケットを疑うのではなく、投票数だけから 優先順位をつける人にとって見えないままにならないよう、ユーザーに代わって自らボードに記録する 価値のある独自のシグナルとして扱おう。
ボードは低優先度として読める:
"Export to CSV": 6か月で4票
サポートは違う話を伝える:
"Export to CSV": 同じ期間に31件のチケット、それぞれ
異なるアカウントから、それぞれ「現在サポートされて
いません、フィードバックをお伝えします」で閉じられたサポートチケットの急増は常に根底にある問題が欠けている機能であることを意味するのか
いいえ、そしてここで二つのチャネルは逆方向に誤解を招く可能性がある。チケットの急増は、すでに 存在する機能を巡る混乱したインターフェース、バグ、または十分な説明なしにリリースされた変更に よって同じくらい頻繁に引き起こされ、そのどれも新しいものを構築することでは解決されない。 すべてのチケットの急増を「ユーザーは私たちが持っていない機能を望んでいる」と読むことは、 実際にはドキュメントのギャップや変装した使いやすさの問題だったもので満たされたロードマップを 生み出す。サポートチケットは摩擦がどこにあるかを教えてくれる。それ自体では、解決策が新しい 機能なのか、インターフェースの変更なのか、より良いヘルプ記事なのかは教えてくれず、それを 混同することはエンジニアリングの時間を間違った解決策に浪費する。
何を構築するかを決める際、二つのシグナルは実際にはどう組み合わせるべきか
チケットを使って摩擦がどこにあるかを見つけ、ボードが薄い場合は直接のアウトリーチと合わせて 機能リクエストボードを使って、望ましい結果が実際にどう見えるかを確認しよう。チケットの クラスターは本物の、感じられた問題を特定する。それに対して構築できるほど正確に解決策を 特定することはめったにない。サポートの会話で苛立ったユーザーは症状を説明するのであって、 仕様を説明するのではないからだ。機能リクエストボードは、同じ根底にある問題に十分な投票が あるとき、「実際に何がこれを満足させるか」という詳細をより多く運ぶ傾向がある。リクエストを 書くことは、何が間違っているかを報告するだけでなく、何が欲しいかを明確に特定する行為だから だ。
サポートエージェントは自分自身でチケットを機能リクエストとして記録すべきか
はい、そしてこれは二つのチャネル間のギャップに対する単一で最もレバレッジの高い修正だ。 チケットを変装した機能リクエストとして認識するエージェントは、単にそれを解決して先に進む のではなく、顧客に代わってそれをボードに記録することができ、それは顧客が二番目のチャネルを 発見して使用することを要求する代わりに、測定ギャップを直接埋める。これは、記録することが エージェントにとって分単位ではなく秒単位で済む場合にのみ機能し、それによってそれを行う摩擦 が、単にチケットを閉じて次に進む摩擦よりも低くなる。
FAQ
機能リクエストの投票は、すべて一つのアカウントやチームから来ている場合、割り引かれるべきか? はい、生の投票数ではなく、別個のアカウントや組織で重み付けしよう。同じ会社の五人からの五票は、 一つの顧客の優先順位を表しているのであって、五つの独立した需要の確認ではないからだ。
チケットには多く現れるがほとんど投票のない機能を構築する価値はあるか? 多くの場合はい、チケット量が本当に別個のアカウントから来ていて、根底にあるニーズが仮定では なく確認されている限り。低い投票数を、需要が本物でない証拠としてではなく、ボードの活性化 コストの測定上の産物として扱おう。
UIの混乱チケットと本物の機能欠如チケットを一目でどう見分けるか? 解決策が既存の機能を説明することにあるのか、欠けているものを謝罪することにあるのかを見よう。 「ああ、実際そこにありました」という解決のパターンはインターフェースまたは発見可能性の問題を 示し、「それはまだサポートしていません」というパターンは本物のギャップを示す。
この区別は非常に小さなサポート量でも同じくらい重要か? 機械的には重要性が低い。少数のチケットは集計分析を必要とせずに個別に読むのが簡単だからだ。 しかし、チケットはイライラしたユーザーを過剰に代表し忍耐強いユーザーを過小に代表するという 根底にある偏りは、どんな規模でも存在し、自分自身ですべてのチケットを読んでいるときでも 心に留めておく価値がある。
この記事の技術的な記述は第三者による確認を受けていません。誤りがあればお知らせください。修正します。