Şunu fark ettim: CRM ekranında “at risk” etiketi gören ekiplerin çoğu aynı refleksi veriyor. İndirim maili. Belki bir hatırlatma. En kötü ihtimalle de otomatik bir “seni özledik” mesajı fırlıyor ortaya (ki bu çoğu kişinin gözünden kaçıyor). Açık konuşayım — bu yaklaşım bazen işe yarıyor, evet. Ama her müşteri için değil, her senaryo için değil. İşin aslı şu ki, sessizleşen iki müşteri birbirine benzer sinyal verdiği için aynı hikâyeyi yaşamış olmak zorunda değil; çoğu zaman da yaşamıyor.
Şöyle söyleyeyim, Geçen ay, İstanbul’da bir SaaS ekibiyle oturdum. Tam da buna benzer bir tablo gördüm orada. Panelde kırmızı yanan kullanıcıların yarısı fiyat hassasiyetiyle bekleme moduna geçmiş kişilerdi; geri kalan yarısı ise ürünü almış ama derin özelliklere hiç dokunmamıştı, yüzeyde dolaşıp duruyordu. İlk gruba kupon atınca dönüş geldi, ikinci gruba eğitim içeriği gönderince etkileşim artmaya başladı. Yani soru sadece “kim gitti?” değil. Asıl soru şu: “Neden böyle davrandı?”
Aynı churn sinyali, aynı aksiyon demek değil. Müşterinin geçmiş davranışı okunmadan verilen retention kararı çoğu zaman ya para yakıyor ya da yanlış kişiyi eğitiyor.
Neden tek sinyal yetmiyor?
Bak şimdi, klasik CRM mantığı çok net: kullanıcı uzun süre sessiz kaldıysa risklidir. Kaba taslak doğru bu. Ama eksik. Ciddi eksik. Çünkü satın alma anındaki niyet ile bugünkü sessizlik arasında kocaman bir boşluk var — o boşluğu doldurmazsanız elinizde ham veri kalıyor, anlam değil. Rakam var ama hikâye yok.
Ben bu ayrımı ilk kez 2023’te kendi tarafımdan kurcaladığım bir projede fark ettim. Küçük bir e-ticaret akışında bazı müşteriler kampanya görünce geri dönüyordu; bazıları ise ürünün premium sürümünü alıp sonra tamamen buharlaşıyordu. İkisine de aynı e-posta gitmişti ve dürüst olayım, sonuç bayağı vasattı. Bir grup daha çok indirim beklemeye alıştı; diğer grup içerik tarafında kayda değer etkileşim gösterdiğinde bile onlara hâlâ fiyat konuşuluyordu. Yanlış müşteriye yanlış mesaj. Klasik.
Buradaki problem şu: churn sinyali yalnızca alarm verir, teşhis koymaz (inanın bana). Ateş ölçer gibi düşünün — ateş var diyorsun ama sebep grip mi, yorgunluk mu, yoksa başka bir şey mi, belli değil. Müşteri tarafında da tamamen aynısı geçerli.
Alice ile Bhavik neden aynı değildi?
Örnek üzerinden gidelim çünkü en anlaşılır yer orası. Alice uzun süre dolaşıp en sonunda indirim bulunca satın alıyor; Bhavik ise kısa sürede karar verip üst seviye ürünü tam fiyattan alıyor. Sonra ikisi de sessizleşiyor. Standart sistem ikisini de “riskli” diye işaretliyor. — tahmin ettiniz — ikisine de aynı türden geri kazanım maili atıyor.
Gel gelelim Alice için doğru hamle indirim veya sadakat odaklı bir teklif olabilirken, Bhavik için eğitim webinarı ya da ileri seviye özellik anlatımı çok daha mantıklı duruyor. Çünkü biri fiyat duyarlılığıyla hareket etmişti, diğeri kabiliyet odaklı satın almıştı. Bu fark küçük gibi görünüyor. İlginç, değil mi? Cüzdana etkisi küçük değil ama.
Bunu biraz açayım.
Ne yalan söyleyeyim, Editör masasında bu konuyu yazarken aklıma geçen yıl Berlin’de dinlediğim bir ürün sunumu geldi. Konuşmacı aynen şunu söylemişti: “Yanlış retention stratejisi sadece dönüşümü düşürmez, müşteriyi yanlış alışkanlığa da öğretir.” Sert bir cümleydi. Doğru da.
İşin sırrı hafızada gizli
Şu fikir hoşuma gitti açıkçası: kısa vadeli olayları tek başına tutmak yerine onları zaman içinde düzenli hafızaya çevirmek. Sistem sadece “son durum”u görmüyor; önceki davranışlardan yapı çıkarıyor. Bana iyi organize edilmiş bir not defteri gibi geliyor bu — sayfa sayfa ilerliyorsun,. En sonda gerçekten ne olduğunu anlayabiliyorsun. Mantıklı değil mi? Dağınık notlardan değil, katmanlı bir hafızadan konuşuyoruz.
Böyle sistemlerde iki ayrı hafıza bankası fikri özellikle can alıcı oluyor. Birincisi kişi bazlı banka — kullanıcının yolculuğunu saklıyor. İkincisi playbook bankası — araştırmalardan çıkan strateji notları, gözlemler ve karar kuralları burada duruyor. Bunları karıştırırsanız empatinin içine sertlik giriyor ya da analiz kısmına gereksiz duygusallık bulaşıyor. İkisi de iyi sonuç vermiyor, tecrübeyle sabit.
Kişiye ait hafıza ne tutar?
Kişisel bankada ilk tıklama nerede olmuş, kaç gün sonra satın alma gelmiş, hangi sayfalarda gidip gelmiş — bunlar tutulur (şaşırtıcı ama gerçek). Hatta kimi senaryoda hangi özellikleri hiç açmadığı bile önemli hale gelir. Çünkü bazen insan neyi kullandığından çok neyi kullanmadığıyla tanınır. Bunu ilk duyduğumda biraz tuhaf geldi, sonra çok mantıklı buldum.
Ve işler burada ilginçleşiyor. Bu konuyla ilgili S3’ü Disk Gibi Bağlamak: AWS’nin Yeni Hamlesi yazımıza da göz atmanızı tavsiye ederim.
Playbook hafızası ne işe yarar?
Bir bakıma, ne yalan söyleyeyim, Playbook tarafında ise Bain raporu mu var, Forrester notu mu var, Reichheld’in sadakat yaklaşımı mı var — hepsi ayrı ayrı değerlendiriliyor. Stratejiye çevriliyor. Ben bunu test ettiğimde şunu gördüm: iyi hazırlanmış playbook olunca ekipler panikle karar vermek yerine hazır akıl yürütme setine yaslanıyor. Panik azalıyor. Karar kalitesi artıyor. Daha fazla bilgi için Qwen3-TTS’te Ses Klonlama Sınırı Kalkıyor: .qvoice Dönemi yazımıza bakabilirsiniz. BTK’nın Yeni IMEI Hamlesi: İki Telefon Devri Kapanıyor mu? yazımızda bu konuya da değinmiştik.
Mimari basit görünüyor ama püf noktası burada
Bakın, şunu fark ettim: Dışarıdan bakınca iki sınıf yazılmış Python kodu gibi duruyor: biri etkinlikleri topluyor, diğeri churn tetiklenince uygun yanıtı seçiyor. Evet. Basit görünüyor. Ama asıl mesele o basitliğin arkasındaki disiplinli ayrımda yatıyor — bunu es geçerseniz sistem kısa sürede karmaşık bir spagetti yığınına dönüşüyor.
class ConversionAgent:
def watch(self):
# pre-conversion events -> per-customer memory
pass
class RetentionAgent:
def react(self):
# customer memory + playbook memory -> right action
passBak şimdi, Küçük startup’larda bu yapı çok rahat çalışıyor çünkü ekip hızlı, veri hacmi yönetilebilir seviyede. Kurumsal tarafta iş biraz değişiyor; orada güvenlik izinleri, veri yönetişimi ve audit log şart oluyor. Bir startup’ta “hemen deneyelim” dediğiniz şey enterprise’da üç onay turundan geçiyor. E peki, sonuç ne oldu? Doğal olarak gecikiyor ama daha sağlam hale geliyor da — ikisi birlikte geliyor maalesef.
| Senaryo | Ne işe yarar? | Zayıf tarafı |
|---|---|---|
| Küçük startup | Hızlı deneme, az ekip yükü | Veri azsa model çabuk şaşabilir |
| Büyüyen SaaS | Kişiselleştirilmiş retention akışı | Operasyonel bakım ister |
| Enterprise | Daha kontrollü karar verme ve denetlenebilirlik | Tatbiki süreçler ağırlaşır |
Nerede parlıyor, nerede tökezliyor?
Aslında, Bence en güçlü tarafı şu: sistem yalnızca tahmin üretmiyor, gerekçe de üretiyor gibi davranıyor. Yani “bu kişiye neden indirim verdik?” sorusunun cevabı havada kalmıyor. Bu tür açıklanabilirlik satış (söylemesi ayıp) ekipleri için altın değerinde — pazarlama ile ürün ekibi arasındaki kavgayı en azından biraz azaltıyor. Az değil bu aslında.
Bir de şu var. Yanlış aksiyon maliyeti bazen göründüğünden büyük oluyor. Fiyat hassasiyeti olan kullanıcıya eğitim satmaya çalışırsanız ilgisini kaybedersiniz; premium kullanıcıya indirim gönderirseniz onu ucuzluğa alıştırırsınız. Bu kısmı kimse sevmiyor ama herkes yapıyor. Hata yapınca yalnızca fırsatı kaçırmıyorsunuz — kullanıcı davranışını da bozabiliyorsunuz. İkinci hasar çok daha sinsi.
Ama dürüst olayım, her şey güllük gülistanlık değil. Bu yaklaşımın güzel yanları kadar ham kalan tarafları da var. Mesela veri kalitesi kötüyse hafıza düzgün oluşmuyor; olay akışı eksikse çıkarım da yamuk çıkıyor. Ayrıca takım içinde hangi hafızanın ne kadar güvenilir olduğu konusunda ortak dil kurulmazsa sistem kağıt üstünde süper görünüyor ama pratikte hayal kırıklığı yaratıyor. Görmüşlüğüm var.
Neyi iyileştirirdim?
- Daha net skor eşikleri koyardım.
- Kişi bazlı hafızaya son etkileşim özetini eklerdim.
- Playbook önerilerini sektör bazında ayırırdım.
- A/B testini varsayılan hale getirirdim; sezgiye fazla güvenmemek lazım.
Böyle bir sistemi kim nasıl kullanmalı?
Eğer küçük bir startup iseniz önce tek kullanım senaryosuna odaklanın — mesela sadece trial-to-paid dönüşümü ya da sadece churn önleme akışıyla başlayın. Neyse uzatmayalım, ilk versiyonda amaç mükemmel olmak değil, doğru ayrımı göstermek olsun.
Kısa bir not düşeyim buraya.
Bilmem anlatabiliyor muyum, Eğer orta ölçekli bir SaaS iseniz segmentasyon kritik hale geliyor; fiyat duyarlı müşteriyle feature-driven müşteriyi ayırmak size ciddi zaman kazandırıyor. Bu ayrımı erken yaparsanız sonraki her karar daha kolay oluyor.
Eğer enterprise seviyedeyseniz bu işin yanına governance eklemeniz gerekiyor çünkü her öneri izlenebilir olmalı. Bazıları buna bürokrasi diyor. Açıkçası güvenlik ve uyumluluk olmadan bu tarz sistemler pek rahat yürümüyor, o da bir gerçek.
Kullanırken akılda tutulacaklar
- Sinyali tek başına yorumlama.
- Tarihsel bağlam olmadan aksiyon verme.
- Aynı otomasyonu tüm segmentlere uygulama.
- Mümkünse çıktıyı insan onayından geçir.
En iyi retention sistemi en çok mail atan sistem değildir; doğru kişiye doğru şeyi söyleyen sistemdir!
Ben olsam buradan nereye giderdim?
Burada, açık konuşayım — ben bu fikri yalnızca churn için kullanmazdım. Lider adaylarını tanımlamada bile işe yarar diye düşünüyorum. Bazı kullanıcılar ürüne hızla bağlanır ama yüzeyde kalır; bazıları yavaş başlar, fakat derine iner. Biri operasyonel değer taşır, diğeri stratejik fırsat üretir. İkisini karıştırmak pahalıya patlıyor.
Editör olarak haberin ilk halini okuduğumda aklıma hemen LLM Wiki: Claude Code ile Unutmayan Bir Yapay Zekâ Hafızası geldi. Burada da mesele belleği düz depolamak değil…
Bir de performans cephesinden bakınca Rate Limiting Deep Dive: Token Bucket, Leaky Bucket. Sliding Window yazısındaki disiplin hissi burada da kendini gösteriyor; kural koymadan akıllılık olmuyor yani.
Peki hepsini gerçek hayatta nasıl toplarsınız? Güvenlik boyutunu unutmamak gerekiyor tabii — bunun için de API Güvenliğinde Kaçan Detay: SaaS’ı Sessizce Yakan Açıklar yazısındaki uyarılar bence iyi tamamlayıcı olur.
Sıkça Sorulan Sorular
Same churn signal two different right answers ne demek?
Aynı churn sinyalinin her müşteri için farklı aksiyon gerektirebileceğini anlatır. Kısacası sessizlik aynı olsa bile satın alma niyeti farklı olabilir.
Müşteri neden sessizleştiğini nasıl anlarsınız?
Sadece son aktiviteye bakmak yetmez. Satın alma hızı,görülen sayfalar,indirime tepki ve kullanılan özellikler birlikte değerlendirmek lazım.Böyle bir sistem küçük şirketlerde işe yarar mı?
Evet,özellikle az sayıda segmentiniz varsa oldukça işe yarar. Küçük ekipler hızlı test yapabildiği için ilk kazanımı daha çabuk görür.Bu yaklaşım CRM otomasyonundan farkını nerede gösterir?
Klasik CRM çoğunlukla tetik bazlı çalışır. Buradaki fark ise geçmiş bağlamdan öğrenip aksiyonu ona göre seçmesidir.Kaynaklar ve İleri Okuma
Hindsight Resmi Dokümantasyonu
Orijinal Yazı — Same churn signal two different right answers
]
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
