E-Ticaret CRM Entegrasyonu Nasıl Yapılır?

E-ticaret CRM entegrasyonu, müşteri listesini başka bir programa kopyalamak değildir. Doğru entegrasyon; kimlikleri güvenli biçimde eşleştirir, profil ile tarihsel sipariş kaydını ayırır, izin ve ret kanıtını bütün kanallarda tutarlı kılar, satış-destek ekiplerine güncel bağlam sağlar, otomasyon hatalarını görünür kılar ve müşteri verisini amaçla sınırlı biçimde kullanır. Başarı; yazılım seçiminden çok veri sahipliği, süreç tasarımı, güvenlik, mevzuat, test ve sürekli ölçümün birlikte kurulmasına bağlıdır.

CRM her alanın tek fiziksel ana kaynağı olmak zorunda değildir. Güncel müşteri tercihi CRM’de, sipariş gerçeği e-ticaret/OMS’de, fatura ERP/e-belge sisteminde, ticari ileti onayı İYS ile senkron yapıda ve destek kaydı help desk’te yetkili olabilir. “Customer 360” bu sistemlerin kuralsız kopyası değil, kaynağı, güncellik zamanı, amaç ve erişim sınırı bilinen birleşik görünümüdür.

CRM nedir ve e-ticaret entegrasyonu neyi çözer?

Customer Relationship Management (CRM), Türkçesiyle Müşteri İlişkileri Yönetimi; müşteri, kişi, şirket, etkileşim, destek ve satış sürecini tanımlı kimlik, sahiplik, izin, iş akışı ve ölçümle yönetme disiplinidir. E-ticaret entegrasyonu sipariş ve davranış bağlamını CRM’e taşırken CRM kararlarını ilgili kanallara kontrollü iletir. Amaç daha çok veri toplamak değil, doğru amaç için güvenilir ve asgari veriyi kullanmaktır.

Katman	Temel soru	CRM rolü	Başarı kanıtı
Kimlik	Aynı kişi hangi kayıtlarda?	Deterministik eşleme ve inceleme kuyruğu	Immutable ID ve merge audit
Bağlam	Müşteri ne yaşadı?	Sipariş, destek ve etkileşim özeti	Kaynak ID ve freshness
İzin	Hangi amaç/kanal kullanılabilir?	Preference ve suppression uygulama	Metin sürümü, zaman, kaynak
Süreç	Kim hangi işi yapacak?	Satış/destek workflow’u	SLA ve görev geçmişi
Aktivasyon	Hangi kanala ne gönderildi?	Segment ve audience çıkışı	Geri çekme ve mutabakat

Küçük ve erken aşamadaki operasyonlarda yerleşik müşteri ve sipariş ekranı yeterli olabilir; ayrı CRM kararı müşteri sayısından çok süreç karmaşıklığı ve riskle verilmelidir.

Hangi işletmeler ayrı CRM’e ihtiyaç duyar?

Ayrı CRM gereksinimi sabit müşteri veya sipariş eşiğiyle belirlenmez. Çok kanal, yüksek destek hacmi, B2B satış döngüsü, marka-kanal-amaç bazlı izin, çok temsilci, dağınık veri kaynağı, yoğun manuel takip ve yanlış ileti maliyeti güçlü sinyallerdir. Tek kanallı küçük mağaza ise yerleşik ekran, basit izin kaydı ve kontrollü raporla daha düşük TCO sağlayabilir.

Sinyal	Yerleşik ekran yeterli olabilir	Ayrı CRM değerlendir	Kanıt
Kanal	Tek site ve az temas	Site, pazaryeri, mağaza, destek	Kanal veri haritası
Ekip	Bir-iki kullanıcı	Satış, destek, pazarlama ekipleri	RACI ve kuyruk hacmi
İzin	Basit tek marka	Çok marka/kanal/amaç	Consent matrisi
B2B	Yok veya basit	Account, contact, fırsat, bayi	Temsili account modeli
Otomasyon	Az tetikleyici	Çok journey ve çakışma	Collision/frequency testleri
Risk	Düşük hata etkisi	Yanlış merge, hassas veri, aktarım	Risk ve kontrol kataloğu

Erken dönem müşteri takibinin sınırlarını ilk 100 sipariş operasyonu bağlamında değerlendirmek gereksiz platform yükünü önleyebilir.

CRM, CDP, ERP, OMS, help desk ve marketing automation nasıl ayrılır?

CRM, CDP, ERP, OMS, help desk ve marketing automation aynı sistem değildir. CRM ilişki ve süreç kaydı tutar; CDP çok kaynaklı olay/profil birleştirme ve aktivasyona, ERP ticari-finansal kayda, OMS sipariş orkestrasyonuna, help desk vaka yönetimine, marketing automation ise ileti journey’lerine odaklanır. Bir ürün bu yetenekleri birlikte sunabilir; ekran benzerliği alan sahipliğini değiştirmez.

Sistem	Birincil amaç	CRM’e verdiği/alacağı veri	CRM’in devralmaması gereken
E-ticaret	Mağaza, hesap, sepet, sipariş	Hesap ve sipariş referansı	Checkout gerçeği
CDP	Olay/profil birleştirme ve aktivasyon	Segment ve identity sinyali	CRM satış workflow’u
ERP	Cari, fatura, tahsilat, finans	Cari/fatura özeti	Muhasebe ana kaydı
OMS	Sipariş yaşam döngüsü	Durum ve istisna özeti	Tahsisi/yönlendirme
Help desk	Ticket ve SLA	Vaka, konuşma, owner	Satış fırsatı ana kaydı
Marketing automation	Journey ve gönderim	Segment, sonuç, suppression	Consent kanıtının tek kaynağı
PIM	Ürün ana verisi	Ürün referansı	Müşteri kimliği

CRM-ERP alan sahipliği için ERP entegrasyonunda source-of-truth yaklaşımı, sipariş kararları için OMS görev sınırı ayrıca değerlendirilmelidir.

Müşteri veri modeli B2C ve B2B’de nasıl kurulmalıdır?

B2C modelinde ziyaretçi, kullanıcı hesabı, alıcı, teslimat alıcısı, fatura alıcısı ve destek talebi sahibi aynı kişi olmayabilir. B2B modelinde account/şirket, şube, contact, satın alma rolü, yetki, bayi, cari, lead, opportunity ve teklif ilişkileri ayrıca gerekir. Tek bir “müşteri” tablosu bu rolleri ezmemeli; ilişki türü, geçerlilik ve kaynak kimliği korunmalıdır.

Varlık	Anlam	Kararlı kimlik	Kritik ayrım
Person	Gerçek kişi profili	Internal person ID	İletişim bilgisi kimlik değildir
User account	Giriş hesabı	Account ID	Person ile birebir olmayabilir
Buyer	Siparişi veren rol	Order snapshot referansı	Teslimat alıcısından ayrıdır
Recipient	Teslim alan	Sipariş snapshot’ı	Güncel profile yazılmaz
Lead	Henüz doğrulanmamış potansiyel	Lead ID	Müşteri garantisi değildir
Ticket owner	Destek talebi sahibi	Case-contact ilişki	Alıcıyla aynı olmayabilir

B2B varlığı	İlişki	Örnek kural	Risk
Account/şirket	Üst ticari varlık	Vergi/cari referansı ERP ile eşlenir	Şirketi kişi sanmak
Branch	Account altı	Adres ve bölge kapsamı	Yetkiyi tüm şirkete yaymak
Contact	Şirketteki kişi	Rol ve geçerlilik tarihli	İşten ayrılan erişimi
Buying role	Karar/ödeme/teslim rolü	Fırsat veya sipariş bağlamı	Sabit kişilik özelliği sanmak
Opportunity	Satış fırsatı	Aşama, owner, tahmini değer	Muhasebe gerçeği saymak
Dealer	Bayi ilişkisi	Bölge ve sözleşme kapsamı	Tenant sınırını ihlal

B2B senaryosunun ticari yapısı için B2B e-ticaret account ve bayi yaklaşımı tamamlayıcıdır.

Müşteri kimliği nasıl çözülür ve yanlış merge nasıl önlenir?

Müşteri kimliği, değişebilen e-posta veya telefonu evrensel anahtar sayarak çözülmemelidir. Internal immutable ID, kaynak external ID’leri, doğrulanmış hesap bağlantıları ve güvenli deterministik kurallar temel olmalıdır. Probabilistik eşleşme yalnız aday ve güven skoru üretmeli; paylaşılan iletişim, alias, numara değişimi ve hesap ele geçirme riskinde manuel inceleme ile geri alınabilir merge gerekir.

Sinyal	Güç	Tek başına merge?	Kontrol
Doğrulanmış account ID	Yüksek	Kaynak sözleşmesine göre	Hesap sahipliği ve tenant
Sipariş customer ID	Yüksek/orta	Kaynağa göre	Misafir/hesap ayrımı
E-posta	Orta	Hayır	Doğrulama, alias, ortak kutu
Telefon	Orta	Hayır	E.164, yeniden tahsis, ortak hat
Ad+adres	Düşük	Hayır	Yazım, hane, snapshot
Cihaz/cookie	Düşük	Hayır	İzin, süre, paylaşılan cihaz

Telefon normalizasyonu E.164 referansına göre biçimsel yardımcıdır; numaranın kime ait olduğunu kanıtlamaz. Yanlış merge’in audience ve destek görünümüne yayılmış etkisi de geri alınmalıdır.

Source of truth ve Customer 360 nasıl tasarlanır?

Customer 360, her kaydın CRM’e kopyalandığı sınırsız depo değildir; kaynak, kapsam, tazelik, hukuki amaç ve erişim seviyesi bilinen birleşik görünümdür. Source of truth alan ve olay bazında tanımlanır. Güncel profil ile sipariş anı snapshot’ı ayrılır; profil adresi değiştiğinde geçmiş faturanın veya teslimat kaydının geriye dönük değiştirilmesi engellenir.

CRM’e hangi veriler aktarılmalı, hangileri aktarılmamalıdır?

CRM’e yalnız tanımlı müşteri, satış veya destek amacı için gerekli ve erişimi yönetilebilir veri aktarılmalıdır. Kart numarası, CVV, parola, oturum tokenı, gizli anahtar, gereksiz TCKN veya hassas serbest metin taşınmamalıdır. Ödeme bağlamı gerekiyorsa işlem referansı, maskelemiş/tokenlaştırılmış özet, durum ve zaman gibi asgari veri güvenlik ve PCI değerlendirmesiyle kullanılabilir.

Ödeme verisi sınırı için PCI DSS v4.0.1 resmî kaynağı ve kuruluşun kendi kapsam değerlendirmesi birlikte kullanılmalıdır.

Veri kalitesi ve normalizasyon nasıl yönetilir?

CRM veri kalitesi yalnız dolu profil oranı değildir. Doğruluk, tamlık, geçerlilik, tutarlılık, güncellik, benzersizlik ve izin kanıtı ayrı ölçülmelidir. Telefon E.164 biçimine normalize edilebilir; bu sahipliği kanıtlamaz. E-posta yerel bölümünü gelişigüzel küçültmek veya nokta/alias kurallarını bütün sağlayıcılara uygulamak yanlış hesap birleştirmesine yol açabilir.

Consent, preference, İYS ve suppression nasıl ayrılır?

Consent tek bir pazarlama bayrağı değildir. KVKK aydınlatması, açık rıza veya diğer işleme şartları; 6563 kapsamındaki ticari elektronik ileti onayı; İYS kaydı; kanal ve marka tercihi; metin sürümü; amaç; kaynak ve suppression ayrı fakat ilişkili kayıtlardır. Ret talebi CRM, İYS, e-posta/SMS/WhatsApp sağlayıcısı, marketing automation ve audience kanallarına ölçülen süre içinde yayılmalıdır.

Güncel hukuki çerçeve için KVKK 2026/347 İlke Kararı duyurusu, Ticaret Bakanlığı ticari elektronik ileti sayfası ve İYS API dokümantasyonu birincil başvuru noktalarıdır.

Silme, anonimleştirme ve suppression nasıl dengelenir?

Silme talebi geldiğinde her kaydı körlemesine yok etmek veya ret kanıtını tamamen silmek doğru varsayım değildir. İşleme amacı, yasal saklama, ispat, hak talebi ve yeniden gönderimi önleme ihtiyacı hukuk, güvenlik ve veri ekipleriyle değerlendirilmelidir. Pseudonymization yeniden ilişkilendirme anahtarı varsa anonimleştirme değildir; hash edilmiş e-posta da otomatik olarak anonim sayılmaz.

KVKK silme, yok etme ve anonimleştirme açıklaması genel çerçeve sunar; somut süreç uzman görüşüyle tasarlanmalıdır.

Yurt dışı SaaS CRM nasıl değerlendirilmelidir?

Yurt dışı CRM seçimi yalnız veri merkezinin Avrupa’da olması veya vendor’ın “uyumluyuz” beyanıyla tamamlanmaz. Veri sorumlusu/veri işleyen rolleri, alt işleyenler, saklama ve işleme ülkeleri, sonraki aktarımlar, Kanun’un 9. maddesindeki mekanizma, standart sözleşme türü, bildirim, teknik-idari tedbir, silme, olay bildirimi ve exit kanıtı birlikte değerlendirilmelidir.

Güncel mekanizmalar için KVKK Yurt Dışına Aktarım Rehberi ve standart sözleşme bildirim duyurusu incelenmelidir.

Sipariş, ödeme, kargo ve iade bağlamı CRM’e nasıl taşınır?

CRM siparişin ana işlem sistemi veya orkestratörü olmamalıdır; temsilciye güvenilir ve zaman damgalı bağlam sunmalıdır. Sipariş, satır, paket, gönderi, teslimat, iade, refund, fatura ve ödeme özeti ayrı kimliklerle bağlanır. Güncel profil ile sipariş snapshot’ı ayrılır; CRM’den OMS/ERP durumuna kontrolsüz geri yazım ve çift yönlü döngü engellenir.

Çok kanallı sipariş verisi sınırı için pazaryeri sipariş entegrasyonu, teslimat olayları için kargo entegrasyonu rehberi ve belge durumu için otomatik faturalandırma süreci ilgili ayrıntıyı sağlar.

Destek ticket’ı ve omnichannel müşteri bağlamı nasıl kurulmalıdır?

Ticket veya case; müşteri, sipariş, kanal, konuşma, owner, kuyruk, öncelik, SLA ve sonuçla ilişkili ayrı bir iş varlığıdır. E-posta, SMS, WhatsApp veya çağrı aktivitesi aynı konuşmaya güvenli biçimde bağlanmalı; kanal verisinin kullanım şartı korunmalıdır. CRM görünümü gecikmeli sipariş özetinin zamanını göstermeli, temsilci notları amaç, saklama ve alan bazlı yetkiyle sınırlandırılmalıdır.

Operasyon adımlarını yeniden üretmeden ticket bağlamını satış sonrası süreçlerin müşteri deneyimi ile ilişkilendirmek mümkündür.

Segmentasyon, RFM, CLV ve skorlar nasıl kullanılmalıdır?

Segment, belirli anda tanımlı koşulları sağlayan müşteri kümesidir; RFM recency-frequency-monetary örüntüsünü, CLV müşteri yaşam boyu değerine ilişkin varsayımlı tahmini, churn ve lead score ise model çıktısını gösterir. Bunlar muhasebe gerçeği veya geleceğin garantisi değildir. Veri dönemi, hesap formülü, model sürümü, kapsam, hata ve ayrımcılık riski görünür olmalıdır.

Sadakat taktiklerini tekrar etmeden veri kullanımını müşteri sadakati ve tekrar satın alma ölçümleri ile; KPI’ları e-ticaret raporlama yaklaşımı ile bağlayabilirsiniz.

Marketing automation ve audience aktivasyonu nasıl güvenli kurulur?

Marketing automation; tetikleyici, koşul, bekleme, eylem, frequency cap, suppression ve sonuç olayını açıkça tanımlamalıdır. Aynı müşteri birden çok journey’ye girdiğinde öncelik ve collision kuralı gerekir. Audience aktivasyonunda veri minimizasyonu, izin amacı, hash/pseudonymization sınırı, hedef platform şartları, geri çekme ve silme sonucu ölçülmelidir. Her gönderim yeniden doğrulanmalıdır.

Kampanya içeriği yerine izin ve veri sınırı için e-posta pazarlamada izinli liste yaklaşımı, audience sınırı için yeniden pazarlama ve retargeting rehberi tamamlayıcıdır.

API, webhook, batch, iPaaS ve event mimarisi nasıl seçilir?

Entegrasyon deseni iş etkisi, gecikme toleransı, hacim, sıra, hata telafisi, maliyet ve kaynak limitine göre seçilir. Her veri gerçek zamanlı olmak zorunda değildir. API sorgu/komut, webhook değişiklik bildirimi, batch yüksek hacimli periyodik taşıma, iPaaS orkestrasyon ve dönüşüm, event bus ise asenkron ayrıştırma için kullanılabilir. Hiçbiri kendiliğinden teslim veya iş başarısı garantisi vermez.

• Gerçek zamanlı: Kritik opt-out gibi yüksek etkili olaylarda kanal desteği ve risk gerektiriyorsa kullanılır; operasyon yükü ayrıca ölçülür.
• Yakın gerçek zamanlı: Ticket veya sipariş özeti dakika düzeyi toleransla kuyruk ve retry üzerinden taşınabilir.
• Mikro batch: Segment güncellemesi kısa pencereyle çalışabilir; toplu hata etkisi ve rollback planlanır.
• Günlük batch: Düşük riskli rapor özeti için uygundur; kullanıcıya freshness zamanı gösterilir.

Event sözleşmesi ve güvenilir teslim nasıl tasarlanır?

Event sözleşmesi entity ID, event ID, schema version, entity version, occurred-at, received-at, tenant, purpose, correlation ID ve veri sınıflandırması taşımalıdır. Webhook “en az bir kez” teslim edilebilir; tüketici idempotent olmalı, tekrarları ayıklamalı ve out-of-order olayı sürümle yönetmelidir. Retry, backoff, jitter, circuit breaker, dead-letter, güvenli replay ve mutabakat birlikte tasarlanır.

Sözleşme için OpenAPI 3.2.0, olay API’leri için AsyncAPI güncel spesifikasyonu, ortak olay zarfı için CloudEvents kullanılabilir.

HTTP yanıtı, iş durumu ve reconciliation nasıl ayrılır?

HTTP 200 yalnız HTTP katmanındaki yanıtı gösterir; müşteri kaydının doğru alana yazıldığını, consent’in işlendiğini veya audience’dan kaldırmanın tamamlandığını kanıtlamaz. Request ID, karşı sistem kimliği, asenkron job durumu, alan doğrulaması ve read-back gerekir. Reconciliation aynı scope, sürüm ve zaman penceresindeki sayı ile kritik alanları karşılaştırır; fark owner kuyruğunda çözülür.

Makinece işlenebilir hata için RFC 9457 Problem Details, HTTP semantiği için RFC 9110 esas alınabilir.

CRM API ve webhook güvenliği nasıl kurulmalıdır?

CRM güvenliği yalnız API anahtarı değildir. OAuth 2.0 scope ve kısa ömürlü token, OIDC kimlik, mTLS veya mesaj imzası, secret vault ve rotasyon, webhook replay koruması, RBAC/ABAC, field-level security, tenant izolasyonu, bulk export ayrımı ve değiştirilemez audit gerekir. Anahtar URL, tarayıcı, istemci kodu, log veya destek biletinde bulunmamalıdır.

OAuth güvenliği için RFC 9700 / BCP 240, OIDC ayrımı için OpenID Connect Core, mesaj imzası için RFC 9421 incelenmelidir.

Log, metric, trace ve veri gözlemlenebilirliği nasıl kurulmalıdır?

Gözlemlenebilirlik teknik hata ile veri hatasını birlikte görünür kılmalıdır. Log correlation ID ve sınıflandırılmış hata taşır; parola, token, kart verisi ve gereksiz PII içermez. Metric; latency, throughput, rate limit, retry, DLQ, consent propagation ve reconciliation farkını ölçer. Trace uçtan uca yolu gösterir; data quality event ise yanlış merge, stale sipariş ve suppression ihlalini owner’a bağlar.

Vendor bağımsız telemetry için OpenTelemetry dokümantasyonu teknik başlangıç sağlar.

Yapay zekâ CRM’de nasıl güvenli kullanılabilir?

AI ticket özeti, sınıflandırma, duygu, lead/churn skoru veya next-best-action için yardımcı olabilir; kesin gerçek veya otomatik müşteri hükmü değildir. Amaç, minimizasyon, kaynak, model/ülke/sağlayıcı, eğitimde kullanım, saklama, yurt dışı aktarım, redaction, açıklanabilirlik, hata, ayrımcılık, insan onayı ve itiraz mekanizması devreye alınmadan müşteri verisi modele gönderilmemelidir.

AI’nin e-ticaretteki genel kullanım sınırı için yapay zekâ destekli e-ticarette insan kontrolü ayrıca incelenebilir.

CRM ve entegrasyon KPI’ları nasıl ölçülmelidir?

CRM başarısı contact sayısı, gönderim hacmi veya dashboard görüntüsüyle ölçülmez. Identity doğruluğu, duplicate ve yanlış merge, consent propagation, suppression ihlali, sipariş freshness, first-time-right, ticket bağlama, otomasyon çakışması, P95/P99 gecikme, DLQ yaşı, reconciliation farkı, manuel dokunuş ve ilgili kişi talebi süresi birlikte izlenmelidir. Satış veya memnuniyet artışı doğrudan CRM’e atfedilmemelidir.

CRM entegrasyonu maliyeti ve TCO nasıl hesaplanır?

CRM maliyeti yalnız lisans değildir. Kullanıcı, contact, event, API, depolama, ileti, sandbox, SSO, audit, connector, iPaaS, veri temizleme, kimlik çözümleme, migration, güvenlik, yurt dışı aktarım hukuku, eğitim, destek, bakım ve exit birlikte hesaplanmalıdır. Güncel teklif olmadan piyasa fiyatı uydurulmamalı; 12 ve 36 aylık senaryolar aynı kapsam ve varsayımla karşılaştırılmalıdır.

CRM sağlayıcısı nasıl seçilir ve PoC nasıl yapılır?

Sağlayıcı seçimi demo veya “uyumluyuz” kutusuna indirgenmemelidir. Gerçek modele benzeyen sentetik/maskelemiş veriyle identity, consent, sipariş snapshot, ticket, webhook, retry, DLQ, güvenlik, export ve rollback test edilmelidir. PoC hipotezi sınar; pilot sınırlı gerçek operasyonu, UAT iş kabulünü doğrular. Üretim güvenliği ve işletim hazırlığı ayrıca kanıtlanmalıdır.

Migration, cutover, rollback ve hypercare nasıl planlanır?

CRM migration tek CSV importu değildir. Kaynak envanteri, profiling, mapping, duplicate temizliği, immutable ID, consent kanıtı, activity/attachment, özel alan, ilişki, otomasyon, delta sync ve exit kapsamı birlikte ele alınır. Big-bang tek seçenek değildir; dalga veya paralel geçiş değerlendirilebilir. Cutover kararının rollback snapshot’ı, tüketici yönü ve hypercare alarmı test edilmelidir.

Müşteri ID, izin ve geçmişin taşınma disiplini için e-ticaret sitesi migration yaklaşımı tamamlayıcı bir çerçevedir.

90 günlük temsili CRM entegrasyonu yol haritası nasıl kurulur?

Doksan günlük plan her proje için canlıya geçiş garantisi değildir; keşif, model, PoC ve kontrollü ilk kapsam için temsili yol haritasıdır. Kaynak kalitesi, hukuk, vendor, entegrasyon ve ekip kapasitesi süreyi değiştirebilir. Her faz owner, kanıt, risk ve çıkış kapısı taşımalıdır; kritik identity, consent, güvenlik veya rollback testi geçmezse sonraki faz otomatik başlamamalıdır.

SoloCommerce ile yerleşik müşteri görünümü mü, ayrı CRM mi?

SoloCommerce’in canlı paketlerinde ürün, sipariş ve operasyon görünümü, temel email/SMS bildirim seviyeleri, WhatsApp için opsiyonel/pilot yaklaşım ve Enterprise’da özel entegrasyon/SLA doğrulanıyor. Paket tablosu bağımsız tam CRM veya CDP’yi açıkça doğrulamıyor. Basit işletme yerleşik görünümle ilerleyebilir; karmaşık identity, consent, B2B fırsat, help desk ve automation ihtiyacında ayrı CRM fit-gap ile değerlendirilmelidir.

Canlı kapsamı Solofor e-ticaret paketleri üzerinden karşılaştırın. Çok kanallı sipariş görünümü için pazaryeri entegrasyonu çözüm sayfası yalnız doğal operasyon bağlamında değerlendirilmelidir.

12 temsili CRM entegrasyonu senaryosu neyi gösterir?

Temsili senaryolar özellik listesini gerçek iş hedefi, kimlik, veri minimizasyonu, izin, entegrasyon, hata ve ölçümle sınamayı sağlar. Aşağıdaki örnekler piyasa verisi, sabit proje süresi veya sonuç garantisi değildir. Her işletme kendi veri sınıfı, hukuk görüşü, kanal şartı, hacim ve riskine göre uyarlamalı; SoloCommerce ve ayrı CRM kararı gerçek katalog/müşteri akışıyla PoC ve UAT üzerinden doğrulanmalıdır.

Temsili senaryo 1: Tek kanallı küçük mağaza

Bu temsili senaryo, küçük ekip, tek web mağazası ve sınırlı destek hacmi. için CRM entegrasyonu kararını risk ve kanıt üzerinden ele alır. Amaç yazılım sonucu vaat etmek değil; kimlik, izin, veri sınırı, teslimat, geri alma ve ölçümün aynı kabul planında görünür olmasını sağlamaktır.

Temsili senaryo 2: Web sitesi ve pazaryerinde ortak görünüm

Temsili senaryo 3: Misafir siparişin hesaba bağlanması

Temsili senaryo 4: Duplicate iletişim ve yanlış merge

Temsili senaryo 5: İYS retinin bütün kanallara yayılması

Temsili senaryo 6: Ticket içinde sipariş ve kargo bağlamı

Temsili senaryo 7: Kısmi iade ve memnuniyet takibi

Temsili senaryo 8: B2B account ve çoklu yetkili

Temsili senaryo 9: Marketing automation ve audience

Temsili senaryo 10: Kampanya yoğunluğunda rate limit ve DLQ

Temsili senaryo 11: Yurt dışı SaaS CRM

Temsili senaryo 12: Eski CRM’den yeni CRM’e geçiş

CRM sağlayıcısına hangi kanıt soruları sorulmalıdır?

İyi sağlayıcı sorusu evet/hayır cevabı istemez; çalışan sürüm, sınır, gerçek veya sentetik test, log, export ve sözleşmeli sorumluluk ister. Aşağıdaki sorular “uyumluyuz”, “güvenliyiz” veya “gerçek zamanlıyız” gibi pazarlama ifadelerini ölçülebilir kanıta dönüştürür. Kritik cevaplarda owner, kapsam, istisna, maliyet ve deprecation ayrıca istenmeli; roadmap bugünkü çalışan yetenek sayılmamalıdır.

Veri modeli ve kimlik

1. S01: Gerçek senaryomuzda B2C ve B2B account/contact modellerini nasıl ayırdığınızı çalışan kayıt ve export ile gösterir misiniz?
2. S02: Misafir siparişin sonradan hesaba bağlanmasında hangi doğrulama, güven skoru ve manuel inceleme uygulanır?
3. S03: Deterministik ve probabilistik identity resolution kurallarınız, eşikleriniz ve yanlış pozitif testiniz nedir?
4. S04: Paylaşılan e-posta veya telefonda otomatik merge’i nasıl engelliyorsunuz; negatif UAT kanıtı sunar mısınız?
5. S05: Yanlış merge’in profil, aktivite, ticket ve audience etkisini unmerge ile nasıl geri alıyorsunuz?
6. S06: Immutable internal ID, external ID ve alias sayısı ile benzersizlik kurallarını dokümante eder misiniz?
7. S07: Profil ile order snapshot ayrımını adres değişikliği örneğinde canlı gösterebilir misiniz?
8. S08: Özel alan, çoklu ilişki, effective date ve tenant kapsamının teknik limitleri nedir?
9. S09: Source-of-truth ve field-level write ownership kuralları nerede yapılandırılır ve audit edilir?
10. S10: Veri sözlüğü, şema, ilişki ve mapping’ler makinece okunabilir formatta tam export edilebilir mi?

Consent, KVKK ve veri yaşamı

1. S11: Marka, kanal, amaç, metin sürümü, kaynak ve zaman bazlı consent kanıtını nasıl tutuyorsunuz?
2. S12: İYS bağlantısı standart mı özel mi; desteklenen metot, paket, limit ve sorumluluğu yazılı verir misiniz?
3. S13: Ret talebinin CRM, İYS, ESP, SMS, WhatsApp ve audience kanallarına yayılma P95/P99 sonucu nedir?
4. S14: Suppression ihlalini gönderimden önce teknik olarak engelleyen kontrolü negatif testle gösterebilir misiniz?
5. S15: Aydınlatma, açık rıza, ticari ileti onayı ve preference kayıtlarını veri modelinde nasıl ayırıyorsunuz?
6. S16: Silme, anonimleştirme, legal hold ve minimum ret kanıtı kararını nasıl uygular ve audit edersiniz?
7. S17: KVKK bağlamında veri sorumlusu/veri işleyen rolünüz ile DPA sorumluluk matrisini sunar mısınız?
8. S18: Veri ve alt işleyenler hangi ülkelerde bulunur; güncel alt işleyen değişiklik bildirimi nedir?
9. S19: Yurt dışı aktarım için desteklediğiniz standart sözleşme tipi, ekler ve bildirim kanıtı nelerdir?
10. S20: İlgili kişi erişim, düzeltme, silme ve export taleplerinde süre, doğrulama ve kanıt akışı nasıldır?

API, event ve hata yönetimi

1. S21: API kapsamı, rate limit, burst, pagination, async job ve payload limitlerini tenant/paket bazında verir misiniz?
2. S22: Webhook teslim, retry, imza, timestamp ve replay korumasını test ortamında gösterebilir misiniz?
3. S23: Aynı idempotency anahtarıyla aynı ve farklı payload tekrarında sistem ne yapar?
4. S24: Entity version, sequence, occurred-at ve received-at ile out-of-order olay nasıl yönetilir?
5. S25: Schema versioning, geriye uyumluluk ve deprecation bildirim süreniz nedir?
6. S26: Geçici ve kalıcı hatayı nasıl ayırır; backoff, jitter ve retry bütçesini nasıl uygularsınız?
7. S27: Dead-letter kaydının alarmı, owner’ı, düzeltme ve yetkili replay aracı var mı?
8. S28: HTTP kabulü ile işlenmiş kayıt ve read-back sonucunu hangi kimliklerle ayırıyorsunuz?
9. S29: Full, incremental ve alan bazlı reconciliation raporu sağlıyor musunuz; farklar nasıl kapatılır?
10. S30: Batch import/export’ta manifest, checksum, satır sayısı, kısmi hata ve rollback nasıl çalışır?

Güvenlik ve süreklilik

1. S31: OAuth 2.0, OIDC, SSO, MFA, mTLS ve kısa ömürlü token seçeneklerinin paket sınırı nedir?
2. S32: Scope, RBAC, ABAC ve field-level security için negatif erişim testi sunabilir misiniz?
3. S33: Bulk export, admin, consent ve merge yetkileri görev ayrılığıyla sınırlandırılabilir mi?
4. S34: Tenant izolasyonu bağımsız test veya raporla nasıl kanıtlanıyor?
5. S35: Secret’lar nerede saklanır; rotasyon, revocation ve log masking provası var mı?
6. S36: Kart, CVV, parola, token veya yasaklı hassas alanın ingest edilmesini nasıl engelliyorsunuz?
7. S37: Audit log kapsamı, değişmezlik, saklama, export ve SIEM bağlantısı nedir?
8. S38: Güncel penetrasyon testi, OWASP ASVS/API kontrol eşlemesi ve açık bulgu politikası nedir?
9. S39: Backup, point-in-time restore, bileşen bazlı RTO/RPO ve son tatbikat sonucu nedir?
10. S40: Vendor veya CRM kesintisinde kuyruk, veri kaybı ve toparlama runbook’unu paylaşır mısınız?

Sipariş, destek ve aktivasyon

1. S41: E-ticaret konektörü customer, order, line, shipment, return, refund ve invoice alanlarının hangilerini hangi yönde taşır?
2. S42: CRM’in OMS/ERP durumuna kontrolsüz geri yazmasını ve sync loop’u nasıl engelliyorsunuz?
3. S43: Ticket-order bağında yanlış müşteri/tenant erişimini hangi testle önlüyorsunuz?
4. S44: E-posta, SMS, WhatsApp ve çağrı aktivitelerinde conversation dedupe ve correlation nasıl yapılır?
5. S45: SLA timer, pause, escalation ve owner değişikliği hangi takvim ve audit ile çalışır?
6. S46: Segment üyeliğinin sorgu sürümü, hesap zamanı ve consent kapısı görünür mü?
7. S47: Journey collision, priority, frequency cap ve kill switch yeteneklerini gösterir misiniz?
8. S48: Audience gönderimi ve opt-out removal için accepted, processed ve read-back durumları var mı?
9. S49: Hashed identifier’ın kullanım amacı, saklama ve platform removal akışını nasıl kanıtlarsınız?
10. S50: Marketplace müşteri verisi için kanal şartı, minimizasyon ve kullanım sınırı nasıl uygulanır?

AI, gözlemleme ve performans

1. S51: AI özellikleri hangi müşteri verisini hangi model, ülke ve alt sağlayıcıya gönderiyor?
2. S52: Müşteri verisi model eğitiminde kullanılıyor mu; opt-out, retention ve silme kanıtı nedir?
3. S53: AI redaction, human approval, kapatma ve itiraz mekanizmasını çalışan örnekle gösterir misiniz?
4. S54: Ticket özeti veya skor için doğruluk, false positive, bias ve açıklanabilirlik metriğiniz nedir?
5. S55: Log, metric ve trace’te correlation ID uçtan uca korunuyor ve müşteri tarafından export ediliyor mu?
6. S56: Consent propagation, sync latency, DLQ age ve reconciliation mismatch için hazır dashboard var mı?
7. S57: Temsili hacmimizde API, bulk import, segment ve export P50/P95/P99 sonuçlarını test eder misiniz?
8. S58: Rate limit ve kampanya patlamasında backpressure ile kuyruk davranışını gösterebilir misiniz?
9. S59: PII maskeleme ve debug log güvenliği için otomatik test ve örnek log sunar mısınız?
10. S60: Planlı bakım, sürüm yükseltme ve geriye alma sırasında kullanılabilirlik nasıl ölçülür?

Maliyet, sözleşme ve exit

1. S61: Lisans kullanıcı, contact, event, depolama, API, ileti, ortam veya modülün hangilerine göre hesaplanır?
2. S62: Pasif, duplicate, arşiv, lead ve B2B contact kayıtları lisans sayımına nasıl girer?
3. S63: Sandbox, SSO, audit, SIEM, API, connector, AI ve export ek ücretli midir?
4. S64: Aşım ücretleri, otomatik paket yükseltme, fiyat/kur artışı ve yenileme şartı nedir?
5. S65: Kurulum, data cleansing, identity, migration, eğitim, destek ve hypercare teklifte ayrı mı?
6. S66: 12 ve 36 aylık TCO’yu aynı hacim varsayımları ve exit maliyetiyle sunar mısınız?
7. S67: SLA, destek saati, service credit, olay bildirimi ve kritik eskalasyon taahhüdü nedir?
8. S68: Tam export; profil, ilişki, activity, attachment, audit, consent ve automation’ı hangi formatta verir?
9. S69: Exit export, geçiş desteği, backup purge ve silme belgesinin süre ve ücreti nedir?
10. S70: Özel kod, iPaaS flow ve connector fikrî/operasyonel sahipliği sözleşmede kimdedir?

PoC, migration ve SoloCommerce

1. S71: PoC hedefi, sentetik veri seti, kabul kriteri, ortam ve sorumluluğu sözleşmeye yazıyor musunuz?
2. S72: Yanlış merge, consent ret, DLQ, replay, field security ve exit testlerini PoC’ye dahil eder misiniz?
3. S73: Migration dry-run, iki prova, delta sync, cutover, rollback ve hypercare hangi kapsamda sunulur?
4. S74: Stable ID, consent evidence, activity, attachment ve özel ilişki bütünlüğünü nasıl mutabıklaştırırsınız?
5. S75: Test ortamından gerçek e-posta/SMS/WhatsApp çıkışını teknik olarak nasıl engellersiniz?
6. S76: SoloCommerce için hazır bağlantı iddiasının alan, yön, sürüm, limit ve destek kanıtı nedir?
7. S77: Hazır konektör yoksa discovery, özel entegrasyon, bakım ve SLA sorumluluğunu nasıl tekliflersiniz?
8. S78: Benzer veri modeli ve riskte referans, performans ve üretim işletim kanıtı sunabilir misiniz?

Toplam 78 kanıt odaklı soru vardır. Yanıtlar demo kaydı, teknik doküman, PoC/UAT sonucu, güvenlik raporu, teklif ve sözleşme ekiyle doğrulanmadan seçim kararı tamamlanmamalıdır.

E-ticaret CRM entegrasyonu kontrol listesi nasıl kullanılmalıdır?

Kontrol listesi, satın alma sonunda işaretlenecek genel niyetler değil; owner, son tarih, kanıt, risk ve durum taşıyan proje iş paketleridir. “Tamamlandı” demek için doküman, negatif test, export, log veya mutabakat sonucu bulunmalıdır. Canlıya geçiş ön koşulları özellikle identity, consent, ödeme verisi, yetki, tenant izolasyonu ve rollback alanlarında sözlü istisnayla kapatılmamalıdır.

İş hedefi ve kapsam

• Belirle: CRM entegrasyonunun ölçülebilir üç iş hedefini owner’larıyla onayla.
• Kaydet: baseline dönemini ve KPI başlangıç değerlerini sakla.
• Sınırla: ilk faz marka, kanal, ekip ve veri kapsamını yaz.
• Doğrula: yerleşik müşteri ekranının yeterli olabileceği senaryoyu değerlendir.
• Ayır: satış, destek, izin ve raporlama hedeflerini farklı ölç.
• Tanımla: canlıya geçiş dışı CDP, call center ve ileri analitik konularını backlog’a al.
• Ölç: manuel iş, yanlış ileti ve duplicate hata maliyetini çıkar.
• Belirle: kritik identity, consent ve güvenlik eleme koşullarını yaz.
• Onayla: hukuk, güvenlik ve operasyon risk iştahını belgelet.
• İzle: kapsam değişikliğini değişiklik kurulu ve TCO etkisiyle yönet.

Ekip ve RACI

• Belirle: business sponsor, data owner ve integration owner rollerini ayır.
• Ata: identity, consent, ticket ve order alanlarına ayrı owner ver.
• Kaydet: veri sorumlusu ve veri işleyen sorumluluklarını RACI’ye ekle.
• Sınırla: editör, merge onaylayıcı ve bulk export yetkilerini ayır.
• Tanımla: incident, DLQ ve privacy request eskalasyon zincirini yaz.
• Doğrula: tatil ve personel ayrılışında yedek rol akışını test et.
• Onayla: hukuk ve güvenlik kapılarının proje planındaki yerini belirle.
• İzle: açık görev, SLA ve owner değişikliğini düzenli raporla.

Sistem envanteri

• Listele: e-ticaret, ERP, OMS, help desk, İYS, ileti ve reklam sistemlerini kaydet.
• Kaydet: her sistemin owner, tenant, ortam ve veri konumunu belirt.
• Doğrula: API, webhook, batch ve export yeteneklerinin güncel sürümünü aç.
• Ölç: kaynak hacim, rate limit, freshness ve bakım penceresini çıkar.
• Belirle: her external ID’nin üretildiği sistemi ve benzersizlik kapsamını yaz.
• Sınıflandır: veri alanlarını kişisel, hassas, finansal ve operasyonel olarak etiketle.
• Tespit et: manuel spreadsheet ve görünmeyen entegrasyon adımlarını belgele.
• Onayla: bağımlılık ve kesinti etkisi haritasını sistem owner’larına doğrulat.

B2C/B2B veri modeli

• Ayır: person, user account, buyer, recipient ve ticket owner varlıklarını modelle.
• Ayır: account, branch, contact, dealer, lead ve opportunity varlıklarını tanımla.
• Belirle: her varlık için immutable internal ID politikasını yaz.
• Kaydet: ilişki türü, yönü, geçerlilik ve kaynağı ayrı alanlarda tut.
• Sınırla: contact’ın şirket değişiminde eski ilişkiyi tarihsel olarak kapat.
• Doğrula: parent-child account ve şube yetkisini negatif test et.
• Ayır: güncel profil ile sipariş anı snapshot’ını farklı nesne yap.
• Tanımla: lead’in hangi kanıtla müşteriye dönüştüğünü belirle.
• Kaydet: buying role ve hesap yetkisini fırsat/sipariş bağlamında tut.
• Sınırla: bayi tenant verisini başka hesaptan görünmez kıl.
• Doğrula: pasif contact’ın erişim ve iletişim akışından çıkarıldığını test et.
• Export et: model, özel alan ve ilişkileri makinece okunabilir biçimde prova et.

Kimlik ve duplicate

• Belirle: tek müşteri kimliği stratejisini internal ID üzerine kur.
• Kaydet: her kaynak external ID’sini tenant ve sistem adıyla eşle.
• Sınırla: e-posta veya telefonu tek başına otomatik merge anahtarı yapma.
• Normalize et: telefonu E.164 biçimine getir fakat sahiplik kanıtı sayma.
• Test et: ortak telefon ve aile e-postası senaryolarını negatif UAT’ye ekle.
• Doğrula: misafir siparişi yalnız doğrulanmış account claim ile bağla.
• Tanımla: deterministik ve probabilistik kuralları ayrı eşiklerle yönet.
• Kaydet: duplicate adayında sinyal, skor ve açıklanabilir nedeni tut.
• Ata: yüksek riskli merge için manuel onaylayıcı belirle.
• Sınırla: farklı tenant veya marka hesabını otomatik birleştirme.
• Kaydet: survivor ID, alias ve kaynak kayıt geçmişini merge audit’ine ekle.
• Test et: unmerge’in profil, activity, ticket ve audience etkisini geri aldığını kanıtla.
• İzle: false merge, missed merge ve inceleme kuyruğu yaşını ölç.
• Koruyun: silinen veya pasif ID’nin başka kişiye yeniden atanmasını engelle.
• Mutabıklaştır: identity mapping tablosunu kaynak sistemlerle periyodik karşılaştır.

Source of truth

• Belirle: her alan ve olay için yetkili kaynak matrisi oluştur.
• Ayır: CRM görünümü, snapshot, referans ve ana kayıt semantiğini yaz.
• Sınırla: CRM’in OMS sipariş durumuna kontrolsüz geri yazmasını engelle.
• Sınırla: ERP cari/fatura alanında çift yönlü sync loop oluşturma.
• Kaydet: alan yazma yönü, çatışma kuralı ve freshness SLO’sunu belirt.
• Göster: özet veride kaynak sistemi ve son güncelleme zamanını kullanıcıya sun.
• Test et: profil adresi değişince geçmiş sipariş snapshot’ının değişmediğini doğrula.
• Tanımla: son yazan kazanır yerine sürüm, owner ve manuel istisna kuralı kullan.
• İzle: yetkisiz alan yazımı ve drift için alarm üret.
• Onayla: source-of-truth değişikliğini tüketici etkisi ve rollback ile yönet.

Veri kalitesi/normalizasyon

• Ölç: doğruluk, tamlık, geçerlilik, tutarlılık, freshness ve uniqueness’ı ayır.
• Tanımla: profile completeness paydasını amaç ve uygulanabilirliğe göre kur.
• Normalize et: telefon, locale, timezone ve ülke kodlarını standartlaştır.
• Sınırla: e-posta local-part dönüşümünü sağlayıcıya özgü varsayımla yapma.
• Doğrula: zorunlu alan, tip, uzunluk ve enum kurallarını negatif test et.
• Karantinaya al: bozuk encoding, beklenmeyen alan ve şema drift’ini ayır.
• Kaydet: düzeltmenin kaynak, kullanıcı, önceki/sonraki değer ve gerekçesini tut.
• İzle: stale order/ticket özetini alan bazlı SLO ile alarm üret.
• Örnekle: gerçek doğruluğu kaynak kanıtı ve insan incelemesiyle ölç.
• Mutabıklaştır: kalite skorunu kural sürümü ve paydasıyla raporla.

Consent/IYS/preference

• Ayır: aydınlatma, açık rıza, ticari ileti onayı ve preference kayıtlarını modelle.
• Kaydet: consent için amaç, marka, kanal, metin sürümü, zaman ve kaynak tut.
• Doğrula: İYS hizmet sağlayıcı ve entegrasyon yetkisini güncel kapsamla kontrol et.
• Test et: IYS onayının CRM’e doğru kimlik ve zamanla işlendiğini kanıtla.
• Test et: İYS retinin CRM ve bütün aktivasyon kanallarına yayıldığını kanıtla.
• Sınırla: CRM preference’ını İYS’nin veya hukuki sebebin tamamı sayma.
• Uygula: suppression kontrolünü ileti gönderiminden önce zorunlu kapı yap.
• Ayır: işlemsel mesaj ile pazarlama içeriğini amaç ve içerikle değerlendir.
• Engelle: işlemsel etiketi taşıyan pazarlama mesajını negatif kuralla durdur.
• Tanımla: opt-in/opt-out event’leri için idempotency ve sıra kuralı yaz.
• İzle: ret propagation P50/P95/P99 ve mismatch oranını ölç.
• Mutabıklaştır: CRM, İYS, ESP, SMS ve WhatsApp durumlarını periyodik karşılaştır.
• Kaydet: consent istisnası için hukuk owner, dayanak ve süre tut.
• Sınırla: marka iznini başka marka veya amaca otomatik yayma.
• Test et: test ortamından gerçek ileti çıkışını teknik kill switch ile engelle.

KVKK ve saklama

• Envanterle: her veri işleme amacı, hukuki sebep ve alıcı grubunu kaydet.
• Sınırla: amaçsız TCKN, özel nitelikli veri ve hassas not toplamayı engelle.
• Ayır: pseudonymization ile geri döndürülemez anonymization kavramlarını uygula.
• Değerlendir: hash edilmiş identifier’ın yeniden ilişkilendirme riskini kaydet.
• Tanımla: veri kategorisi bazlı saklama, imha ve legal hold kuralı yaz.
• Doğrula: ilgili kişi talebinde kimlik doğrulama ve kapsam kontrolünü test et.
• Test et: erişim, düzeltme, silme ve export workflow’unu kanıtla.
• Kaydet: veri sorumlusu/veri işleyen ve alt işleyen sorumluluklarını DPA’ya ekle.
• Doğrula: yurt dışı aktarım mekanizmasını Kanun 9 ve güncel rehberle incele.
• Bildir: standart sözleşme sürecini imza ve beş iş günü kontrolüyle yönet.
• Test et: vendor exit’te export, backup purge ve silme belgesi almayı prova et.
• İzle: veri ihlali eskalasyonu, kanıt ve bildirim kararını tatbik et.

Sipariş/iade/kargo

• Ayır: order, line, package, shipment, return, refund ve invoice kimliklerini modelle.
• Kaydet: CRM özetinde kaynak ID, durum sürümü ve freshness zamanı göster.
• Sınırla: kart, CVV ve ödeme sağlayıcı sırrını payload’dan engelle.
• Aktar: yalnız gerekli ödeme referansı, maskeli özet ve durumu kullan.
• Test et: kısmi shipment ve kısmi refund’ın tam sipariş durumunu bozmadığını doğrula.
• Test et: out-of-order delivery olayını entity version ile yönet.
• Sınırla: marketplace müşteri verisini kanal şartı ve amaçla kullan.
• Bağla: invoice referansını ERP/e-belge ana kaydına read-only iliştir.
• Mutabıklaştır: order/refund sayısı ve kritik alanları günlük karşılaştır.
• İzle: stale sipariş özeti ve yanlış müşteri bağını owner kuyruğuna gönder.

Destek ve omnichannel

• Modelle: ticket/case için ID, owner, queue, priority, SLA ve status alanlarını tanımla.
• Bağla: ticket-order ilişkisini tenant ve kimlik kontrolüyle kur.
• Kaydet: e-posta, SMS, WhatsApp ve çağrı activity’sini kanal message ID ile tut.
• Tekilleştir: aynı conversation veya webhook tekrarını idempotent işle.
• Sınırla: temsilci notlarını şablon, amaç, erişim ve saklamayla yönet.
• Test et: yanlış müşterinin ticket veya siparişini agent’tan gizle.
• Tanımla: SLA start, pause, resume ve escalation kurallarını yaz.
• Göster: CRM sipariş özetinin son güncelleme zamanını temsilci ekranında belirt.
• Sınırla: ticket status sync’inde çift yönlü loop’u önle.
• Ölç: doğru bağlam kapsaması, stale oranı ve manuel refresh ihtiyacını izle.

Segmentasyon/otomasyon

• Tanımla: her segmentin koşul, dönem, veri kaynağı ve sürümünü kaydet.
• Ayır: RFM, CLV, churn ve lead score’u muhasebe gerçeği sayma.
• Kaydet: skor model/sürüm, varsayım ve hesap zamanını görünür kıl.
• Uygula: journey tetikleyici, koşul, bekleme, eylem ve sonucu açıkça tanımla.
• Sınırla: frequency cap’i marka, kanal ve dönem bazında uygula.
• Tanımla: çakışan journey’ler için öncelik ve collision kuralı yaz.
• Uygula: consent ve suppression’ı her activation öncesi yeniden kontrol et.
• Test et: satın alma sonrası sepet otomasyonunun durduğunu doğrula.
• Test et: opt-out sonrası audience removal read-back sonucunu al.
• Ölç: otomasyon hatasını satış garantisinden ayrı operasyon KPI’ıyla izle.

API/webhook/event

• Belgele: API’yi güncel OpenAPI sözleşmesiyle sürümle.
• Belgele: event ve webhook’u AsyncAPI veya eşdeğer sözleşmeyle tanımla.
• Kaydet: event ID, entity ID/version, schema version ve correlation ID taşı.
• Ayır: occurred-at ve received-at zamanlarını farklı alanlarda tut.
• Uygula: idempotency key kapsamı ve saklama penceresini yaz.
• Test et: aynı key ve farklı payload’ı çatışma olarak alarm üret.
• İmzala: webhook’u HMAC veya uygun mesaj imzasıyla doğrula.
• Engelle: timestamp ve nonce ile replay saldırısını sınırla.
• Sınırla: OAuth scope’larını akış ve tenant bazında daralt.
• Uygula: kısa ömürlü token, rotasyon ve revocation yeteneği kur.
• Test et: expired ve revoked token’ın erişemediğini doğrula.
• Belirle: rate limit, burst, pagination ve async job sınırlarını kaydet.
• Uygula: backpressure ile kampanya patlamasında bağımlı sistemi koru.
• Test et: schema deprecation ve consumer contract uyumluluğunu doğrula.
• Karantinaya al: bilinmeyen şema veya tenant olayını işleme dışı bırak.

Hata/retry/reconciliation

• Ayır: geçici timeout/429 ile kalıcı validation hatasını sınıflandır.
• Uygula: exponential backoff, jitter ve toplam retry bütçesi belirle.
• Engelle: kalıcı 4xx hatasını sonsuz retry’a sokma.
• Uygula: circuit breaker ve kontrollü recovery half-open testi kur.
• İzle: DLQ count, age, owner ve severity alarmlarını aç.
• Sınırla: DLQ replay’i yetki, dry-run ve audit ile yap.
• Test et: timeout sonrası read-back ile belirsiz sonucu çöz.
• Mutabıklaştır: kaynak-hedef kayıt sayısını aynı watermark ile karşılaştır.
• Mutabıklaştır: kritik alanları aynı entity version ve scope ile kıyasla.
• Kaydet: mismatch kök neden, owner, düzeltme ve kapanış kanıtı tut.
• Test et: CRM ve e-ticaret kesintisinde kuyruk ile kayıp olmadığını kanıtla.
• Ölç: first-time-right, retry rate, DLQ age ve mismatch oranını raporla.

Güvenlik ve yetki

• Uygula: SSO ve yüksek riskli roller için MFA zorunluluğu kur.
• Ayır: OAuth yetkilendirme ile OIDC kimlik doğrulamasını doğru kullan.
• Sınırla: RBAC/ABAC’yi rol, ekip, account, tenant ve amaçla uygula.
• Sınırla: field-level security ile hassas alanı yetkisiz rolden gizle.
• Ayır: görüntüleme, merge, consent, admin ve bulk export yetkilerini böl.
• Engelle: paylaşımlı admin hesabı ve uzun ömürlü kişisel token kullanımını durdur.
• Sakla: API key ve secret’ları vault içinde yönet.
• Döndür: secret ve sertifikaları kesintisiz rotasyon provasıyla yenile.
• Maskele: PII, token ve secret’ı log ve destek kaydında gizle.
• Test et: tenant izolasyonunu çapraz erişim negatif senaryosuyla doğrula.
• İncele: vendor penetrasyon testi ve açık bulgu kapatma kanıtını al.
• Eşle: OWASP ASVS 5.0 ve API Security kontrollerini risk planına bağla.
• Uygula: DLP/şema kuralıyla kart, CVV, parola ve token ingest’ini engelle.
• İzle: yüksek hacimli export ve yetki değişikliğine alarm üret.
• Test et: ayrılan personel erişiminin tanımlı sürede kapandığını kanıtla.

Gözlemlenebilirlik

• Taşı: correlation ID’yi e-ticaretten CRM ve kanal sonucuna kadar koru.
• Kaydet: teknik ve iş hatasını sınıflandırılmış kodlarla logla.
• Ölç: API P50/P95/P99, throughput, rate limit ve queue age’i izle.
• Ölç: consent propagation, order freshness ve audience removal gecikmesini izle.
• İzle: duplicate, false merge, suppression ihlali ve stale summary olaylarını alarm üret.
• Bağla: log, metric ve trace verisini owner/runbook ile ilişkilendir.
• Sınırla: telemetry retention ve erişimini veri sınıfına göre ayarla.
• Test et: alert’in gerçek owner’a ulaştığını ve kapanış kanıtı ürettiğini doğrula.

AI

• Belirle: AI kullanım amacı ve izin verilen veri alanlarını yaz.
• Sınırla: modele gönderilen müşteri verisini minimizasyon ve redaction ile azalt.
• Doğrula: model, sağlayıcı, ülke, eğitimde kullanım ve retention şartını sözleşmeden al.
• Test et: ticket özeti doğruluğu ve hassas veri sızıntısını örneklemle ölç.
• Kaydet: model/sürüm, prompt bağlamı, çıktı ve insan kararını audit’e ekle.
• Engelle: AI skorunun tek başına olumsuz veya ayrımcı karar vermesini önle.
• Sağla: kullanıcı/temsilci için düzeltme, itiraz ve kapatma mekanizması kur.
• İzle: false positive, bias, override ve drift göstergelerini düzenli gözden geçir.

TCO ve sözleşme

• Hesapla: kullanıcı, contact, event, API, depolama ve ileti lisans metriğini doğrula.
• Ekle: sandbox, SSO, audit, SIEM, AI ve connector ücretlerini TCO’ya kat.
• Ekle: data cleansing, identity, migration, eğitim ve iç ekip zamanını hesapla.
• Senaryolaştır: 12 ve 36 aylık hacim, kur ve fiyat artışını ayrı göster.
• Ayır: standart ürün, partner eklentisi ve özel geliştirmeyi teklifte işaretle.
• Yaz: SLA, RTO/RPO, support hour ve incident notification şartlarını sözleşmeye ekle.
• Doğrula: hazır connector alan/yön/limit ve deprecation kapsamını ek yap.
• Test et: tam export’un başka ortamda okunabildiğini kanıtla.
• Belirle: exit desteği, ücret, süre, backup purge ve silme belgesini yaz.
• Onayla: vendor lock-in riskini özel workflow, ID, API ve partner bağımlılığıyla puanla.

PoC/UAT

• Tanımla: PoC hipotezi, kapsamı, veri seti ve kabul kriterini yaz.
• Kullan: gerçek müşteri yerine sentetik veya maskelenmiş temsili veri seç.
• Engelle: test ortamından gerçek ileti ve audience çıkışını kill switch ile durdur.
• Test et: guest link, shared contact, duplicate, merge ve unmerge akışını doğrula.
• Test et: consent create, IYS ret, suppression ve silme workflow’unu doğrula.
• Test et: webhook imza, replay, idempotency, out-of-order ve DLQ akışını doğrula.
• Test et: field security, tenant isolation ve bulk export negatif senaryolarını çalıştır.
• Ölç: temsili hacimde P95/P99 ve rate limit davranışını kaydet.
• Test et: full export, data deletion ve exit bütünlüğünü PoC’de sınamayı değerlendir.
• Kaydet: başarısız test için kök neden, owner, düzeltme ve yeniden test kanıtı tut.
• Engelle: kritik identity, consent, yetki ve ödeme veri testi geçmeden go-live yapma.
• Ayır: PoC başarısını üretim operasyon ve güvenlik hazırlığıyla karıştırma.

Migration/cutover

• Envanterle: profil, ilişki, activity, attachment, audit ve automation kapsamını çıkar.
• Profille: duplicate, boş alan, stale consent ve orphan relation oranını ölç.
• Eşle: immutable ID ve external ID crosswalk tablosunu oluştur.
• Temizle: duplicate adaylarını owner onayı olmadan merge etme.
• Taşı: consent metin sürümü, zaman, kaynak ve ret kanıtını koru.
• Prova et: tam migration’ı en az iki kez reconciliation ile çalıştır.
• Test et: activity ve attachment ilişkilerinin orphan kalmadığını doğrula.
• Planla: delta sync, watermark ve freeze penceresini yaz.
• Tanımla: cutover go/no-go yetkisi ve tüketici yön değişimini belirle.
• Hazırla: rollback snapshot, credential ve eski sistem yazma planını test et.
• İzle: hypercare alarm, owner ve kapanış SLA’sını kur.
• Sil: exit sonrası eski sistem verisini retention ve kanıt süreciyle yönet.

Eğitim ve işletim

• Eğit: satış, destek, marketing ve admin rollerine görev bazlı içerik ver.
• Öğret: consent, suppression, hassas not ve export risklerini örnekle göster.
• Belgele: identity merge, DLQ replay, privacy request ve incident runbook’larını yayımla.
• Test et: kullanıcıların yanlış merge ve güvenlik olayını doğru eskale ettiğini ölç.
• Ata: entegrasyon on-call ve vendor iletişim zincirini belirle.
• İzle: adoption yerine veri kalitesi ve süreç KPI’larını birlikte raporla.
• Gözden geçir: rol ve erişim yetkilerini periyodik yeniden onayla.
• Yenile: model, mevzuat ve vendor sürümü değiştikçe eğitim ve UAT’yi güncelle.

SoloCommerce kapsam kontrolü

• Doğrula: canlı paket sayfasındaki müşteri-sipariş görünümü ve bildirim kapsamını kaydet.
• Ayır: email/SMS bildirim desteğini tam CRM veya marketing automation sayma.
• Doğrula: WhatsApp’ın opsiyonel/pilot/teklif durumunu satın alma öncesi yazılı al.
• Sınırla: standart pakette dedicated CRM/CDP bulunduğunu kanıtsız iddia etme.
• Test et: gerçek customer/order akışıyla yerleşik ekranın ihtiyacı karşılayıp karşılamadığını ölç.
• Belirle: ayrı CRM fit-gap’inde identity, consent, B2B, ticket ve automation boşluklarını yaz.
• Doğrula: Enterprise özel entegrasyon ve SLA’yı teklif ekiyle sınırla.
• Ayır: SoloCommerce paket maliyeti ile ayrı CRM, migration ve connector TCO’sunu hesapla.

Toplam 238 uygulanabilir kontrol maddesi vardır. Kontroller model, mevzuat, kanal, vendor veya sürüm değiştiğinde yeniden değerlendirilmelidir.

PoC ve UAT test matrisi nasıl hazırlanmalıdır?

PoC kritik çözüm hipotezini, UAT ise iş kabulünü üretime yakın koşullarda doğrular. Aşağıdaki 119 test satırı sentetik veya maskelenmiş veriyle uyarlanmalıdır. Her satır ön koşul, adım, beklenen sonuç, veri/güvenlik kontrolü, kanıt, öncelik, owner ve sonuç alanı taşır. Kritik consent, silme, identity merge, yetki ve ödeme verisi testleri yüzde yüz geçmeden canlıya çıkılmamalıdır.

Toplam 119 özgün UAT satırı vardır. Rollback yalnız dokümanla değil testle; test ortamı ileti kilidi yalnız prosedürle değil teknik engelle; başarısız kritik test ise sözlü risk kabulüyle değil düzeltme ve yeniden test kanıtıyla kapatılmalıdır.

Sık yapılan CRM entegrasyonu hataları ve kırmızı bayraklar nelerdir?

Kırmızı bayraklar çoğunlukla ekran eksikliğinden değil, kimlik, consent, veri minimizasyonu, yetki, teslimat ve exit boşluğundan doğar. Aşağıdaki maddelerin her biri risk sahibi, düzeltme planı ve kabul kanıtı gerektirir. Kritik bir boşluk “sonra bakarız” diye üretime taşınırsa yanlış merge, izinsiz ileti veya veri sızıntısı çok sayıda kanal ve kullanıcıya hızla yayılabilir.

1. K01: CRM’i müşteri Excel’i veya yalnız kişi listesi sanmak.
2. K02: Her işletmeye ayrı CRM gerektiğini söylemek.
3. K03: CRM, CDP, ERP, OMS ve help desk’i eş anlamlı kullanmak.
4. K04: Tek ve immutable müşteri ID stratejisi belirlememek.
5. K05: E-posta adresini değişmez evrensel müşteri anahtarı saymak.
6. K06: Telefon numarasını sahiplik kanıtı kabul etmek.
7. K07: Misafir siparişi yalnız benzer e-postayla hesaba bağlamak.
8. K08: Paylaşılan telefon veya ortak kutuyu tek kişi sanmak.
9. K09: Probabilistik eşleşmeyi otomatik kesin merge’e çevirmek.
10. K10: Merge onayı ve audit kaydı tutmamak.
11. K11: Yanlış merge için unmerge mekanizması kurmamak.
12. K12: Merge geri alırken audience ve ticket etkisini düzeltmemek.
13. K13: Profil değişince geçmiş sipariş snapshot’ını değiştirmek.
14. K14: Her alanı bütün kaynaklardan CRM’e kopyalamak.
15. K15: CRM’i order veya fatura ana kayıt sistemi yapmak.
16. K16: ERP/OMS durumunu CRM’den kontrolsüz geri yazmak.
17. K17: Çift yönlü senkronizasyon döngüsü oluşturmak.
18. K18: Source-of-truth’u alan ve olay bazında tanımlamamak.
19. K19: Özet veride kaynak ve freshness zamanı göstermemek.
20. K20: Kart numarası veya CVV’yi CRM’e taşımak.
21. K21: Parola, oturum tokenı veya secret’ı payload’a eklemek.
22. K22: Gereksiz TCKN veya özel nitelikli veri toplamak.
23. K23: Serbest temsilci notuna hassas veya ayrımcı bilgi yazmak.
24. K24: Telefon biçim normalizasyonunu sahiplik doğrulaması sanmak.
25. K25: E-posta local-part’ını evrensel kuralla değiştirmek.
26. K26: Completeness skorunu doğruluk saymak.
27. K27: Consent, preference, İYS ve suppression’ı tek bayrak yapmak.
28. K28: Aydınlatma ile açık rızayı aynı metin/kayıt sanmak.
29. K29: Ticari ileti onayıyla KVKK işleme sebebini birleştirmek.
30. K30: İşlemsel etiketiyle pazarlama içeriği göndermek.
31. K31: Ret talebini yalnız CRM’de işaretlemek.
32. K32: İYS retini e-posta/SMS/WhatsApp ve audience’a yaymamak.
33. K33: Suppression listesini silme talebinde körlemesine yok etmek.
34. K34: Marka veya amaç iznini başka kapsama taşımak.
35. K35: İzin metni sürümü, zaman ve kaynağını saklamamak.
36. K36: Hash edilmiş e-postayı otomatik anonim veri saymak.
37. K37: Pseudonymization ile anonymization’ı karıştırmak.
38. K38: Yurt dışı aktarımı yalnız veri merkezi konumuyla çözmek.
39. K39: Vendor’ın “KVKK uyumlu” beyanını kanıtsız kabul etmek.
40. K40: Standart sözleşme tipini ve eklerini yanlış seçmek.
41. K41: Standart sözleşme bildirim sürecini takip etmemek.
42. K42: Alt işleyen ve sonraki aktarım listesini almamak.
43. K43: Pazaryeri müşteri verisini sınırsız yeniden kullanmak.
44. K44: Silme, retention ve legal hold kararını ownersız bırakmak.
45. K45: Gerçek zamanlı entegrasyonu her alan için zorunlu görmek.
46. K46: Webhook teslimini garanti edilmiş saymak.
47. K47: HTTP 200’ü iş başarısı kabul etmek.
48. K48: Idempotency olmadan timeout retry yapmak.
49. K49: Aynı idempotency anahtarında farklı payload’ı fark etmemek.
50. K50: Kalıcı validation hatasını sonsuz retry etmek.
51. K51: Backoff ve jitter olmadan rate limit’i zorlamak.
52. K52: Out-of-order event’i entity version olmadan işlemek.
53. K53: Schema versioning ve deprecation süresi olmaması.
54. K54: DLQ’yu ownersız arşive dönüştürmek.
55. K55: DLQ replay’i yetkisiz ve dry-run olmadan yapmak.
56. K56: Reconciliation yapmadan senkronu başarılı saymak.
57. K57: Accepted, processed ve activated durumlarını birleştirmek.
58. K58: API limit, pagination ve async job sınırını okumamak.
59. K59: Uzun ömürlü statik tokenı varsayılan güvenli yöntem saymak.
60. K60: OAuth 2.0 ile OIDC’yi aynı kavram sanmak.
61. K61: Aşırı geniş OAuth scope vermek.
62. K62: Secret’ı kod, URL, log veya destek biletinde saklamak.
63. K63: Webhook imzası ve replay koruması uygulamamak.
64. K64: Her çalışana admin veya bulk export yetkisi vermek.
65. K65: Field-level security kullanmamak.
66. K66: Tenant izolasyonunu negatif test etmemek.
67. K67: PII’ı debug loguna yazmak.
68. K68: Audit logu değiştirilebilir bırakmak.
69. K69: Yedek alıp restore tatbikatı yapmamak.
70. K70: RTO ve RPO’yu bileşen bazında tanımlamamak.
71. K71: Test ortamından gerçek SMS/e-posta/WhatsApp göndermek.
72. K72: PoC’de gereksiz gerçek müşteri verisi kullanmak.
73. K73: Sandbox olmadan canlı API’de deneme yapmak.
74. K74: Demo’yu PoC veya UAT kanıtı saymak.
75. K75: Migration öncesi duplicate ve stale consent temizlememek.
76. K76: Consent kanıtını migration dışında bırakmak.
77. K77: Activity, attachment ve ilişki geçmişini export edememek.
78. K78: Stable ID’leri migration sırasında değiştirmek.
79. K79: Delta sync ve freeze penceresi planlamamak.
80. K80: Big-bang cutover’ı tek seçenek saymak.
81. K81: Rollback’i yalnız dokümanda tutup test etmemek.
82. K82: Hypercare alarm ve owner planı kurmamak.
83. K83: Kullanıcı eğitimini ve role-based runbook’u atlamak.
84. K84: KPI baseline almadan fayda iddiası üretmek.
85. K85: Contact sayısı gibi vanity metric’i başarı saymak.
86. K86: CLV, churn veya lead score’u kesin gerçek kabul etmek.
87. K87: AI özetini kaynak konuşmayla karşılaştırmadan kullanmak.
88. K88: AI sağlayıcısına amaçsız müşteri verisi göndermek.
89. K89: AI eğitim, retention ve ülke şartını sormamak.
90. K90: AI skoruyla açıklamasız ayrımcı karar vermek.
91. K91: Journey collision ve frequency cap tasarlamamak.
92. K92: Retli müşteriyi reklam audience’ında tutmak.
93. K93: Satış veya memnuniyet artışını doğrudan CRM’e atfetmek.
94. K94: Yalnız lisans fiyatını karşılaştırmak.
95. K95: API, SSO, audit, sandbox ve export ek ücretini sormamak.
96. K96: Kullanıcı/contact/event limitini ve aşımı okumamak.
97. K97: Vendor lock-in ve exit export’unu sona bırakmak.
98. K98: Hazır konektörün alan, yön ve sürüm kapsamını test etmemek.
99. K99: SoloCommerce’te tam CRM’in standart dahil olduğunu varsaymak.
100. K100: Email/SMS bildirim desteğini dedicated CRM sanmak.
101. K101: WhatsApp’ı her pakette kesin dahil kabul etmek.
102. K102: Enterprise özel entegrasyonu sabit ve sınırsız kapsam saymak.
103. K103: CRM’in satış, dönüşüm, memnuniyet veya mevzuat uyumu garantisi verdiğini yazmak.

Toplam 103 farklı hata ve satın alma kırmızı bayrağı vardır. Her madde yok, kontrol altında, kabul edilmiş süreli risk veya bloke edici olarak sınıflandırılmalı; karar vendor sunumuna değil test ve sözleşme kanıtına bağlanmalıdır.

Sıkça Sorulan Sorular

E-ticaret CRM entegrasyonu nedir?

Customer Relationship Management (CRM), Türkçesiyle Müşteri İlişkileri Yönetimi; müşteri, kişi, şirket, etkileşim, destek ve satış sürecini tanımlı kimlik, sahiplik, izin, iş akışı ve ölçümle yönetme disiplinidir.

Müşteri kimliği nasıl eşleştirilir?

Müşteri kimliği, değişebilen e-posta veya telefonu evrensel anahtar sayarak çözülmemelidir. Internal immutable ID, kaynak external ID’leri, doğrulanmış hesap bağlantıları ve güvenli deterministik kurallar temel olmalıdır.

WhatsApp CRM entegrasyonu nasıl yapılır?

CRM maliyeti yalnız lisans değildir. Kullanıcı, contact, event, API, depolama, ileti, sandbox, SSO, audit, connector, iPaaS, veri temizleme, kimlik çözümleme, migration, güvenlik, yurt dışı aktarım hukuku, eğitim, destek, bakım ve exit birlikte hesaplanmalıdır.

CRM segmentasyonu nasıl yapılır?

Sağlayıcı seçimi demo veya “uyumluyuz” kutusuna indirgenmemelidir. Gerçek modele benzeyen sentetik/maskelemiş veriyle identity, consent, sipariş snapshot, ticket, webhook, retry, DLQ, güvenlik, export ve rollback test edilmelidir.

Uygulamaya Geçmeden Önce

E-ticaret CRM entegrasyonu doğru müşteriyi doğru kayıtla eşleştiren, profil ile işlem snapshot’ını ayıran, consent ve ret kanıtını bütün kanallarda tutarlı kılan, satış-destek ekiplerine güncel bağlam sağlayan ve otomasyon hatalarını görünür yapan bir işletim modelidir. Ayrı CRM gerekip gerekmediğini müşteri sayısıyla değil identity, izin, kanal, B2B, destek, güvenlik ve hata maliyetiyle değerlendirin.

Yerleşik müşteri-sipariş görünümü ihtiyacı karşılıyorsa gereksiz mimari yük eklemeyin. Ayrı CRM gerekiyorsa source-of-truth, minimizasyon, API güvenliği, migration, exit ve rollback’i teklif öncesinde kanıtlayın. Güncel bildirim kapasitesi ile özel entegrasyon seçeneklerini operasyon ve entegrasyon kapsamını karşılaştırarak değerlendirin; SoloCommerce’i kanıtsız biçimde dedicated CRM veya hazır her CRM konektörünü sunan ürün gibi konumlandırmayın.

Teknik güvenlik kontrol setini OWASP API Security Top 10 2023 ve OWASP ASVS 5.0.0 ile başlatabilirsiniz; bu kaynaklar mevzuat veya ürün güvenliği garantisi değil, doğrulanacak teknik gereksinimler için referanstır.