Türkiye'de müşteri deneyimi projelerinin teknik olarak kırıldığı yer kanal sayısı ya da NPS ölçümü değil; kişiselleştirme katmanının hukuki olarak kanal kanal kapılı olması. Bir müşteriye e-posta gönderme izniniz, aynı müşteriye SMS gönderme izniniz anlamına gelmiyor, ve bu ayrım veri modelinize yansımadıysa proje ilk şikâyette duruyor.
Aşağıdaki kurallar Ticari İletişim ve Ticari Elektronik İletiler Hakkında Yönetmelik'ten. Bir CX mimarisinde bunlar pazarlama kısıtı değil, doğrudan tablo tasarımı ve servis seviyesi gereksinimi.
Onay bir boolean değil, delil
Yönetmeliğin 7. maddesi onayın neyi içermesi gerektiğini sayıyor: alıcının ticari elektronik ileti gönderilmesini kabul ettiğine dair olumlu irade beyanı, adı soyadı ve elektronik iletişim adresi. Aynı maddenin onuncu fıkrası ise mimariyi belirleyen cümleyi taşıyor: onayın alındığına ilişkin ispat yükümlülüğü hizmet sağlayıcıya aittir. (bkz. Ticari İletişim ve Ticari Elektronik İletiler Hakkında Yönetmelik, md. 7/10)
İspat yükümlülüğü sizdeyse, marketing_opt_in = 1 gibi bir alan yeterli değil. Saklamanız gereken şey kararın kendisi değil, kararın nasıl verildiği: hangi kanaldan, hangi metin gösterilerek, hangi anda, hangi IP ve hangi oturumla.
Aynı maddede ikinci bir sınır var: hizmet sağlayıcı, onay vermesini sunduğu mal veya hizmetin temini için ön şart olarak ileri süremez. Yani kayıt formunda pazarlama onayı kutusunu zorunlu yapan akış baştan hatalı.
Minimum çalışan bir tablo şu şekilde kurulabilir (MySQL 8.0):
CREATE TABLE customer_consents (
id BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
customer_id BIGINT UNSIGNED NOT NULL,
channel ENUM('email','sms','call') NOT NULL,
address VARCHAR(255) NOT NULL, -- onayın verildiği adresin kendisi
state ENUM('granted','revoked') NOT NULL,
source VARCHAR(64) NOT NULL, -- web_form | cagri_merkezi | magaza | iys
consent_text TEXT NOT NULL, -- gösterilen metnin o günkü hâli
ip_address VARBINARY(16) NULL,
occurred_at DATETIME(3) NOT NULL,
created_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
KEY idx_lookup (customer_id, channel, occurred_at)
) ENGINE=InnoDB;Dikkat edilecek nokta, tablonun append-only olması. Onay kaydını güncellemeyin, yeni satır yazın. Geçerli durum en son satırdır; ispat ise satırların tamamıdır.
Ret, yalnızca bildirildiği kanalı kapatır
Yönetmeliğin 9. maddesi kolayca yanlış okunan bir cümle içeriyor: alıcının ret bildiriminde bulunması, bildirimin yapıldığı iletişim kanalına ilişkin onayı geçersiz kılar (bkz. aynı Yönetmelik, md. 9). Yani müşteri SMS'teki ret linkine bastığında SMS onayı düşüyor, e-posta onayı düşmüyor.
Çoğu CRM kurulumunda bu ters uygulanıyor. Ya tek bir global "iletişime kapalı" bayrağı var (aşırı kısıtlayıcı, pazarlamayı gereksiz yere daraltıyor) ya da ret yalnızca gönderim listesinden çıkarma olarak işleniyor ve bir sonraki listede müşteri geri geliyor.
Yukarıdaki tabloda bu doğal olarak çözülüyor: ret, ilgili channel için state = 'revoked' satırıdır. Gönderim öncesi sorgu da kanal bazlı çalışır.
Üç iş günü bir SLA'dır, kampanya takvimi değil
Yönetmeliğin 10. maddesi net: hizmet sağlayıcı, ret talebinin kendisine ulaşmasını takip eden üç iş günü içinde alıcıya ticari elektronik ileti göndermeyi durdurur (bkz. aynı Yönetmelik, md. 10).
Bu cümleyi mühendislik gereksinimine çevirdiğinizde iki şey çıkıyor. Birincisi, ret bildirimi ile gönderim motoru arasındaki gecikme üç iş gününden kısa olmalı; nightly batch ile çalışan ve haftada bir senkronlanan bir yapı bu sınırı aşıyor. İkincisi, kampanya zamanlandığı anda değil gönderildiği anda onay kontrolü yapılmalı. Cuma günü kuyruğa alınıp pazartesi çıkan bir kampanya, cumartesi gelen ret bildirimini görmek zorunda.
Pratik kural: gönderim kuyruğundaki her mesaj, çıkmadan hemen önce kanal bazlı onay kontrolünden geçmeli. Kuyruğa alma anında yapılan kontrol, kuyruk süresi kadar eski bir bilgiyle çalışır.
Mesajın içine ne yazmak zorunda olduğunuzu şablon değil mevzuat belirliyor
8. madde içerik zorunluluklarını sayıyor: ticari elektronik iletinin başlığında veya içeriğinde tacirler için MERSİS numarası ve ticaret unvanı, esnaflar için adı soyadı ile T.C. kimlik numarası yer alır (bkz. aynı Yönetmelik, md. 8).
Pazarlama otomasyonu kurarken bu alan çoğunlukla şablon altbilgisine elle yazılıyor ve şirket unvanı değiştiğinde güncellenmeyi unutuyor. Doğrusu, kurum bilgisini şablondan değil yapılandırmadan beslemek ve her gönderim şablonunun bu alanı içerdiğini bir testle doğrulamak.
İYS: onay artık yalnızca sizde durmuyor
2020'den bu yana onayların merkezî bir sistemde de tutulması gerekiyor. İleti Yönetim Sistemi, 6563 sayılı Elektronik Ticaretin Düzenlenmesi Hakkında Kanun'da 28.11.2017 tarihinde yapılan değişiklikle alınan yetkiye dayanıyor; yönetmelik de 04.01.2020 tarihinde bu doğrultuda değiştirildi (bkz. T.C. Ticaret Bakanlığı, İleti Yönetim Sistemi sayfası).
Entegrasyon açısından bunun anlamı, onay verisinin artık iki yönlü senkronize edilmesi gereken bir kaynak olması. Kendi sisteminizde toplanan onaylar merkezî sisteme taşınıyor, merkezî sistemde kullanılan ret hakkı da size geri geliyor. Tek yönlü kurulan entegrasyonlar burada sessizce bozuluyor: kendi veritabanınız onaylı görünürken müşteri dışarıda ret vermiş oluyor.
Mimaride bunu ayrı bir source = 'iys' değeriyle işaretleyin. Bir uyuşmazlık çıktığında hangi kaydın nereden geldiğini bilmek, tüm kaydı yeniden üretmekten hızlı.
Onay gerektirmeyen mesajları ayırın
6. madde bir istisna tanımlıyor: alıcı kendisiyle iletişime geçilmesi amacıyla iletişim bilgilerini vermişse, temin edilen mal veya hizmetlere ilişkin değişiklik, kullanım ve bakıma yönelik iletiler için ayrıca onay alınmıyor. Devam eden abonelik, üyelik veya ortaklık durumu için de ayrı bir fıkra var (bkz. aynı Yönetmelik, md. 6).
Bu, sipariş durumu, teslimat bildirimi, randevu hatırlatması gibi işlemsel mesajların pazarlama onayına bağlanmaması gerektiği anlamına geliyor. Uygulamada iki hata da yaygın: işlemsel mesajları pazarlama onayına bağlayıp müşteriye kargo bildirimi göndermemek, ya da pazarlama mesajını işlemsel şablon içine gizlemek.
Çözüm teknik ve basit: mesaj tipini gönderim katmanında ayrı bir alan olarak taşıyın ve onay kontrolünü yalnızca ticari tipte çalıştırın. Aynı şablon motorunda iki sınıf, iki farklı kontrol yolu.
Veri talebi akışı bir CX özelliği değil, otuz günlük kanuni yükümlülük
CX yol haritalarında "self servis" başlığı çoğunlukla SSS sayfası olarak yorumlanıyor. Bu başlığın Türkiye'de bağlayıcı bir yüzü var: 6698 sayılı Kanun'un 13. maddesine göre veri sorumlusu, başvurudaki talepleri talebin niteliğine göre en kısa sürede ve en geç otuz gün içinde ücretsiz sonuçlandırmak zorunda. Talep ya kabul edilir ya gerekçesi açıklanarak reddedilir; cevap yazılı olarak veya elektronik ortamda bildirilir (bkz. 6698 sayılı Kişisel Verilerin Korunması Kanunu, md. 13).
Süre kaçarsa devreye md. 14 giriyor: başvurunun reddedilmesi, cevabın yetersiz bulunması veya süresinde cevap verilmemesi hâllerinde ilgili kişi, cevabı öğrendiği tarihten itibaren otuz ve her hâlde başvuru tarihinden itibaren altmış gün içinde Kurula şikâyette bulunabiliyor. Aynı maddenin ikinci fıkrası, başvuru yolu tüketilmeden şikâyete gidilemeyeceğini söylüyor. Süresinde yanıt vermek, şikâyeti önlemenin tek yolu.
Ürün tarafındaki karşılığı üç akış: "verilerimi indir", "hesabımı sil" ve "iletişim tercihlerim". Üçü de müşteri hesabının içinde çalıştığında otuz günlük süre bir operasyon sorunu olmaktan çıkıyor.
Önkoşul bir envanter: bir müşterinin verisi kaç sistemde duruyor ve hangi anahtarla eşleşiyor? Kayıt CRM'de e-posta, çağrı merkezinde telefon, e-ticarette müşteri numarası ile tutuluyorsa silme talebi tek sorguyla karşılanamaz. Envanteri çıkarmadan otuz günlük süreyi taahhüt etmeyin.
Ölçeceğiniz metrikler NPS değil
CX panolarında NPS ve CSAT var, ama bunlar sizin kontrol edebildiğiniz şeyler değil. Kontrol edebildiğiniz ve gerçekten riskli olan üç sayı şunlar:
- Kanal bazlı onay kapsamı. Kaç müşteride e-posta onayı var, kaçında SMS? İki sayı arasındaki fark, kampanya planınızın gerçek erişimini belirliyor.
- Ret-durdurma gecikmesi. Ret bildiriminin gelmesi ile o müşteriye son mesajın gitmesi arasındaki süre. Üç iş gününü aşan her vaka bir uyumsuzluk kaydı.
- Kuyrukta yakalanan ret sayısı. Gönderim anında yapılan kontrolün kaç mesajı durdurduğu. Bu sayı sıfırsa kontrol muhtemelen yanlış yerde çalışıyor.
Üçüncüsü en çok şey söyleyen metrik. Sıfır olması sistemin temiz olduğu anlamına gelmiyor; kontrolün kuyruğa alma anında yapıldığı anlamına geliyor.
Sırada ne var
Mevcut CRM'inizde tek bir sorgu çalıştırın: aynı müşteri için e-posta ve SMS onaylarını ayrı ayrı döndürebiliyor musunuz? Cevap hayırsa kişiselleştirme projesine başlamadan önce yapılacak iş onay modelidir, segmentasyon değil. Bu sıra ters kurulduğunda proje teknik olarak çalışıp hukuken durur.
Müşteri verisi tarafındaki kurulum için CRM kurulum ve entegrasyon yazısına, veri güvenliği tarafı için veri ihlali yazısına bakabilirsiniz. Kendi onay modelinizi gözden geçirmek isterseniz iletişim sayfası üzerinden yazın.
Mevzuat alıntıları, Ticari İletişim ve Ticari Elektronik İletiler Hakkında Yönetmelik'in 15.07.2015 tarihli Resmî Gazete metninden 25 Eylül 2026'da doğrulanmıştır (md. 6, 7, 8, 9, 10, 13). Yönetmelik sonradan değiştirilmiştir; kayıt saklama süresi gibi sayısal değerler için güncel mevzuat metnine bakın. İYS'nin dayanağı T.C. Ticaret Bakanlığı'nın İleti Yönetim Sistemi sayfasından doğrulanmıştır. Otuz günlük yanıt süresi ve şikâyet yolu, 6698 sayılı Kişisel Verilerin Korunması Kanunu'nun resmî metninden (md. 13 ve md. 14) doğrulanmıştır. Bu yazı hukuki görüş değildir.
