Geri bildirim döngüsü

Yazılım ürününde müşteriden geri bildirim nasıl istenir

6 dk okuma

Bir yazılım ürününde müşteriden geri bildirim istemek için, kullanıcının az önce yaptığı somut bir şey hakkında, onu yaptığı yerde tek bir soru sorun. Bir export’tan hemen sonra gelen “O rapor export’u nasıl geçti?” cevap alır. Alt bilgideki “Ürünümüz hakkında ne düşündüğünüzü bize söyleyin” sessizlik alır. Sayfanın geri kalanı anlar, kanallar ve tam cümlelerdir.

Bu konudaki öğütlerin çoğu mağazalar ve hizmet masaları için yazılmıştır. Bir yazılım ekibi kullanıcının bir saniye önce ne yaptığını tam olarak bilir, o yüzden soru ona dair olabilir.

AnNerede sorulurHazır soru
Bir görev bittikten hemen sonraUygulamada, sonucun yanında“Bu export ihtiyacınızı karşıladı mı?”
Yeni bir özelliğin ilk kullanımından sonraUygulamada, bir kez“Toplu Düzenle ile ne yapmaya çalışıyordunuz?”
Bir destek ticket’ı çözüldükten sonraDestek yazışmasında“Bu çözdü mü, yoksa hâlâ ters giden bir şey var mı?”
Kullanıcı bir akışta durduktan veya terk ettikten sonraE-posta, bir gün sonra“Kurulumun 3. adımında durdunuz. Sizi ne engelledi?”
30 günlük düzenli kullanımdan sonraAdı olan bir kişiden e-posta“Değiştireceğiniz tek şey ne olurdu?”
Kullanıcı iptal ettiğindeİptal akışında“Bugün ayrılmaya sizi ne karar verdirdi?”
İstedikleri bir şeyi yayımladıktan sonraİstedikleri yerde“CSV içe aktarma istemiştiniz. Yayında. Sizin durumunuzu karşılıyor mu?”

Geri bildirim istemenin doğru zamanı ne zaman?

Doğru zaman, kullanıcı bir şeyi bitirdikten hemen sonradır, ayrıntı hâlâ aklındayken. Bir eylemi izleyen soru o eylem hakkında cevap alır. Durup dururken gelen soru, kişinin o anki ruh hali hakkında bir cevap alır, ya da hiç alamaz.

Kayıt sırasında sormayın, çünkü kimse henüz bir şey kullanmadı. Bir görevin ortasında sormayın, çünkü öğrenmek istediğiniz şeyi kesintiye uğratıyorsunuz. Biri cevap verdikten sonra, bildirecek bir şeyiniz olana kadar onu rahat bırakın.

Müşteriden geri bildirim nereden istenmeli?

Deneyimin yaşandığı yerden isteyin. Uygulama içi bir istem bir ekran hakkındaki soruya uyar. Destek yazışması bir düzeltme hakkındaki soruya uyar. E-posta bir haftalık kullanım ya da terk edilen bir akış hakkındaki soruya uyar. Bir görüşme, önceden tahmin edemeyeceğiniz sorulara uyar.

Her kanal farklı türde cevap getirir:

  • Uygulama içi: kısa, anında ve somut, ama sadece orada olan insanlardan. Ayrılan kullanıcılardan hiçbir şey duymazsınız.
  • Destek yazışması: yazmaya yetecek kadar bunalmış insanlardan. Bozuk şeyleri bulmak için iyi, ürünün geri kalanını yargılamak için zayıf.
  • E-posta: daha az insandan daha uzun cevaplar ve sessizleşen kullanıcılara ulaşmanın tek yolu. Adı olan bir kişiden, içinde tek bir soru bulunan kısa bir not olarak yazın.
  • Görüşme: insanların bir şeyi neden yaptığını öğrenmenin yolu. Onlardan nasıl çalıştıklarını göstermelerini isteyin ve onlar yaparken sessiz kalın.

Geri bildirim sinyal kalitesi her kanalın size söylediğini nasıl tartacağınızı anlatır.

Profesyonelce geri bildirim nasıl istenir?

Konuda somut olun, neden sorduğunuzu söyleyin ve cevabın bir dakikadan az sürmesini sağlayın. Profesyonel bir istem anı adlandırır, cevabı bir insanın okuyacağını belli eder ve kesinti için özür dilemez.

Tam eylemi adlandırın (“az önce çalıştırdığınız export”), tek bir şey isteyin, zorunlu alan olmayan serbest metin kutusu kullanın ve bir ilk adla imzalayın.

Geri bildirim istemek için iyi bir cümle nasıl olur?

İyi bir cümle, belirli bir an hakkında, birkaç kelimeyle cevaplanabilen bir sorudur. Aşağıdaki iki sütunu karşılaştırın. Soldakiler omuz silkerek cevaplanabilir. Sağdakiler kişinin gerçek bir şeyi hatırlamasını ister.

Zayıf istemDaha güçlü istem
“Geri bildiriminiz var mı?”“Bunu kurarken en zor kısım neydi?”
“Ürünümüzü nasıl buluyorsunuz?”“Geçen hafta bunu ne için kullandınız?”
“Deneyiminizi 1’den 10’a puanlayın.”“Bugün yapmaya geldiğiniz işi bitirebildiniz mi?”
“Nasıl gelişebileceğimizi söyleyin.”“Bu hafta sizi yavaşlatan tek şey neydi?”
“Bizi tavsiye eder miydiniz?”“Bunu en son kime gösterdiniz ve ne dediniz?”

Hemen her yerde işe yarayan bir başkası: “Bu sizin için işe yaramadığında yerine neyi kullanıyorsunuz?” Gerçek rakibi ortaya çıkarır, ki bu çoğu zaman bir e-tablodur.

Geri bildirim istemenin en kötü yolları nelerdir?

En kötü istemler geniş, erken, uzun ya da yönlendiricidir. Hepsinin ortak bir sorunu var: kişi, sizin yapmanız gereken düşünmeyi yapmadan cevap veremez.

  1. “Lütfen 20 soruluk anketimizi doldurun.” Bitirenler en çok boş zamanı olanlar ya da en güçlü fikri olanlardır.
  2. Girişten sonraki ilk sayfada bir pop-up. Kullanıcı bir şey yapmaya geldi ve siz engellediniz. Kapatmak tek makul cevaptır.
  3. Soru olmadan “Geri bildiriminizi çok isteriz!” Kullanıcıdan konuyu icat etmesini ister.
  4. Yönlendirici bir soru: “Yeni panoyu ne kadar çok seviyorsunuz?” Onay alırsınız ve hiçbir şey öğrenmezsiniz.
  5. Takibi olmayan bir puan. 10 üzerinden 6, ruh halini söyler. Neyi değiştireceğinizi söylemez.
  6. Sorup sonra susmak. Bu bir sonraki turu kaybettirir, aşağıda anlatılıyor.

Bir ürün hakkındaki müşteri geri bildirimine ne denir?

Bir ürün hakkındaki geri bildirime genellikle ürün geri bildirimi denir ve iki türe ayrılır. Hata raporu bir şeyin amaçlandığı gibi çalışmadığını söyler. Özellik talebi bir şeyin eksik olduğunu söyler. Bu ayrım önce kimin bakacağına karar verir ve özellik talebi mi hata mı yazısı bu çizgiyi çizer. Üçüncü tür olan övgü, saklamaya ve izinle alıntılamaya değer.

İlk seçenek olarak “Hata” ve “Özellik talebi” sunan bir geri bildirim formu bu ilk ayrımı sizin yerinize yapar.

Cevaplarla ne yaparsınız?

Her cevabı, ekibin zaten çalıştığı yere, kişinin kendi kelimeleriyle koyun. Alıntılanmış tek bir satır, sizin özetinizden iyidir. Türüne ve kabaca aciliyetine göre etiketleyin, tekrarları birleştirin ve karar verin: yap, beklet ya da reddet.

Reddetmek de bir cevaptır. “Bunu yapmayacağız ve nedeni şu” beklemeyi bitirir ve özellik taleplerini reddetmek bunun için ifadeler sunar. Altyapı için özellik talebi takibi, beş kanaldan gelen talepleri tek bir listeye nasıl sokacağınızı anlatır. Talepleri yazılı alıyorsanız, bir özellik talebi şablonu onları karşılaştırılabilir tutar.

Changeloop’un widget’ı her gönderimi bir GitHub issue’su olarak açar, böylece geri bildirim onu düzeltecek kodun yanına düşer. Hangi araçla olursa olsun kural aynı: tek liste, tek sahip, hiçbir cevap birinin gelen kutusunda kalmaz.

Yayımlananları neden anlatmalı?

Kişiye cevap vermenin zamanına değdiğini gösterir. Size bir şey söyleyen ve sonra “bu yayımlandı, teşekkürler” cevabını alan bir kullanıcının tekrar cevap vermek için bir nedeni olur. Hiçbir şey duymayan ise kutunun okunmadığı sonucuna varır.

Yani istemenin son adımı bir cevaptır. Her isteyen kişiye, talebi yayımlandığında, kendi diliyle, kullandığı kanaldan haber verin. Müşteri geri bildirim döngüsünü kapatmak mekanizmayı anlatır: mesajı yayımlanmış changelog girdisi tetikler, böylece isteyene ancak değişiklik canlıya çıktığında haber verilir. Changeloop’ta widget geri bildirimi bir GitHub issue’su olduysa ve birleştirilen pull request onu kapattıysa, girdiyi onaylamak o issue’ya bir “Shipped” yorumu bırakır ve girdiyi widget’ta gönderene gösterir; elle açılan issue’lar ile GitLab ya da Bitbucket depoları yorum almaz. Dokümanlarımız widget ve feed kurulumunu listeler.

Cevap kısa olabilir: “Mart’ta CSV içe aktarma istemiştiniz. Bugün yayında ve nasıl çalıştığı şöyle.” Ayrıca size en iyi bir sonraki soruyu verir: ihtiyacınız olanı karşılıyor mu?

Bir başlangıç planı

En üstteki tablodan bir an seçin, kullanıcıların en sık başarılı olduğu ya da vazgeçtiği anı. Onun için tek bir soru yazın, tek bir kanala koyun ve ikinci bir istem eklemeden önce iki hafta boyunca her cevabı okuyun. Size somut bir şey veren herkese cevap verin.

FAQ

Müşterilerden ne sıklıkla geri bildirim istenmeli? İstemleri takvime değil olaylara bağlayın. Bir kullanıcı haftada en fazla bir istem görmeli ve birine cevap verdikten hemen sonra hiç görmemeli. Geri bildirimden sonraki ilk mesaj, ona ne olduğuna dair bir cevap olmalı.

Kullanıcıları rahatsız etmeden geri bildirim nasıl istenir? Bir görevden sonra sorun, asla ortasında değil, tek soruya sadık kalın ve kapatmayı kolay yapın. Bir kapatmaya birkaç hafta saygı gösterin.

Geri bildirim için bir teşvik sunulmalı mı? Genellikle gerek yoktur. Somut bir soru ve görünür bir cevap, bir hediye kartından daha çok ağırlık taşır ve teşvikler ödülü isteyen insanları çeker. Onları, birinden 20 dakika istediğiniz görüşmelere saklayın.

Kimse cevap vermezse ne olur? Soruyu daraltın ve ana yaklaştırın, örneğin tek bir ekran, kullanıldıktan hemen sonra sorulsun. Sessiz kalırsa, bir avuç kullanıcıya doğrudan e-posta gönderin ve bu konuşmaları daha iyi istemler yazmak için kullanın.


Bu yazıdaki teknik iddialar bağımsız olarak kontrol edilmedi. Yanlış bir şey varsa bize söyle, düzeltelim.

changeloop'ta ilgili sayfalar: Geliştirici dokümantasyonu

changeloop
Döngüyü kapatan bir changelog geliştiren ekip. Kullanıcıların bir şey ister, ekibin teslim eder, isteyen kişi haberdar olur.