Kullanıcı satın alan taraf değilse nasıl satış yapılır?
(writings.founderlabs.io)- 'Kullanıcı ürünü kullanıyor ama ödeme yetkisine sahip değil' durumunda kilit nokta, gerçek yetki ve etki gücünün kimde olduğunu anlamaktır.
- Gerçek yetkiye sahip karar verici, her zaman satın alan kişiyle veya ilk kullanıcıyla aynı kişi olmayabilir.
- Küçük ölçekli organizasyonlarda zaman tasarrufu önemli olduğundan, geliştiricinin aracı doğrudan benimseyip üst yönetimi ikna ederek satın almaya götürme olasılığı yüksektir.
- Büyük ölçekli organizasyonlarda güvenlik ve prosedür kısıtları daha güçlüdür; bu nedenle satın alma kararı CTO veya yöneticilerde olur ve uzun bir satış döngüsü gerekir.
- Satın alma yetkisine sahip kişi, her zaman bütçe sahibiyle aynı olmayabilir; kilit hedef, ürünün değerini en güçlü şekilde hissedip süreci ileri taşıyabilecek kişidir.
- Etkili strateji, kullanıcıların yöneticileri ikna edebilmesi için somut veri ve ikna materyalleri sunmak ve bu süreci desteklemektir.
- Nihai başarı, kullanıcının içeride bir satış rolü üstlenebilmesini destekleyen bir süreç tasarımı kurmaktır.
Giriş – Sorunun çıkış noktası
- Ürünü gerçekten kullanan kişi ile satın alma kararını veren müşteri farklıysa nasıl yaklaşılmalı?
- Buradaki tipik bağlam, geliştiricinin ürünü denediği ve CTO veya Director of Engineering'in nihai kararı verdiği bir B2B yazılım satışı senaryosudur.
Yetkiye dair temel soru
- 'Gerçek güç kimde?' sorusu en kritik noktadır.
- Belirleyici olan sadece kartla ödeme yetkisi ya da ürünü deneme önceliği değil, gerçek etki gücü ve motivasyondur.
Organizasyon yapısına göre senaryolar
Küçük organizasyonlarda: yapı daha yataydır ve kararlar hızlı alınır
- Geliştiricinin ürünü keşfedip benimsemeyi fiilen yönlendirdiği durumlar yaygındır.
- CTO'nun temel motivasyonu pazara hızlı çıkmak ve hızlı iterasyon olduğu için, geliştiricinin araç önerisi karar üzerinde ciddi etki yaratır.
- Geliştiricinin aracı ücretsiz olarak hızla denemesi ve sonrasında ücretli kullanıma geçilmesi şeklindeki Trojan-horse tarzı yayılım sık görülür.
Büyük organizasyonlarda: güvenlik ve uyumluluk başlıca kısıtlardır
- Güvenlik gibi zaman dışındaki kısıtlar vardır ve süreç boyunca liderliğin kararı belirleyici olur.
- Kullanıcının (geliştiricinin) aracı kendi başına kurmasına veya satın almasına izin verilmez; satış döngüsü uzun ve karmaşıktır.
- Değer/risk algısı, UI/UX veya DX'ten çok güvenlik ve nihai çıktı üzerine odaklanır.
Gerçek etki gücü ve değer perspektifi
- Bütçe sahibi her zaman fiili karar verici olmayabilir.
- Önemli olan, 'kimin kaldıraç gücüne sahip olduğu' ve 'kimin teşviklerinin süreci ilerletmede en güçlü rolü oynadığı'dır.
- Ürünün fiyatı karşılığında sunulan değeri gerçekten değiş tokuş edebilen tarafın kim olduğunu gerçekçi biçimde anlamak gerekir.
Ürün benimseme akışına dair somut bir örnek
- Kullanıcı/geliştirici ürüne üye olur
- Ücretsiz denemeyi yerel ortamda kullanır
- Gerçek işlev değerini (ör. Pull Request öncesi/sonrası karşılaştırması, sorun vurgulama) doğrudan deneyimler
- Değer algısı oluşur → iş verimliliği ve otomasyon beklentisi doğar
- Kullanıcı, ihtiyacı liderliğe anlatıp ikna etmeye çalışır
- Liderlik, iç test ve bütçe değerlendirmesinin ardından onay veya ret verir
- Liderlik nihai satın alma onayını verir
- Satın alma tamamlanır ve ürün organizasyon içinde daha da yayılır
İki tarafın teşviklerine dair soru
- Geliştiricinin aracı önermesinin temel motivasyonunu anlamak gerekir (iş kolaylığı, kişisel yetkinliği görünür kılma, şirket hedeflerine ulaşma vb.)
- Liderliğin satın alma motivasyonunu anlamak gerekir (geliştirme verimliliğini artırma, şirket hedeflerine daha hızlı ulaşma vb.)
- Bu temel motivasyonlar mevcutsa şu stratejiler önerilir:
Pratik karşılık stratejileri
- Kullanıcının liderliği ikna edebilmesi için doğru öncesi-sonrası karşılaştırma raporları gibi ikna araçları sağlayın.
- Burada önemli olan soyut tavsiyeler değil, nicel verilere dayalı sonuçlardır.
- 'Önceki yönteme kıyasla ne kadar zaman tasarrufu sağlandı?' gibi gerçek sayılar, iknanın anahtarıdır.
- Gerçek satın alma konuşmalarının nasıl ilerlediğini müşteri (geliştirici) görüşmeleriyle anlayın ve ikna sürecindeki engelleri önceden giderin.
- Yani doğrudan satın alma yetkilisini ikna etmeye çalışmak yerine, kullanıcının şirket içi satış rolünü başarıyla yerine getirebilmesi için gerekli tüm ortam desteğini ve somut materyalleri sağlamak gerekir.
- Bu süreçte kullanıcının başarısı, doğrudan satıcının başarısına bağlanır (kullanıcı-satıcı-liderlik-şirket arasında herkesin kazandığı bir yapı).
Sonuç ve özet
- En iyi strateji, kullanıcının şirket içi satış rolünü başarıyla üstlenmesini desteklemektir.
- Odak, liderliği ikna etmek için gerekli nicel kanıtları ve somut değer materyallerini sağlamada olmalıdır.
- Öncelikle organizasyon ölçeğine ve kısıtlarına göre karar alma yapısını dikkatle analiz etmek gerekir.
- Sonuçta, kullanıcı başarılı olduğunda hem satıcı hem de şirket aynı anda kazanır.
1 yorum
Hacker News görüşü
Sadece bir indirme yapmak isterken iletişim bilgileri istenmesinden bıktım; ardından satış temsilcileri arayıp e-posta atmaya başlıyor, nazikçe reddetsem bile bunu görmezden gelip sürekli toplantı talep ediyorlar. Satın alma yetkim yok ama ekibim içinde memnuniyetsizlik yayabilirim; sonuçta ürünün imajı bozuluyor. Bir mühendis benden tavsiye isterse elbette bunu anlatıyorum. Veeam, AWS ve Keyence buna örnek.
Bir IT Manager olarak bunu neredeyse her hafta yaşıyorum. Benden yanıt alamayınca iş arkadaşlarıma ya da şirketteki başka kişilere rastgele e-posta atarak dolanmaya çalışanlar oluyor; bunu yaptıklarında o alan adını hızla tamamen engelliyoruz. Ayrıca sadece bir fiyat teklifi almak için zorla demo izletilmemesini isterdim. Ürünü zaten araştırmış, gerekiyorsa trial da denemiş oluruz; bu yüzden satış sunumu ya da demo yerine önce fiyatı vermek daha mantıklı.
Auth0 ve Okta da aynı sorunu yaşıyor. Gerçekten satın alma yetkim ve bütçem vardı ama iletişim o kadar aşırıydı ki üründen soğudum.
“Memnuniyetsizlik gücü” kavramını çok seviyorum. Özellikle ürünü ücretsiz verseniz bile satış ya da pazarlama ekibi fazla hevesliyse şirket algısı kötüleşebiliyor. Müşteriye onların istediği şekilde ulaşmak gerekir; sadece kendi istedikleri biçimde davranırlarsa ters teper. Ama bu, teşvik tasarımı açısından zor bir konu.
Bazı SaaS pazarlama ekiplerinde her 5-15 dakikada bir e-posta gönderildiği aşırı deneyimler yaşadım. Bazen bu tek bir çalışanın anlık hareketi olabilir ama bazen de üst yönetim ya da CEO doğrudan e-posta pazarlama aracını sonuna kadar açmış gibi görünüyor.
Buna Microsoft ürünlerini de eklemek gerekir. Kayıt olmak için “professional account” oluşturmanız gerekiyor ve bunun için gmail hesabına izin vermemek gibi giriş bariyerleri var. 30 günlük trial kullanıp ürünü değerlendirmek isteseniz bile hesap sorunu yüzünden erişemediğiniz oluyor. Trial bile bu kadar zorken gerçek kurulum sürecini düşünmek istemiyorum. Bu yüzden AI tabanlı CRM, ERP, Dataverse gibi şeyleri kullanma isteğim kalmıyor.
Bu durum Principal-Agent problemi'nden kaynaklanıyor. Şirket yönetimi bütçeyi elinde tutuyor ama ürünleri/araçları gerçekte geliştiriciler ve sahadaki çalışanlar kullanıyor. Girişimci açısından verilen tavsiye, kullanıcıları kendi tarafına çekip liderliği ikna etmelerini sağlamak. Temel mesele şu: gerçekten kredi kartını elinde tutan kişiyle konuşamıyorsanız, kullanıcıların liderliği ikna edebilmesini mümkün olduğunca desteklemelisiniz. Yani kullanıcıyı/geliştiriciyi fiilen satış rolüne sokuyorsunuz. Bu yaklaşım freemium model gibi yerlerde işe yarayabilir ama hastane sistemleri ve EHR (elektronik sağlık kaydı) gibi satın alma kararının tamamen yöneticiler tarafından tek taraflı verildiği sektörlerde, kullanıcıların ürünü deneyimleme şansı bile olmuyor; bunun nasıl aşılacağını merak ediyorum.
Sahada çoğu zaman bunun tersi de yaşanıyor. Parlak bir satışçı bütçe yetkisi olan kişiyi hedefleyip gerçek kullanıcılarla iletişimi kesiyor ve önce sözleşmeyi imzalatıyor. Kullanıcılar memnuniyetsizlik duyup sorunları dile getirdiğinde para çoktan ödenmiş oluyor.
“Liderliği ikna etmek için en iyi fırsatı verin ve bu seçeneği liderliğe iletebilmeleri bile kullanıcıların öne çıkmasını sağlar” tavsiyesini uygulamak için biz de ayrı bir “CEO Page” hazırlamıştık: https://www.rsync.net/products/ceopage.html
Enterprise sales yaklaşımına ek olarak şunu söylemek gerekir: karar verici kişi bile çoğu zaman şirket içindeki gerçek güç dinamiklerini tam anlamıyor olabilir. Ayrıca bu kişinin bir maliyet merkezinde mi yoksa gelir üreten bir birimde mi olduğu, yeni bir teknoloji mi zorlandığı yoksa standart bir ürün mü olduğu ve bu ürünü kimin risk ya da güç tehdidi olarak göreceği önceden düşünülmeli. Kime satış yapılacağına, kimden kaçınılacağına, ne zaman küçük ölçekli ya da büyük ölçekli gidileceğine dair strateji bu bilgilere dayanmalı.
Slack ve Postman’ın sık kullandığı yaklaşım şu: “Ekibinizin %96’sı zaten ürünümüzü kullanıyor. Artık satın almak mantıklı görünmüyor mu?”
Buna karşı “Zaten herkes kullanıyorsa neden satın alalım ki?” sorusu geliyor; bu da satın alanla kullanan arasındaki kopukluğun seviyesini gösteriyor. Özellikle KOBİ ortamında bu kopukluk büyük.
Öğrencilere yazılımı ücretsiz vermek de aynı sebepten.
Büyük şirketlerdeki küçük ekiplerde de bu sık görülüyor. Güvenlik ekibi varsa birden çok Slack workspace'e dağılmış kullanımı sorun olarak görebiliyor; bu yüzden “400 kişi 12 workspace kullanacağına bunu tek bir resmî hesap altında yönetin” argümanı işe yarayabiliyor.
Ticari open source ya da benzeri modellerin gizli avantajı, bireysel kullanıcı benimsemesi arttıkça şirket düzeyinde benimsemenin de artmasıdır.
Daha önce kurduğum şirket de bu sorunla karşılaşmıştı. Gerçek satın alma yetkisi olmayan geliştirici ekiplerine satış yapmak zorundaydık. Küçük şirketlerde ya da yetkili kişiye erişilebilen istisnai durumlarda anlaşma kolaydı ama çoğu vakada uzun bir satış döngüsü içinde maliyet tasarrufunu üst karar vericilere anlatmak gerekiyordu. Sonuçta bu süreç uzun sürdü ve başarı oranı düşüktü; şirketin başarısız olmasının başlıca nedenlerinden biri de buydu. Bu konunun daha açık konuşulmasına sevindim. Pek çok küçük işletme bunu yaşıyor ama resmî tavsiye şaşırtıcı derecede az.
Kullanıcının ürünü doğrudan kullanabildiği ve aynı organizasyon içinde olduğu durumlarda bu model iyi işliyor. Ama kullanıcı karar vericiyle doğrudan bağlantılı değilse ya da satın alma gerekçesini göstermek zorsa (örneğin otomobiller için keyless entry pop gibi), nasıl yaklaşmak gerektiğini merak ediyorum. Sürücü için büyük fayda var ama Ford CTO’su açısından toplantı isteği gereksiz görünebilir. Böyle bir durumda ürün geliştirildikten sonra pazara nasıl gidilmesi gerektiğine dair tavsiye arıyorum.
Böyle durumlarda bottom-up strateji cazip oluyor. Ford genel merkezi yerine ikinci el araç satıcıları, oto tamircileri ve aksesuar mağazalarını hedefleyerek başlamak etkili olabilir. Remote starter örneğinde kullanıcılar bunu istiyordu ama otomobil üreticileri ilgilenmiyordu; bu yüzden pazar önce ses sistemi mağazalarında çapraz satışla oluştu, sonra üreticiler de bunu opsiyon olarak sunmaya başladı. Hırsızlık önleme cihazlarında benzer bir deneyimim oldu; küçük başlayıp müşteri tabanı oluşturduktan sonra büyük şirketlere gitmek etkili oluyor.
Rakiplerin bu özelliği zaten benimsediğini vurgulayıp FOMO (kaçırma korkusu) yaratmak da bir yöntem olabilir.
Enterprise'da sadece CTO’ya satış yapmak yetmez. AWS veya Azure gibi gerçekten çekirdek rol oynayan şirketlerde CTO’yu ve kilit mühendisleri ikna etmek tüm organizasyonu değiştirebilir ama çoğu yazılımda kararı line manager, director ya da bölüm yöneticisi verir. Hatta her bölümün aldığı yazılım farklı olabilir; bu yüzden hedef kitleyi ayrıştırmak gerekir.
B2B2C marketplace'ler özellikle ilginç. “B2B” kullanıcıdan ücret almayıp işlem başına komisyon alınan modelde, kullanıcılar dağıtık bir satış gücü gibi kullanılıyor. Her kullanıcının kendi instance'ı üzerinden B2C müşterileri çekebilmesine yardımcı olmanız gerekiyor. Girişim ekibi açısından geliştirilecek şeyler çoğalıyor ve bu bazen karmaşık geliyor ama ilk giriş engeli düşük olduğu için, her hesap son müşteriye iyi değer sundukça gelir doğal olarak ciddi şekilde büyüyebiliyor.
Bizim şirket de buna çok yakın bir durum yaşıyor. Entity resolution ile ilgili bir business intelligence API geliştiriyoruz ve engineering, product, data science ekipleri işin içinde olduğundan satın alanla kullananın ayrışması daha da karmaşıklaşıyor. Mühendisler karmaşık şirket verisi eşleştirmenin zorluğunu sezgisel olarak anlıyor ama yöneticiler bunu sadece projenin gecikmesi olarak görüyor. Bu yüzden son zamanlarda “ekibiniz veri eşleştirmeye aylar harcıyor” gibi bir yaklaşımla gitmek daha ikna edici oluyor. Bir şirket bunu 10 yıldır kurum içinde çözmeye çalışmış ama hâlâ düzgün çalışmıyor. Elbette şirketten şirkete ve duruma göre yaklaşımın değiştiğini de görüyoruz.
TikTok gibi işlem başına ortadan yüzde alan model de bir seçenek olabilir.