Tiket dukungan vs. permintaan fitur: mana yang Anda percaya?

Papan permintaan fitur menangkap apa yang diminta pengguna saat mereka punya waktu untuk duduk dan menjelaskan apa yang mereka inginkan. Tiket dukungan menangkap di mana pengguna terjebak sekarang, sering jengkel, sering tanpa kosakata untuk menjelaskan dengan rapi permintaan yang mendasarinya. Keduanya adalah sinyal nyata, dan tim yang hanya melihat salah satunya akhirnya menyelesaikan masalah yang salah dengan percaya diri, karena setiap kanal secara sistematis terlalu mewakili jenis pengguna yang berbeda dan jenis kebutuhan yang berbeda. Memprioritaskan permintaan fitur membahas peringkat apa yang sudah ada di papan; ini tentang kesenjangan antara apa yang sampai ke papan sama sekali dan apa yang hanya pernah muncul sebagai tiket dukungan.

Mengapa masalah yang mendasari sama bisa muncul di satu kanal dan tidak di kanal lain?

Karena kedua kanal punya biaya aktivasi berbeda, dan besarnya biaya itu menentukan siapa yang melewatinya. Mengajukan permintaan fitur butuh inisiatif: pengguna harus percaya bahwa permintaan itu layak diungkapkan, menemukan papannya, dan menulis sesuatu yang koheren, yang menyeleksi pengguna yang terlibat dan sabar yang sudah berinvestasi dalam produk. Mengajukan tiket dukungan hampir tidak butuh inisiatif dibandingkan itu, sering hanya klik “bantuan” di tengah tugas, yang berarti itu menangkap pengguna yang frustrasi saat itu, termasuk mereka yang tidak akan pernah repot dengan papan permintaan fitur sama sekali. Kesenjangan nyata dalam produk bisa tidak terlihat di papan fitur dan ribut di dukungan hanya karena pengguna yang mengalaminya adalah yang paling kecil kemungkinannya mengajukan permintaan formal.

Apakah volume tiket untuk fitur yang hilang berarti sama dengan jumlah suara untuk itu?

Tidak, karena keduanya mengukur populasi berbeda dalam kondisi berbeda. Permintaan fitur dengan seratus suara mewakili seratus orang yang meluangkan waktu untuk menemukan dan mendukung permintaan yang sudah ada, yang merupakan sinyal kuat permintaan yang bertahan dan dipertimbangkan. Seratus tiket dukungan tentang kesenjangan yang mendasari sama, diajukan dalam periode yang sama, kemungkinan mewakili pengguna yang menabrak tembok saat itu, beberapa di antaranya akan sepenuhnya lupa begitu gesekan langsungnya berlalu. Memperlakukan keduanya sebagai sinyal setara “seratus orang menginginkan ini” terlalu membobot volume tiket, karena tiket murah untuk dihasilkan dan suara tidak.

Apa artinya jika sebuah fitur punya tiket dukungan tapi hampir tidak ada suara di papan?

Sering kali, permintaan itu ada tapi pengguna yang mengalaminya tidak tahu papan itu ada, tidak percaya voting akan mengubah apa pun, atau menghadapi masalah itu terlalu jarang untuk repot berpindah kanal demi mendaftarkannya secara formal. Ini persis populasi yang secara struktural terlewat oleh papan permintaan, dan jumlah suara yang rendah di sini adalah bukti kesenjangan pengukuran, bukan bukti permintaan rendah. Perlakukan kelompok tiket dukungan seputar fitur yang hilang sebagai sinyalnya sendiri yang layak Anda daftarkan sendiri ke papan, atas nama pengguna, alih-alih tidak percaya pada tiket itu, agar tidak tetap tidak terlihat bagi siapa pun yang memprioritaskan hanya dari jumlah suara.

Papan terbaca sebagai prioritas rendah:
"Export to CSV": 4 suara dalam 6 bulan

Dukungan menceritakan kisah berbeda:
"Export to CSV": 31 tiket dalam periode yang sama, masing-
masing dari akun berbeda, masing-masing ditutup dengan
"belum didukung saat ini, akan meneruskan masukan"

Apakah lonjakan tiket dukungan selalu berarti masalah yang mendasari adalah fitur yang hilang?

Tidak, dan di sinilah kedua kanal bisa menyesatkan ke arah yang berlawanan. Lonjakan tiket sama seringnya disebabkan oleh antarmuka yang membingungkan seputar fitur yang sudah ada, bug, atau perubahan yang keluar tanpa penjelasan memadai, yang tidak satu pun terselesaikan dengan membangun sesuatu yang baru. Membaca setiap lonjakan tiket sebagai “pengguna menginginkan fitur yang tidak kami miliki” menghasilkan roadmap penuh hal-hal yang sebenarnya adalah kesenjangan dokumentasi atau masalah kegunaan yang menyamar. Tiket dukungan memberi tahu Anda di mana gesekannya; itu sendiri tidak memberi tahu Anda apakah solusinya fitur baru, perubahan antarmuka, atau artikel bantuan yang lebih baik, dan mencampuradukkan itu membuang waktu rekayasa untuk solusi yang salah.

Bagaimana kedua sinyal itu seharusnya benar-benar digabungkan saat memutuskan apa yang dibangun?

Gunakan tiket untuk menemukan di mana gesekannya, dan gunakan papan permintaan, ditambah jangkauan langsung di mana papannya tipis, untuk mengonfirmasi seperti apa hasil yang sebenarnya diinginkan. Kelompok tiket mengidentifikasi masalah nyata yang dirasakan; jarang menentukan solusi cukup presisi untuk dibangun, karena pengguna yang frustrasi dalam percakapan dukungan menjelaskan gejala, bukan spesifikasi. Papan permintaan, ketika punya cukup suara pada masalah yang mendasari sama, cenderung membawa lebih banyak detail “apa yang benar-benar akan memuaskan ini”, karena menulis permintaan sudah merupakan tindakan menentukan apa yang diinginkan, bukan sekadar melaporkan apa yang salah.

Haruskah agen dukungan mencatat tiket sebagai permintaan fitur sendiri?

Ya, dan ini perbaikan berdaya ungkit tertinggi untuk kesenjangan antara kedua kanal. Agen yang mengenali tiket sebagai permintaan fitur yang menyamar, alih-alih hanya menyelesaikannya dan melanjutkan, bisa mencatatnya ke papan atas nama pelanggan, yang langsung menutup kesenjangan pengukuran alih-alih mengharuskan pelanggan menemukan dan menggunakan kanal kedua. Ini hanya berhasil jika mencatat memakan waktu detik bagi agen, bukan menit, sehingga gesekan melakukannya lebih rendah daripada gesekan hanya menutup tiket dan pindah ke berikutnya.

FAQ

Haruskah suara permintaan fitur pernah didiskon jika semuanya berasal dari satu akun atau tim? Ya, timbang berdasarkan akun atau organisasi yang berbeda alih-alih jumlah suara mentah, karena lima suara dari lima orang di perusahaan yang sama mewakili prioritas satu pelanggan, bukan lima konfirmasi independen permintaan.

Apakah layak membangun fitur yang banyak muncul di tiket tapi hampir tidak ada suara? Sering ya, asalkan volume tiket benar-benar berasal dari akun berbeda dan kebutuhan yang mendasari dikonfirmasi bukan diasumsikan; perlakukan jumlah suara yang rendah sebagai artefak pengukuran biaya aktivasi papan, bukan bukti bahwa permintaannya tidak nyata.

Bagaimana cara membedakan sekilas tiket kebingungan UI dari tiket fitur hilang yang genuine? Lihat apakah resolusinya melibatkan menjelaskan kemampuan yang sudah ada atau meminta maaf atas yang hilang. Pola resolusi “oh, sebenarnya ada di sana” menunjuk masalah antarmuka atau kemudahan penemuan; pola “kami belum mendukung itu” menunjuk kesenjangan nyata.

Apakah perbedaan ini sama pentingnya dengan volume dukungan yang sangat kecil? Secara mekanis kurang penting, karena segelintir tiket mudah dibaca satu per satu tanpa perlu analisis agregat, tapi bias yang mendasarinya, tiket terlalu mewakili pengguna frustrasi dan kurang mewakili yang sabar, hadir di skala mana pun dan layak diingat bahkan saat Anda membaca setiap tiket sendiri.

Klaim teknis dalam artikel ini belum ditinjau secara independen. Jika ada yang keliru, beri tahu kami dan kami akan memperbaikinya.

Terkait di changeloop: Dokumentasi developer, Perbandingan alat changelog