Yazılımınızı Büyük Kurumlara Nasıl Satarsınız?

Türkiye’de konuşlanmış pek çok kurumun ve yazılımcının hayali dünya devlerine ürün satabilmek. Ancak bu konuda oldukça az Türkçe kaynak var, bu nedenle Emirates, Verizon, Coca Cola, Microsoft, Deutsche Telekom gibi kurumların her birisine Countly ürününü geliştirip satarken elde ettiğimiz tecrübeleri kaleme almak istedim. Umarım bu yazı sayesinde Türkiye’den daha çok yazılım firması yurtdışı odaklı satışlarını artırır.

Fotoğraf: Unsplash

Son zamanlarda Türkiye’deki yazılım sektöründeki en hararetli tartışmalar, Türkiye’nin ekonomisine paralel şekilde sektördeki gidişat, yurtdışındaki seçenekler ve küresel bir firma olmanın getirileri etrafında dönüyor. Bu dönemde repertuarında bir kaç Fortune 2000 (dünyanın en büyük 2000 kurumu) bulunan kurumlar, bunların markalarını web sayfalarına koyduklarında diğerlerine de örnek olabiliyor ve satışlarını artırma imkanı yakalıyorlar. Bu yazımızın da amacı, Countly’de Onur Alp Soner ile birlikte edindiğimiz tecrübelerden hareketle, daha çok döviz girdisi elde edebilmek ve Türkiye dışındaki pazarlara da açılabilmek adına, yazılım firmalarımızın önem vermeleri gereken konuları aktarmak.

(Metin biraz uzun, o nedenle çayınızı kahvenizi yanınıza alın. Başlıyoruz)

Yazının bundan sonraki geneli için bir kaç varsayım hazırlayalım, böylece hedef kitlemize daha uygun ve belirli kapsamlı bir metin kaleme alabilelim:

1. Satış hedefinde bulunacağımız bu tür “iri” firmalara F2000 adını verelim (not alın: dünyanın en büyük 2000 kurumu).
2. Bu firmaların hedefleri de sizin ürününüzü yıllık 10K-100K arası fiyatlarla temin etmek olsun.
3. Ürününüz küresel olarak satılabilecek, İngilizce desteği olan bir yazılım ürünü olsun ve bir ihtiyacı karşılasın.
4. Sizin, müşteri karşısına çıkabilecek küçük de olsa bir satış ve destek ekibiniz bulunsun.

Başarılı bir satış için yukarıdaki 4 varsayım dışındaki hiç bir ölçütün önemi bulunmuyor.

F2000'lerin yazılım seçiminde aradıklarına geçmeden önce yazılım satış süreçlerinde neden bu kadar önemli olduklarını inceleyelim:

1. Bir kez yazılım ürününüzü temin ettiklerinde dikey ve çapraz satışa oldukça açık olmaları (=up-sell/cross-sell), kurum içinde başka departmanların da aynı sürece hızlıca dahil olarak ek lisans satışına olanak vermeleri.
2. Satış süreci uzun olsa da sözleşme kapandıktan sonra kolay kolay müşteri kaybı yaşatmamaları (=churn), ve kurumun yazılımı en az 5–10 yıl arası kullanması.
3. Kimi zaman yazılımı kalıcı lisans ile temin etmek istemeleri (=perpetuity) ve bu sayede 2.5–3.5 yılın lisansını önden ödeyip gelir-gider dengesinde avantaj yaratmaları.
4. Genellikle yüksek hacimli satışlara aracılık etmeleri, bu sayede yıllık satış kotanızın %20'lere kadar olan hacmini tek başlarına karşılamaları.

Varsayımlar ve F2000'in yazılım satış sürecindeki öneminden sonra bazı temel kurallara açıklık getirmekte fayda var.

• Kural 1: İsteyen herkes F2000'e satış yapabilir. Ben satış süreçlerine her zaman dahil oldum, ancak hiç bir zaman kendimi iyi -hatta vasat- bir satışçı olarak göremedim. Sadece izlenimlerimden bu işin belli kuralları olduğunu ve F2000'in belli başlı taleplerinin nasıl karşılanması gerektiğini öğrendim. Siz de aynı yöntemi (sabırla) uygulayıp benzer kesime satış yapabilirsiniz.
• Kural 2: Her kurumun satın alma sürecine yaklaşımı temelde aynıdır, nüanslar kuralları bozmaz. Bazı adımlar atlanabilir, bazı adımlar diğerlerinden uzun ya da kısa olabilir. Bir KOBİ’ye ürünü anlatıp 90 dakikada satın almalarını sağlayabilirsiniz, ancak büyük kurum için bu süreç 2 seneye kadar uzayabilir. Ama ihtiyaç > test > iletişim > seçim > satınalma süreci nadiren değişir.
• Kural 3: F2000'e satışın kapanması için öncelik teknik yeterlilikte değil, iletişim, yakınlık ve destekte yatar. 5 kişilik bir firmayken bile F2000 ihtiyacını karşılıyorsanız bu ödüllendirici sürecin içinde kendinizi bulabilirsiniz. Kimi zaman RFP’ler hazırlanır ama puanlamanın (genellikle) önemi olmaz, yerine satış ve teknik destek ekibinin müşteriyle ne kadar ilgilendiği akılda kalır ve seçim buna göre yapılır.

Bu varsayımlar ve kurallar sonrasında öncelikle F2000 satış sürecini 6 adımda inceleyelim.

F2000 satış sürecini anlamak

Aşağıdaki maddeler, F2000 seviyesinde bir firmanın ihtiyaç oluşmasından satınalma sürecinin kapanmasına kadar olan adımlarını içeriyor. Bu adımlara hakimseniz bu başlığı atlayıp diğer konulara geçebilirsiniz.

1. Kurumda yazılım ihtiyacının doğması: Bir ekip, kurum içinde olmayan ve temin edilmesi halinde belirli bir fayda sağlayacak bir yazılım için ihtiyaç analizi yapar. Analiz sonrası satınalmaya yönlendirmek amacıyla onay gelir. Bu onay kurum içinde bu yazılımı sahiplenecek olan paydaş ekipten çıkar.

Dışa dönük (outbound) B2B satışlarının en büyük problemi, kurumun ihtiyacı olmadığı zaman kapılarını çalmaktır. Bu durumda potansiyel müşteri sizi geri çevirmezse o ihtiyaç/bütçe çıkana kadar oyalanma ihtimaliniz vardır. Bu nedenle satış sürecinde bir gereksinim/bütçe analizi yapmak ve gelecek yanıta göre devam etmek en iyi yöntemdir.

2. İş birimlerinin analiz dokümanı hazırlaması: Ürün basitse ve ekip içinde kullanılacaksa çok hızlı bir şekilde analiz onayı çıkar. Yazılım, ürün / pazarlama yöneticileri ve geliştiriciler tarafından aynı anda ihtiyaç duyulabilecek bir ürün ise bu durumda farklı iş birimlerinden yorum ve onay alınır, bütçe çıkar (ya da finansal dönem başında ayarlanmıştır). Bu analiz sürecine girebilirseniz seçilme ihtimaliz çok artar (tahmini süre: 1–2 ay).

Tam bu noktada not-invented-here sendromu (NIH) ortaya çıkabilir. NIH, kurumların, sırf başkalarının bulduğu teknolojilerden uzak durması ve kurum içinde “biz de yaparız” sürecine girme hastalığına verilen isimdir. NIH sendromu genelde bir yöneticiyle başlar - yönetici, ekibine benzer bir işi daha kısa sürede ve daha düşük maliyetle yaptırabileceğini düşünür, böylece bir sonraki terfisi için iyi bir fırsat yaratır.

3. Tedarikçi listesi hazırlanması: Önce uzun, ardından elemelerle kısa tedarikçi listesi (=shortlist) hazırlanır. Tedarikçilere önce RFI (konu hiç bilinmiyorsa gönderilen açık uçlu dosya), ardından RFP (hedeflenen tahmini özelliklerin bulunduğu ve tedarikçilerin yanıtlamaları beklenen dosya) ve sonrasında RFQ (ihtiyaçlar tam netleşip artık değişmeyecek noktaya gelince hazırlanan ve tedarikçilere gönderilen dosya) gönderilir. Çoğu süreçte salt RFP ile ilerlenir. Burada sizinle iletişime geçen kişilerin aynı zamanda bütçeyi yöneten ekibin de içinde olup olmadığını belirlemeniz, içeriden daha net bilgi akışı almanıza ve hedefe daha hızlı gitmenize olanak sağlar (tahmini süre: 1–2 ay).

Eğer bir firmadan ilk defa haber aldığınızda sizden RFP doldurmanız isteniyorsa, o projeyi kazanmanız oldukça düşük bir ihtimaldir. Bahsi geçen RFP’yi muhtemelen sizden önce bir tedarikçi hazırlamıştır ve en az 3 firma kuralını doldurmak üzere satınalma ekibi tarafından size gönderilmiştir.

4. Tedarikçilerle yazılım test süreçlerine girilmesi: Kısa listeye giren firmalarla iletişime geçilerek yazılımın tam kapsamlı bir sürümünün belirli bir süre boyunca denenmesi talep edilir. Bu süreçte yazılım detaylıca test edilir. Alıcı firma en az 45 gün talep eder, ancak 6 ay süre isteyen eden firmalara da rastlayabilirsiniz. Bu adım, sürecin en uzun ve zahmetli kısmıdır, zira operasyon, güvenlik ve (kısmen) maliyet hesabına girilir. Bu aşamayı da geçerseniz, tebrikler, %99 ihtimalle ürününüzü sattınız demektir (tahmini süre: 2–4 ay).

5. Sözleşme süreci: Satınalma ekibi ile genellikle onların elindeki sözleşmeye bağlı kalınarak devam edilir. Özellikle bankalar tarafında sizin sözleşmenizi ya gözardı ederler, ya da ciddi değişikliklere uğratarak onay için gönderirler. Dikkat etmeniz gereken en önemli noktalar cezai müeyyideler, yazılım teminatları (=indemnification), entellektüel sermaye haklarının — özellikle terzi dikim yazılım geliştirme durumu varsa — kimde olacağı (=intellectual property), ürün/servisin kurum içinde kimler tarafından kullanılabileceği ve en önemlisi de sunulan servisin kapsamıdır. Stopaj, KDV, olası vergilerin kimin tarafından hangi taraflarca ödenmesi gerektiği konusu önemlidir, bu maddelere dikkat edin (tahmini süre: 1–3 ay).

Sözleşme süreci kimi zaman mevsimsel etki gösterebilir. Özellikle mali yıl (fiscal year) sonlarında olan firmalar kalan bütçelerini kullanmak isteyebilirler. Ancak B2B sektöründe anlaşmaya varmak için aylar geçtiğinden bu mevsimsel dönemlerin etkileri banka hesabında doğrudan görülmeyebilir. Mali yıl sonu herhangi bir çeyreğin son ayı olabileceğinden (örn. 31 Mart, 30 Haziran, 31 Aralık) çoğu B2B yazılım satışı yapan kurumda gelir-gider tablosu %10–20'lik aralıklarda dalgalanmalar yaşar.

6. Yazılım kurulum süreci: Sözleşme imzalandıktan sonra rahatladınız, keyfiniz yerine geldi. Çok önemli bir durum olmadıkça artık müşteriniz ürünü içeride kabul ettirmiş, tüm paydaşlara benimsetmiş ve kullanmaya hazırdır. İster SaaS ürününüz olsun, isterseniz müşteride kurulum yapın (on-premises), bu işin tamamlanmasının ardından oldukça yoğun bir işlemler silsilesi bitmiştir. Sözleşmeye bağlı olarak eğitimler (Skype üzerinden ya da yerinde) verilir, entegrasyon süreci desteklenir ve canlıya çıkılır. Müşteriniz bunu içerideki proje yöneticisinin herkese gönderdiği projenin tamamlandığına dair mesajla kutlar, size de teşekkür e-postası gönderilir.

Bu dönemde işler biraz daha ciddiye bindiği için test sırasında hiç ortaya çıkmayan talepler birden gelmeye başlayabilir. Özellikle zayıf bir ihtiyaç analizi yapılan işletmelerde kurulum sonrasında ürün gerçekten kullanılmaya başlanınca yeni ihtiyaç kalemleri doğar. Bir üstteki maddede sözleşme hazırlarken profesyonel hizmetleri (=professional services) adam-gün olarak yazmıştınız, oraya bağlı kalarak birlikte analizini yaptığınız ek özellikleri ve değişim taleplerini (=change request) tamamlayıp ek fatura kesebilirsiniz.

Müşterinin üründen (teknolojik) beklentileri

Yazının şu ana kadar olan kısmında öncelikle F2000'e satış varsayım ve kurallarından bahsettik ve ardından süreçleri öğrendik. Aşağıda, ürününüzün kurumsal (=enterprise) bir firmaya satışı sırasında karşıdan gelebilecek taleplerini bulacaksınız.

• Single sign on (SSO) ve LDAP (merkezi kimlik denetimi): Müşteri yazılımınızı kullanırken merkezi bir noktadan kimlik denetimi yapılmasını talep edebilir. Countly’den bir örnek vermek gerekirse, ürünü kullanan pek çok müşterimizin içeride 10'larca farklı ekipten 100'lerce hesap açtıklarını biliyoruz. Bunları elle açmak ve hepsinin parola yönetimini LDAP’sız idare etmek oldukça güç, bu nedenle eğer ürününüzün böyle bir özelliği varsa büyük avantaj sağlayabilirsiniz.
• Denetim günlükleri (audit logs): Bunlar, ekipteki kişilerin yazılım içinde ne yaptığını tutan merkezi günlüklerdir. F2000'deki her kurum, yazılıma giriş-çıkışları, içeride yapılan işlemleri kontrol etmek ve gerektiğinde kayıtlı işlemlere geri dönmek ister. Şüpheli işlemler, geçmişte yapılan ve detaylıca araştırılması gereken hareketler bu denetim günlüklerinde yer almalıdır. Ek olarak büyük kurumların ISO-27002 uyumluluğu alabilmesi için içeride kullanılan tüm yazılımların denetim günlüğüne sahip olmaları gerekir.
• Rol temelli erişim denetimi, kısaca uygulamayı kullanan kişilerin sadece erişmeleri gereken noktalara erişimini sağlayacak altyapının, ürünle birlikte hazır gelmesidir. En asgari ihtiyaç, farklı erişim seviyelerine sahip kullanıcılar tanımlayabilmektir. Daha detaylı ihtiyaç ise bu kullanıcıları gruplayabilmek ve erişim yetkilerini detaylı kısıtlayacak mekanizmaları geliştirmek olacaktır.
• Güvenlik: Elinizde, parola yönetiminin nasıl yapıldığını, veriyi saklarken hangi şifreleme yöntemlerinin kullanıldığını, GDPR’a nasıl uyumluluk gösterildiğini, kimlik denetimi ve erişim yetki seviyelerini vb anlatan detaylı bir “Security at Şirketim” PDF kılavuzu olmalı. Örnek olması açısından yakın zamanda Atlassian’ın satın aldığı OpsGenie’nin güvenlik sayfasına bakabilirsiniz.
• Kurulum seçenekleri: Bu satırları okuyorsanız muhtemelen single-tenant, multi-tenant, on-premises ve private cloud terimlerini biliyor ve/veya hali hazırda kendi yazılımınız için de bu seçenekleri veriyorsunuzdur. Yazılımınız firma içinde kurulabiliyorsa, ürün veritabanı ile uygulama sunucu katmanı ayrı sunucularda tutulabilmeli ve veritabanı replikasyonu kolayca yapılabilmelidir. Son zamanlarda kullanım oranı artan Docker ve Kubernetes opsiyonları işinizi kolaylaştırabilir. Felaket yönetimi ve yedekleme de gündeminizde mutlaka olacak ve müşteriniz tarafından detaylıca sorgulanacak bir başka konudur.
• API: Forrester/Liaison Teknoloji Raporu’na göre ekiplerin %96'sı ellerindeki verileri diğer ürünlerle API’ler üzerinden entegre etmekte sorun yaşıyorlar. Bu problemin önüne geçebilmek için ürününüzün kurumsal müşterilerdeki diğer entegrasyon noktalarıyla iletişim kurabilmesine yönelik detaylı bir API servisine ihtiyacı bulunuyor.
• SLA ve destek seçenekleri: En temel kurumsal ihtiyaçların başında gelir. Firmalar yüksek maliyet kalemlerine sahip ürünleri temin ederken problem anında bunların belirli kurallar içinde belirli saat aralıkları içinde çözülmesini beklerler. SLA (Service Level Agreement), yazılımınızın asgari olarak ayakta kaldığı (uptime) süreyi ve destek sorularına verilecek yanıtlar için müşterilerin bekleme, ve problemin çözülme sürelerinin sözleşmeye yazılmasıdır.

Liste geniş gibi duruyor olabilir, ancak zaman içinde elinizde bir repertuar oluşacağından bir sonraki talep zincirinin altından daha kolay kalkabileceğinizi göreceksiniz.

Sözleşmeler

Sözleşme yönetimi bir anlaşmanın en önemli bacağını oluşturur. Müşteri gizlilik sözleşmesinden ürün deneme ve kullanım sözleşmesine, kurum güvenlik politikasından GDPR eklentisine kadar pek çok konuda sizden ek belge isteyebilir. İş ortaklarıyla çalışıyorsanız iş ortağı sözleşmesi ve ürün talep formları da elinizin altında olmalı.

Yaptığınız işin niteliğine ve büyüklüğüne göre bu sözleşmeleri A) İnternet’te kısa bir araştırmayla bulup kendinize göre düzenlemek ve B) bir avukatla oturup hazırlamak seçeneklerine sahipsiniz. Bu işlere yeni başlasaydım önce A, 5 yıl kadar sonra da B seçeneğine bakardım.

Hazırlamanız gereken sözleşmelerin bir listesini önem ve öncelik sırasına göre aşağıda bulabilirsiniz:

1. Software license subscription & maintenance agreement: Müşteri ile üretici (siz) arasında karşılıklı imzalanan ve ürünün müşteri tarafından hangi şartlar altında kullanılabileceğini tanımlayan sözleşmedir.
2. Software evaluation agreement: Ürünü belirli bir süreyle müşterinin kullanımına test amaçlı açmanız halinde her iki tarafça imzalanan sözleşmedir.
3. (Mutual) non-disclosure agreement: Müşterinin sizinle iletişime geçmesinin ardından yolladığı ve size aktarılan bilgilerin üçüncü partilerle paylaşılmayacağını belirleyen gizlilik sözleşmesidir. Genellikle karşılıklıdır ve iki taraf için ayrım gözetmeyen maddeleri vardır.
4. Partnership agreement: Birlikte çalıştığınız iş ortaklarının (reseller, OEM, vb) hangi şartlar altında ürününüzü satacağını belirleyen sözleşmedir.
5. Statement of Work (SoW): Belirli bir iş tanımı ve karşılık gelen işin ne kadar süreyle & maliyetle yapılacağını ve ödeme esaslarını belirten dokümandır.
6. Pentest, ISO, güvenlik ve diğer raporlar: Müşteriler güvenlik ve gizlilikle ilgili alınan sertifikalar, pentest (güvenlik testleri) raporları ve diğer alınan lisansları talep edebilir. Özellikle ISO27001 bazı projelerde kırmızı çizgidir. Bunlar ilk etapta elinizde olmayabilir, özellikle pentest oldukça maliyetli ($5K–$20K) bir kalemdir — acele etmeyin ve zamanla temin etmeye bakın.

Yukarıdaki maddelerin dışında müşterilerin size gönderdiği ve yanıtlamanız beklenen soruları da olabilir. Bu tür dosyalar 300'den fazla soru içerebilir ve doldurmak bir kaç saatinizi alabilir. İç süreçlerinizden yıllık gelirlerinize, müşteri sayısından destek elemanlarının CV’lerine kadar geniş bir yelpazede gelebilecek sorulara hazırlıklı olun. Dahası bu sorular ara ara tekrar sorulabilir. Ekipte bu tür dokümanları doldurup yönetecek bir “kontrat yöneticisi” (contract & compliance manager) ünvanı bile olabilir.

F2000'e satış öncesi ve sonrasında başarıya götürebilecek noktalar

Yukarıdaki başlıklar içine yazılması mümkün olmayan, ancak belirtmekte fayda gördüğüm noktaları aşağıda madde madde okuyabilirsiniz. Bu maddelerden bazıları, müşterilerin, aslında her ne kadar açık açık söylemeseler de temel korkularını ve bu korkuların nasıl giderileceğinin yöntemini de içerir.

1. Elinizde müşterilerinize hikayesini anlatabileceğiniz nitelikli vaka çalışmaları olmalı. Bankalar diğer bankaların, operatörler diğer operatörlerin yaptıklarını bilmek ve başarı hikayelerini benimsemek isterler. Dolayısıyla her sektörden 2 farklı müşteriyle konuşarak sayıları da işin içine katarak (örnek: ürünümüz TüylüPati’yi kullanan müşterilerde son kullanıcı memnuniyeti 6 ay içinde %12 arttı, kurumsal gelirlerde 4 ay içinde %5 iyileşme yaşandı) vaka çalışması hazırlamalı ve ürünün teknik becerilerinden daha önce bu vaka çalışmasını anlatmalısınız.
2. Dünyanın her yerinde hizmet / ürün sattığınızda içeride sizi aslında diğer paydaşlara anlatan ve destek isteyen kişiye satarsınız — bu kişi işten ayrılabilir, muhatap aldığınız ekipler değişir, ürüne ihtiyaçlar azalabilir — bu anlarda ürününüzden de bir parça kopar. Böyle durumlarda, talebin azalma ihtimalinin önüne geçmek için içerideki “şampiyonunuzla” sürekli dirsek temasında olmalı ve üst yönetime karşı elini güçlendirmesine katkıda bulunmalısınız. Kurum içindeki şampiyonunuzun kim olduğunu anlamanın yolu, onun 1) diğerlerini etkileyebilme seviyesinin yüksek olmasından ve 2) bütçe ile ilgili yorum yapmasından geçer.
3. Kalabalık bir ekibe satış yapacağınız için ek eğitim ihtiyacı doğacaktır. Müşterinize yerinde ya da uzaktan eğitim verdikten sonra, ürünün canlıya çıkması zaman alacağından ve ekip değişiminden dolayı her 6 ayda bir daha önce verdiğiniz eğitimi tekrarlamayı teklif etmelisiniz (burası çokomelli).
4. Yazılımınızı satarken proje yöneticisi ya da ürün yöneticisine ihtiyacınız yok. Sadece ürünü iyi tanıyan, müşterinin ihtiyaçlarını anlayan, korkularını bilen, bunlara karşı ne yanıt verilebileceğini hissedip ona göre pozisyon alan bir satış elemanı ile (ki ilk başlarda bu kişi doğrudan siz olursunuz), teknik sorulara en hızlı şekilde yanıt verebilecek bir kişi gereklidir. Dolayısıyla organizasyonel şema üzerinde kafa yormak bu aşamada gereksizdir, zaten çoğu F2000 şemanızı merak bile etmeyecektir.
5. (SaaS hariç) çok nadiren F2000'e yazılım satan bir firmanın web sayfasında ürünün fiyatı görünür haldedir. Siz bu seviyede bir satış yapıyor ve yazılımınıza web sayfasından net fiyat biçiyorsanız daha başlamadan masada para bırakmayı da göze almış oluyorsunuz. F2000 firmaları talepkardır, daha ikinci haftadan o fiyatlarla satış yapılamayacağını, 1 yıl boyunca sürecek sözleşme sürecine dayanamayacağınızı anlamış olursunuz. O nedenle naçizane önerim; önce /pricing altındaki fiyatınızı ya silin, ya da “Enterprise” adı altında bir sayfa açarak potansiyel büyük müşterilerinizi o sayfaya yönlendirin.
6. Muadil ürün/servisler ve müşterilerin kullandığı servislerden sizin farkınız, sunduğunuz desteğiniz olmalıdır. F2000'de teknik yeterlilik sonra gelir. İletişimde olduğunuz ekibin yanında olduğunu hissettirmek, onlara yakın durmak, dezavantajlı pozisyonlarda:

“Evet, böyle bir eksiğimiz var, ancak müşteri odaklı bir firma olduğumuz için sizlerle birlikte çalışıp isteklerinizi yol haritasına almayı çok isteriz. Küçük bir firma olabiliriz ama sizin gibi kurumları azimle, hevesle kazanmak ve ilişkimizi devam ettirmek bizim en büyük ihtiyacımız. Diğer büyük rakiplerimiz bunu yapamayacaklar, zira butik çalışmak onların geleneğinde bulunmuyor. Bu nedenle bizi seçmeniz size en büyük faydayı getirecektir.”

dediğiniz zaman karşıda vazgeçilmez bir etki yaratırsınız. Toplantı notlarınızı her telco sonrasında tutup gönderin ve sorulara mutlaka geri dönüş yapın. Müşterilerinizi fiziksel olarak görmeden de, düzgün bir süreç yöneterek onların gönlünü kazanabilir ve endişelerinizi giderebilirsiniz — zira Countly’de biz tüm müşterilerin sadece %10'u ile yüz yüze görüşmelerde bulunduk.

Satış uzun soluklu bir iştir

Kurumsal firmalara yazılım satışı -emin olun- başarı yüzdesinin düşüklüğüne, süresinin uzunluğuna ve git-gellerine rağmen, başarıldığı zaman muazzam haz veren, firmanızı bir adım ileriye taşıyan ve sağladığı referanslarla başka satışların da önünü açan bir olay.

Kurumsal ihtiyaçları anlayabilen, bunlara net yanıt verebilen, satış öncesi ve sonrasında müşterisinin yanında olan firmalar en büyük kazancı yaşayacaklar. Sizin de bu cazip ve keyifli işte “ama”lara takılmadan en prestijli firmalara ürettiğiniz yazılımı satmanız gayet mümkün.

YOLUNUZ AÇIK OLSUN!

Bu yazımı beğendiyseniz, aşağıdaki yazılarıma da göz atmanızı öneririm:

40 maddede ürün yönetimi: İyi bir ürün yöneticisi her gün neler yapar?

Kullanıcıyı ilk defa ağırlarken nelere dikkat etmelisiniz?

Girişiminiz için kanıtlanmış açık kaynak kodlu yazılım modelleri ve stratejileri

Türkiye’nin SaaS girişimleri