ÜRÜN VE İNOVASYON

Müşteri yorumları ürün ekibinin kararına nasıl ulaşır?

25 Eylül 20268 dk okuma

Bir ekran görüntüsü, bir yol haritası tartışması

Tanıdık bir sahne: Biri şirket içi yazışma kanalına sert bir müşteri yorumunun ekran görüntüsünü atıyor. Birkaç saat içinde konu yönetim toplantısına taşınıyor ve ürün ekibinden bir değişiklik bekleniyor. Aynı haftalarda farklı kanallarda onlarca müşterinin dile getirdiği başka bir sorun ise kimseye ulaşmıyor, çünkü hiçbiri tek başına dikkat çekecek kadar sert değil.

Kısa yanıt şu: Müşteri yorumları ürün ekibine çoğu zaman kanıt olarak değil, anekdot olarak ulaşır. Bir yorumun karara dönüşebilmesi için dört şeyin görünür olması gerekir: Bu tekil bir yorum mu yoksa tekrar eden bir sinyal mi? Hangi ürün ya da SKU ile ilgili? Hangi ham yorumlara dayanıyor? Hangi ekip inceleyecek ve ilk adım ne olabilir?

Bu yazıda yorumların ekiplere neden bu bilgiler olmadan ulaştığını, tekil yorumla tekrar eden sinyali nasıl ayırabileceğinizi ve bir bulguyu ekiplerin inceleyebileceği bir işe nasıl dönüştürebileceğinizi ele alıyoruz.

Kanıtsız ulaşan yorumun bedeli

Yorumun nasıl ulaştığı, ne söylediği kadar önemlidir. Bağlamından kopmuş bir yorum üç farklı sorun yaratır.

Öncelik gürültüye göre belirlenir. En görünür yorum, en çok tekrar eden yorumun önüne geçer. Ürün ekibi bir uç örneği düzeltmeye zaman ayırırken daha yaygın bir sorun bekler.

Ekipler arası güven aşınır. “Müşteriler şikayet ediyor” cümlesinin arkasında kaç yorum, hangi ürün ve hangi dönem olduğu belli değilse, ürün ekibi bunu tartışmaya açık bir iddia olarak görür. Yorumları taşıyan pazarlama ya da e-ticaret ekibi ise dinlenmediğini düşünür.

Sahipsiz bulgular kaybolur. Bir sorun fark edilse bile kimin inceleyeceği ve ilk adımın ne olduğu yazılmadıysa, bulgu bir sunum slaytında kalır. Birkaç ay sonra aynı konu yeniden “keşfedilir”.

Mevcut akışlar neden yetmiyor?

Sorun yorum eksikliği değildir; çoğu marka için yorum fazlasıyla vardır. Sorun, yorumla karar arasındaki yolda bilginin dökülmesidir.

• Yorumlar dağınıktır. Pazaryerleri, şikayet platformları ve sosyal medya ayrı ekranlarda, ayrı ekiplerin sorumluluğunda izlenir. Aynı sorunun farklı kanallarda tekrar ettiği, kimse hepsini yan yana koymadıkça görünmez.
• Özet raporlar kanıttan kopar. Aylık raporda “ambalaj şikayetleri arttı” yazar ama hangi üründe, kaç yorumla ve hangi ifadelerle arttığı yazmaz. Okuyan kişi doğrulamak için ham veriye dönemez.
• Duygu skorları “ne yapmalı?” sorusunu yanıtlamaz. Olumsuzluk oranının yükseldiğini bilmek, hangi ürünün hangi özelliğinin sorun yarattığını söylemez.
• Bulgu ile ekip arasında bir devir biçimi yoktur. Kalite ekibi bir hata kaydı, ürün ekibi bir problem tanımı, içerik ekibi bir düzeltme listesi bekler. Yorum analizi bunların hiçbirinin biçiminde gelmediğinde, ekibin kendi işine çevirmesi gerekir ve bu adım çoğu zaman atılmaz.

Ürün keşfi literatürü aynı noktayı farklı bir açıdan vurgular. Teresa Torres, Continuous Discovery Habits kitabında ekiplerin çözümlere değil, müşteri kanıtına dayanan fırsatlara odaklanması gerektiğini savunur. Yorumlar bu kanıtın zengin bir kaynağıdır, ama ancak fırsatı tanımlayacak biçimde düzenlendiğinde.

Tekil yorumu tekrar eden sinyalden ayırmak

Her yorum bir veri noktasıdır ama her yorum bir sinyal değildir. Bir konunun ekip gündemine girip girmemesi gerektiğine karar vermek için beş soru işe yarar.

Son satır önemli bir istisnayı hatırlatır. Tekrar ölçütü gürültüyü azaltmak içindir, ciddi bir riski sayı birikene kadar bekletmek için değil.

Bu soruların hiçbiri tek başına karar vermez. Ama birlikte kullanıldığında “bir müşteri şikayet etti” ile “üç kanalda, iki aydır, tek bir varyantta tekrar eden bir sorun var” arasındaki farkı görünür kılarlar.

Bulgudan ekibin inceleyebileceği bir işe

Bir sinyal ayırt edildikten sonra ekibe hangi biçimde ulaştığı belirleyicidir. İncelenebilir bir bulgu dört parçadan oluşur: ilgili ürün ya da SKU, onu destekleyen ham yorumlar, konuyu inceleyecek ekip ve önerilen bir sonraki adım.

Bu yapıda bir bulgu ifadesi şöyle kurulabilir: “X ürününün Y varyantında kapak sızdırması şikayeti birden fazla kanalda ve birkaç haftadır tekrar ediyor. İlgili yorumlar ekte. Kalite ekibinin aynı döneme ait üretim partisini kontrol etmesi önerilir.”

Bu cümle ekiplerin zaten kullandığı biçimlere kolayca çevrilir: kalite ekibi için bir kontrol talebi, ürün ekibi için bir problem tanımı, içerik ekibi için bir düzeltme maddesi. Tekil yorumlar ise kaybolmaz; izlemede kalır ve tekrar etmeye başladıklarında yeniden değerlendirilir.

Prodora bu akışta nerede devreye giriyor?

Bulgunun dört parçası basit görünür. Zor olan, bu parçaları her bulgu için güvenilir biçimde doldurmak ve bunu her hafta tekrarlamaktır. Bunun için birkaç sorunun aynı anda çözülmesi gerekir:

• Aynı sorunu tanımak. Müşteriler aynı sorunu farklı kanallarda, farklı kelimelerle ve ürüne farklı adlarla değinerek anlatır. Bunların tek bir konu olduğunu görmek, kelime eşleştirmenin ötesinde bir okuma gerektirir.
• Sinyali sürekli izlemek. Tekil yorumu tekrar eden sinyalden ayırmak için tekrar, kanal, süreklilik ve SKU ölçütlerinin her konu için aynı anda ve zaman içinde izlenmesi gerekir. Tek seferlik bir analiz bunu yakalayamaz.
• Doğru ekibi bulmak. “Kapak sızdırıyor” şikayeti kalite ekibinin, “fotoğraftakinden küçük” şikayeti içerik ekibinin konusudur. Aynı ürün için gelen yorumların farklı sahiplere ayrılması gerekir.
• Kanıtı korumak. Bulgu ile ham yorumlar arasındaki bağ, analiz ne kadar ilerlerse ilerlesin kopmamalıdır. Aksi halde bulgu tekrar bir iddiaya dönüşür.

Prodora bu adımları tek bir akışta birleştirir. Pazaryerleri, şikayet platformları ve sosyal medyadaki yorumları toplar, tekrar eden konuları kanallar arasında birleştirir ve her bulguyu ilgili ürün ya da SKU, dayandığı ham yorumlar, konuyu incelemesi beklenen ekip ve önerilen bir sonraki adımla birlikte sunar. Böylece bulgu ekibe kendi diliyle ve kanıtıyla ulaşır: Kalite ekibi hangi ürüne, ürün ekibi hangi yorumlara bakacağını bilir.

Önerilen adım bir karar değildir; incelemenin nereden başlayabileceğine dair bir öneridir. Neyin değişeceğine ve neyin öncelik alacağına yine ekip karar verir. Prodora'nın katkısı, bu kararın bir ekran görüntüsüne değil, kapsamı ve kanıtı belli bir bulguya dayanmasını sağlamaktır.

Sınırlamalar: Yorumlar neyi söylemez?

Kanıtla bağlanmış bir bulgu bile yorumun doğasından gelen sınırları taşır.

• Yorum yazanlar sessiz çoğunluğu temsil etmez. Çevrim içi yorumlarda uç deneyimler orta deneyimlerden daha fazla görünür. Bir sorunun yorumlardaki sıklığı, tüm kullanıcılar arasındaki sıklığı değildir.
• Yorumlar ne olduğunu söyler, neden olduğunu her zaman söylemez. “Kumaş ilk yıkamada çekti” yorumu sorunu tarif eder; nedeni üretimde, malzemede ya da yıkama talimatında olabilir. Bunu ekibin kendi kayıtları gösterir.
• Önerilen adım bir başlangıç noktasıdır. Öneriyi uygulamadan önce ilgili yorumlardan bir örneklemi okumak ve iç verilerle karşılaştırmak gerekir.
• Otomatik gruplama hata yapabilir. İroni, argo ve tek yorumda birden fazla konunun geçmesi sınıflandırmayı zorlaştırır. Bulgunun yanında ham yorumların durmasının bir nedeni de budur: Bulguyu kontrol etmek kolay olmalı.
• Yorum verisi tek başına yetmez. Satış, müşteri hizmetleri ve kalite kayıtları gibi verilerle birlikte okunduğunda daha güvenilir bir tablo ortaya çıkar.

Yorumu anekdot olmaktan çıkarmak

Müşteri yorumlarının ürün kararlarına etki etmesi için daha fazla yorum toplamaya gerek yoktur. Gereken, mevcut yorumların ekibe tekrarı, ürünü, kanıtı, sahibi ve ilk adımıyla birlikte ulaşmasıdır. Bu beş bilgi yerinde olduğunda tartışma “bu yorum ne kadar önemli?” sorusundan “bunu nasıl doğrularız?” sorusuna geçer.

Yorumlardan ekiplerin inceleyebileceği bulgular çıkarma yaklaşımımızı Ürün ve İnovasyon çözüm sayfamızda daha ayrıntılı anlatıyoruz. Kendi ürünleriniz için nasıl çalışacağını görmek isterseniz ekibimizle bir görüşme planlayabilirsiniz.

Kaynaklar

• Torres, T. (2021). Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value. Product Talk LLC.
• Hu, N., Pavlou, P. A. ve Zhang, J. (2009). “Overcoming the J-shaped distribution of product reviews.” Communications of the ACM, 52(10).