Müşteriyi kaybetmeden bir özellik talebi nasıl reddedilir

Döngüyü kapatmak genelde birine talebinin gönderildiğini söylemek demektir. Çoğu takip sisteminin hiç süreci olmadığı zor yarısı ise hayır demektir. Çoğu özellik talebi asla gönderilmez, bu da bir ürünün kullanıcılarına gerçekten borçlu olduğu döngü kapatmanın çoğunun bir duyuru değil, bir ret olduğu anlamına gelir, ve kötü ele alınan bir ret sessizliğin maliyet edeceğinden daha fazla iyi niyete mal olur. İyi ele alındığında neredeyse hiçbir şeye mal olmayabilir, çünkü talep eden kişinin çoğu zaman en çok istediği şey duyulduğunu bilmektir, özelliğin kendisi değil.

İyi reddetmek neden iyi göndermek kadar önemli?

Çünkü sessizlik açıklamasız bir ret gibi okunur, ve açıklanmış bir hayır dikkat gibi okunur. Hiçbir şey duymayan kişi ya talebin yok sayıldığını ya da kaybolduğunu varsayar, ve her iki sonuç da ona sormaktan vazgeçmeyi öğretir, ki bu bir ürünün gerçek bir retten elde ettiği aynı sonuçtur, sadece daha yavaş ulaşılır ve yol boyunca daha fazla kırgınlıkla. Açıkça ve bir nedenle hayır diyen bir yanıt, döngüyü gönderilmiş bir özellik kadar tamamen kapatır, ve bunu daha hızlı yapar.

Bir reddi kötü hissettiren nedir?

Neredeyse her zaman üç şey, birleşik olarak. Genellik: ne istendiğine gerçekte değinmeyen kalıp “geri bildiriminiz için teşekkürler” hiç okunmamış gibi görünür, okunmuş olsa bile. Gecikme: talep eden kişi sormayı unuttuktan sonra, talepten altı ay sonra gelen bir ret, hızlı bir hayırdan daha kötü hissettirir, çünkü talebin düşünülüp reddedilmek yerine dokunulmadan kaldığını ima eder. Ve dayanmayan bir neden: “yol haritamızda değil” hiçbir şeyi yanıtlamaz, “bu, bu yıl dokunmayı planlamadığımız izin mantığını yeniden tasarlamayı gerektirir” ise talep eden kişiye gerçekten değerlendirebileceği ve yeterince önemliyse yükseltebileceği veya etrafından dolaşabileceği bir şey verir.

İyi bir ret gerçekte ne söylemeli?

Bu sırayla dört şey: genel bir parafraz değil, belirli talebi adlandıran bir onay; dürüst neden daha yumuşak bir bahane yerine “bu, ürünün gittiği yöne uymuyor” olsa bile dürüstçe belirtilen gerçek neden; kapının kapalı mı yoksa şu an sadece açık olmadığı mı, çünkü bunlar çok farklı tonlar gerektirir; ve varsa, tam olarak istenen özellik olmasa bile altta yatan ihtiyacı ele alan bir alternatif.

Merhaba Jamie,

Takım davetleri için toplu CSV içe aktarma eklenmesi talebiniz için
teşekkürler. İnceledik, ve bunu inşa etmeyeceğiz: davet akışımız
güvenlik nedenleriyle her yeni üyenin ayrı ayrı incelenmesine
dayanıyor, ve toplu içe aktarma, kasıtsız değil, tasarım gereği buna
karşı çalışır.

Asıl sorun büyük bir takımı hızlıca davet etmekse, API, incelemeyi
atlamadan neredeyse tüm hızı sağlayan script tabanlı bireysel davetleri
destekliyor: [bağlantı]. Kurmak için yardım isterseniz memnuniyetle
yardımcı olurum.

Bunun bir şablonun yapamayacağı şeyi ne yaptığına dikkat edin: gerçek özelliği adlandırıyor, belirsiz bir politika yerine gerçek bir tasarım kararına bağlı bir neden veriyor, ve sadece bileti kapatmak yerine altta yatan sorunu çözen bir yol sunuyor.

Bu, gönderilmiş bir özellikte döngüyü kapatmaktan nasıl farklı?

Mekanik benzer, ton değil. Müşteriyle geri bildirim döngüsünü kapatmak mesajın iyi haber olduğu ve ana riskin göndermeyi unutmak olduğu gönderilmiş durumu ele alır. Bir ret kötü haberdir, ya da en azından istenmeyen haberdir, ve verilen nedende daha fazla özen ve teslimatta daha az otomasyon gerektirir: gönderilmiş bir özellik bildirimi, bir durum değişikliği tarafından tetiklenen kalıp bir yorum olabilir, ama kalıp gibi okunan bir ret, tam olarak bu yaklaşımın tamamının kaçınmaya çalıştığı başarısızlık biçimidir. İkisi yine de bir gereksinimi paylaşır: orijinal talep talep eden kişiyle bağlantılı kalmalıdır, özellik talebi takibinin ele aldığı aynı takip disiplini, yoksa her iki mesajı da bireysel olarak gönderecek bir yol yoktur.

Bir ret, herkese açık bir yol haritasındaki bir durum gibi herkese açık olmalı mı?

Genellikle durum öyle olsa bile belirli neden değil. Herkese açık yol haritası talep eden kişinin tekrar sormadan kontrol edebileceği durum etiketlerini ele alır, ve bir “reddedildi” veya “planlanmadı” durumu o sistemin parçası olabilir. Ama özellikle dahili öncelikleri veya pek de gurur verici olmayan bağlamı içeren ayrıntılı neden, genellikle herkese açık bir durum sayfasından çok bireysel yanıtta daha değerlidir, orada aynı ifade gerçekten soran tek kişi yerine her okuyucu için işe yaramak zorundadır.

Reddedilen her talep bireysel bir yanıtı hak eder mi?

İsimli, ulaşılabilir bir kişiden gelen her talep hak eder, en azından kısa bir tane. Yüksek hacimli, tekrar eden veya anonim talepler istisnadır: benzer talepleri gruplandırıp grup başına bir kez yanıtlamak, veya paylaşılan bir durum etiketini güncellemek, bireysel yanıtlar gerçekten ölçeklenmediğinde makuldür. Tutulması gereken sınır, “herkese bireysel olarak yanıt veremeyiz”in gerçek hacme karşı kontrol edilen gerçek bir operasyonel kısıtlama olması gerektiğidir, iki dakika sürecek bir yanıtı atlamak için varsayılan bir bahane değil.

FAQ

Zayıf bir nedenle hızlıca reddetmek mi, yoksa iyi bir tane için zaman ayırmak mı daha iyi? Dürüst bir nedenle hızlıca, ikisini de tek başına geçer. Gerçek bir nedenle, kısa bile olsa, hızlı bir yanıt, cilalı bir nedenle yavaş bir yanıtı geride bırakır; gecikmenin kendisi güveni zedeleyenin parçasıdır.

Bir ret talebin daha sonra yeniden değerlendirileceğini vaat etmeli mi? Sadece bu gerçekten olasıysa ve onu gerçekten yeniden değerlendirmek için bir mekanizma varsa, mesela bir planlama döngüsünde onu yeniden yüzeye çıkaran bir etiket gibi. Böyle bir mekanizma olmadan belirsiz bir “aklımızda tutacağız”, işlevsel olarak sessizlikle aynıdır, sadece daha kibarca ifade edilmiş.

Dürüst neden şirketin paylaşamayacağı bir şeyse, rekabet endişesi gibi? Daha yumuşak bir neden uydurmak yerine bunu doğrudan söyleyin. “Buradaki belirli gerekçeyi paylaşamıyoruz, ama bu inşa etmeyi planladığımız bir şey değil”, takip sorusu karşısında çöken uydurma bir açıklamadan daha dürüst, ve daha saygı görür.

Bir talebi reddetmek, takipten silinmesi gerektiği anlamına mı gelir? Hayır. Onu, nedenle birlikte reddedildi olarak etiketlenmiş şekilde saklayın, böylece bir sonraki benzer talebin karşı gruplandığı örüntünün parçası olur, ve daha sonra değişen bir bağlam (yeni bir entegrasyon, yeni bir takım önceliği) değerlendirmeyi sıfırdan başlatmak yerine onu yeniden yüzeye çıkarabilir.

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, Changelog araçları karşılaştırması