# Churn Riskine Kademeli Müdahale

Sayfa: https://alidemirbas.com.tr/lab/journeys/churn-riski-yonetimi

Churn riski yükseldi → kanıtı değerlendir → riske göre müdahale et

## Amaç

Churn riski eşik üzerine çıktığında sinyallerin gücüne göre kademeli müdahale seçmek ve kullanımın geri dönüp dönmediğini izlemek.

Hedef: İlişki kurtarma ve müdahale · Kategori: Elde Tutma & Abonelik

## Adımlar

- **Tetikleyici**: Churn riski tanımlı eşiği geçti
- **Aksiyon**: Sinyal sayısı ve gücünü, segmenti / LTV'yi, yenileme zamanını ve son davranışı değerlendir
- **Karar**: Churn risk seviyesi ne?
  - Düşük: Push: İlgili bir değeri veya özelliği hatırlat
  - Orta: Kullanıcının aktif bir uygulama oturumu var mı?
  - Yüksek: WhatsApp izni var mı?
- **Aksiyon**: Push: İlgili bir değeri veya özelliği hatırlat
- **Bekleme**: 3 gün bekle
- **Karar**: Kullanım toparlandı ya da risk düştü mü?
  - Evet: Risk azaldı / ilişki toparlandı
  - Hayır: Kullanıcının aktif bir uygulama oturumu var mı?
- **Karar**: Kullanıcının aktif bir uygulama oturumu var mı?
  - Evet: In-app: Oturum sırasında ilgili özelliği öne çıkar
  - Hayır: E-posta: Kullanıcının kaçırıyor olabileceği kişiselleştirilmiş değeri göster
- **Aksiyon**: In-app: Oturum sırasında ilgili özelliği öne çıkar
- **Aksiyon**: E-posta: Kullanıcının kaçırıyor olabileceği kişiselleştirilmiş değeri göster
- **Bekleme**: 3–5 gün bekle
- **Karar**: Kullanım toparlandı ya da risk düştü mü?
  - Evet: Risk azaldı / ilişki toparlandı
  - Hayır: WhatsApp izni var mı?
- **Aksiyon**: WhatsApp: Doğrudan yardımın deneyimi iyileştirip iyileştirmeyeceğini sor
- **Karar**: WhatsApp izni var mı?
  - Evet: WhatsApp: Doğrudan yardımın deneyimi iyileştirip iyileştirmeyeceğini sor
  - Hayır: E-posta: Doğrudan yardımın deneyimi iyileştirip iyileştirmeyeceğini sor
- **Aksiyon**: E-posta: Doğrudan yardımın deneyimi iyileştirip iyileştirmeyeceğini sor
- **Bekleme**: 2–3 gün bekle
- **Karar**: Sorun çözüldü ya da risk azaldı mı?
  - Evet: Risk azaldı / ilişki toparlandı
  - Hayır: Churn'ün ana nedeni ne?
- **Karar**: Churn'ün ana nedeni ne?
  - Fiyat / değer: E-posta: Daha uygun bir plan veya paket değişikliği öner
  - Kullanım zorluğu: E-posta: Kullanım rehberi veya onboarding desteği paylaş
  - Teknik sorun: Teknik desteğe aktar
  - Ödeme sorunu: Ödeme desteğine aktar
  - Memnuniyetsizlik / şikâyet: Şikâyet Kaydını Sahiplenme journey'sine aktar
  - Belirgin neden yok: E-posta: Kişiselleştirilmiş değer, yeni özellikler veya ilgili bir rehber göster
- **Aksiyon**: E-posta: Daha uygun bir plan veya paket değişikliği öner
- **Aksiyon**: E-posta: Kullanım rehberi veya onboarding desteği paylaş
- **Devir**: Teknik desteğe aktar
- **Devir**: Ödeme desteğine aktar
- **Devir**: Şikâyet Kaydını Sahiplenme journey'sine aktar
- **Aksiyon**: E-posta: Kişiselleştirilmiş değer, yeni özellikler veya ilgili bir rehber göster
- **Bekleme**: 3–5 gün bekle
- **Karar**: Kullanım ya da satın alma toparlandı mı?
  - Evet: Risk azaldı / ilişki toparlandı
  - Hayır: Elde tutma teklifine uygun mu?
- **Karar**: Elde tutma teklifine uygun mu? - Yalnızca tanımlı bir teklif varsa, açık destek ya da ödeme kaydı yoksa ve bu çalıştırmada teklif gönderilmediyse.
  - Evet: E-posta: Kişiselleştirilmiş tek bir elde tutma teklifi gönder
  - Hayır: Toparlanma yok; pasif churn takibine geç
- **Aksiyon**: E-posta: Kişiselleştirilmiş tek bir elde tutma teklifi gönder
- **Bekleme**: Teklif süresi boyunca bekle - Süre teklifle birlikte tanımlanır; kullanım ya da satın alma toparlandığı anda dur.
- **Karar**: Kullanım ya da satın alma toparlandı mı?
  - Evet: Risk azaldı / ilişki toparlandı
  - Hayır: Toparlanma yok; pasif churn takibine geç
- **Çıkış**: Risk azaldı / ilişki toparlandı
- **Çıkış**: Toparlanma yok; pasif churn takibine geç

## Koruma kuralları

- Tek bir zayıf sinyali kesin churn nedeni sayma.
- Kullanım geri döndüyse sonraki müdahaleyi gönderme.
- Destek, ödeme veya şikâyet sorunu varsa ilgili journey'ye aktar; aynı çalışmada teklif gönderme.

## Temel kural

Müdahalenin yoğunluğunu riskin düzeyi ve gözlenen nedene göre artır; her adımda yeniden değerlendir.

## Ne zaman kurulmalı?

Churn raporlarında risk skoru eşiği geçen müşterilerin kendiliğinden toparlanmadığını görüyorsan ve hepsine aynı tepkiyi veriyorsan bu journey'yi kur. Skorun sinyal sayısı, segment ya da LTV, yenileme zamanı ve son davranışla birlikte okunabilmesi, aktif oturum bilgisinin ve push, e-posta ile WhatsApp izinlerinin müşteri kaydında bulunması, teklif uygunluk kuralının tanımlı olması gerekir. Risk artışı açık bir destek, ödeme ya da şikâyet kaydından geliyorsa önce o kaydı çözen journey'yi çalıştır; churn mesajı sorunu örtmez.

## Nasıl kurulmalı?

- **Tetikleyici ve giriş**: Churn riski tanımlı eşiği geçtiğinde journey başlar; ilk adımda sinyal sayısı ve gücü, segment ya da LTV, yenileme zamanı ve son davranış değerlendirilir. Eşiği geçen müşteriler girişte rastgele ikiye ayrılır: journey grubu müdahaleyi alır, kontrol grubu hiçbir müdahale almaz.
- **Kimler girmemeli**: Kapsam müşteri ilişkisidir; aynı risk artışı için ikinci bir çalışma açılmaz. Açık destek, ödeme ya da şikâyet kaydı olan müşteri o journey'de kalır ve burada teklif almaz; tek bir zayıf sinyal tek başına kademe yükseltme gerekçesi değildir.
- **Zamanlama ve kanallar**: Düşük riskte push ile değer hatırlat, 3 gün bekle; orta riskte ya da toparlanma yoksa aktif oturumda uygulama içi, değilse e-posta, 3 ile 5 gün bekle. Yüksek riskte ya da toparlanma yoksa izin varsa WhatsApp, yoksa e-posta ile yardım sor, 2 ile 3 gün bekle; nedene uygun e-postayı 3 ile 5 gün, uygunsa tek teklif e-postasını teklif süresi izler.
- **Çıkış ve devir**: Hangi kademede olursa olsun kullanım toparlanmış ya da risk düşmüşse journey risk azaldı çıkışıyla biter ve sonraki müdahale gönderilmez. Teknik sorun teknik desteğe, ödeme sorunu ödeme desteğine, şikâyet Şikâyet Kaydını Sahiplenme journey'sine aktarılır; teklife uygun değilse veya teklif sonrası toparlanmazsa müşteri pasif churn takibine geçer.
- **Sıklık ve izin**: En fazla beş temas gider; her kademe yalnızca öncekine toparlanma gelmediğinde açılır. WhatsApp, push ve e-posta için ayrı ayrı izin gerekir. Tek teklif e-postası yalnızca tanımlı teklif varken, açık destek ya da ödeme kaydı yokken ve bu çalışmada önce teklif gitmemişken çıkar.

## Başarı nasıl ölçülmeli?

**Kontrol grubuna göre ek kullanıma dönüş oranı**: Journey'yi haklı çıkaran tek şey, müdahale alan grupta kullanıma dönenlerin payının kontrol grubunu aşmasıdır; risk skorunun düşmesi tek başına kanıt sayılmaz. Eşiği geçtiğinde iki gruptan birine atanan tüm müşteriler paydadır; pay, atamadan sonra aynı takip süresinde kullanımı ya da satın alması toparlanan ve ilişkisi süren müşterilerdir. Grupların payları arasındaki fark journey'nin etkisidir; mesajın teslimi ya da yanıtlanması paydayı değiştirmez.

Ayrıca izle:

- **Riskin düşme oranı**: Atanan müşteriler içinde risk skoru eşiğin altına inenlerin payı; skor güncellemesini davranış sonucundan ayrı raporla, çünkü düşen skor tek başına toparlanma değildir.
- **Kademe başına toparlanma**: Push, uygulama içi ya da e-posta, yardım sorusu, nedene göre e-posta ve teklif adımlarından sonraki toparlanmaları ayrı izle; üst kademeler ek katkı getirmiyorsa yoğunluğu artırmanın karşılığı yoktur.
- **Devir payı ve neden dağılımı**: Nedenlerin dağılımını ve teknik desteğe, ödeme desteğine ya da Şikâyet Kaydını Sahiplenme journey'sine devredilen müşterilerin payını izle; devir payı yüksekse sorun churn mesajının değil o süreçlerin konusudur.
- **İzin kapatma ve şikâyet**: Riskli müşteri zaten hassastır; push iznini kapatma, e-posta aboneliğinden çıkma ve WhatsApp şikâyetlerini kanal bazında izle, bu sayılar yükselirse müdahale churn'ü hızlandırıyor olabilir.

## Sonuç yorumlanırken nelere dikkat edilmeli?

- Müdahale alan grup kontrol grubundan daha sık kullanıma dönmüyorsa müdahale davranışı değil skoru oynatmış olabilir; daha çok açılma, yanıt ya da düşen skor bu açığı gidermez. Yalnızca kullanıma dönüş farkına dayanarak karar ver.
- Bulgu bu kademe sırası, bu bekleme süreleri ve tanımladığın risk eşiğiyle sınırlıdır. Teknik desteğe, ödeme desteğine ya da Şikâyet Kaydını Sahiplenme journey'sine devredilen müşterinin toparlanmasını o sürece yaz, bu journey'ye bir daha sayma; tek bir zayıf sinyalden çıkan neden etiketini kesin churn nedeni gibi raporlama.
- Eşiği geçen müşteri sayısı azsa ve toparlanma nadirse fark şansla da çıkabilir. Başlamadan kontrol grubunun doğal toparlanma oranını ve görmek istediğin en küçük farkı [örneklem büyüklüğü hesaplayıcısına](https://alidemirbas.com.tr/hesaplayicilar/orneklem-buyuklugu-hesaplama) gir; verdiği müşteri sayısına ulaşmadan kademeleri karşılaştırma.
- Kullanım geri döndüğü halde sonraki kademe gönderilmişse bunu ayrı bir kurulum hatası olarak say; toparlanmış müşteriye giden yardım sorusu ya da teklif hem maliyet hem izin kapatma riskidir.

## Sık Sorulan Sorular

### Churn riski yüksek her müşteriye indirim verilmeli mi?

Önce riskin düzeyini ve gözlenen nedeni ayır. Bu akış düşük riskte değer hatırlatması, daha güçlü sinyallerde yardım ve nedene uygun çözüm kullanır. Teklif yalnızca tanımlı uygunluk varsa son seçeneklerden biridir. Teknik sorun veya ödeme hatasını indirimle örtmeye çalışma.

### Churn skoru müşterinin kesin ayrılacağını gösterir mi?

Skor bir risk sinyalidir, kesin karar değildir. Son davranış, sinyal gücü, yenileme zamanı ve müşteri bağlamıyla birlikte değerlendir. Sadece model puanı arttı diye aynı yoğun müdahaleyi herkese uygulama. Eksik veya eski veriyle verilen kararı ayrıca incele.

### Müşterinin ayrılma nedeni belli değilse hangi yol izlenir?

Doğrulanmamış bir neden uydurma. İlgili değeri veya yararlı bir kullanım rehberini gösterip güncel tepkiyi izle. Teknik, ödeme veya şikâyet sorunu belirlenirse doğru destek akışına aktar. Aktarım sonrası eski churn mesajlarının aynı sorunu tekrar anlatmasını önle.

### Risk skorunun düşmesi churn önlemenin işe yaradığını kanıtlar mı?

Tek başına kanıtlamaz. Gerçek kullanıma dönüş, satın alma ve müşteri ilişkisinin devamını uygun takip süresinde izle. Skor güncellemesini davranış sonucundan ayrı raporla. Kullanım toparlanmazsa bu örnek sınırlı teklif denemesinden sonra pasif takibe geçer.