B2B müşteri görüşmelerini ürün kararına dönüştürme rehberi

Bir müşteri adayı ürününüzü beğenebilir, toplantının sonunda sizi tebrik edebilir ve bir daha cevap vermeyebilir. Görüşme sırasında duyulan ilgiyle bir problemi çözmek için gösterilen çaba aynı şey değildir. Ürün geliştirmeden önce aradığınız bilgi, insanların fikrinizi sevip sevmediğinden çok, bugün hangi işi nasıl yaptıklarıdır.

Bu rehber, şirketlere yazılım satmayı hedefleyen erken aşama girişimler için hazırlandı. Amaç, görüşme notlarından hangi özelliğin yapılacağına, hangi varsayımın tekrar araştırılacağına ve ne zaman küçük bir deneme önerileceğine karar vermek. Aşağıdaki senaryo ve sayılar açıklama amacıyla kurgulanmıştır; gerçek müşteri araştırması sonucu değildir.

Görüşmeden önce tek bir karar seçin

“Küçük işletmeler ne istiyor?” sorusu bir görüşmeyle cevaplanamayacak kadar geniştir. “Haftalık müşteri raporu hazırlayan küçük ajanslarda veriyi bir araya getirmek, çözüm aramalarına neden olan bir sorun mu?” daha işlevsel bir başlangıçtır. Kiminle görüşeceğinizi ve hangi geçmiş olayı soracağınızı belirler.

Görüşme öncesinde bir cümle yazın. “Bu görüşme grubunun sonunda raporları tek ekranda birleştiren küçük bir deneme hazırlayıp hazırlamayacağıma karar vereceğim.” Bu cümle, sohbetin her yeni özellik fikriyle başka yöne kaymasını önler.

Birbirinden çok farklı şirketleri aynı grupta değerlendirmeyin. Tek kişilik bir ajansla onay süreçleri olan büyük bir ajans aynı işi farklı kısıtlarla yapabilir. Görev, şirket yapısı ve işi yapan kişinin sorumluluğu birbirine yakın olduğunda cevapları karşılaştırmak kolaylaşır.

Girişim fikrinin hangi probleme dayandığı henüz net değilse önce girişim rehberindeki problem–çözüm uyumu bölümünü okuyup araştıracağınız varsayımı daraltabilirsiniz.

Yirmi beş dakikalık görüşme akışı

Bu süre bir zorunluluk değil, uygulanabilir bir başlangıç planıdır. Karşınızdaki kişinin zamanı ve işin karmaşıklığına göre değiştirebilirsiniz.

İlk üç dakika içinde işi ve kişiyi tanıyın. “Raporu kim hazırlıyor, kim kontrol ediyor, kim kullanıyor?” diye sorun. Ürünü kullanacak kişiyle satın alma kararını verecek kişinin aynı olduğunu varsaymayın.

Sonraki yedi dakikayı son gerçek olaya ayırın. “En son hazırladığınız raporda ilk adımdan gönderime kadar neler yaptınız?” sorusu, genel görüşlerden daha ayrıntılı bir anlatım sağlar. İşi neyin başlattığını, hangi araçların kullanıldığını ve nerede bekleme yaşandığını takip edin. Paylaşılması uygun bir boş şablon üzerinden anlatmasını isteyebilirsiniz; müşteri isimleri veya ticari sırlar gerekli değildir.

Sonraki beş dakikada sorunun sonucunu açın. “En zor kısmı hangisiydi?”, “Gecikince ne oldu?”, “Bunu çözmek için daha önce ne denediniz?” sorularını kullanın. “Çok vakit alıyor” cevabında kalmayın. Sürenin ölçülmüş mü, tahmini mi olduğunu ayrıca not edin. Kişi bilmiyorsa boşluğu kendi tahmininizle doldurmayın.

Beş dakikada mevcut çözümü ve kararı konuşun. Başka bir araca geçmeyi kim değerlendirebilir? Yeni bir aracı denemek için hangi izinler gerekir? Mevcut yöntemin sevilen tarafı nedir? Son soru özellikle değerlidir; girişiminiz hız kazandırsa bile insanların vazgeçmek istemediği bir kontrolü ortadan kaldırıyor olabilir.

Son beş dakikada duyduğunuzu geri okuyun. “Doğru anladıysam asıl sorun veriyi bulmak değil, son sürümün hangisi olduğunu kontrol etmek” gibi kısa bir özet yapın. Yanlış anlamayı o anda düzeltin. Uygunsa somut bir sonraki adım önerin; örneğin kimlik bilgileri temizlenmiş bir örnek raporla ikinci görüşme.

“Böyle bir ürün olsa kullanır mıydınız?” sorusunu temel kanıtınız yapmayın. Nazik bir olumlu yanıt, kullanım veya satın alma kararı anlamına gelmez.

Notları kanıttan ayırmadan kaydedin

Her görüşme için aşağıdaki kartı kopyalayın. Doğrudan söylenenlerle kendi yorumunuzu ayrı alanlara yazın.

Görüşmenin hemen ardından “kanıtlamadığımız şey” alanını da ekleyin. Örneğin rapor hazırlamanın zor olduğunu öğrenmiş olabilirsiniz, fakat bunun için ödeme yapılacağını henüz öğrenmemişsinizdir. Bu ayrım, araştırma notlarının yanlışlıkla satış tahminine dönüşmesini önler.

Kurgusal bir örnek üzerinden karar verin

Üç küçük ajansla görüştüğünüzü düşünün. Birinci ajansın çalışanı son raporda farklı tablolardaki sütunları elle eşleştirdiğini anlatıyor ve temizlenmiş bir örnek paylaşmayı kabul ediyor. İkinci ajans mevcut aracından memnun; “tek ekran güzel olur” diyor ama son işinde bir aksama tarif etmiyor. Üçüncü ajansta ise rapor hazırlanmış olmasına rağmen yönetici onayı iki gün beklemiş.

Üç görüşmeyi “herkes rapor otomasyonu istiyor” diye özetlemek hatalı olur. İlk görüşme veri birleştirme problemini araştırmayı destekliyor. İkinci görüşme güçlü bir değişim ihtiyacı göstermiyor. Üçüncü görüşme farklı bir probleme, onay akışına işaret ediyor.

Bu aşamada bütün raporlama ürününü geliştirmek yerine ilk ajansa benzeyen başka ekiplerle görüşmek ve örnek dosya üzerinde küçük bir deneme hazırlamak daha kontrollü bir adımdır. Üç görüşme pazarın büyüklüğünü, ödeme isteğini veya ürün–pazar uyumunu ispatlamaz. Buradaki fayda, bir sonraki araştırma sorusunu netleştirmesidir.

Çelişen cevapları silmeyin. Sorunu yaşamayan şirketlerin hangi koşullarda rahat çalıştığını anlamak, müşteri profilinizin sınırlarını çizmenize yardım edebilir.

Küçük bir pilotun sınırlarını yazın

Görüşme sonrasında ilgi varsa “size bir demo yaparız” cümlesini açık bir deneme önerisine dönüştürün. Aşağıdaki metin ticari sözleşme değil, görüşmede kapsamı netleştirmek için kullanılacak bir çalışma şablonudur.

Tek bir rapor türü üzerinde çalışacağız. Siz paylaşılması uygun örnek girdiyi ve beklenen çıktı biçimini sağlayacaksınız. Önce mevcut hazırlama süresini aynı kapsamda kaydedeceğiz. Sonra deneme çıktısını süre, eksik alanlar ve manuel düzeltme ihtiyacı bakımından karşılaştıracağız. Başarı ölçütünü başlamadan birlikte belirleyeceğiz. Denemenin sonunda devam, düzeltme veya durdurma kararı vereceğiz.

Başlamadan şu boşlukları doldurun. Denemeyi kim kullanacak? Çıktının doğruluğunu kim kontrol edecek? Hangi veri paylaşılabilir? Deneme ücretli mi ücretsiz mi? Başlangıç ve değerlendirme tarihleri ne? Veriler deneme sonrasında nasıl kaldırılacak?

Sadece hız ölçmeyin. Daha kısa sürede oluşan ama sürekli düzeltme gerektiren bir rapor, sorunu çözmüş sayılmaz. Mevcut yöntemle denemeyi aynı iş kapsamı üzerinden karşılaştırın; farklı zorluktaki iki raporun sürelerini yan yana koymak yanıltıcıdır.

Görüşmelerin sonunda yapılacak kontrol

Ürün geliştirmeye geçmeden önce elinizdeki notlarla şu cümleleri tamamlayın.

• Sorunu yaşayan kişi şu işi yapıyor ve şu koşullarda zorlanıyor.
• Bunu düşünmemizin dayanağı, anlatılan şu geçmiş olaylar.
• Mevcut çözümün yetersiz kaldığı nokta şu.
• Bu yoruma uymayan görüşmeler şunlar ve farkları şu olabilir.
• Hâlâ bilmediğimiz konu şu; bunu öğrenmek için yapacağımız sonraki iş bu.

Son cümle dolmuyorsa yeni özellik listesi çıkarmak için erken olabilir. Bir sonraki adımınız bazen kod yazmak, bazen farklı bir rolle görüşmek, bazen de aynı işi gerçekleşirken izlemek olacaktır. Görüşmelerin değeri, toplantı sayısında değil, hangi kararı hangi bilgiyle verdiğinizi açıklayabilmenizde ortaya çıkar.

Görüşmelerin ardından müşteri adaylarına ulaşmak ve teklifinizi netleştirmek için ilk 10 müşteriyi bulma rehberindeki adımları kullanabilirsiniz. Benzer uygulama odaklı çalışmalar rehber arşivinde yer alıyor.