Voice of Customer | Enver Balci Blog

30 saniyelik özet

Voice of Customer, yani müşterinin sesi, müşterilerin ihtiyaçlarını, beklentilerini ve yaşadıkları güçlükleri sistematik biçimde anlamaya yönelik çalışmadır. Görüşmeler, destek kayıtları, anketler ve kullanım gözlemleri bu çalışmaya girdi sağlar. Amaç, gelen talepleri sayıp en popüler özelliği geliştirmek değildir. Hangi müşterinin, hangi durumda, hangi sonucu elde edemediğini anlamak; bu bilgiyi ürün, süreç ve hizmet kararlarına taşımaktır. Bir geri bildirimin kaynağı ve bağlamı, kendisi kadar önemlidir.

Neden önemli?

Satış ekibi yeni bir müşterinin isteğini, destek ekibi tekrar eden şikâyetleri, ürün ekibi kullanım sorunlarını görür. Bu bilgiler ayrı yerlerde kaldığında aynı müşteri ihtiyacı farklı talepler gibi değerlendirilir. Tersine, benzer kelimelerle ifade edilen farklı ihtiyaçlar tek bir özellik başlığında birleştirilebilir.

“Müşteriler raporlama istiyor” cümlesi buna örnektir. Bir kullanıcı işini yönetmek, başka biri yöneticisine sonuç göstermek, satın alma kararını veren kişi ise hizmetin bedeline değip değmediğini anlamak istiyor olabilir. Hepsine aynı rapor ekranını sunmak, bu ihtiyaçların hiçbirini yeterince karşılamayabilir.

Junior bir iş analisti için müşterinin sesi çalışması, geri bildirim ile gereksinim arasındaki farkı öğrenme fırsatıdır. Müşteri ifadesi önemli bir başlangıçtır; ancak geliştirme kararı için neden, bağlam ve etki araştırılmalıdır. Yönetici açısından ise bu çalışma, şirketin iç varsayımlarını dışarıdan gelen bilgiyle sınamasını sağlar.

En görünür müşterilerin beklentileri bütün müşteri kitlesini temsil etmeyebilir. Destek kanalına yazmayan, ürünü bırakmış veya satın almaktan vazgeçmiş kişiler de önemli bilgi taşır. Bu grupları dışarıda bırakmak, yalnızca mevcut hizmete uyum sağlayabilmiş kullanıcıların deneyimini iyileştirmeye odaklanmamıza yol açabilir.

Terim nedir?

Müşterinin sesi, belirli bir anketin veya yazılım aracının adı değildir. Müşteri bilgisini toplama, anlamlandırma ve karar süreçlerine bağlama yaklaşımıdır. Doğrudan geri bildirim, müşterinin söylediğini gösterir. Kullanım gözlemleri ve kayıtlar ise anlattığı ihtiyacın hangi davranışlarla ilişkili olduğunu değerlendirmeye yardımcı olur.

Müşteri de tek bir rol değildir. İşletmelere ürün sunan bir şirkette yazılımı kullanan çalışan, satın alma kararını veren yönetici ve ödemeyi onaylayan kişi farklı olabilir. Kullanıcının iş yükünü azaltmak ile satın alanın yatırım beklentisini karşılamak ilişkili, fakat ayrı ihtiyaçlardır. Kimin sesini duyduğumuz açıkça belirtilmelidir.

Veri toplarken ifadeyi, bağlamı ve yorumu ayırmak gerekir. “Raporu dışarı aktarmak istiyorum” müşteri ifadesidir. “Yönetim toplantısında farklı sistemlerden gelen sonuçları karşılaştırıyor” bağlamdır. “Ortak bir karar görünümüne ihtiyaç olabilir” ise analistin yorumudur. Bu yorum yeni görüşmeler veya gözlemle doğrulanmadan kesin ihtiyaç kabul edilmemelidir.

Geri bildirimler müşteri grubu, kullanım aşaması, problem türü ve etki bakımından sınıflandırılabilir. Aynı müşterinin aynı konuyu farklı kanallarda tekrar iletmesi, bağımsız müşterilerden gelen taleplerle karıştırılmamalıdır. Kayıt sayısı ile etkilenen müşteri sayısı ayrı değerlendirilir; ikisi de tek başına öncelik kararını belirlemez.

Jobs-to-be-Done, yani müşterinin belirli bir durumda gerçekleştirmek istediği ilerlemeyi araştıran yaklaşım, bu bilgiyi yorumlamak için kullanılabilir. Ancak müşterinin sesi bununla sınırlı değildir. Hizmet sorunları, beklenti uyuşmazlıkları ve süreçteki engeller de değerlendirilir. Kullanılan yöntem değişse de müşteri ifadesi ile şirketin yorumu arasındaki ayrım korunmalıdır.

Gerçek vaka: Intercom müşteri görüşmelerini nasıl kullandı?

Intercom’un Matt Hodges tarafından yayımlanan anlatımında, şirketin müşterilerin ürünü hangi amaçlarla kullandığını araştırdığı açıklanıyor. Çalışma yalnızca uzun süredir kullanan müşterilerle sınırlı tutulmamış; yeni başlayan ve ürünü bırakmış müşteriler gibi farklı grupların dinlenmesi gerektiği vurgulanmış.

Intercom, The Rewired Group ile müşteri telefon görüşmeleri yaptığını ve seçilen görüşmeleri ayrıntılı biçimde incelediğini aktarıyor. Bulgular, müşterilerin gerçekleştirmek istediği işleri sade bir dille açıklayan kartlara dönüştürülmüş. Şirket bu anlayışı ürünün paketlenmesine, pazarlama mesajlarına ve müşterilere kullanımın anlatılmasına taşımış.

Bu, Jobs-to-be-Done yöntemiyle yürütülmüş bir çalışmadır. Müşterinin sesi açısından gösterdiği nokta, görüşmelerin yalnızca alıntı veya talep listesi üretmek için kullanılmamasıdır. Müşteri bilgisi, farklı ekiplerin kararlarına ortak bir girdi sağlamış. Kaynak şirketin kendi değerlendirmesini içeriyor; anlatılan ticari gelişmenin yalnızca müşteri araştırmasından kaynaklandığını kanıtlayan bağımsız bir etki analizi sunmuyor.

Kaynak: Matt Hodges, “How to market the Job-to-be-Done”, Intercom, 21 Ocak 2016.

Varsayımsal örnek: “Otomatik rapor istiyoruz” talebi

Danışmanlık şirketlerine proje takibi yazılımı sunan bir işletmede “otomatik rapor” talebinin farklı kanallarda geldiğini düşünelim. Satış, bunun yeni sözleşmeler için önemli olduğunu söylüyor. Destek ekibi ise rapor hazırlamaktan yakınan kullanıcıların kayıtlarını paylaşıyor.

İş analisti önce kayıtların hangi müşterilere ve rollere ait olduğunu eşleştirir. Aynı isteğin satış görüşmesinde ve destek kanalında bulunması, birbirinden bağımsız ihtiyaçların sayısını artırmamalıdır. Ardından müşterilerin mevcut raporlarını, bunları kim için hazırladıklarını ve raporla hangi kararın verildiğini araştırır.

Görüşmelerde proje yöneticisinin kaynak kullanımındaki sapmayı görmek istediği, danışmanın ise müşteriye tamamlanan işleri sunmak zorunda olduğu ortaya çıkabilir. Satın alma kararını veren kişi hizmetin ekonomik değerini değerlendirmek istiyor olabilir. Ortak kelime “rapor” olsa da beklenen sonuçlar farklıdır.

Analist bu bulguları tek bir özellik talebinde eritmez. Her ihtiyaç için tetikleyici olayı, mevcut yöntemi, engeli ve beklenen sonucu yazar. Proje yöneticisinin ihtiyacı zamanında uyarı almak olabilirken danışmanın ihtiyacı paylaşılabilir bir çalışma özeti olabilir. Otomatik rapor gönderimi, bu işlerden yalnızca biri için uygun çözüm olabilir.

Bulgular ürün ve müşteriyle çalışan ekiplerle değerlendirilir. Hangi müşteri grubunun işletmenin hedefleri açısından öncelikli olduğu ve problemin ne kadar yaygın göründüğü araştırılır. Yalnızca en yüksek sesle dile getirilen talep seçilmez; etki, kanıt ve çözüm maliyeti birlikte ele alınır.

Karar verildikten sonra müşteriye hangi ihtiyacın anlaşıldığı ve nasıl ele alınacağı açıklanır. Her talep geliştirme sözüne dönüşmez. Uygulanan çözümün beklenen işi kolaylaştırıp kolaylaştırmadığı sonradan değerlendirilir. Böylece geri bildirim, kayda girip unutulan bir ifade olmaktan çıkar ve öğrenme sürecine bağlanır.

Yaygın üç hata

Talep sayısını doğrudan öncelik saymak. Çok tekrar eden bir istek önemli olabilir; ancak tekrarların aynı müşteriden gelip gelmediği, kimleri etkilediği ve işletme hedefiyle ilişkisi araştırılmalıdır. Seyrek bildirilen bir sorun da ciddi operasyonel etki yaratabilir. Sıklık ve önem ayrı boyutlardır.
Sadece memnun ve erişilebilir müşterileri dinlemek. Düzenli görüşmeye katılan müşteriler değerli bilgi sağlar; fakat ürünü bırakan veya satın almayan kişilerin deneyimi farklı olabilir. Araştırmanın hangi grupları kapsadığı açıklanmalıdır. Görüşülen gruptan bütün pazara genelleme yapmak için yeterli dayanak bulunmayabilir.
Müşteri ifadesini çözüm şartnamesi gibi kullanmak. Müşteri yaşadığı işi ve engeli iyi anlatabilir; şirketin bütün teknik ve operasyonel seçeneklerini bilmek zorunda değildir. İfadeyi olduğu gibi geliştirme talebine çevirmek, daha uygun çözümleri dışlayabilir. Önce ihtiyacın anlamı, sonra çözüm seçenekleri değerlendirilmelidir.

Mini uygulama: Müşterinin sesi kayıt kartı

Bir geri bildirim aldığınızda aşağıdaki kartı kullanın. Müşterinin söylediği ile sizin çıkardığınız sonucu ayrı alanlara yazın.

Kaynak ve tarih: Bilgi nereden, ne zaman geldi?
Müşteri grubu ve rol: Kim konuşuyor, üründeki görevi ne?
Müşteri ifadesi: Talep veya şikâyet nasıl dile getirildi?
Bağlam: Hangi iş sırasında, hangi koşullarda ortaya çıktı?
Mevcut yöntem: Müşteri işi bugün nasıl tamamlıyor?
Engel ve etki: Ne aksıyor, hangi sonuç etkileniyor?
Yorum: Bu ifade hangi ihtiyaca işaret ediyor olabilir?
Destekleyen kanıt: Hangi gözlem veya kayıt bunu destekliyor?
Belirsizlik: Hangi bilgi henüz doğrulanmadı?
Karar ve takip: Kim değerlendirecek, müşteriye nasıl dönülecek?

Bir değerlendirme toplantısında özellik taleplerini sıralamak yerine kartları ihtiyaçlara göre gruplayın. Karşıt örnekleri de inceleyin: Benzer işi yapıp sorun yaşamayan müşteri neyi farklı yapıyor? Bu soru, problemi açıklayan koşulları anlamaya yardımcı olur. Kararın gerekçesini kaydetmek, sonraki geri bildirim geldiğinde hangi varsayımın yeniden değerlendirileceğini gösterir.

İlgili terimler

Requirements Elicitation, Customer Interview, Customer Discovery, Jobs to Be Done, Problem Statement, Business Objective, Stakeholder Analysis, Buyer Persona, User Persona, Value Proposition, Product Discovery, Product Backlog