Yazılım & teknoloji firması için CRM: B2B satış, demo ve destek döngüsü

Ankara'da on iki kişilik bir yazılım firması düşünün: ürün iyi, demolar akıcı geçiyor, deneme kayıtları geliyor. Ama satışın nabzı hâlâ bir e-tabloda ve birkaç WhatsApp grubunda tutuluyor. Geçen çeyrekte "sıcak" işaretlenmiş bir fırsat, teklif aşamasında sessizce eridi; sonradan anlaşıldı ki asıl kararı verecek teknik değerlendirici deneme ortamına iki haftadır hiç girmemişti. Tabloda hâlâ "sıcak" yazıyordu, üründe çoktan soğumuştu. Bu, doğru bir yazılım firması için CRM'e henüz geçmemiş ekiplerin en sık yaşadığı sahnedir: ilişki iyi görünür, veri yanıltır.

Bu yazıda bir yazılım firması için CRM'in neden sıradan bir kişi rehberinden farklı olması gerektiğini anlatıyoruz: B2B ve teknik bir satış döngüsünü, demo-POC-deneme hattını, ürün kullanım sinyallerini, teknik ve ekonomik alıcıyı aynı anda yönetmeyi, satıştan sonra devam eden yenileme-genişleme-churn döngüsünü ve tüm bunları operasyonel hâle getiren pratik bir kurulumu.

1Demo2POC / deneme3Teklif4Kapanış → yenileme

Yazılım satışı neden başka bir oyun?

Bir kafeye masa satmakla bir şirkete yıllık abonelikli bir yazılım satmak aynı iş değildir. Yazılım ve teknoloji satışı neredeyse her zaman B2B'dir; döngü daha uzun, daha teknik ve tek bir kişiyle bitmez. Kararı çoğu zaman bir satın alma komitesi verir: ürünü teknik olarak değerlendiren biri (CTO, yazılım lideri, DevOps), bütçeyi onaylayan ekonomik alıcı (genel müdür, finans) ve çoğu kez satın alma, hukuk ya da bilgi güvenliği tarafı — KVKK uyumu, veri işleme sözleşmesi, SSO gibi başlıklar masaya gelir.

İkinci fark, satışın bir demoyla değil bir kanıtla ilerlemesidir. Müşteri önce "gösterin" der, ardından "kendi verimizle deneyelim" der; canlı demo, POC (kavram kanıtı) ve deneme sürümü sürecin merkezindedir. Üçüncüsü, birçok teknoloji şirketinde self-serve ya da freemium bir giriş ile satış destekli büyümenin iç içe geçmesidir. Ve en önemlisi: satış, sözleşme imzalanınca bitmez. Gelir aboneliklerle tekrar eder; asıl mesele yenilemeyi, genişlemeyi ve kaybı (churn) yönetmektir.

Sıradan kişi-takibi neden yetersiz kalır

Adları, telefonları ve "aranacak/arandı" notlarını tutan bir liste düzenli bir defter tutar ama yazılım satışının gerçek durumunu göstermez. Çünkü bu satışta önemli olan kimin aranmış olduğu değil, ürünün içinde ne olup bittiğidir. Bir e-tablo size şunları söyleyemez:

• Ürün nitelikli aday (PQL) var mı: deneme kaydı yapan bir ekip gerçekten ürünü kurdu, kilit özelliği kullandı, ilk değer anına ulaştı mı — yoksa sadece e-posta mı bıraktı?
• Kullanım sinyalleri ne diyor: davet edilen kullanıcı sayısı, aktif gün sayısı, entegrasyonun kurulup kurulmadığı — bir fırsatın gerçekten canlı mı yoksa ölü mü olduğunu bunlar söyler.
• Teknik değerlendirme hangi aşamada: güvenlik incelemesi, entegrasyon testi ve POC kabul kriterleri bir yerde takip ediliyor mu?
• Kaç paydaşla konuşuluyor: anlaşma tek bir kişiye mi bağlı, yoksa komitedeki birden çok kişiyle ilişki kuruldu mu?

Bu dört sorunun cevabı hiçbir yerde olmayınca, ekip fırsatları hisle etiketler — ve his, yazılım satışında çoğu zaman yanılır.

Demo, POC ve deneme: pipeline'ı doğru modellemek

İyi bir SaaS ve yazılım satışı için CRM, boruyu (pipeline) gerçek satış hareketine göre kurar. Genel bir "ilgilendi → teklif → kapandı" hattı yerine bu sektörde aşamalar somut kapılarla ilerler: ilk temas → keşif → demo → POC/deneme → teknik ve güvenlik onayı → teklif → kapanış. Her aşamanın bir çıkış kriteri olmalı; "demo yapıldı" değil, "teknik değerlendirici canlı ortamda kilit senaryoyu gördü ve kabul etti" gibi somut bir eşik.

Özellikle demo aşaması, sektörün en pahalı adımıdır çünkü mühendislik zamanı harcar. Ürün demosunu doğru kurgulamak — hangi senaryoyu, kime, hangi sırayla göstereceğinizi bilmek — döngüyü kısaltan en güçlü kaldıraçlardan biridir. CRM burada demoyu ve POC'yi birer aşama olarak modelleyip her birinin kabul kriterini kaydettiğinde, "iyi geçti" hissi ölçülebilir bir ilerlemeye dönüşür.

Kullanım sinyalleri ve PQL: ürünü satış sinyaline çevirmek

Yazılım satışında en değerli veri CRM'in dışında, ürünün içinde üretilir. Bir ekibin denemeyi kurup ilk değere ulaşması, satışa bir görüşmeden çok daha net bir "hazırım" sinyali verir. Bu yüzden modern bir kurulumda ürün kullanım olayları CRM'e akar ve fırsatı besler: kim aktif, hangi özellik kullanıldı, deneme bitişine kaç gün kaldı.

Bu, özellikle freemium ve ürün öncülüğünde büyüme (PLG) modelinde kritiktir; çünkü orada satışçı devreye girmeden önce ürün kendini çoktan anlatmıştır. Satışçının işi, sinyali doğru okuyup doğru anda devreye girmektir. Deneme sürümünü ücretliye çevirmenin yolu, herkese aynı e-postayı atmak değil; aktivasyona ulaşmış, ürün nitelikli adaylara zamanında ve bağlamla dokunmaktır.

Pre-sales, ürün ve destek: ilişkiyi çok kanallı yönetmek

Karmaşık bir yazılım anlaşması tek bir kişiyle yürümez; buna multi-threading (çok kanallı ilişki) denir. Teknik değerlendiriciyle ve ekonomik alıcıyla paralel ilişki kurmak, tek bir şampiyonun şirketten ayrılmasıyla anlaşmanın çökmesini engeller. CRM, her paydaşın rolünü, itirazını ve son temasını aynı fırsat kartında göstermelidir.

Aynı şey satış sonrası için de geçerli. Bir teknoloji şirketinde satış öncesi sorular, ürün kullanımı ve destek talepleri aslında tek bir ilişkinin farklı yüzleridir; bunları ayrı sistemlerde tutmak kör noktalar yaratır. Gelir operasyonları (RevOps) yaklaşımının özü tam da budur: pre-sales, müşteri başarısı ve destek verisini tek bir müşteri zaman çizelgesinde birleştirmek. Destekteki tekrar eden bir hatanın yaklaşan yenilemeyi riske attığını, ancak bu bütünsel görünümde fark edebilirsiniz.

Yenileme, genişleme ve churn: satıştan sonra gelen gelir

Tek seferlik bir üründe satış biter; abonelikli bir yazılımda asıl gelir eğrisi oradan sonra başlar. Bu yüzden CRM yalnızca yeni anlaşmaları değil, mevcut hesapların yenileme tarihlerini, genişleme fırsatlarını (ek koltuk, üst paket, yeni modül) ve churn risklerini de izlemelidir.

Bir yazılım şirketinde sözleşme, satışın bitiş çizgisi değildir; gelirin büyük kısmı o çizgiden sonra kazanılır ya da kaybedilir.

Churn'ü erken yakalamak, kullanım sinyalleriyle yenileme takvimini birleştirmeyi gerektirir: aktifliği düşen bir hesap, yenilemeden aylar önce sessiz bir uyarıdır. Net gelir tutundurma (NRR) mantığını benimseyen ekipler, büyümenin yalnızca yeni müşteriden değil, mevcut müşteriyi elde tutup büyütmekten de geldiğini bilir. Elde tutma, satıştan bağımsız bir "başarı" işi değil, gelir döngüsünün doğal devamıdır.

Ölçmeniz gereken metrikler

Doğru CRM, doğru soruları sormanızı sağlayan panoyu da üretir. Bu sektörde anlamlı metrikler tek seferlik satış rakamları değil, tekrar eden gelirin sağlığını gösteren ölçütlerdir: aylık ve yıllık tekrar eden gelir (MRR/ARR), net gelir tutundurma (NRR), aktivasyon oranı, satış döngüsü süresi ve kazanma oranı. Bunları birlikte okumak, hangi aşamanın tıkandığını ve hangi müşteri profilinin en hızlı büyüdüğünü gösterir.

Buradaki amaç rapor için rapor üretmek değil, kararları yönlendirmektir. Gelir zekâsı (revenue intelligence) yaklaşımı, dağınık aktivite verisini "bir sonraki çeyrekte neye odaklanmalıyız" sorusuna verilen bir cevaba dönüştürür. Somut rakamlar sizin kendi verinizden gelmeli; sağlıklı bir eşik uydurmak yerine kendi geçmiş verinizi referans alın. Önemli olan hangi metriği neden izlediğinizi bilmektir.

"Kendi CRM'imizi yazalım mı?" ve pratik başlangıç

Yazılım ekiplerinin klasik bir refleksi vardır: "Bunu biz de yazarız." Teknik olarak doğru; ama çoğu zaman pahalı bir dikkat dağınıklığıdır. Kendi CRM'inizi yazmak, çekirdek ürününüzden mühendislik zamanı çalar, kalıcı bir bakım yükü yaratır ve yıllar içinde kimsenin dokunmak istemediği bir iç araca dönüşür. Kendi aracını yazmak yalnızca gerçekten benzersiz ve ölçeklenmiş bir iş akışınız olduğunda mantıklıdır; standart bir satış-destek süreci için hazır bir çözümü benimsemek neredeyse her zaman daha ucuzdur — hem de daha hızlı.

Başlamak için sadeleştirilmiş bir kurulum yeterli:

• Aşamaları ve çıkış kriterlerini tanımlayın: demo → POC/deneme → teknik onay → teklif → kapanış; her kapı için net bir "geçti" tanımı yazın.
• Ürün sinyallerini bağlayın: aktivasyon ve kilit kullanım olaylarını fırsata iliştirin ki PQL'ler kendini göstersin.
• Pre-sales ve desteği tek gelen kutusunda birleştirin: satış öncesi sorular ve destek talepleri aynı müşteri zaman çizelgesinde dursun.
• Yenileme ve genişlemeyi takvime alın: her hesabın yenileme tarihini ve risk skorunu görünür kılın.
• Az sayıda metrikle başlayın: MRR/ARR, NRR ve döngü süresiyle başlayıp gerektikçe derinleşin.

Sıkça sorulan sorular

Sonuçta bir yazılım firması için CRM, bir kişi listesi değil; demoyla başlayıp yenilemeyle devam eden bir gelir döngüsünün kumanda panosudur. Doğru kurulduğunda ürün sinyalini, satış aşamasını ve destek geçmişini aynı ekrana getirir. Rocketly gibi hepsi bir arada bir CRM, satış pipeline'ını, pre-sales ve destek için birleşik gelen kutusunu ve raporlamayı bir teknoloji KOBİ'si için tek yerde toplayarak bu döngüyü görünür ve yönetilebilir kılar.