Kullanım Düşüşlerini ve Müşteri Churn Riskini Tespit Eden Bir Web Uygulaması Oluşturun

Ne inşa ediyorsunuz ve neden önemli

Bu proje, müşteri kullanımındaki anlamlı düşüşleri iptale dönüşmeden önce erken tespit etmeye yardımcı olan bir web uygulaması. Yenileme konuşmasını bekleyip sorun keşfetmek yerine uygulama net bir sinyal gösterir (ne değişti, ne zaman ve ne kadar) ve ilgili ekibi yanıt vermeye yönlendirir.

Amaç: daha erken tespit, daha iyi tutundurma

Kullanım azalışları genellikle iptale gitmeden haftalar önce görünür. Uygulamanız bu düşüşleri görünür, açıklanabilir ve işe yarar hâle getirmeli. Pratik hedef basit: riski daha erken yakalayıp tutarlı şekilde yanıt vererek churn’u azaltmak.

Kimler için (ve her grubun ihtiyacı ne)

Farklı ekipler aynı veride farklı “gerçekleri” arar. Kullanıcıları göz önünde bulundurarak tasarlamak uygulamanın sıradan bir pano olmaktan çıkmasını sağlar.

• Customer Success dikkat gerektiren hesapların önceliklendirilmiş görünümünü ve bilgilendirici bir başlangıç bağlamını ister.
• Satış (özellikle hesap yöneticileri) yenileme odaklı risk bayrakları ve genişleme veya kurtarma konuşmalarını destekleyecek konuşma noktaları ister.
• Ürün ve analitik ekipleri sürtünme, benimseme boşlukları veya değer ödemenin gerçekleşmediğini gösteren toplu trendleri ister.

Sağladığınız çıktılar

En azından uygulama şunları üretmeli:

• Son kullanım trendleri ve risk göstergeleriyle bir müşteri sağlık panosu
• Bir hesap anlamlı bir eşiği aştığında (düşüş, etkinlik kaybı veya desen değişikliği) uyarılar
• Sonraki en iyi eylemler: ne yapılacağını öneren öneriler (mesaj, arama, eğitim, düzeltme veya iç eskalasyon)

Bu, “veri bir yerde mevcut” olmaktan “insanların gerçekten takip ettiği bir iş akışı”na geçiştir.

Başarıyı nasıl ölçeceksiniz

Ürün gibi başarıyı metriklerle tanımlayın.

• Kesinlik (Precision): uyarılan hesapların kaçı gerçekten riskteydi?
• Yanıt süresi: bir sinyalden sonra ekip ne kadar hızlı müdahale ediyor?
• İş etkisi: kurtarılan yenilemeler, azalan churn veya korunan genişlemeler

Uygulama kararları iyileştirip eylemi hızlandırırsa benimsenir ve maliyetini çıkarır.

Kullanım Düşüşlerini ve Müşteri Birimini Tanımlayın

“kullanım düşüşü”nü tespit etmeden önce kullanım için net bir tanım ve tutarlı bir ölçüm birimi gerekir. Bu, analitik jargonundan çok yanlış alarmları önlemek (veya gerçek churn riskini kaçırmamak) ile ilgilidir.

“Kullanım” ne anlama gelmeli

Gerçek değeri yansıtan bir birincil kullanım metriği seçin. İyi seçenekler ürününüze bağlıdır:

• Anahtar olaylar: örn. oluşturulan raporlar, gönderilen mesajlar, tamamlanan dağıtımlar
• Oturumlar veya aktif günler: birçok işlem hafifse faydalı
• Dakikalar / tüketim: video, çağrı, compute veya API ağır araçlar için yaygın
• Aktif koltuklar: anlamlı iş yapan ayrı kullanıcı sayısı

Manipüle edilmesi zor ve yenileme niyetiyle yakından ilişkili bir metrik hedefleyin. Daha sonra birden çok metrik takip edilebilir, ama cümleyle açıklayabileceğiniz birinden başlayın.

Müşteri birimi: kim “düşüyor”?

Skorlayacağınız ve uyaracağınız varlığı tanımlayın:

• Hesap/workspace (B2B için en yaygın)
• Abonelik (bir şirketin birden fazla planı varsa faydalı)
• Hesap içi kohort (ör. departman) eğer benimseme çok değişkense

Bu seçim tüm şeyi etkiler: toplulaştırma, panolar, sahiplik ve uyarı yönlendirme.

“Düşüş” ne sayılır

Müşteri davranışına uyan eşikleri belirleyin:

• Haftalık değişim (basit ve açıklanabilir)
• Hareketli ortalama vs önceki hareketli ortalama (gürültüyü azaltır)
• Mevsimselliğe duyarlı bazeline’lar (hafta içi/hafta sonu desenleri için kritik)

Ayrıca zaman penceresini (günlük vs haftalık) ve kabul edilebilir raporlama gecikmesini (örn. “uyarılar ertesi sabah 9’a kadar” vs gerçek zaman) kararlaştırın. Net tanımlar uyarı yorgunluğunu önler ve skorları güvenilir kılar.

Veri Kaynaklarını ve Entegrasyon Yaklaşımını Seçin

Uygulamanız izlediği girdiler kadar güvenilirdir. Panolar veya risk skorlama oluşturmadan önce hangi sistemlerin sizin için “kullanım”, “değer” ve “müşteri bağlamı” tanımladığını belirleyin.

Minimum kaynak sistemi seçin

Doğru ve güncel tutabileceğiniz dar bir kaynak setiyle başlayın:

• Ürün olayları: girişler, ana özellik eylemleri, API çağrıları, kullanılan koltuklar, dışa aktarımlar—değer ile korelasyonlu ne varsa
• Faturalama/abonelik: plan, yenileme tarihi, ödeme durumu, genişlemeler/düşüşler, deneme başlangıç/bitim
• CRM: hesap sahibi, segment, yaşam döngüsü aşaması, sözleşme koşulları
• Destek ticketları: hacim, önem derecesi, yanıt süreleri, çözülmemiş sorunlar
• Durum/olay geçmişi: kesintiler ve performans düşüşleri kullanım düşüşlerini açıklayabilir

Emin değilseniz önce ürün olayları + faturalamayı önceliklendirin; çekirdek izleme çalışınca CRM/destek ekleyin.

Veriler nasıl gelecek (ve ne sıklıkta)

Üç yaygın alım yöntemi vardır ve birçok ekip karışım kullanır:

• Webhooks/streaming gerçek zamanına yakın ürün olayları ve abonelik değişiklikleri için
• Toplu içe aktarma (günlük/saatlik) CRM ve destek araçları için, saniye saniye güncelleme gerektirmiyorsa
• ETL/ELT konektörleri Salesforce/Zendesk gibi araçlardan yönetilen senkronizasyon istiyorsanız ve özel kod yerine tutarlılık tercih ediyorsanız

Kararı otomasyonla vereceğiniz kararlara göre eşleştirin. Örneğin, ani bir düşüşten sonra CSM’leri bir saat içinde uyarmayı planlıyorsanız, olay alımı günde bir kez olmamalıdır.

Tanımlayıcıları doğru yapın (yoksa her şey bozulur)

Kullanım düşüşleri her müşteri birimi için tespit edilir (hesap/tenant). Eşlemeleri erken tanımlayın ve kalıcı kılın:

• Account ID (tenant/workspace) birincil gruplayıcı anahtar olarak
• User ID’ler hesap ile bağlı olarak (kullanıcılar hesaplar arasında hareket edebilir—geçmişi takip edin)
• Plan ID / subscription ID faturalama dönemleriyle ilişkilendirilen

Her entegrasyonun aynı hesaba çözülmesi için tek bir kimlik eşleme tablosu/hizmeti oluşturun.

Sahiplik ve erişimi baştan belgeleyin

Hangi veri setinin kimin sorumluluğunda, nasıl güncellendiğini ve kimlerin görüntüleyebileceğini yazın. Bu, hassas alanlar (faturalama detayları, destek notları) eklendiğinde veya metrikleri paydaşlara açıklamanız gerektiğinde engellerin önüne geçer.

Metrikler, Sinyaller ve Geçmiş İçin Veriyi Modelleyin

İyi bir veri modeli uygulamanızı hızlı, açıklanabilir ve genişletmesi kolay tutar. Sadece olay depolamıyorsunuz—kararları, kanıtı ve ne olduğunu gösteren bir iz tutuyorsunuz.

Çekirdek varlıklar (“gerçek kaynak”)

Her şeyin referans verdiği birkaç sabit tabloyla başlayın:

• accounts: account_id, name, plan, status, timezone, CSM owner
• users: user_id, account_id, role, created_at, last_seen_at
• subscriptions: account_id, start/end dates, MRR, seats, renewal date
• events: event_id, occurred_at, user_id, account_id, event_name, properties (JSON)

CRM, faturalama, ürün gibi sistemlerde ID’leri tutarlı tutun ki join’ler tahmin yürütmeden çalışsın.

Hız için toplulaştırma: günlük metrikler ve özellik kullanımı

Ham olaylardan her pano görünümü için sorgu yapmak hızla maliyetli olur. Bunun yerine şu gibi ön hesaplanmış anlık görüntüler oluşturun:

• account_daily_metrics: account_id, date, active_users, sessions, key_actions, time_in_product
• account_feature_daily: account_id, date, feature_key, usage_count (veya dakika, kullanılan koltuk vb.)

Bu yapı hem yüksek seviyeli sağlık görünümlerini hem de özellik düzeyinde soruşturmayı destekler (“kullanım düştü—tam olarak nerede?”).

Risk sinyallerini kanıtla birlikte ayrı depolayın

Risk tespitini kendi ürün çıktısı olarak ele alın. Bir risk_signals tablosu oluşturun:

• signal_type (örn. usage_drop_30d, no_admin_activity)
• severity (low/med/high)
• timestamp ve lookback window
• evidence (sayılar, bazlinelar, metrik satırlarına referanslar)

Bu, skorlama sürecini şeffaf tutar: uygulama bir hesabı neden işaretlediğini gösterebilir.

Denetim ve öğrenme için geçmişi takip edin

Ekleme-yönelimli geçmiş tabloları oluşturun:

• health_score_history: account_id, computed_at, score, contributing_signals
• alert_history: triggered_at, channel, recipients, dedupe_key
• actions_taken: created_by, action_type, notes, outcome

Geçmişle şu soruları cevaplayabilirsiniz: “Risk ne zaman yükseldi?”, “Hangi uyarılar göz ardı edildi?” ve “Hangi playbook’lar churn’u gerçekten azalttı?”

Ürün Olaylarını ve Veri Kalitesi Kontrollerini Enstrumente Edin

Altyapı olayları tutarsız veya eksikse uygulamanız kullanım düşüşlerini tespit edemez. Bu bölüm olay verisini panolar, uyarılar ve risk sinyalleri için yeterince güvenilir kılmakla ilgili.

Basit bir izleme planı tanımlayın

Değeri temsil eden davranışların kısa bir listesiyle başlayın:

• Anahtar eylemler (örn. “proje oluşturuldu”, “takım davet edildi”, “rapor yayımlandı”)
• Özellik kullanımı (hangi modüller kullanıldı, ne sıklıkla)
• Sürtünme sinyalleri (hatalar, başarısız ödemeler, izin reddi)
• Performans göstergeleri (yavaş API yanıtları, sayfa yükleme gecikmeleri, zaman aşımı)

Pratik olun: bir etkinlik metrik, uyarı veya iş akışı tetiklemeyecekse henüz takip etmeyin.

Olay şemasını standardize edin

Tutarlılık yaratıcılıktan daha iyidir. Her olay için ortak bir şema kullanın:

• event_name (fiil + nesne, örn. report_exported)
• timestamp (UTC)
• account_id ve user_id (uygunsa zorunlu)
• properties (feature, plan, environment, error_code, latency_ms vb.)

Her olay için gerekli özellikleri hafif bir takip spesifikasyonunda belgeleyin ve ekip tarafından PR’larda gözden geçirilebilir hâle getirin.

Kritik olaylar için sunucu tarafı izlemeyi tercih edin

İstemci tarafı izleme faydalı olabilir, ama engellenebilir, düşebilir veya çoğaltılabilir. Yüksek değerli olaylar (fatura değişiklikleri, başarılı dışa aktarımlar, tamamlanan iş akışları) için eylem onaylandıktan sonra backend’den olay yayınlayın.

Otomatik veri kalitesi kontrolleri ekleyin

Veri sorunlarını ürün hatası gibi ele alın. Şunlar için kontroller ve uyarılar ekleyin:

• Eksik veya null account_id/user_id
• Yinelenenler (aynı event idempotency anahtarı)
• Saat kayması (tarihlerin uzak gelecekte/çok geçmişte olması)
• Olay türüne göre ani hacim değişimleri (genellikle hatalı bir sürüm)

Küçük bir veri kalite panosu ve günlük ekip raporu, churn-risk tespitini baltalayan sessiz hataları engeller.

Müşteri Sağlığı ve Risk Skorlama Sistemi Tasarlayın

İyi bir sağlık skoru “churn’u mükemmel tahmin etmek”ten çok insanlara sonraki adımı söylemektir. Basit başlayın, açıklanabilir tutun ve gerçekten tutunmayla ilişkilenen sinyalleri öğrendikçe geliştirin.

Bilinçli olarak kural tabanlı bir skorla başlayın

Herkesin anlayıp debug edebileceği küçük, net kurallarla başlayın.

Örneğin: “Haftalık aktif kullanım, önceki 4 haftalık ortalamaya göre %40 düştüyse risk puanı ekle.” Bu yaklaşım anlaşmazlıkları yapıcı kılar çünkü tam olarak hangi kuralın ve eşiklerin uygulandığını gösterebilirsiniz.

Gerçek dünya riskine uyan ağırlıklı sinyaller ekleyin

Temel kurallar çalıştıktan sonra, ağırlıklarla birden fazla sinyali birleştirin. Yaygın girdiler:

• Kullanım düşüşü (ürün etkinliği, ana özellik benimsemesi, API çağrıları)
• Koltuk azalması (kaldırılan lisanslar, artan inaktif koltuklar)
• Başarısız ödemeler (fatura hataları, kart reddi, gecikmiş durum)
• Ticket artışı (destek hacmi, önem, çözüm süresi)

Ağırlıklar iş etkisi ve güvene göre belirlenmeli. Bir ödeme hatası hafif bir kullanım düşüşünden daha fazla ağırlık taşıyabilir.

Önde giden ve geride kalan göstergeleri ayırın

Önde giden göstergeler (son değişim) ile geride kalan göstergeler (yavaş ilerleyen risk) farklı muamele görmeli:

• Önde giden: son 7–14 günlük kullanım değişimi, ani hata patlamaları
• Geride kalan: yenileme tarihi yakınlığı, uzun dönem düşük benimseme

Bu, uygulamanızın hem “Bu hafta ne değişti?” hem de “Kim yapısal olarak risk altında?” sorularına cevap vermesini sağlar.

Skor bandlarını eylemlerle tanımlayın

Sayısal skoru düz ifadelere çevirin:

• Healthy: kullanım stabil veya artıyor; kritik bir sorun yok
• Watch: anlamlı negatif trend; izle ve hafif müdahale
• At risk: sürdürülen düşüş veya kritik sinyaller; acil müdahale

Her banda varsayılan bir sonraki adımı (sahip, SLA ve playbook) bağlayın ki skor sadece kırmızı bir rozet olmasın, tutarlı takibi tetiklesin.

Anormallikleri ve Anlamlı Kullanım Değişikliklerini Tespit Edin

Anomali tespiti, müşterilerin ürününüzü gerçekten nasıl kullandığını yansıtıyorsa faydalıdır. Amaç her küçük oynaklığı işaretlemek değil—churn riskini öngören ve insan müdahalesi gerektiren değişiklikleri yakalamaktır.

Gerçeğe uygun bazlinelar oluşturun

Aşırı tepki vermemek için birden fazla baseline kullanın:

• Hesabın kendi geçmişi: bu haftayı aynı hesabın son 4–8 haftasıyla karşılaştırın
• Segment ortalamaları: benzer müşterilerle karşılaştırın (plan, sektör, boyut, bölge) ki düşük genel kullanım içinde gizlenen “sessiz vazgeçmeler”i görün
• Mevsimsellik: karşılaştırmaları hafta içi/hafta sonu veya aya göre hizalayın (örn. aynı haftanın gün ortalaması)

Bu bazlinelar “onlar için normal” ile “bir şey değişti”yi ayırır.

Ani düşüş vs kademeli gerileme

Bunları farklı ele alın; çünkü çözümler farklıdır:

• Ani düşüşler (örn. hafta bazında %70 azalma, ana olaylarda ani durma) genellikle kesinti, entegrasyon kopması, faturalama değişimi, kullanıcı kaybı veya izin sorunlarını işaret eder.
• Kademeli gerileme (örn. bir ay boyunca haftada %10 azalma) genellikle değer aşınmasını işaret eder: şampiyonun ayrılması, rakip araç benimsenmesi veya eksik rollout.

Uygulamanız paterni etiketlemeli; playbook’lar ve sahipler farklı olacaktır.

Yanlış alarmları azaltın

Yanlış alarmlar güveni hızlı yıpratır. Koruyucu önlemler ekleyin:

• Minimum aktivite eşiği: çok düşük bazlineli hesapları uyarmayın (örn. 20 anahtar olay/hafta’dan az)
• Bekleme dönemleri: onboarding, plan değişiklikleri, tatiller veya bilinen olaylardan sonra kısa boşlukları görmezden gelin
• Doğrulama pencereleri: düşüşün 2–3 gün boyunca sürmesini (veya düşük frekanslı ürünler için 1–2 hafta) gerektirin

Her bayrağı açıklanabilir yapın

Her risk sinyali kanıt taşımalı: “neden işaretlendi” ve “ne değişti”. Ekleyin:

• Kullanılan baseline (geçmiş/segment/mevsimlik)
• Metrik ve zaman aralığı (örn. “API çağrıları, son 7 gün”)
• Delta ve eşik (örn. “önceki 4 haftalık aynı gün ortalamasına göre -62%”)
• En çok katkıda bulunan sürücüler (örn. “5 aktif kullanıcının 3’ü durdu”, “entegrasyon X veri göndermeyi durdurdu”)

Bu, uyarıları gürültü değil karar haline getirir.

Web Uygulaması UI’sını Oluşturun: Panolar ve Hesap Görünümleri

İyi bir UI dağınık telemetriyi günlük iş akışına dönüştürür: “Kimin dikkate ihtiyacı var, neden ve ne yapmalıyız?” İlk ekranları yönlendirici ve hızlı tutun—çoğu ekip burada yaşayacak.

Pano gereklilikleri

Panonuz üç soruya anında cevap vermeli:

• Trendler: genel kullanım için basit bir grafik (isteğe bağlı olarak ana özelliklere göre) ve haftalık değişim
• En riskli hesaplar: geçerli sağlık skoru, en büyük negatif deltalar ve güçlü churn risk sinyalleri ile sıralanmış tablo
• Son uyarılar: ne tetiklendi, ne zaman ve etkilenen müşteri birimi gösteren sıkıştırılmış akış

Her satır hesap görünümüne tıklanabilir olmalı. Tanıdık tablo desenlerini tercih edin: sıralanabilir sütunlar, sabitlenmiş risk sütunları ve açık bir last-seen zaman damgası.

Hesap sayfası: tam hikâye

Hesap görünümünü bir zaman çizelgesi etrafında tasarlayın ki bir CSM bağlamı saniyeler içinde anlayabilsin:

• Kullanım zaman çizelgesi notlarla (deploy’lar, plan değişiklikleri, fatura olayları)
• Anahtar olaylar (aktivasyon kilometre taşları, özellik benimsemesi, destek eskalasyonları)
• Sinyal kaydı her churn risk sinyalini: değer, eşik ve değerlendirme zamanı
• Notlar ve görevler böylece işler hesap üzerinde kalır, farklı araçlara dağılmaz

Uyarılar insanları doğru görünüme yönlendirebilmek için /accounts/{id} gibi iç derin bağlantı desenlerine sahip olsun.

Filtreleme, dışa aktarma ve paylaşma

Filtreleme panoları işe yarar kılar. Global filtreler sağlayın: plan, segment, sektör, CSM sahibi, bölge ve yaşam döngüsü aşaması ve seçimi URL’de saklayarak paylaşılabilir görünüm kazandırın.

Dışa aktarma için tabloları filtreleri koruyarak CSV indirme izni verin ve iç devretmeler için “Bağlantıyı kopyala” özelliği ekleyin—özellikle risk listesi ve uyarı akışı için.

Uyarılar, Bildirimler ve Yönlendirme Oluşturun

Uyarılar doğru kişiye doğru zamanda ulaşmazsa işe yaramaz—ve herkesi onları görmezden gelmeye eğitir. Bildirimleri bir ayrıntı değil ürünün parçası olarak ele alın.

Uyarı tetiklerini tanımlayın (ne dikkate değer)

Net eylemlerle eşlenen küçük bir tetik setiyle başlayın:

• Skor eşikleri: örn. müşteri sağlık skoru 60’ın altına düştüğünde veya churn riski 80’in üstünde
• Ani kullanım düşüşleri: örn. ana bir olayda hafta bazında %40 düşüş
• Çoklu sinyal desenleri: örn. kullanım düşüşü ve destek ticket’larında artış gibi

Önce basit kurallar, sonra temel güven kazandıktan sonra daha akıllı mantık ekleyin (anomali tespiti gibi).

Ekiplerin çalışma şekline uygun kanallar seçin

Birincil bir kanal ve yedek bir kanal seçin:

• E-posta özetler, günlük sindirimler ve chat’te yaşamayan paydaşlar için
• Slack zaman duyarlı uyarılar için (örn. #cs-alerts veya on-call rotasyonu)
• Uygulama içi bildirimler CSM’lerin yaşadığı dahili araçlar için (iş kuyruğu stili takip için en iyi)

Emin değilseniz Slack + uygulama içi görevle başlayın. E-posta çabuk gürültüye dönüşebilir.

Spam’ı önlemek için yönlendirme ve dedupe ekleyin

Uyarıları hesap sahipliği ve segmente göre yönlendirin:

• Hesabın sahibi varsa CSM bildirim alınsın
• Yüksek değerli hesapsa CS liderliği de bilgilendirilsin
• Sinyal teknikse engineering/on-call bilgilendirilsin

Aynı uyarıları tek bir başlık veya ticket’ta toplayarak çoğalmayı engelleyin (örn. “kullanım düşüşü 3 gün sürdü”). Cool-down pencereleri ekleyin ki aynı uyarı her saat gönderilmesin.

Uyarıya eylem için bağlam ekleyin

Her uyarı şunu yanıtlamalı: ne değişti, neden önemli, sonraki adım ne olmalı. İçerikte bulunmalı:

• Hareket eden metrik(ler) ve baseline karşılaştırması
• Olası sürücü (özellik, workspace, koltuk grubu, bölge)
• Önerilen sonraki adım (örn. “kontrol e-postası gönder” veya “onboarding tamamlanmasını incele”)
• Hesap görünümüne doğrudan bağlantı metni: /accounts/{account_id}

Uyarılar net bir sonraki adıma götürdüğünde ekip bunlara güvenecek ve kullanacaktır.

Takip İş Akışlarını ve Playbook’ları Otomatikleştirin

Tespit, sonraki en iyi eylemi güvenilir şekilde tetiklemezse yararsızdır. Takip iş akışlarını otomatikleştirmek “düşüş gördük”ü tutarlı, izlenebilir müdahaleye çevirir ve zamanla tutundurmaya katkıda bulunur.

Sinyalleri playbook’lara dönüştürün

Her sinyali basit bir playbook’a eşleyerek başlayın. Playbook’ları yönlendirici ve hafif tutun ki ekipler gerçekten kullansın.

Örnekler:

• Ana özellikte kullanım düşüşü: temas e-postası + 15 dakikalık çalışma oturumu teklifi
• Yeni admin ama rollout yok: enablement hatırlatıcısı + kontrol listesi paylaşma
• Hata veya yavaşlık artışı: teknik kontrol + log talebi + dahili incident başlatma

Playbook’ları şablon olarak saklayın: adımlar, önerilen mesajlaşma, gerekli alanlar (örn. “kök neden”) ve çıkış kriterleri (örn. “kullanım 7 gün boyunca baseline’a döndü”).

Göz ardı edilemeyecek görevler yaratın

Bir sinyal tetiklendiğinde otomatik olarak görev oluşturun:

• Sahip (hesaba atanmış CSM veya kuyruktaki round-robin)
• Son tarih (ciddiyete göre; örn. yüksek risk için 4 iş saati içinde)
• Durum takibi (Open → In progress → Blocked → Done)

Her göreve kısa bir bağlam paketi ekleyin: hangi metrik değişti, ne zaman başladı, son sağlıklı dönem ve son ürün olayları. Bu, ilk temasın hızlanmasını sağlar.

Ekiplerin zaten kullandığı yerlere entegre edin

Herkesi yeni bir sekmeye zorlamayın. Görevleri ve notları mevcut sistemlere itip sonuçları uygulamaya geri çekin.

Yaygın hedefler CRM ve destek araçlarıdır (örneğin /integrations/crm). İş akışını çift yönlü tutun: bir görev CRM’de tamamlandıysa sağlık panosunda yansısın.

Takibi ölçün (ve görünür kılın)

Otomasyon yanıt kalitesini artırmalı, sadece hacmini. Şunları takip edin:

• Uyarıdan ilk temasa kadar geçen süre
• Çözüm notları (ne yapıldı ve neden)
• Sonuç etiketleri (Recovered, Ongoing risk, Product issue, Customer downsized)

Bu metrikleri aylık gözden geçirerek playbook’ları iyileştirin, yönlendirme kurallarını sıkılaştırın ve hangi eylemlerin gerçekten kullanım kurtarmayla ilişkili olduğunu belirleyin.

Hızlı prototip için Koder.ai (opsiyonel)

Spesifikasyondan çalışan iç araca hızlı geçmek istiyorsanız, Koder.ai gibi bir vibe-coding platformu dashboard, hesap görünümleri ve uyarı iş akışını chat üzerinden prototiplemenize yardımcı olabilir. Koder.ai tam yığın uygulamalar (React web, Go servisler ve PostgreSQL) oluşturabilir, anlık görüntüler/rollback ve kaynak kodu dışa aktarma destekler; veri modeli, yönlendirme kuralları ve UI akışını gerçek ürüne yatırım yapmadan doğrulamak için pratiktir.

Güvenlik, Gizlilik ve Uyum Temelleri

Uygulamanız ürün olaylarını, hesap bağlamını ve churn riski uyarılarını bir araya getirdiğinde güvenlik ve gizlilik kararlarını erken doğru almak kolaydır. Amaç basit: ekiplerin harekete geçmesi için yeterli veriyi verirken riski azaltmak.

Veri minimizasyonu: sadece gerekeni toplayın

İzleme için ne gerektiğini tanımlayın. Eğer kullanım-düşüş tespiti sayımlar, trendler ve zaman damgalarıyla çalışıyorsa, ham mesaj içeriği, tam IP adresleri veya serbest biçimli notlara muhtaç olmayabilirsiniz.

Pratik yaklaşım olarak saklayın:

• Hesap ve workspace tanımlayıcıları (iç ID’ler)
• Olay türü + zaman damgası
• Toplu metrikler (günlük aktif kullanıcılar, özellik kullanım sayıları, API çağrıları)
• Yönlendirme için gerekli asgari kullanıcı referansları (örn. dahili kullanıcı ID)

Veri setini dar tutmak uyum yükünü azaltır, blast radius’u küçültür ve saklama politikalarını kolaylaştırır.

Erişim kontrolü ve denetlenebilirlik

Kullanım-düşüş panoları genellikle CS, destek, ürün ve liderlik gibi çok disiplini araçlar haline gelir. Herkes aynı detayı görmemeli.

Rol tabanlı erişim kontrolü (RBAC) uygulayın:

• Yöneticiler: özet görünümler ve trendler
• CSM’ler: sahip oldukları hesaplar ve ilgili detaylar
• Destek: operasyonel sinyaller, hassas müşteri meta verisi değil
• Yöneticiler: entegrasyonlar ve yapılandırma yalnızca

Hassas eylemler (veri dışa aktarma, eşik değişiklikleri, hesap düzeyinde görüntüleme) için denetim logları ekleyin. Denetim logları ayrıca “kim neyi değiştirdi”yi debug etmede de faydalıdır.

KİŞİSEL VERİ (PII) işleme: hashing, şifreleme ve saklama

PII’yi (isimler, e-postalar, telefonlar) isteğe bağlı tutun. Bildirimler için gerekiyorsa CRM’den talep üzerine çekmeyi tercih edin, izleme veritabanına kopyalamayın.

PII saklarsanız:

• İletim halinde şifreleme (TLS) ve dinlenirken şifreleme kullanın
• Birleştirme için sadece gerekliyse kimlikleri hash’lemeyi düşünün (örn. hash’lenmiş e-posta)
• Saklama politikaları tanımlayın (örn. ham olaylar 30–90 gün, toplulaştırmalar 12–24 ay)
• Yedeklerin aynı kurallara uyduğundan emin olun

Rıza ve uyum (GDPR/CCPA) iddialarını abartmadan ele alın

Ne topladığınızı, neden topladığınızı (izleme ve müşteri desteği) ve ne kadar süre sakladığınızı belgeleyin. Kesin ve spesifik dil kullanın—“tam uyumlu” gibi ifadeler yalnızca resmi bir inceleme tamamlandıysa kullanılmalı.

En azından desteklemeye hazır olun:

• Veri erişim/silme talepleri (kullanıcı düzeyinde veriyi silme veya anonimleştirme)
• Amaç sınırlaması (izleme verisini alakasız profilleme için yeniden kullanmayın)
• Vendors ve alt işleyici takibi (analitik araçlar, e-posta/SMS sağlayıcıları)

Müşteri tarafı dokümanlarda dahili olarak /privacy ve /security gibi politikalara referans verin ve bunları sistemin gerçek işleyişiyle uyumlu tutun.

Test, Yayınlama ve Sürekli İyileşme

Churn-risk uygulaması “çalışıyor mu”dan daha fazlasıdır: ekipler sinyallere güvenip harekete geçmeli ve sistem ürününüz ve verileriniz evrildikçe güvenilir kalmalıdır.

Geçmiş verilerle doğrulama (backtesting)

Kimseyi uyarmadan önce modelinizi veya kurallarınızı geçmiş haftalar/aylar üzerinde replay ederek sonuçları (yenileme, küçülme, churn) bildiğiniz dönemlerde test edin. Bu, eşikleri ayarlamanıza ve gürültülü uyarılardan kaçınmanıza yardımcı olur.

Basit bir değerlendirme için karışıklık matrisi kullanın:

• True positives: işaretlenen ve daha sonra churn/küçülme yaşayan hesaplar
• False positives: işaretlenen ama aslında iyi olan hesaplar
• False negatives: gözden kaçan ama churn olan hesaplar
• True negatives: doğru şekilde görmezden gelinen hesaplar

Operasyonel olarak önemli olanı hedefleyin: CSM’lerin uyarıları görmezden gelmemesi için false positive’leri azaltırken, gerçek riski erken yakalayacak kadar false negative’i düşük tutmak.

İzlemeyi izleyin (veri hattı kontrolleri)

Birçok “kullanım düşüşü” aslında veri sorunudur. Her pipeline adımı için hafif izleme ekleyin:

• Tazelik: bu tablo en son ne zaman güncellendi?
• Eksik veri: aniden sıfıra düşme, eksik tenant’lar veya kısmi alım
• İş hataları: retry’ler, şema değişiklikleri, API rate limitleri

Bu sorunları dahili bir durum görünümünde gösterin ki kullanıcılar “müşteri kullanımını kaybetti” ile “veri gelmedi” arasındaki farkı ayırt edebilsin.

Aşamalı yayın planı

İç kullanıcılarla (veri/ops + birkaç CSM) başlayın ve uyarıları mevcut bildiklerine karşı karşılaştırın. Doğruluk ve iş akışı stabil olduğunda daha geniş bir gruba açın.

Yayın sırasında benimseme sinyallerini ölçün: uyarılar açıldı mı, triage süresi neydi ve kullanıcılar hesap görünümüne tıkladı mı?

Sonuçları iyileştirecek geri bildirim döngüleri kurun

Kullanıcılara bir uyarıyı false positive, bilinen sorun veya işlem yapıldı olarak tek tıkla işaretleme yolu verin. Bu geri bildirimi kaydedin ve haftalık gözden geçirerek kuralları iyileştirin, skorlama ağırlıklarını yeniden ayarlayın veya dışlama ekleyin (örn. mevsimsel müşteriler, planlı bakım).

Zamanla bu uygulamayı statik bir panodan ekibin gerçekliğinden öğrenen bir sisteme dönüştürecektir.