Cara meminta umpan balik pelanggan di produk software
7 menit baca
Untuk meminta umpan balik pelanggan di produk software, ajukan satu pertanyaan spesifik tentang sesuatu yang baru saja dilakukan pengguna, di tempat mereka melakukannya. “Bagaimana hasil mengekspor laporan tadi?” tepat setelah ekspor akan dijawab. “Beri tahu kami pendapat Anda tentang produk kami” di footer hanya mendapat kesunyian. Sisa halaman ini berisi momen, kanal, dan kalimat persisnya.
Kebanyakan saran soal topik ini ditulis untuk toko dan meja layanan. Tim software tahu persis apa yang dilakukan pengguna sedetik lalu, jadi pertanyaannya bisa tentang hal itu.
| Momen | Tempat bertanya | Kalimat siap pakai |
|---|---|---|
| Tepat setelah tugas selesai | Di aplikasi, di samping hasilnya | “Apakah ekspor itu sesuai kebutuhan Anda?” |
| Setelah pemakaian pertama fitur baru | Di aplikasi, sekali saja | “Apa yang ingin Anda capai dengan Bulk Edit?” |
| Setelah tiket support selesai | Di thread support | “Apakah itu menyelesaikannya, atau masih ada yang janggal?” |
| Setelah pengguna berhenti atau keluar dari sebuah alur | Email, sehari kemudian | “Anda berhenti di langkah 3 setup. Apa yang menghalangi?” |
| Setelah 30 hari pemakaian rutin | Email dari orang yang disebut namanya | “Satu hal apa yang akan Anda ubah?” |
| Saat pengguna berhenti berlangganan | Di alur pembatalan | “Apa yang membuat Anda memutuskan pergi hari ini?” |
| Setelah Anda merilis sesuatu yang mereka minta | Di tempat mereka memintanya | “Anda meminta impor CSV. Sudah live. Apakah cocok dengan kasus Anda?” |
Kapan waktu yang tepat untuk meminta umpan balik?
Waktu yang tepat adalah tepat setelah pengguna menyelesaikan sesuatu, selagi detailnya masih ada di kepala mereka. Pertanyaan yang mengikuti sebuah tindakan mendapat jawaban tentang tindakan itu. Pertanyaan yang muncul tiba-tiba mendapat jawaban tentang suasana hati orang itu saat itu, atau tidak dijawab sama sekali.
Jangan bertanya saat pendaftaran, karena belum ada yang dipakai. Jangan bertanya di tengah tugas, karena Anda mengganggu hal yang ingin Anda pelajari. Setelah seseorang menjawab, biarkan mereka sampai Anda punya sesuatu untuk dilaporkan kembali.
Di mana sebaiknya Anda meminta umpan balik pelanggan?
Bertanyalah di tempat pengalaman itu terjadi. Prompt di dalam aplikasi cocok untuk pertanyaan tentang sebuah layar. Thread support cocok untuk pertanyaan tentang sebuah perbaikan. Email cocok untuk pertanyaan tentang seminggu pemakaian, atau tentang alur yang ditinggalkan orang. Panggilan cocok untuk pertanyaan yang tidak bisa Anda duga.
Setiap kanal menghasilkan jenis jawaban yang berbeda:
- Di aplikasi: singkat, langsung, dan spesifik, tetapi hanya dari orang yang sedang hadir. Anda tidak mendengar apa pun dari pengguna yang sudah pergi.
- Thread support: dari orang yang sudah cukup kesal untuk menulis. Bagus untuk menemukan hal yang rusak, kurang baik untuk menilai sisa produk.
- Email: jawaban lebih panjang dari lebih sedikit orang, dan satu-satunya cara menjangkau pengguna yang sudah diam. Tulis sebagai catatan singkat dari orang yang disebut namanya, dengan satu pertanyaan di dalamnya.
- Wawancara: cara untuk mempelajari mengapa orang melakukan sesuatu. Minta mereka menunjukkan cara kerja mereka, dan diamlah selagi mereka melakukannya.
Kualitas sinyal umpan balik membahas cara menimbang apa yang dikatakan setiap kanal.
Bagaimana cara meminta umpan balik secara profesional?
Spesifik soal hal yang ditanyakan, jelaskan mengapa Anda bertanya, dan buat jawabannya memakan waktu kurang dari semenit. Permintaan yang profesional menyebut momennya, menegaskan bahwa seorang manusia akan membaca jawabannya, dan tidak meminta maaf karena mengganggu.
Sebut tindakan persisnya (“ekspor yang baru Anda jalankan”), minta satu hal, pakai kotak teks bebas tanpa kolom wajib, dan tanda tangani dengan nama depan.
Apa kalimat yang baik untuk meminta umpan balik?
Kalimat yang baik adalah pertanyaan tentang momen tertentu yang bisa dijawab dalam beberapa kata. Bandingkan dua kolom di bawah ini. Yang kiri bisa dijawab dengan angkat bahu. Yang kanan mengharuskan orang mengingat sesuatu yang nyata.
| Pertanyaan lemah | Pertanyaan lebih kuat |
|---|---|
| “Ada masukan?” | “Apa bagian tersulit saat menyiapkan ini?” |
| “Bagaimana pendapat Anda tentang produk kami?” | “Untuk apa Anda memakai ini minggu lalu?” |
| “Nilai pengalaman Anda dari 1 sampai 10.” | “Apakah Anda menyelesaikan yang ingin Anda lakukan hari ini?” |
| “Beri tahu kami cara memperbaiki.” | “Apa satu hal yang memperlambat Anda minggu ini?” |
| “Maukah Anda merekomendasikan kami?” | “Kepada siapa terakhir kali Anda menunjukkan ini, dan apa yang Anda katakan?” |
Satu lagi yang cocok hampir di mana saja: “Apa yang Anda pakai sebagai gantinya ketika ini tidak berhasil untuk Anda?” Pertanyaan ini memunculkan pesaing yang sebenarnya, yang sering kali berupa spreadsheet.
Apa cara terburuk untuk meminta umpan balik?
Permintaan terburuk itu terlalu luas, terlalu dini, terlalu panjang, atau menggiring. Semuanya punya masalah yang sama: orang tidak bisa menjawab tanpa melakukan pemikiran yang seharusnya Anda lakukan.
- “Mohon isi survei 20 pertanyaan kami.” Yang menyelesaikannya adalah orang dengan waktu luang paling banyak atau pendapat paling kuat.
- Popup di halaman pertama setelah login. Pengguna datang untuk melakukan sesuatu dan Anda menghalanginya. Menutupnya adalah satu-satunya jawaban yang masuk akal.
- “Kami sangat menantikan masukan Anda!” tanpa pertanyaan. Ini meminta pengguna mengarang topiknya.
- Pertanyaan menggiring: “Seberapa suka Anda dengan dasbor baru?” Anda mendapat persetujuan dan tidak belajar apa-apa.
- Penilaian tanpa tindak lanjut. Angka 6 dari 10 memberi tahu suasana hati. Ia tidak memberi tahu apa yang harus diubah.
- Bertanya, lalu diam. Ini merugikan putaran berikutnya, yang dibahas di bawah.
Apa sebutan untuk umpan balik pelanggan tentang produk?
Umpan balik tentang produk biasanya disebut umpan balik produk, dan terbagi menjadi dua jenis. Laporan bug menyatakan sesuatu tidak berfungsi sebagaimana mestinya. Permintaan fitur menyatakan ada yang kurang. Pembedaan ini menentukan siapa yang melihatnya lebih dulu, dan permintaan fitur vs bug menarik garisnya. Jenis ketiga, pujian, layak disimpan dan dikutip dengan izin.
Formulir umpan balik yang menawarkan “Bug” dan “Permintaan fitur” sebagai pilihan pertama sudah melakukan penyortiran awal itu untuk Anda.
Apa yang dilakukan dengan jawabannya?
Taruh setiap jawaban di tempat tim sudah bekerja, dengan kata-kata orang itu tetap utuh. Satu baris kutipan lebih baik daripada ringkasan Anda. Beri tag menurut jenis dan perkiraan urgensi, gabungkan yang berulang, lalu putuskan: bangun, tunda, atau tolak.
Menolak juga merupakan jawaban. “Kami tidak akan membangun ini, dan inilah alasannya” mengakhiri penantian, dan menolak permintaan fitur punya contoh kalimatnya. Untuk saluran pipanya, melacak permintaan fitur menjelaskan cara membawa permintaan dari lima kanal ke satu daftar. Jika Anda menerima permintaan secara tertulis, template permintaan fitur menjaga agar permintaan bisa dibandingkan.
Widget Changeloop menyimpan setiap kiriman sebagai GitHub issue, sehingga umpan balik mendarat di samping kode yang akan memperbaikinya. Dengan alat apa pun aturannya sama: satu daftar, satu pemilik, tidak ada jawaban yang tertinggal di kotak masuk seseorang.
Mengapa memberi tahu orang apa yang dirilis?
Itu menunjukkan kepada orang tersebut bahwa menjawab ada gunanya. Pengguna yang pernah memberi tahu Anda sesuatu lalu mendengar “ini sudah dirilis, terima kasih” punya alasan untuk menjawab lagi. Yang tidak mendengar apa-apa menyimpulkan bahwa kotak itu tidak dibaca.
Jadi langkah terakhir dalam meminta adalah membalas. Beri tahu setiap orang yang meminta kapan permintaannya dirilis, dengan bahasa mereka, lewat kanal yang mereka pakai. Menutup lingkaran umpan balik pelanggan menjelaskan mekanismenya: entri changelog yang diterbitkan adalah pemicu pesan, sehingga peminta baru diberi tahu setelah perubahan itu live. Di Changeloop, ketika umpan balik widget menjadi issue GitHub dan pull request yang digabung menutupnya, menyetujui entri akan memposting komentar “Shipped” di issue itu dan menampilkan entri itu ke pengirim di widget; issue yang dibuat manual, serta repositori GitLab atau Bitbucket, tidak mendapat komentar. Dokumentasi kami mencantumkan pengaturan widget dan feed.
Balasan bisa singkat: “Anda meminta impor CSV pada bulan Maret. Hari ini sudah live, dan begini cara kerjanya.” Itu juga memberi Anda pertanyaan berikutnya yang terbaik, yaitu apakah fitur itu mencakup yang mereka butuhkan.
Rencana awal
Pilih satu momen dari tabel di atas, yaitu saat pengguna paling sering berhasil atau menyerah. Tulis satu pertanyaan untuknya, taruh di satu kanal, dan baca setiap jawaban selama dua minggu sebelum menambah prompt kedua. Balas siapa pun yang memberi sesuatu yang konkret.
FAQ
Seberapa sering Anda sebaiknya meminta umpan balik pelanggan? Kaitkan permintaan dengan peristiwa, bukan kalender. Pengguna sebaiknya melihat paling banyak satu prompt seminggu, dan tidak ada tepat setelah menjawab satu. Pesan berikutnya setelah umpan balik sebaiknya berupa balasan tentang apa yang terjadi padanya.
Bagaimana meminta umpan balik tanpa mengganggu pengguna? Bertanyalah setelah tugas, bukan di tengahnya, batasi pada satu pertanyaan, dan buat mudah ditutup. Hormati penutupan itu selama beberapa minggu.
Haruskah menawarkan insentif untuk umpan balik? Biasanya tidak perlu. Pertanyaan yang spesifik dan balasan yang terlihat lebih berbobot daripada voucher, dan insentif menarik orang yang mengejar hadiahnya. Simpan untuk wawancara, ketika Anda meminta 20 menit waktu seseorang.
Bagaimana jika tidak ada yang menjawab? Persempit pertanyaannya dan dekatkan ke momennya, misalnya satu layar, ditanyakan tepat setelah dipakai. Jika tetap sepi, kirim email langsung ke beberapa pengguna dan pakai percakapan itu untuk menulis prompt yang lebih baik.
Klaim teknis dalam artikel ini belum ditinjau secara independen. Jika ada yang keliru, beri tahu kami dan kami akan memperbaikinya.