Arama Planlamayı Bırakma Talebi
(matduggan.com)- Yeni bir SaaS ürününü hafifçe denemeye kalktığınız andan itibaren satış e-postaları, mailing listeleri ve tekrarlanan arama talepleri başlar; kullanıcının zamanı sürekli aşınır
- Satın alma akışı, aslında gereken bir iki özellikten çok önceden belirlenmiş demoya ve “everything platform” tarzı anlatımlara sürüklenir; satış temsilcisi ve sales engineer aramaları artırır
- Ödeme onayı aşamasında üst düzey karar vericileri aramaya dahil etme baskısı artar; iç onay genelde en az bir ay, Fortune 500 şirketlerinde ise her şey yolunda gitse bile en az 3 ay sürer
- Satın alma sonrasında satış temsilcisi ortadan kaybolur; gerçek kullanıcıya LLM tabanlı müşteri desteği, uzun SLA’ler, belgelenmemiş sınırlar ve hata modları kalır
- Hesap temsilcisi sorun çözmekten çok ek özellik satmaya odaklanır; sonunda daha hızlı ve ücretsiz bir açık kaynak alternatifi ortaya çıktığında sözleşme yenilememe ve e-postayla vedalaşma ile biter
Deneme sürümünün peşinden gelen temaslar
- Yeni bir hizmeti ya da ürünü denerken en büyük engellerden biri, sonrasında gelen kesintisiz temastır
- Başta “sorunuz olursa bize bildirin” gibi zararsız bir e-postayla başlar; ama kısa süre sonra “customer success fun-gineer” gibi bir görevli, deneme deneyimini kontrol etmek için iletişime geçer
- Kullanıcı çoğu zaman belirli tek bir özelliği kontrol etmek için kaydolur
- O özellik yoksa ilgisini kaybeder ve unutur
- Hâlâ değerlendirme aşamasında değilse neden kendisiyle iletişime geçildiğini anlamak zordur
- Mailing listesinde kalırsa yeni sürüm ve lansman duyuruları almaya devam eder
- İlgisi olmasa bile, istediği özelliğin eklenmiş olma ihtimali yüzünden her seferinde abonelikten çıkıp çıkmamayı düşünür
- Erişilebilir sürüm notları yoksa, pazarlama e-postaları özelliğin eklenip eklenmediğini kontrol etmenin tek yolu gibi olur
“Bir arama yapalım”a dönüşen satın alma akışı
- En kötü durum, hizmeti gerçekten kullanabildiğiniz zamandır; bu noktadan itibaren bir dizi arama planına bağlanırsınız
- Web sitesine kredi kartı numarasını girip bitirmek yerine, Microsoft Teams’te yabancılarla ilişki kurmanız gerekir
- Tipik bir SaaS satış ekibinde iki rol ortaya çıkar
- Satış temsilcisi CRM’e veri girer ve satış kapanana kadar bastırmaya devam eder
- “sales engineer”, “customer success engineer” gibi unvanlara sahip kişi ise dokümanları gerçekten okumuş az sayıdaki insandan biridir ve ürünü yeni bir “everything platform” gibi anlatır
- Demo, kullanıcının istemediği özellikleri de içerir
- Kullanıcı yalnızca bir iki özelliği kontrol etmeye gelmiştir ama önceden belirlenmiş demo şablonu esnek değildir
- Satış temsilcisi, kullanıcının teknik olduğuna dair hafif bir iltifatla havayı yumuşatmaya çalışır
- Sales engineer’ın demosu kötü bir anda bozulur; ardından “normalde iyi çalışır” açıklaması gelir
Güvenlik, uyumluluk ve uzayan onay
- Bir noktada uyumluluk ve güvenlik sorulduğunda, anlamsız bir sertifika paketi gönderilir
- Sertifikasyon belgeleri, maddelerin gerçekten yapıldığının kanıtından çok, bunların yapılmış gibi makul görünebileceğini gösteren şeyler olarak ele alınır
- Demo ve ilişki kurma tamamlandıktan sonra satış ekibi, kullanıcının üst düzey karar vericisini aramaya dahil etmeye çalışır
- Karar verici her hafta birçok şirketin satış sunumunu dinlemek istemediği için, teklifi toparlama işi kullanıcıya kalır
- Kullanıcı ürünü gerçekten önemli görüyorsa, iç onay için gereken kişilerle bizzat temas kurmak zorunda kalır
- Bu süreç en az bir ay sürer
- Fortune 500 şirketlerinde her şey kusursuz ilerlese bile en az 3 ay sürer
- Zaman kazandırması beklenen ürün devreye alma işi büyük bir projeye dönüşünce, kullanıcı aracı kendisinin tersine mühendislikle çözmesi gerekip gerekmediğini düşünmeye başlar
Satın alma sonrası kalan sınırlar ve müşteri desteği
- Onay bitip para el değiştirdikten sonra satış temsilcisi kaybolur ve kullanıcı Customer Service’e, yani LLM’ye devredilir
- “limitless, cloud-based platform” gerçek kullanımda çeşitli sınırlar gösterir
- Bir gün normal çalışır
- Ertesi gün görünmeyen bir eşiği aşar ve tüm akış çöker
- Dokümanlar avantajları vurgulayacak şekilde düzenlendiğinden uyarıları veya sınırları bulmak zordur
- LLM müşteri desteği aynı doküman bağlantılarını tekrar tekrar sunar; ancak bundan sonra gerçek bir kişiye e-posta göndermek mümkün olur
- Destek e-postasının SLA’i 72 business hours gibi uzundur; bu da Super Enterprise Plan™ seçilmediği için böyle ele alınır
- Yanıt, görünmeyen bir sınıra ulaşıldığı ve workflow’un yeniden yapılandırılması gerektiği gibi bir sonuçla biter
- Kullanım sürdükçe belgelenmemiş hata modlarının listesi uzar
- Örn: “iki düğmeye çok hızlı basarsanız iFrame hata verir”
- Stack’in hatayı kaydediyor olması beklenir, ama kimse nedenini açıklamak ya da düzeltmeye yardım etmek için iletişime geçmez
Hesap temsilcisi, ek satış, açık kaynak ve ayrılık
- Bir gün yeni bir hesap temsilcisi(account rep) iletişime geçer; ürünü nasıl kullandığınızı ve nasıl yardımcı olabileceğini konuşmak için arama ister
- Bu arama, geri bildirim toplama ya da sorun çözmekten çok başka bir satış sunumuna benzer
- Temsilci sorun listesini dinleyip “bakacağını” söyler, ama asıl amaç ek özellik satın almaya ikna etmek olarak ortaya çıkar
- Ek özellikler, SSO veya API erişimi gibi satıcıya neredeyse hiç maliyeti olmayan ama kullanıcı için büyük fark yaratan kalemlerdir
- Kullanıcı, temel özellikleri elde etmek için üründen daha fazla mı satın alacağına yoksa ürünü tamamen kaldırıp başka bir yola mı gideceğine karar vermek zorunda kalır
- Sonunda bir açık kaynak geliştiricisi aynı işi yapan ücretsiz bir araç yapar
- Adı CodeSquish, Dojo, GitCharm gibi komik bir şey olabilir
- Bir iş arkadaşı sayesinde öğrenilir; bakıldığında gereken her şeyi yaptığı, maliyetsiz olduğu ve 100 kat daha hızlı olduğu görülür
- Tek bir kişi tarafından bakım yapılsa ve forumu yalnızca bir Discord sunucusu olsa bile ticari üründen çok daha iyidir
- Sözleşme yüzünden ayrılık ertelenir, ama sonunda Finance’e yenilememesi söylenir
- Yenilememe görüldüğünde tedarikçi ekip birden büyük ilgi göstermeye başlar ve açık kaynak aracın aslında daha kötü olduğuna ikna etmeye çalışır
- Kullanıcı “içeride konuşacağız” der ama gerçekte hiçbir görüşme yapmaz; en sonunda e-postayla ayrılığı bildirir ve domain’i engeller
1 yorum
Hacker News yorumları
Yatırımcılar da bu süreçleri çoğu zaman olgunluk sinyali ve en üst düzey uygulama olarak görüyor
Tersi yaklaşım ise bilgiyi mümkün olduğunca şeffaf biçimde paylaşmak ve engellememek, zayıf yönleri önce dürüstçe söylemek, müşteri bir insanla konuşmak istediğinde onu hemen sorunu çözebilecek kişiye bağlamak, müşteri istemedikçe yapay zeka temsilcisinin aramamasını sağlamak ve yapay zeka olduğunu hemen belirtmek, yalnızca aylık/çeyreklik/yıllık/sürüm notları gibi esnek e-posta abonelik seçenekleri sunmak, ürün uygun değilse daha uygun başka bir ürün gibi faydalı alternatifler önermek
Birçok şirket değer bazlı fiyatlandırma yüzünden bu duruma düşüyor. Standart bir fiyat koymak yerine müşteriyi ayrıntılı inceleyip üründen elde edeceği değeri tahmin ediyor ve buna göre fiyat belirliyorlar; teoride geliri maksimize ediyor ama yavaş ve istilacı bir yöntem
Ücretsiz plan kullanıcısı, çok temel programlama bile bilmezken izin verirsen tüm teknik destek zamanını tüketebilir
Yapay zeka kullanıldığını açıklamak, birden fazla bülten seçeneği sunmak, uygun değilse dürüstçe söylemek mantıklı ve pratikte de iyi çalıştı. Ama ilk üçü ürünü mahvedebilir. Yine de belki ben alaycıyımdır ya da şimdiye kadar bunu yanlış yönetmişimdir
Eğer varsayım yatırımcı parasıyla bir unicorn yaratmaksa evet, ama başka yan gelirleri olan tek kişilik bir şirketin yavaş ama istikrarlı büyümesi için bu yaklaşım uygun olabilir
Düzenlenmemiş rekabet dibe doğru yarıştır; en etik dışı, en istilacı, yasallık sınırında ve manipülatif taktiklerin kazanmasına yol açar
En iyi ürün değil en iyi pazarlama kazanır, müşteri dostluğu değil baskıyla elde edilen dönüşüm oranı kazanır ve fiyatı ürün ile hizmetin değeri değil insanların ödeyebileceği azami miktar belirler
Ücretsiz plan ya da deneme sürümü ve düzgün dokümantasyon olmasına rağmen demo istiyorlar. Kendi taraflarında birine inceletmek yerine benim zamanımı harcamayı tercih ediyorlar
Aslında geçmeyi düşünmüyorlar bile; sadece kurumsal rakipleriyle yenileme sözleşmesini daha ucuza almak için beni fiyat/özellik karşılaştırması olarak kullanıyorlar
Daha satıp satamayacağım bile belli değilken sonsuz güvenlik anketleri doldurmak zorunda kalıyorum. Cuma gecesi 11'de 100'den fazla soruyu doldurmayı seviyorsun, değil mi, der gibiler
Satın alma süreci 3 ila 6 ay sürüyor ve çoğu zaman sadece kendi marjını düşünen bir iki üçüncü taraf yazılım satıcısı da araya giriyor. CDW'ye fiyatı %15 düşürüp onların para kazanmasını sağlamayacağımı söylemek zorunda kalıyorum
Sözleşme bittikten sonra bile para 60-90 gün sonra geliyor ama hizmeti çoktan vermiş oluyorum ve nakit akışı zorlanıyor. Bankadaki müşteri temsilcisi de marjın ve kredi kartı limitinin neden dolu olduğunu sormak için arayabiliyor
Bu yüzden büyük şirketlere kesinlikle pahalı fatura keseceğim
Ne yapıp ne yapmayacağınızı baştan net söylemek gerçekten yardımcı oluyor. Hâlâ satın alma formları gibi şeyler istiyorlar ama en azından reddedebilir ve beklentiyi baştan koyabilirsiniz
https://help.timetastic.co.uk/hc/en-us/articles/115003288769...
Biraz özelleştirme gerekiyorsa ya da ürün-pazar uyumunu keskinleştirip kanıtlamaya çalışan erken aşama bir startup, pilot müşterilerle işbirliği yapıyorsa işler daha da zorlaşıyor. Müşteri yatırımcı portföyündeki başka bir startup değil de gerçek bir şirketse ve orada çok küçük bir ekibin ötesinde etki yaratıyorsa, CEO'nun kulağını çoktan kapmış olsanız bile farklı departmanlardaki paydaşlarla aylarca sürecek sonsuz toplantılara hazır olmanız gerekir
Çevik bir erken aşama startup açısından, teoride büyük ve hantal kurumsal şirketlere karşı muazzam bir inovasyon üstünlüğünüz olması gerektiğini hissediyorsunuz. Çünkü onların hiçbir şey yapamadığı izlenimi oluşuyor
Ama tam da hiçbir şey yapamayan o büyük ve hantal kurumun onayını gerektiren hatayı yaptıysanız, artık onların hareket engellerinin çoğu sizin engeliniz haline gelir
Aynı hikayenin daha kötü bir varyasyonunu da gördüm. Ekibinde zaten iyi bir açık kaynak çözümü başarıyla çalıştıran bir mühendis, başka bir mühendisin berbat bir ürünün kurumsal satış baskısına maruz kaldığını duyup alarm vermeye çalıştı ama artık çok geçti
Organizasyon şemasının üst tarafında birileri siyasi sermayesini ortaya koyup imzayı atmıştı ve bazı durumlarda şirket parasını o belirli ürüne harcamak kişisel performans göstergesine bile dönüşmüştü. Böylece bütün alternatifler kapatılıyor, herkes satışın tamamlanmasını aylarca bekliyor, ardından IT'nin SSO ve veritabanını kurması için bir ay daha bekleniyor ve iyi çalışan çözümden zorla berbat olana geçiriliyor
Sonunda sözleşme yenilenmiyor ve bunu zorlayanlar itibarlarını koruyor ama yükü sırtlanan insanların yarısı daha iyi şirketlere geçiyor, dörtte biri berbat ürün yüzünden işini yapamaz hale gelip PIP alıyor ya da kariyeri duraklıyor, kalan dörtte birin çoğu da ertesi yıl işten çıkarılıyor
Kurumsal satışa bazen sadece HAYIR demek gerekir. Kendi ürününü satmak için kurumsal satış yapmak zorunda olmaktan daha kötü tek şey, çalışan olarak başka bir kurumsal satışın yarattığı kötü satın alma kararını kullanmaya mecbur bırakılmaktır
Oysa bir açık kaynak çözüm bulursanız genelde daha iyidir ve istediğiniz her şeyi yapabilir.
docker compose upile zaten kolayca test de edilebilirAma dağıtım aşamasında uyumluluk ekibi yalnızca SOC2 sertifikasına bakıyor ve teorik olarak dünyanın herhangi bir yerinden herkes kodu değiştirebilir diye kod üzerinde derin inceleme talep ederek buna sert biçimde engel oluyor
Yönetici, ücretsiz ve açık kaynak olmasına rağmen bunun nasıl bu kadar iyi olabildiğini sorar; zaten aşırı yük altındaki ekipler de genelde öngörülemez bir yazılımı daha desteklemekten hoşlanmaz.
Sonunda seçim, berbat bir SaaS’a, bitmek bilmeyen ve faydasız satış döngülerine, korkunç ve pahalı satıcı bağımlılığına para ve enerji harcamakla; ya da açık kaynağı şirket içinde kullanıp işleterek biraz para ve enerji harcamak arasında kalır.
Genelde seçim açık kaynak olur. Özellikle de SaaS hızlı ve kolay self-servis onboarding, anlamlı bir değerlendirme süresi, öngörülebilir ve şeffaf fiyatlandırma sunmuyorsa bu daha da geçerlidir.
Ve eğer yaygın biçimde benimsenirse, yazarı desteklerler ya da daha karmaşık açık kaynak yazılımlarda bir destek planı için bütçe ayırırlar. Pratikte buna neredeyse hiç ihtiyaç duyulmayacak olsa bile bunu yaparlar.
"[...] Google’da CodeSquish’i arattım; ihtiyaç duyduğum her şeyi yapıyordu, maliyeti 0’dı ve performansı 100 kat daha iyiydi. Üstelik Vermont’taki çiftliğinden ara sıra çıkıp kendi self-hosted git deposuna kod push eden bir münzevi tarafından bakımı yapılıyordu."
O zavallı münzevi bakımcı, bir salı öğleden sonrası şirketinizin “CodeSquish” ile yılda 100 milyon dolar kazandığını ve hiçbir katkıda bulunmadığını öğrenir. Vermont’taki çiftliğinde tavukları beslerken sessizce hayat tercihlerini, daha doğrusu lisans tercihlerini sorgulamaya başlar.
Açık kaynak ya da SaaS’ın çoğu, Fortune 500 şirketlerinde faydalı olsa da daha çok kolaylık kategorisindedir; bu yüzden değer biçmek zordur. Yazıda da SaaS satıcısının, büyük şirketler için daha değerli görünmek adına süsleme yaptığı, insanları arayıp saçmalık pompaladığı ve değer bazlı fiyatlandırma kullandığı görülüyor.
Bir şirket açık kaynak bir sistemi işletiyor diye onu yeniden sattığına da pek sık rastlamadım. Genelde tüm fikri mülkiyete sahip olmak istedikleri için, yazıdaki gibi kendi dandik sürümlerini yeniden yapıyorlar.
Amazon’un Elastic’e yaptığını yapabilmesi, Elastic’in bir marka oluşturmuş olmasındandı. Rastgele bir projede bunu yapamazsınız. Bir projeyi altyapı işletiminde kullanabilirsiniz, ama değeri belirli bir kütüphane ya da projeye atfetmek çok zordur.
Amazon para kazanıyorsa bu Linux kernel kullandığı için değil, Amazon olduğu içindir. Her hâlükârda zihinde toparlaması zor bir konu.
Birincisi, bunun büyük kısmı B2B satış yapmak ve yazılım sektörünün yarısının dönmesini sağlamak için gerçekten gerekli olabilir. Satıcı tarafındaki şirketin birçok kez iletişime geçmesi, satış mühendisi devreye sokması ve tüm karar vericilerin hizalanmasına yardımcı olması gerekebilir. Yoksa iş hiç ilerlemez. Alıcılar fazla meşgul, büyük şirketlere satış yapmak da fazla karmaşık; dolayısıyla bunun bir kısmı, B2B işlemlerini sürdürmek için gerekli bir kötülüktür.
İkincisi, keşke şirketlerin gerçekten daha iyi satın aldığını hayal edebilsek. Büyük şirketler, startup’lar onda bir maliyetle 10 kat daha iyi bir şey yapabilirken enterprise şişkin yazılımlara milyonlarca dolar harcıyor. Onlara satış yapmak daha kolay olsaydı, herkes bu delilik olmadan daha iyi şeyler kullanabilirdi.
Orijinal yazıdaki deneyimin ruh emici olduğuna katılıyorum, ama müşteriler de kendilerine biraz yardımcı olsalar ceplerinde daha çok para kalır ve daha iyi teknolojiye erişirler.
Enterprise ürünler basitçe başka bir kategoridir; bu da ürünün kendisinden ayrıdır.
“LinkedIn’de İspanyolca bildiğinizi gördüm. ‘¡Qué chévere!’ ifadesinin konuşmalara enerji ve parlaklık katma şeklinin benzersiz derecede çekici olduğunu duydum. Son zamanlarda pratik yapma fırsatınız oldu mu?”
“Değişen regülasyonlara adapitates olan uyumluluk otomasyonu araçları geliştirerek, güvenli ve verimli yatırım programlarını garanti altına alırken genel giderleri azaltıyoruz.”
Hiç kimse LinkedIn’deki İspanyolca seviyemin “sınırlı çalışma yeterliliği” olduğunu görüp ilk cümledeki gibi konuşmaz. Ve ikinci cümledeki “Adapitates” gerçek bir kelime değil; bir halüsinasyon. https://old.reddit.com/r/ChatGPT/comments/1d8gc6x/did_chatgp...
Sorun satışın kendisi değil; çoğu insan bir miktar satış yaklaşımını tolere eder. Bir veri kopyalama şirketinden kişiselleştirilmemiş bir cold mail almıştım; kısa, öz ve spam mail’e göre samimiydi, bu yüzden gerçekten ürünle ilgilenmeye başladım.
Dünyadaki her şirket bu teknolojiyi deniyor; onlar bunu berbat ettiğinde güçlü sinyaller vermezsek, gelecekteki kendimizi bu çöplüğe zincirlemiş oluruz.
Bu özellikleri isteyen müşteriler, maliyet ne olursa olsun destek ya da SOC-2 raporu gibi şeylere ihtiyaç duyar; böylece bunlara ihtiyaç duymayan müşterileri sübvanse etmiş olurlar. Yardımcı olacaksa, SSO ve SLA içeren üst paketi ürünün gerçek fiyatı olarak görebilirsiniz.
Zaten teknoloji alanında gerçek anlamda maliyet bazlı fiyatlandırma neredeyse yoktur.
Bu fiilen şirketin en az 1 ek çalışanın tam yüklenmiş maliyetini karşılaması gerektiği anlamına gelir. Bu tam yüklenmiş maliyeti kabaca maaşın 2 katı sayın; bunu da bu SLA’yı talep eden müşteri sayısına bölünce, ne kadar ücret almanız gerektiği görünmeye başlar.
Yanıtı ancak 3 gün sonra alacağımı biliyorsam, bariz şeyleri kendim aratırım ve ancak başka yollarla yanıt bulamazsam desteğe ulaşırım. Ama daha kısa SLA’ler, özellikle telefon desteği, bazı müşteri tiplerini karşılaştıkları her hata mesajını olduğu gibi kopyalayıp yapıştırmaya ve o hata üründen çıkmamış olsa bile destek ekibinin bunu çözmesini beklemeye teşvik ediyor. Bunu bizzat yaşadım
Çapraz sübvansiyon, regülasyon nedeniyle ortaya çıkabilir ya da şirket pazar tekeli kurmaya çalışırken görülebilir
Ürün fiyatları, geliştirme maliyetinden çok ne kadar ücret alınabileceğine ve değişken maliyetlere göre belirlenir. İşaret ettiğiniz gibi bu, fiyat ayrımcılığına yol açar; bu yüzden görünüşte bir grubun diğerini sübvanse ettiği izlenimi oluşsa da gerçekte durum böyle olmayabilir
Marjinal maliyet ve ideal karar verme modeli görmek isterim. Yalnızca yüksek ödeme yapan müşterilere özel bir özellik geliştirme kararı, ancak o müşteriler bu özelliğin bedelini ödüyorsa kârlıdır. Diğer müşteriler de o özelliğe erişebilir ama buna “sübvansiyon” denmez. Yine de daha iyi kelimenin ne olduğunu ben de bilmiyorum
Lafı dolandırmayan doğrudan erişim, anında demo, anlamlı bir değerlendirme süresi, kolay onboarding vb. sunarsanız, genelde klasik satış oyunu bekleyen müşterileri kaybedersiniz
Kaynak: doğrudan erişim yaklaşımını bizzat uyguluyorum
Öyleyse neden satış mühendisiyle telefon görüşmesi yapıyor? E-postayı sadece silebilir
Betimlenen durumdaki gibi teknik sorumlu kişi nihai karar vericiyi engelliyorsa, bu daha çok kumardır ve sık sık başarısız olur
Kredi kartı bilgilerimi girip hemen başlamak isteyeceğim ürünler ancak AWS EC2 ya da alan adı kayıt hizmetleri gibi genel amaçlı yazılımlar olur
Fiyatlandırma/satış modelinde çizgiler bazen karışıyor; kurumsal ürünün genel amaçlı yazılım gibi fiyatlandırılması buna örnek. Bu genelde şirketin olgunlaşmamış olduğunun işaretidir
İki ya da üç haneli fiyatlı yazılımlarda satış ekibi olmamalı. Beş ya da altı hane ve üzeri fiyatlı yazılımlarda ise satış ve onboarding sürecinde mutlaka insan olmalı. Çünkü ödediğim şeyin büyük kısmı destektir
Sorun şu ki, bizim öğrenmek istediğimiz şey genelde “bu kullanım senaryosunu karşılıyor mu” değil, “bu kullanım senaryosunu ne kadar iyi karşılıyor” oluyor. Yazılıma bizzat dokunmadan bunu değerlendirmek zor
Sık sık satış konuşması almıyorum ama başka nedenlerle benzer bir tutumum var. İçeri girebilmek için önce evet deyip ayrıntılarda hayıra dönülmesine karşı, her şeyin yazılı olmasını istiyorum