Herkes kaç kişi taşındığını sayar. Kimse hangi kişinin hangi izinle listede olduğunu, o müşterinin nereden geldiğini ve iki yıl önce ne konuşulduğunu saymaz. Göç bittiğinde tablo dolu görünür — ama karar vermeye yarayan kısmı gitmiştir.
Veri göçü bir kopyalama işi gibi görünür: dışa aktar, eşleştir, içe aktar, sayıları karşılaştır. Sayılar tutar. Kaybolan şey sayılabilir bir şey olmadığı için raporda görünmez.
Onayın ne zaman, hangi kanaldan ve hangi kapsamda alındığı bilgisi çoğu göçte "abone: evet" kutucuğuna indirgeniyor. Ret kayıtları daha da kötü durumda: eski sistemde çıkmış birinin reddi taşınmadığında, o kişi yeni sistemde temiz bir kayıt olarak yeniden listeye giriyor.
Kiminle ne zaman ne konuşulduğu, hangi teklifin neden düştüğü, kimin karar verici olduğu. Bunlar not alanlarında ve e-posta eşleşmelerinde duruyor; standart alan olmadıkları için eşleştirme haritasına girmiyor ve ilk taşımada düşüyorlar.
Müşterinin nereden geldiği bilgisi tek bir alanda değil: not, etiket, kampanya adı, UTM parçaları, form adı. Göçten sonra "hangi kanal müşteri getiriyor" sorusu geçmiş için cevapsız kalıyor — ve bütçe kararı dayanağını kaybediyor.
Eski sistemdeki listeler çoğu zaman bir kurala göre değil, yıllar içinde elle oluşmuş. Kuralı kimse yazmamış. Liste taşınıyor, kural taşınmıyor; yeni sistemde aynı segmenti yeniden üretmek imkânsız hale geliyor.
CRM değişimi çoğu firmanın veri yığınına yıllar sonra ilk kez baktığı an. Mevzuat açısından bu bir fırsat: taşımadan önce elenmeyen veri, yükümlülüğüyle birlikte yeni sisteme geçiyor.
KVKK m.4/2, kişisel verilerin işlendikleri amaçla bağlantılı, sınırlı ve ölçülü olmasını; ilgili mevzuatta öngörülen ya da amaç için gerekli olan süre kadar muhafaza edilmesini istiyor. "Ne olur ne olmaz" diye taşınan on yıllık kayıt bu ilkeyle karşı karşıya kalır.
KVKK m.7 uyarınca işlenmesini gerektiren sebepler ortadan kalktığında kişisel veriler resen veya ilgili kişinin talebi üzerine silinir, yok edilir ya da anonim hale getirilir. "Resen" kelimesi kritik: kimse talep etmese de yükümlülük duruyor. Göç, bu temizliğin doğal takvimi.
Ticari İletişim Yönetmeliği m.13/2 uyarınca onay kayıtları onayın geçerliliğinin sona erdiği tarihten, diğer kayıtlar ise kayıt tarihinden itibaren üç yıl saklanıyor. Ticari elektronik iletide ispat yükü hizmet sağlayıcıda; taşınmayan izin kaydı, ispat edilemeyen izin demek.
Hangi alan gerçekten kullanılıyor, hangi liste hangi kurala dayanıyor, izin ve ret kaydı nerede duruyor. Çoğu firmada bu döküm ilk kez burada çıkıyor.
Taşınmayacaklar yazılı olarak belirlenir ve gerekçesi kaydedilir. Kişisel veri içeren kalemlerde karar, saklama süresi ve işleme amacı üzerinden verilir.
Önce küçük bir örneklem, sonra tamamı. Doğrulama sayı karşılaştırmasıyla bitmez: izin durumu, kaynak alanı ve son temas tarihi tek tek örneklenerek kontrol edilir.
Tek bir geçiş tarihi ilan edilir, eski sistem yazmaya kapatılır. Paralel çalışan iki CRM, iki ayrı gerçek üretir; ekip hangisine yazacağını bilemez.
Hayır, ve bu sadece bir düzen sorusu değil. KVKK m.4/2 kişisel verilerin işlendikleri amaçla bağlantılı, sınırlı ve ölçülü olmasını ve ilgili mevzuatta öngörülen ya da amaç için gerekli olan süre kadar muhafaza edilmesini istiyor. İşleme sebebi ortadan kalkmış veriyi yeni sisteme kopyalamak, yükümlülüğü de kopyalamak demek. Göç, temizlik için doğal bir fırsat.
Listeniz duruyor ama onu kullanma hakkınızı ispat edemiyorsunuz. Ticari elektronik iletide ispat yükü hizmet sağlayıcıda. Onayın ne zaman, hangi kanaldan ve hangi kapsamda alındığı kaydı yeni sisteme gelmediyse, pratikte o kayıt için yeniden onay almak gerekir. Ret kayıtları daha da kritik: taşınmayan bir ret, reddetmiş kişiye yeniden ileti göndermek demektir.
İYS'deki kayıt merkezi olarak durur; ama CRM'iniz hangi kişinin hangi izinle hangi listede olduğunu bilmiyorsa günlük işleyişte bir faydası olmaz. İki tarafı eşitlemek gerekiyor. Ayrıca İYS dışında alınan onayların üç iş günü içinde İYS'ye kaydedilmesi gerekiyor; göç sırasında bu akışın kesilmemesi lazım.
Çünkü çoğu CRM'de kaynak, standart bir alan değil; not, etiket, kampanya adı ve UTM parçalarına dağılmış durumda. Göçte bu alanlar eşleşmediği için sessizce düşüyor. Sonuç: yeni sistemde "hangi kanal müşteri getiriyor" sorusu taşınma tarihinden öncesi için cevapsız kalıyor ve bütçe kararı dayanaksız hale geliyor.
İki sistemi paralel çalıştırmak güvenli görünür ama iki ayrı gerçek üretir; ekip hangisine yazacağını bilemez. Doğru sıra: doğrulama biter, tek bir geçiş tarihi ilan edilir, eski sistem yazmaya kapatılır ve bir süre sadece okunur kalır. Sonrasında eski sistemdeki kişisel verinin akıbeti ayrı bir karar: KVKK m.7 uyarınca işleme sebebi kalkan veri resen silinir, yok edilir veya anonim hale getirilir.
Evet, iki başlık. Birincisi yurt dışına aktarım: KVKK'nın bu maddesi 2024'te değişti ve aktarımın hangi güvenceye dayandığının belirlenmesi gerekiyor. İkincisi veri işleyen ilişkisi: KVKK m.12/2 veri işleyeni veri güvenliğinden veri sorumlusuyla müştereken sorumlu tutuyor. Bu iki başlık avukatınızın alanı; biz sadece göç planını bu sorular cevaplanmadan başlatmayız.
Alıcı tacir veya esnafsa önceden onay gerekmiyor — ama üç yükümlülük yerine geliyor: ret hakkı, üç iş günü kuralı ve zorunlu ileti içeriği. Listeyi buna göre nasıl kurarsınız.
Rehberi okuyun →İrtibat bürosu, distribütörlük ve denkleştirme, İYS ve B2B e-posta. Mevzuat ile uygulamayı bir arada ele alan, kaynağı belirtilmiş rehberler.
Kaynaklara gidin →15 dakikalık ücretsiz bir görüşmeyle başlayalım; mevcut sisteminizde neyin taşınmaya değer olduğunu ve göçün hangi sırayla yürümesi gerektiğini söyleyelim.
Ücretsiz Görüşme Alınveya hemen arayın: +90 551 372 31 02