CRM Kurulum ve Gelişim Yol Haritası

Özet

Müşteriyi bütünlüklü tanımak, alışveriş davranışını analiz etmek ve uygun tekrar satış fırsatları oluşturmak

Bu çalışma, mevcut CRM sistemlerini yönetme ve geliştirme deneyimimi yeni bir CRM projesine nasıl aktaracağımı gösteren bağımsız bir örnektir. Kamuya açık bilgilere ve temsili senaryolara dayanır; Vatan Bilgisayar'ın iç sistemlerini veya canlıya alınmış bir CRM uygulamasını temsil etmez.

Yetkinlik

CRM'i uçtan uca kurgulamak

Çalışmada keşiften işletime uzanan altı aşamalı kurulum yaklaşımıyla gösterilir. Her aşamada yanıtlanacak soru, üretilecek çıktı, sorumlu roller ve geçiş koşulu yer alır. Mimari, entegrasyon ve devreye alma planı bu aşamaları ayrıntılandırır.

Yetkinlik

İhtiyacı gereksinime dönüştürmek

Tek bir kullanıcı hikâyesi (US-01) iş kurallarına (BR), veri gereksinimlerine (DR) ve test edilebilir kabul kriterlerine (AC) ayrılır. İzlenebilirlik tablosu her kuralın hangi veriyle, hangi testle ve hangi ölçümle bağlandığını gösterir.

Yetkinlik

Veriyi iş sonucuna bağlamak

Kahve makinesi senaryosunda teklif kararı müşteri verisinden adım adım çıkarılır. Analitik bölümünde iptal ve iade düşülmüş RFM, kategori bazlı pasifleşme, CLTV'nin geçmiş cirodan farkı ve kontrol gruplu ek katkı hesabı yer alır.

CRM kurulum yaklaşımı: altı aşama

Bu aşamalar çalışmanın metodolojik yol haritasıdır; sayfa bölümlerinin numaralarıyla ilişkili değildir.

Örnek iş fırsatı

Daha önce kahve makinesi satın almış müşterilere, sahip oldukları ürünle uyumlu ve açık bir ihtiyaç veya ilgi sinyaline dayanan teklif sunmak: bakım ürünü, uyumlu aksesuar veya üst model. Sinyal yoksa teklif göndermemek de geçerli bir sonuçtur. Bu senaryo CRM projesinin tamamını değil, kullanım örneklerinden birini temsil eder.

İlk uygulamanın kapsamı

Tek kategori, sınırlı ve uygun bir müşteri grubu, iletişim izni olan kanallar ve aynı uygun havuzdan seçilen kontrol grubu. Canlı pilottan önce kabul, erişim, izin ve veri doğruluğu testleri tamamlanır.

Başarının ölçülmesi

Kontrol grubuna göre tekrar satın alma oranı farkı
İndirim, iade ve gönderim maliyetleri sonrası ek katkı
Ret ve şikâyet oranı (paydası tanımlı)
Mükerrer ve uygunsuz gönderim sayısı

Başlangıç değerleri ölçülmeden hedef veya beklenen kazanç belirlenmez.

Keşifte incelenecek olasılıklar

Kanallardaki kayıtların tek müşteri altında ne ölçüde birleştiği, servis ve iade bilgisinin kampanya kararlarına ne kadar sürede yansıdığı ve kampanya sonuçlarının kontrol grubuyla ölçülüp ölçülmediği. Bunlar doğrulanmış sorunlar değil, keşifte yanıtlanacak sorulardır.

Bilgi türleri

Doğrulanmış şirket bilgisiYalnızca resmi kaynaklardan, tarih ve bağlantıyla. "11. Kaynaklar" bölümünde.

Önerilen tasarımYaklaşım, kurallar, veri modeli, ölçüm ve plan. Şirketin bugünkü durumunu anlatmaz.

VarsayımKeşifte teyit edilmesi gereken kabuller; ilgili yerde belirtilir.

Temsili veriYöntemi göstermek için oluşturulmuş müşteri, ürün ve sayılar. Şirket verisi veya sonucu değildir.

Yaklaşım

Keşiften işletime CRM kurulum ve gelişim yaklaşımı

Aşamalar takvimle değil geçiş koşuluyla ilerler. Mevcut altyapı bilinmeden süre, bütçe veya ürün önerilmez.

CRM'in kapsamı kampanyadan geniştir

Önerilen hedef kapsam. İlk pilot bunların küçük bir bölümünü kullanır.

Alan	İçerik	İlk pilotta
Müşteri ve aday müşteri yönetimi	Tekil müşteri kaydı, kaynak kimlikleri, aday müşteri (ör. bilgi isteyen, teklif alan) kayıtları	Kısmen: yalnızca okuma
Satış ve talep takibi	Telefonla satış talepleri, kurumsal teklif istekleri, "gelince haber ver" talepleri	Hayır
Hizmet süreçleri	Şikâyet ve talep kayıtları, servis durumunun müşteri kaydında görünmesi	Kısmen: servis durumu bastırma için okunur
Görevler ve iş akışları	Çağrı merkezi ve mağaza için görev atama, hatırlatma, yükseltme	Hayır
İletişim izinleri	Kanal ve amaç bazında onay/ret, İYS senkronu, gönderim öncesi kontrol	Evet
Kampanya ve pazarlama otomasyonu	Segment, tetik, kontrol grubu, gönderim, sonuç	Evet: tek kategori
Analitik ve segmentasyon	RFM, pasifleşme, CLTV, kampanya ölçümü	Kısmen: net RFM ve ölçüm raporu
Erişim ve rol yönetimi	Rol bazlı görünürlük, maskeleme, erişim kayıtları	Evet: pilot rolleri için

Çözüm seçimi

Aşama 2'de üç seçenek aynı ölçütlerle karşılaştırılır. Şirketin mevcut CRM'ini değiştirmek peşinen önerilmez; mevcut sistemin geliştirilmesi de eşit ağırlıkta değerlendirilir.

Mevcut sistemi geliştirmek

İş bilgisi ve entegrasyonlar korunur; geliştirme kapasitesi ve teknik borç değerlendirilir.

Hazır CRM ürünü

Hazır modüller hızlı başlangıç sağlar; uyarlama sınırı, lisans ve veri taşıma yükü değerlendirilir.

Özel geliştirme

İhtiyaca tam uyum sağlar; geliştirme ve bakım sorumluluğu kurumda kalır.

Ölçütler: ihtiyaçların karşılanma düzeyi, entegrasyon ve veri taşıma yükü, toplam sahip olma maliyeti, ekibin yetkinliği ve kapasitesi, güvenlik ve KVKK gereksinimleri, risk ve geri dönüş kolaylığı.

İş analizi yöntemleri ve bu çalışmadaki karşılıkları

İş analizi eğitimimde edindiğim yöntemleri bu örnek çalışmada şu çıktılarla uyguladım.

Yöntem	Ne işe yarar	Bu çalışmada
Kullanıcı hikâyesi	Kimin, neyi, hangi amaçla istediğini tanımlar	US-01 (aşağıda)
MoSCoW önceliklendirmesi	İlk sürüme neyin girip neyin sonraya kaldığını belirler	Bu bölümdeki öncelik tablosu
İş kuralları	Kararın koşullarını ve istisnalarını yazar	BR-01 … BR-15 (4. Kurallar ve kabul)
Veri gereksinimleri	Kuralların hangi alana, kaynağa ve güncelliğe ihtiyaç duyduğunu belirler	DR-01 … DR-11 (4. Kurallar ve kabul)
Kabul kriterleri	Her kuralın test edilebilir karşılığıdır	AC-01 … AC-19, "Diyelim ki / Eğer / O zaman" yapısında
İzlenebilirlik	Hikâye, kural, veri, test ve ölçüm arasındaki bağı gösterir	İzlenebilirlik tablosu (4. Kurallar ve kabul)

Kullanıcı hikâyesi ihtiyacı tanımlar. RFM, pasifleşme analizi veya kampanya ölçümü gibi analitik çalışmalar ise bu ihtiyacı karşılayan kararları destekler; hikâyenin yerine geçmez.

US-01Ana kullanıcı hikâyesi

“CRM ve pazarlama uzmanı olarak, müşterilerin farklı kanallardaki alışveriş geçmişini ve kategori ilgisini birlikte değerlendirerek uygun müşteri gruplarına ilgili teklifler sunmak istiyorum; böylece tekrar satın almayı ve kampanyaların net katkısını artırabilirim.”

Bu hikâye geniştir: tüm kategorileri, kanalları ve teklif türlerini kapsar. İlk uygulama tek bir dilimle sınırlandırıldı: "Daha önce kahve makinesi satın almış müşteriler için uygun teklif belirleme." Bu dilim, CRM projesinin tamamını değil, CRM'in kullanım örneklerinden birini temsil eder.

Neden bu dilim?

Tek kategori olduğu için veri ihtiyacı ve test kapsamı sınırlıdır.
Üç teklif türü (bakım ürünü, uyumlu aksesuar, üst model) ve "teklif yok" sonucu aynı senaryoda denenebilir.
Cihaz ile bakım ürününün satın alma döngüsü farklıdır; bu, kategori bazlı düşünmeyi sınamak için uygundur.

Varsayım Kategori örnek amaçlı seçildi. Gerçek seçim keşifte müşteri sayısı, veri erişimi ve ürün uyumluluk verisinin varlığına göre yapılır.

Kapsam

İlk dilimde	Sonraya bırakılan
Kahve makinesi kategorisi	Diğer kategoriler
Bakım ürünü ve uyumlu aksesuar teklifi	Üst model teklifi, eşleme ve fiyat verisi hazır değilse
İzinli e-posta ve SMS	Uygulama bildirimi, mağaza ekranı, web kişiselleştirme
Kural tabanlı uygunluk	Tahmin modeliyle (churn, CLTV) otomatik karar
Aynı uygun havuzdan kontrol grubu	Çok kollu testler, kişiye özel indirim düzeyi

Önceliklendirme (MoSCoW)

Öncelik	İçerik	Gerekçe
Must · olmazsa olmaz	BR-01–05, BR-08–13, BR-15: hedef kitle, sahiplik, kimlik, servis, model sahipliği, hedefleme sınırları, izin, kontrol grubu, kaynak erişimi, mükerrer engeli, hizmet/pazarlama ayrımı, satılabilirlik	Müşteriye yanlış veya izinsiz ileti gitmesini önler; ölçümü mümkün kılar.
Should · olmalı	BR-06, BR-07 (bakım ve aksesuar için), BR-14 temas sıklığı	Teklifin isabetini artırır; değerleri keşif verisiyle belirlenir.
Could · olabilir	Üst model teklifi	Halef model eşlemesi ve güncel fiyat farkı verisine bağlıdır.
Won't (şimdilik)	Diğer kategoriler, gerçek zamanlı kişiselleştirme, model tabanlı otomatik kararlar	İlk dilimin sonucu görülmeden kapsam genişletilmez.

Örnek senaryo · US-01 ilk dilimi

Kahve makinesi sahipleri için uygun teklif

Aşağıdaki müşteriler temsilidir; her biri kuralların farklı bir sonucunu göstermek için oluşturuldu. Bir müşteri seçin: beş adımın her birinde kullanılan veri, uygulanan kural ve sonuç görünür. Bu senaryo CRM'in kullanım örneklerinden yalnızca biridir.

Müşteriyi tanıOnaylı kimlik bağlantıları

Uygunluğu değerlendirNet sahiplik, iade, servis

Teklifi belirleUyumluluk, fiyat, ihtiyaç/ilgi sinyali

Gönderim kontrolleriErişim, izin, satılabilirlik, temas sıklığı, grup, mükerrer

Sonucu ölçKarar kaydı, test ve kontrol

Temsili müşteri

Tüm temsili müşteriler için sonuç

Grup atamaları temsilidir: bu örnekte elle verilmiştir. Gerçek uygulamada atama, tüm uygunluk, izin ve satılabilirlik kontrollerinden geçen aynı havuzdan rastgele yapılır.

Kullanılmayan veya sınırlanan veriler

Cinsiyet, yaş ve bunlardan çıkarılan yaşam olayları veya ihtiyaçlar (ör. "evlilik dönemi") hedeflemede kullanılmaz.
Son alımdan geçen süre tek başına üst model ihtiyacının kanıtı sayılmaz.
Bakım ürününü daha önce almamış olmak tek başına bakım ihtiyacının kanıtı sayılmaz.
Bir kategorideki ilgi, müşteriyi başka kategorilerden kalıcı olarak dışlamak için kullanılmaz.
Oturum açılmadan toplanan veya kullanım izni belirsiz gezinme verisi müşteriye bağlanmaz.
Ürün uyumluluğu, fiyat farkı ve stok varsayılmaz; veri yoksa ilgili teklif seçilmez veya bekletilir.

İhtiyaç ve ilgi sinyalleri (temsili tanım)

Bakım: Müşterinin oturum açıkken bakım ürünü (ör. kireç çözücü) araması veya ürün kaydında bakım hatırlatması almayı seçmesi.
Aksesuar: Oturum açıkken uyumlu aksesuar araması veya sepete ekleyip almaması.
Üst model: Oturum açıkken üst model sayfasını görüntülemesi veya karşılaştırma yapması.

Sinyallerin tanımı, süresi ve güvenilirliği keşifte veriyle belirlenir. Kullanım izni olmayan veri sinyal sayılmaz.

Teklif seçenekleri ve gerekli veri

Seçenek	Ne zaman değerlendirilir	Gerekli veri	Veri yoksa
Bakım ürünü	Modelle uyumlu bakım ürünü tanımlı, müşteri bu ürünü daha önce almamış ve bakım sinyali var	Uyumluluk tablosu, bakım ürünü alımları, bakım sinyali	Teklif seçilmez
Uyumlu aksesuar	Uyumlu aksesuar tanımlı ve aksesuar ilgisi var	Uyumluluk tablosu, ilgi olayları	Teklif seçilmez
Üst model	Halef model tanımlı, fiyat farkı hesaplanabiliyor, açık ilgi var ve müşteri o modeli almamış	Halef eşlemesi, güncel fiyat, ilgi olayları, sipariş geçmişi	Teklif seçilmez
Teklif yok	Hiçbiri sağlanmıyorsa veya bir engel kuralı çalışıyorsa	Neden kodu	Karar yine kaydedilir

Birden çok seçenek uygunsa sıra: üst model, aksesuar, bakım. Müşteriye tek ileti gider; kanal önceliği keşifte belirlenir (örnekte e-posta).

Veri modeli · önerilen

Varlıklar, ilişkiler ve kimlik eşleme

Bir varlığa dokunun: ilişkili varlıklar mor çerçeveyle işaretlenir. Alan adları örnektir; gerçek şema kurumun sistemlerine göre çıkarılır.

Bire-çok ve çoka-çok

1 — N Bir müşterinin birden çok siparişi olur; her sipariş tek bir müşteriye aittir.

N — N Bir siparişte birçok ürün olur, bir ürün birçok siparişte geçer. Bu ilişki araya giren bir tabloyla kurulur: Sipariş Kalemi adet, fiyat, indirim ve durumu taşır. Aynı yapı Kampanya ↔ Müşteri (Kampanya Katılımı), Ürün ↔ Lokasyon (Stok), Sevkiyat ↔ Kalem (Sevkiyat Kalemi) ve Ürün ↔ Ürün (Ürün Uyumluluğu) için de kullanılır.

Kısmi iade, bölünmüş teslimat, satış ve teslim mağazası

Kısmi iade: İade siparişe değil sipariş kalemine bağlanır ve adet taşır. Analizler kalem bazında net adet ve net tutarla yapılır.

Bölünmüş teslimat: Bir siparişin birden çok sevkiyatı olabilir; Sevkiyat Kalemi hangi kalemin kaç adedinin hangi pakette gittiğini tutar.

Satış ve teslim mağazası: Sipariş üzerinde satis_kanali ve satis_lokasyon_id, sevkiyat üzerinde teslim_lokasyon_id tutulur. İade üçüncü bir mağazada kabul edilebilir (kabul_lokasyon_id).

Kimlik eşleme: kanıt düzeyleri

Yanlış birleştirme, ayrı kalmış iki kayıttan daha zararlıdır: başkasının alışverişi ve izni yanlış müşteriye bağlanır. Öneri, birleştirmeyi kanıt düzeyine göre ayırmak ve her işlemi geri alınabilir tutmaktır.

Kanıt düzeyi	Örnek	Karar
Aynı hesap	Kayıt, müşterinin oturum açtığı hesapla veya hesap numarasıyla oluşmuş; ya da müşteri kendi hesabına girerek bir kartı/kodu OTP ile kendisi eklemiş	Bağlanır; işlem kaydı tutulur
Güçlü aday	OTP ile doğrulanmış aynı telefon + uyumlu ad; doğrulanmış aynı e-posta + uyumlu ad	Manuel inceleme veya bir sonraki temasta müşteri onayı. Onaya kadar geçmiş kayıtlar ayrı tutulur.
Zayıf veya çelişkili	Aynı telefon, farklı ad; aynı ad ve il, farklı telefon; doğrulanmamış telefon; çelişen fatura bilgisi	Manuel inceleme; çelişki giderilmezse ayrı tutulur
Kanıt sayılmaz	Yalnızca ad-soyad; "ortak" işaretli telefon; yalnızca adres; servis numarası + telefonla yapılan sorgu	Aday üretilmez

Neden OTP tek başına yetmez?

OTP, numaranın doğrulama anında kimde olduğunu gösterir. Aynı numarayla yıllar önce oluşmuş kayıtların aynı kişiye ait olduğunu göstermez; numara el değiştirmiş olabilir.
Değerlendirilecek sinyaller: numaranın ilk ve son görüldüğü tarihler, aynı numarayla görülen farklı adlar, ortak telefon işareti, çelişen e-posta veya fatura bilgisi.
Servis numarası + telefonla sorgu, servis durumunu görüntüleme yetkisidir; kimlik eşleşmesi değildir.
Vatan Kart sözleşmesindeki "uyuşmazlıkta cep telefonu sahibi hesap sahibidir" hükmü hesap sahipliğiyle ilgilidir. Geçmiş kayıtların birleştirilmesinde nasıl yorumlanacağı hukuk birimiyle teyit edilmelidir.

İnceleme, işlem kaydı ve geri alma

Aday eşleşme, kullanılan kurallar ve gerekçeyle üretilir.
Olası eşleşmeler müşteri veri yönetimi kuyruğuna düşer; iki kaydın kaynakları, siparişleri ve izinleri yan yana görünür.
İnceleyen birleştirir, ayrı tutar veya müşteriden doğrulama ister.
Her işlem kaydedilir: kim, ne zaman, hangi kanıtla, önceki ve sonraki durum.
Birleştirme geri alınabilir; ayırmada kayıtlar ve bağlı siparişler önceki müşteriye döner.
İzinler kişi, iletişim noktası, kanal, amaç ve kaynak bağlamıyla korunur. Birleştirme yeni izin üretmez; bir kaydın onayı diğer kaydın iletişim noktasına uygulanmaz; bir iletişim noktasındaki ret her durumda geçerlidir.

Örnekler temsili

Analitik

SQL, RFM, pasifleşme, CLTV ve kampanya ölçümü

Bu bölümdeki müşteriler, eşikler ve sayılar temsilidir; yöntemi göstermek için seçildi. Analitik çalışmalar US-01'deki karar ihtiyacını destekler.

RFM: iptal ve iade düşülünce segment değişir

temsili 7 müşteri

R: son net alışverişten bu yana geçen gün (az olan yüksek puan alır). F: net tutarı sıfırdan büyük sipariş sayısı. M: kalem bazında iade düşülmüş net ciro (F ve M'de yüksek olan yüksek puan alır). Net alışverişi olmayan müşteriye skor verilmez.

Sabit eşikler ve sınır testleri

R: ≤90 gün → 5, ≤180 → 4, ≤365 → 3, ≤730 → 2, daha fazla → 1. F: ≥6 → 5, ≥4 → 4, 3 → 3, 2 → 2, 1 → 1. M: ≥100.000 TL → 5, ≥50.000 → 4, ≥20.000 → 3, ≥5.000 → 2, daha az → 1. Sınır değer üst puana dahildir.

Ekrandaki tablo sabit eşik kullanır; aşağıdaki SQL ise müşterileri birbirine göre sıralayan göreli sıra yöntemini kullanır. İki yöntem aynı müşteriye farklı puan verebilir. Sabit eşiğin açıklaması kolaydır ama dağılım değişince güncellenmelidir; göreli sıra her dönem kendini ayarlar ama dönemler arası karşılaştırma zorlaşır.

Net RFM için örnek SQL (PostgreSQL · temsili şema)

-- Tablolar veri modeliyle aynı:
-- siparis(siparis_id, musteri_id, siparis_tarihi DATE, durum)
-- siparis_kalemi(kalem_id, siparis_id, urun_id, adet, net_tutar, durum)
-- iade(iade_id, siparis_id, durum), iade_kalemi(iade_id, kalem_id, adet, iade_tutari)
WITH iade_toplam AS (
  SELECT ik.kalem_id, SUM(ik.iade_tutari) AS iade_tutari
  FROM iade_kalemi ik
  JOIN iade i ON i.iade_id = ik.iade_id AND i.durum = 'TAMAMLANDI'
  GROUP BY ik.kalem_id
),
net_siparis AS (
  SELECT s.musteri_id, s.siparis_id, s.siparis_tarihi,
         SUM(k.net_tutar - COALESCE(it.iade_tutari, 0)) AS net_ciro
  FROM siparis s
  JOIN siparis_kalemi k ON k.siparis_id = s.siparis_id
  LEFT JOIN iade_toplam it ON it.kalem_id = k.kalem_id
  WHERE s.durum <> 'IPTAL'
    AND k.durum <> 'IPTAL'
    AND s.siparis_tarihi >= CURRENT_DATE - INTERVAL '24 months'
  GROUP BY s.musteri_id, s.siparis_id, s.siparis_tarihi
  HAVING SUM(k.net_tutar - COALESCE(it.iade_tutari, 0)) > 0  -- tamamen iade edilen sipariş sayılmaz
),
musteri_rfm AS (
  SELECT musteri_id,
         CURRENT_DATE - MAX(siparis_tarihi) AS recency_gun,   -- DATE - DATE = tam sayı (gün)
         COUNT(*)                          AS frequency,
         SUM(net_ciro)                     AS monetary_net
  FROM net_siparis
  GROUP BY musteri_id
)
-- PERCENT_RANK eşit değerlere aynı sırayı verir; NTILE ise eşit değerleri
-- farklı gruplara bölebilir. Bu yüzden eşitlerin aynı puanı alması için PERCENT_RANK kullanıldı.
SELECT musteri_id, recency_gun, frequency, monetary_net,
       LEAST(5, WIDTH_BUCKET(PERCENT_RANK() OVER (ORDER BY recency_gun DESC), 0, 1, 5)) AS r_skor,
       LEAST(5, WIDTH_BUCKET(PERCENT_RANK() OVER (ORDER BY frequency),        0, 1, 5)) AS f_skor,
       LEAST(5, WIDTH_BUCKET(PERCENT_RANK() OVER (ORDER BY monetary_net),     0, 1, 5)) AS m_skor
FROM musteri_rfm;
-- Son 24 ayda net alışverişi olmayan müşteriler sonuçta yer almaz; ayrı bir "skor yok" grubunda raporlanır.

Geç gelen iade geçmiş skoru değiştirir. Öneri: skorlar her gece son 24 ay için yeniden hesaplanır; iade süresi kapanmamış siparişler raporda "geçici" işaretlenir. Bu SQL bir veritabanında çalıştırılarak test edilmedi; şemaya göre uyarlanmalıdır.

Pasifleşme (churn): elektronikte tek eşik neden yanıltır?

Aksesuar veya sarf malzemesi birkaç ayda bir alınabilir; dizüstü bilgisayar veya televizyon yıllarca değişmeyebilir. Tek bir "180 gün" kuralı uzun ömürlü ürün alan memnun müşteriyi kayıp sayabilir, sık alınan ürünlerde ise kaybı geç fark eder. Öneri: pasifleşmeyi müşteri × kategori düzeyinde, kategorinin gözlenen tekrar alım aralığına göre tanımlamak.

Son alımdan bu yana geçen süre:

Aralıklar temsili varsayımdır. Gerçek değerler aşağıdaki sorgu gibi bir hesapla kategori bazında çıkarılır.

Kategori bazında tekrar alım aralığı için örnek SQL

-- Kategori bazında tekrar alım aralığı (PostgreSQL · temsili şema)
-- İş kuralı: iptal kalemler alım sayılmaz; tamamen iade edilen kalem 0 adede düşer;
-- kısmi iadede kalan adet > 0 ise alım sayılır.
WITH iade_adet AS (
  SELECT ik.kalem_id, SUM(ik.adet) AS iade_adet
  FROM iade_kalemi ik
  JOIN iade i ON i.iade_id = ik.iade_id AND i.durum = 'TAMAMLANDI'
  GROUP BY ik.kalem_id
),
kalem_net AS (
  SELECT s.musteri_id, s.siparis_id, s.siparis_tarihi, u.kategori,
         k.adet - COALESCE(ia.iade_adet, 0) AS net_adet
  FROM siparis s
  JOIN siparis_kalemi k ON k.siparis_id = s.siparis_id
  JOIN urun u ON u.urun_id = k.urun_id
  LEFT JOIN iade_adet ia ON ia.kalem_id = k.kalem_id
  WHERE s.durum <> 'IPTAL' AND k.durum <> 'IPTAL'
),
alim AS (   -- müşteri–sipariş–kategori düzeyinde tek satır: aynı siparişteki iki ürün tek alımdır
  SELECT musteri_id, kategori, siparis_id, siparis_tarihi
  FROM kalem_net
  GROUP BY musteri_id, kategori, siparis_id, siparis_tarihi
  HAVING SUM(net_adet) > 0
),
aralik AS (
  SELECT musteri_id, kategori,
         siparis_tarihi - LAG(siparis_tarihi) OVER (
           PARTITION BY musteri_id, kategori
           ORDER BY siparis_tarihi, siparis_id) AS gun_farki    -- DATE - DATE = gün
  FROM alim
)
SELECT kategori,
       COUNT(DISTINCT musteri_id)                              AS alici,
       COUNT(DISTINCT musteri_id) FILTER (WHERE gun_farki > 0) AS tekrar_alan,
       PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY gun_farki)
         FILTER (WHERE gun_farki > 0)                         AS medyan_gun,
       PERCENTILE_CONT(0.8) WITHIN GROUP (ORDER BY gun_farki)
         FILTER (WHERE gun_farki > 0)                         AS p80_gun
FROM aralik
GROUP BY kategori;
-- Aynı gün verilen ikinci sipariş 0 gün üretir ve aralık hesabına alınmaz.
-- siparis_tarihi TIMESTAMP ise önce siparis_tarihi::date ile tarihe çevrilir.

Aralıklar yalnızca en az iki alımı olan müşterilerden hesaplanır. Tek alımı olanlar ve gözlem süresi henüz dolmamış müşteriler hesaba girmez; bu da dağılımı kısa aralıklara doğru kaydırır.
Uzun ömürlü kategorilerde (TV, dizüstü) 24–36 aylık veri penceresi tekrar alımı gözlemek için yetersiz kalabilir.
Bu nedenle sonuçlar bir başlangıç ölçüsüdür; tekrar almayanları da hesaba katan yaşam süresi (survival) analizi daha sağlam bir sonraki adımdır.

CLTV geçmiş ciro değildir

temsili iki müşteri

CLTV, müşterinin belirli bir ufukta (ör. 24 ay) bırakması beklenen katkıdır: beklenen alım sayısı × ortalama sepet × brüt marj, eksi beklenen iade ve hizmet maliyeti. Geçmiş ciro bir girdi olabilir, ancak kendisi CLTV değildir.

Bu örnekte geçmişte daha çok harcayan A, düşük marjlı tek büyük alım ve yüksek iade nedeniyle gelecekte daha az katkı bırakabilir. Girdilerin tamamı varsayımdır.

Kontrol gruplu kampanya ölçümü

temsili girdiler · değiştirilebilir

Kampanyanın etkisi test ve kontrol grupları arasındaki farktır. Test grubunun toplam cirosu "kampanya cirosu"dur ve ek katkıyla karıştırılmamalıdır: bu müşterilerin bir kısmı kampanya olmasa da alacaktı. Oranların paydası gruptaki müşteri sayısıdır.

Ek katkının bileşenleri (test grubu ölçeğinde)

Maliyet varsayımları ve istatistiksel sınırlılıklar

Maliyet varsayımları

Marj, iade işlem maliyeti ve gönderim maliyeti tahmindir; gerçek değerler finans ve operasyonla birlikte belirlenir.
İndirim, zaten alacak olanlar dahil tüm test alıcılarına uygulanmış sayılır.
Kontrol grubunun oranları test grubu büyüklüğüne ölçeklenerek karşılaştırılır.

İstatistiksel sınırlılıklar

İki oranın farkı için normal yaklaşımlı z testi kullanıldı; küçük gruplarda ve çok düşük oranlarda güvenilir değildir.
Güven aralığı yalnızca oran farkı içindir; ek katkı tutarının belirsizliği ayrıca tahmin edilmelidir.
Ana ölçü ve ölçüm penceresi önceden belirlenmelidir; sonuçlara ara ara bakıp erken karar vermek yanlış pozitif riskini artırır.
Grup boşsa istatistik üretilmez.

Pilot ve ölçüm · Aşama 5 ve 6'nın ayrıntısı

Önce test, sonra sınırlı pilot, sonra karar

Canlı pilottan önce kritik kabul, erişim, izin ve veri doğruluğu testleri tamamlanır. Pilottan sonra bulgular düzeltilip yeniden test edilmeden yaygınlaştırılmaz. Süre ve bütçe verilmedi.

İlk pilotun kapsamı

US-01 ilk dilimi: kahve makinesi kategorisi
Kurallardan geçen, sınırlı sayıda uygun ve izinli müşteri
Bakım ürünü ve uyumlu aksesuar teklifi; izinli e-posta ve SMS
Aynı uygun havuzdan rastgele kontrol grubu ve kayıtlı atama
Teklif kararlarının ("teklif yok" dahil) neden koduyla kaydı

Ön koşullar

İzin verisinin gönderim anında okunabilmesi ve ret kayıtlarının güncel olması
Servis, iade ve sipariş durumu bilgisine erişim
Ürün uyumluluk verisinin ve satılabilirlik sorgusunun hazır olması
Kontrol grubu atamasının kalıcı kaydı
Hukuk ve uyum biriminin ileti içeriği ve kanal değerlendirmesi
Durdurma ve geri dönüş prosedürünün yazılı ve denenmiş olması

Kapsam dışı

Diğer kategoriler ve "6. Mimari" bölümündeki diğer senaryolar
Üst model teklifi (eşleme ve fiyat verisi hazır olmadan)
Satış/talep takibi, görev akışları, mağaza ekranı, uygulama bildirimi
Churn veya CLTV modeline dayalı otomatik karar

Durdurma ve geri dönüş koşulları

Ret veya izin dışı tek bir gönderim tespit edilirse pilot hemen durdurulur.
Mükerrer veya kurallara aykırı (ör. açık servisli müşteriye) gönderim görülürse durdurulur.
Test grubunda teslim edilen ileti başına ret veya şikâyet oranı önceden belirlenen eşiği aşarsa durdurulur. Eşik pilottan önce ilgili birimlerle yazılı olarak belirlenir.
İzin, uygunluk veya satılabilirlik kaynağına erişim kesilirse gönderim ertelenir.
Kontrol grubu ataması bozulursa ölçüm geçersiz sayılır.

Geri dönüş: kampanya duraklatılır, kuyruktaki iletiler iptal edilir, kök neden belirlenir, düzeltme yeniden test edilir.

Başarı ölçümleri ve paydaları

Başlangıç değerleri ve hedefler verilmedi. Önce keşifte mevcut durum ölçülür, sonra hedef birlikte belirlenir.

Keşifte yanıtlanacak sorular

Kaynaklar

Doğrulanmış bilgiler, varsayımlar ve doğrulanamayanlar

Şirket bilgileri yalnızca kamuya açık resmi sayfalardan alındı. Değişebilecek bilgiler erişim tarihiyle verildi.

Mağaza ve il sayısı

Kaynak	İfade	Erişim
Resmi site, Hakkımızda	"2026 itibariyle 57 ilde 150+ mağaza". Zaman çizelgesinde: 2024 – 56 ilde 150 mağaza; 2022 – 55 ilde 147 mağaza.	25.10.2026
Resmi site, Mağazalar	"150 mağaza listeleniyor"; il seçicisinde 57 il.	25.10.2026
LinkedIn şirket profili	55 il ifadesinin yer aldığı belirtildi. Profil oturum açmadan görüntülenemediği için bu çalışmada doğrulanamadı.	24–25.10.2026

Bu çalışmada resmi sitedeki güncel ifade esas alındı: 57 ilde 150'den fazla mağaza (25.10.2026).

Doğrulanmış şirket bilgisi

1983'te kuruldu; Vatan ailesine ait. 2026 itibarıyla 5.400+ çalışan; 204.586 m² kapalı alan, 112.381 m² satış alanı. (Hakkımızda, 25.10.2026)
Kanallar: mağazalar, web sitesi, mobil uygulama, telefonla sipariş, çağrı merkezi. (Hakkımızda; Vatan Kart sözleşmesi ve KVKK metni uygulamadan söz ediyor, 24.10.2026)
Mağazadan teslim seçeneği var; iade ve değişim mağazadan veya kargoyla yapılabiliyor. Bazı mağaza kayıtlarında müşteri hizmetleri bulunmadığı belirtiliyor. (Sipariş Aşamaları, Mağazalar, 24.10.2026)
Kargo ile siparişler ortalama 2 iş gününde teslim ediliyor. (Sipariş Aşamaları, 24.10.2026)
Mesafeli satışta 14 gün cayma hakkı; kurulum veya aktivasyon yapılmış, sarf malzemesi açılmış ürünler ve yazılımlar iade dışı. (Sipariş Aşamaları, 24.10.2026)
Servis takibi servis numarası ve telefon numarasıyla yapılıyor. Ücretsiz onarım veya değişim için azami 30 iş günü belirtiliyor. (Servis Takip Formu, 24.10.2026)
Vatan Kart: SMS ile üyelik; veriler ad, soyad, cep telefonu ve isteğe bağlı e-posta; pazarlama amaçlı kullanım; uyuşmazlıkta cep telefonu sahibi hesap sahibi sayılıyor. (Vatan Kart Sözleşmesi, 24.10.2026)
KVKK aydınlatma metni toplama kanallarını sayıyor: mağaza formları, online formlar, çağrı merkezi kayıtları, servis teslim süreçleri, web ve mobil uygulama. (24.10.2026)

İş ilanı

CRM ve Veri Analitiği Uzmanı, İstanbul, tam zamanlı. 24.10.2026'da ilan başvuruya kapalı görünüyordu.
Görevler: şirket içi yazılım sisteminin etkin kullanımı için yazılım ekibine geri bildirim; veri sistemindeki süreç ve hataların tespiti; segmentasyon ve hedefleme; e-posta, web push, uygulama push ve SMS gönderimlerinin günlük planlanması; Google Analytics ile performans takibi; pazarlama otomasyonlarının veri sistemine entegrasyonu; churn, RFM ve CLTV analizleri.
Nitelikler: CRM, veri analitiği ve growth alanında 3–4 yıl; SQL ile veri çekme ve raporlama; Excel/Google Sheets, tercihen Power BI; yazılım ekipleriyle teknik iletişim.

Mevzuat (birincil kaynak)

Ticari İletişim ve Ticari Elektronik İletiler Hakkında Yönetmelik (RG 15.07.2015/29417; 04.01.2020/30998 sayılı RG ile değişik). Mevzuat Bilgi Sistemi, erişim 25.10.2026:

md. 5: Tanıtım ve pazarlama amaçlı iletiler için önceden onay alınır; İYS'de onayı bulunmayan alıcıya ticari ileti gönderilemez.
md. 6/1–2: Satın alınan mal veya hizmetin değişiklik, kullanım ve bakımına yönelik iletiler ile teslimat gibi bildirimler için önceden onay aranmaz; bu bildirimlerde mal veya hizmet tanıtımı yapılamaz. md. 6/3: Tacir ve esnafa gönderimde önceden onay zorunlu değildir; ret hakkı saklıdır.
md. 7/11–12: İYS dışında alınan onaylar üç iş günü içinde İYS'ye kaydedilir; kaydedilmeyen onaylar geçersizdir.
md. 9/6: Hizmet sağlayıcıya iletilen ret bildirimleri üç iş günü içinde İYS'ye bildirilir. md. 10/1: Ret talebinin ulaşmasından itibaren üç iş günü içinde gönderim durdurulur.
md. 13/2: Onay kayıtları onayın geçerliliğinin sona erdiği tarihten, diğer kayıtlar kayıt tarihinden itibaren üç yıl saklanır.

Bu özet hukuki görüş değildir. Uygulamadan önce hukuk birimiyle teyit edilmelidir.

Varsayımlar

İlanda geçen "şirket içi yazılım sistemi" ve "yazılım ekibi" ifadeleri, CRM işlevlerinin en azından bir kısmının şirket içinde geliştirildiği izlenimini veriyor. Doğrulanmadı.
Ürün uyumluluk, halef model, fiyat ve satılabilirlik verilerinin bir sistemde yapılandırılmış biçimde bulunduğu varsayıldı.
Web ve uygulama olaylarının oturum açmış müşteriye bağlanabildiği ve kullanım izninin kaydedildiği varsayıldı.
Kahve makinesi kategorisi örnek amaçlı seçildi.

Doğrulanamayanlar

Kullanılan CRM, ERP, OMS, WMS, pazarlama otomasyonu ve veri ambarı ürünleri
Depo ve dağıtım merkezi sayısı ve konumları
Tedarikçi ve kargo bağlantılarının yöntemi
Vatan Kart puan kuralları (sözleşme metninde yer almıyor)
Müşteri sayısı, mağaza satışlarında müşterinin tanınma oranı, mevcut RFM/churn/CLTV yöntemi, kampanya sonuçları

Testler hakkında

Kabul kriterleri ve hesaplamalar, bu sayfadaki temsili karar motoru üzerinde otomatik çalıştırılır; gerçek bir CRM sisteminin testi değildir.
SQL örnekleri bir veritabanında çalıştırılarak test edilmedi.
Kontrol grubu atamaları temsilidir; gerçek bir müşteri deneyi uygulanmadı.

Kaynak bağlantıları

vatanbilgisayar.com/hakkimizda
vatanbilgisayar.com/magaza
vatanbilgisayar.com/siparis-asamalari
vatanbilgisayar.com/servis-takip-formu
vatanbilgisayar.com/vatan-kart-sozlesmesi
vatanbilgisayar.com/kvk-aydinlatma-metni
LinkedIn iş ilanı 4473643379
Ticari İletişim ve Ticari Elektronik İletiler Hakkında Yönetmelik (Mevzuat Bilgi Sistemi)
İYS Sıkça Sorulan Sorular (sayfa içeriği tarayıcı betiğiyle yüklendiği için metin okunamadı; kurallar yönetmelikten alındı)

Müşteriyi bütünlüklü tanımak, alışveriş davranışını analiz etmek ve uygun tekrar satış fırsatları oluşturmak

CRM'i uçtan uca kurgulamak

İhtiyacı gereksinime dönüştürmek

Veriyi iş sonucuna bağlamak

CRM kurulum yaklaşımı: altı aşama

Örnek iş fırsatı

İlk uygulamanın kapsamı

Başarının ölçülmesi

Keşifte incelenecek olasılıklar

Bilgi türleri

Keşiften işletime CRM kurulum ve gelişim yaklaşımı

CRM'in kapsamı kampanyadan geniştir

Çözüm seçimi

Mevcut sistemi geliştirmek

Hazır CRM ürünü

Özel geliştirme

İş analizi yöntemleri ve bu çalışmadaki karşılıkları

Neden bu dilim?

Kapsam

Önceliklendirme (MoSCoW)

Kahve makinesi sahipleri için uygun teklif

Tüm temsili müşteriler için sonuç

Kullanılmayan veya sınırlanan veriler

İhtiyaç ve ilgi sinyalleri (temsili tanım)

İş kuralı → veri gereksinimi → kabul kriteri → ölçüm

İş kuralları

Veri gereksinimleri

Kabul kriterleri

İzlenebilirlik: US-01 → kural → veri → test → ölçüm

Kim neyi görür?

D. Örnek

Rol bazlı görünürlük matrisi

Müşteri verisi nereden gelir, CRM neyi talep eder?

Akışlar

CRM'e gelen bilgi

CRM'den giden işlem talebi

Aynı mimarinin diğer kullanımları

Varlıklar, ilişkiler ve kimlik eşleme

Bire-çok ve çoka-çok

Kısmi iade, bölünmüş teslimat, satış ve teslim mağazası

Kimlik eşleme: kanıt düzeyleri

Neden OTP tek başına yetmez?

İnceleme, işlem kaydı ve geri alma

Örnekler temsili

Her bağlantının sahibi, hızı ve hata planı

Hata durumları

Göndermeden önce kaynağından doğrula

SQL, RFM, pasifleşme, CLTV ve kampanya ölçümü

RFM: iptal ve iade düşülünce segment değişir

Pasifleşme (churn): elektronikte tek eşik neden yanıltır?

CLTV geçmiş ciro değildir

Kontrol gruplu kampanya ölçümü

Ek katkının bileşenleri (test grubu ölçeğinde)

Maliyet varsayımları

İstatistiksel sınırlılıklar

Önce test, sonra sınırlı pilot, sonra karar

İlk pilotun kapsamı

Ön koşullar

Kapsam dışı

Durdurma ve geri dönüş koşulları

Başarı ölçümleri ve paydaları

Keşifte yanıtlanacak sorular

Doğrulanmış bilgiler, varsayımlar ve doğrulanamayanlar

Mağaza ve il sayısı

Doğrulanmış şirket bilgisi

İş ilanı

Mevzuat (birincil kaynak)

Varsayımlar

Doğrulanamayanlar

Testler hakkında

Kaynak bağlantıları