Excel'den CRM'e Geçiş: KOBİ İçin Adım Adım Göç Planı ve Excel'de Kalmanın Gerçek Maliyeti

Bir işletmenin müşteri listesi neredeyse hep aynı yerde başlar: bir Excel dosyası. İlk on müşteride bu yeterlidir, hatta doğrusudur. Sorun dosyanın büyümesiyle değil, dosyanın çoğalmasıyla başlar. Bir gün masaüstünde "musteriler.xlsx" ile "musteriler_son_guncel_v3_SON.xlsx" yan yana durur, ikisinde de aynı kişinin farklı telefon numarası vardır ve hangisinin doğru olduğunu kimse bilmez.

Bu yazı tam o noktaya gelmiş bir küçük ya da orta ölçekli işletme için yazıldı. İçinde "CRM kullanın" tavsiyesi yok. İçinde elinizdeki dosyayı açıp uygulayabileceğiniz bir göç planı var: kolon eşleme tablosu, telefon numarası normalizasyon kuralları, TCKN ile VKN'yi ayırma yöntemi, Türkçe karakterlerin CSV'de neden bozulduğu ve nasıl düzeltileceği, mükerrer kayıt birleştirme kuralları, tarih biçimi tuzağı, KVKK tarafında ne yapmanız gerektiği ve 30 günlük bir takvim.

Bir de baştan dürüst bir şey söyleyeyim: bu yazıyı okuyanların bir kısmının CRM'e geçmemesi gerekiyor. Hangi kısmının, ilk bölümde.

Önce dürüst olalım: Excel'in gerçekten iyi olduğu yer

Excel'i savunmayan bir CRM göç rehberi güvenilmezdir, çünkü Excel'in neden bu kadar yaygın olduğunu açıklayamaz. Excel yaygın, çünkü iyi. Kurulum gerektirmez, kimseden izin istemez, şeması yoktur, kolon eklemek için kimseye sormazsınız, formül yazarsınız ve o anda cevabı görürsünüz. Hiçbir CRM bu üç şeyi Excel kadar hızlı yapamaz.

50 müşterisi olan işletmenin CRM'e ihtiyacı yok

Tek kişilik bir danışmanlık, ayda on beş teklif veren bir imalatçı, elli aktif müşterisi olan bir servis atölyesi: bunların hiçbirinin CRM'e ihtiyacı yok. Bu işletmelerde "kim hangi müşteriyle konuştu" sorusunun cevabı zaten bir kişide, o kişinin kafasında duruyor. CRM'in çözdüğü asıl sorun kayıt tutmak değil, kaydı birden fazla insan arasında paylaştırmak. Paylaşacak insan yoksa çözülecek sorun da yok.

Somut bir eşik vermek gerekirse, göç kararını üç sorunun cevabına bakarak verin. Müşteriyle konuşan kişi sayısı ikiden fazla mı? Aynı müşteriye iki farklı kanaldan (telefon, WhatsApp, e-posta, Instagram) ulaşılıyor mu? Birinin izne çıktığı hafta o kişinin müşterileri gerçekten takip edilebiliyor mu? Üç sorudan ikisine "hayır" diyorsanız Excel'de kalın ve bu yazıyı altı ay sonra tekrar açın.

Excel'in tek başına yendiği üç iş

Birincisi keşif: elinizde ne olduğunu bilmediğiniz bir veriyi anlamak için Excel hâlâ en hızlı araç. Bu yazının üçte biri zaten dosyayı Excel'de gezmekle ilgili. İkincisi tek seferlik hesap: "bu çeyrek hangi ilden kaç sipariş geldi" sorusunu bir kere sormak için rapor ekranı beklemek anlamsız, pivot tablo otuz saniyede cevap verir.

Üçüncüsü aktarım biçimi olarak Excel. Muhasebeciniz, kargo firmanız, bayiniz size veriyi Excel gönderecek ve siz de onlara Excel göndereceksiniz. CRM'e geçmek Excel'i hayatınızdan çıkarmaz, Excel'i tek gerçek kaynak olmaktan çıkarır. Fark burada.

Excel'in gerçek sınırı sandığınız yerde değil

"Excel'in satır sınırına dayandık" cümlesini çok duyarsınız ama pratikte doğru değil. Microsoft'un Excel teknik özellikler ve sınırlar belgesine göre bir sayfa 1.048.576 satır ve 16.384 sütun taşıyabilir, bir hücreye 32.767 karakter sığar. Müşteri listesi bu sınıra dayanan bir KOBİ neredeyse yok.

Excel'in gerçek sınırı üç başka yerde:

• Sayı gibi görünen alanların bozulması. Burada iki ayrı arıza var ve karıştırılıyor. Birincisi baştaki sıfırın kaybı: Excel "0532..." değerini sayı sayar ve sıfırı atar, telefon numarası da vergi kimlik numarası da bu yüzden bozulur. İkincisi hassasiyet: Microsoft'un baştaki sıfırlar ve büyük sayılar belgesine göre Excel en fazla 15 anlamlı basamak taşır, 16 ve daha fazla basamaklı bir sayıda 15. basamaktan sonrası sıfıra yuvarlanır. Bu ikincisi 10 haneli bir telefonu değil, IBAN ve kart numarası gibi uzun dizeleri vurur. İkisinin de çözümü aynı: bu alanları metin olarak tutun.
• Eşzamanlılık. Paylaşılan çalışma kitabında aynı anda en fazla 256 kullanıcı olabilir ama asıl sorun sayı değil, çakışma. İki kişi aynı satırı aynı anda düzenlediğinde "hangi değer kazandı" sorusunun kayıtlı bir cevabı yoktur.
• Denetlenebilirlik. Bir hücrenin ne zaman, kim tarafından, hangi değerden hangi değere çevrildiğini Excel size söylemez. CRM'in Excel karşısındaki asıl üstünlüğü rapor ekranı değil, işte bu kayıt.

Elektronik tablo hatalarının ne kadar yaygın olduğu üzerine yapılmış en çok atıf alan derlemelerden biri Raymond Panko'nun "Spreadsheet Errors: What We Know. What We Think We Can Do" çalışması. Özetin ilk cümlesi şöyle: "Fifteen years of research studies have concluded unanimously that spreadsheet errors are both common and non-trivial", yani on beş yıllık araştırmalar oybirliğiyle şu sonuca varmış: elektronik tablo hataları hem yaygın hem de önemsiz değil. Bu çalışma Türkiye verisi değil ve yıllar öncesine ait, o yüzden buradan bir oran alıp size sunmayacağım. Ama yönü net: elle doldurulan bir tabloda hata istisna değil, kural.

Kırılma noktaları: dosyanın artık taşımadığı an

Göç kararı genelde tek bir olayla verilmez. Altı yedi küçük olay birikir ve bir gün biri "böyle olmuyor" der. Aşağıdakiler o olayların en sık görülenleri. Kaçının size tanıdık geldiğini işaretleyin.

Aynı dosyanın iki kopyası

En sık başlangıç bu. Biri dosyayı e-postayla gönderir, karşı taraf indirir, üzerinde çalışır, geri gönderir. Bu arada gönderen kişi kendi kopyasında da değişiklik yapmıştır. Artık iki dosya var ve ikisi de eksik. Bunu birleştirmenin otomatik yolu yok, çünkü "hangi satır daha yeni" sorusunun cevabı dosyada yazmıyor.

Bulut üzerinde ortak düzenleme bu sorunun bir kısmını çözer, hepsini değil. Ortak düzenlemede de biri filtreyi açık bırakıp yanlış satırı siler, biri sıralamayı değiştirip yan sütunları kaydırır. Fark şu: Excel'de bir satır bir kayıt değil, sadece bir satır. Sütunlar arasındaki bağı koruyan bir kural yok.

"son_guncel_v3_SON.xlsx"

Dosya adına sürüm yazmak, aslında bir veritabanı özelliğini elle taklit etme çabasıdır ve insanlar bunu yaparken haksız değil: bir yerde "bu güncel" demek gerekiyor. Ama bu isimlendirme iki hafta içinde anlamını yitirir, çünkü "SON" olduğunu iddia eden üç dosya olur ve dosya tarihleri de yanıltıcıdır; açıp kapatmak bile değiştirme tarihini oynatabilir.

Kimin hangi müşteriyle konuştuğu bilinmiyor

Excel'de "Sorumlu" diye bir kolon açabilirsiniz ve açarsınız. Sorun şu ki bu kolon niyeti yazar, olanı değil. Sorumlu kolonunda "Mehmet" yazan bir müşteriyi Ayşe aramış olabilir, dosyada bunun izi yoktur. İki hafta sonra müşteri "geçen konuştuğumuz gibi" diye bir cümle kurduğunda kimse neyi kastettiğini bilemez.

Bu, işletmenin dışarıya en görünen zaafı. Müşteri sizi tek bir kurum olarak görür; sizin içeride kaç dosyanız olduğu onu ilgilendirmez.

Telefon değişti, eski kayıt kaldı

Müşteri numarasını değiştirir, size yeni numaradan yazar, siz de rehbere yeni numarayı eklersiniz. Excel'deki eski numara silinmez, çünkü silmeyi kimse üstlenmez. Altı ay sonra listeye toplu bir bilgilendirme geçtiğinizde eski numaraya da gider. O numara artık başka birine tahsis edilmiş olabilir. Bu sadece verimsizlik değil, bir veri koruma sorunu: yanlış kişiye o kişiyle ilgisi olmayan bir ticari ileti gitmiş olur.

Dosyayı tutan kişi işten ayrıldı

Klasik senaryo: dosya bir kişinin bilgisayarında, o kişinin OneDrive ya da Drive hesabında duruyor. Kişi ayrılıyor, hesabı kapatılıyor, dosyanın en güncel hâli kayboluyor. Elinizde kalan, üç ay önce birinin e-postayla gönderdiği kopya. Bunu yaşamış bir işletmenin göç kararı vermesi genelde bir hafta sürüyor.

Mesaj geçmişi WhatsApp'ta, kayıt Excel'de

Türkiye'de bu, listenin en önemli maddesi. TÜİK'in 2026 Hanehalkı Bilişim Teknolojileri Kullanım Araştırması'na göre 16-74 yaş arası bireylerin %90,0'ı WhatsApp kullanıyor; rakamın ayrıntısı ve kırılımı için TÜİK verileriyle hazırladığımız Türkiye tablosuna bakabilirsiniz. Yani müşteriniz sizinle büyük olasılıkla mesajlaşıyor, e-postalaşmıyor. Konuşmanın kendisi bir uygulamada, kaydın özeti başka bir dosyada duruyor ve ikisi arasında hiçbir bağ yok.

Sonuç: bir müşterinin geçmişini görmek için önce Excel'i açıp kim olduğunu bulmanız, sonra telefonu açıp konuşmayı bulmanız gerekir. Bu iki adım tek kişilik ekipte katlanılabilir, üç kişilik ekipte imkânsız. Bu boşluk, kanal bazlı maliyet ve dönüş hesabını da bozar; kanal kanal ne ödediğinizi görmek istiyorsanız kanal başına gerçek maliyet hesabına bakın.

KVKK envanterinde Excel nerede duruyor

Bu madde çoğu rehberde yok, olması gerekir. Kişisel veri işleme envanteri hazırlarken sorulan sorulardan biri "bu veri hangi ortamda tutuluyor" sorusudur. Cevap "Ahmet'in bilgisayarındaki bir Excel dosyası ve iki kişinin e-posta kutusundaki kopyaları" ise bu, envantere yazılabilir bir cevap değildir. Yazılabilir olmadığı için de çoğu işletme envanteri eksik doldurur.

Excel'de kalmak hukuka aykırı değildir, bunu net söyleyelim. Ama Excel'de kalırken veriye kimin eriştiğini, ne kadar süre saklandığını ve ne zaman silindiğini gösterebilmek zorundasınız. Dosya kopyalandıkça bu üç sorunun cevabı kaybolur.

Excel'de kalmanın maliyeti: varsayımları görünür bir hesap

İnternette dolaşan "CRM yatırımınızı şu kadar katına çıkarır" oranlarının neredeyse hiçbirinin kaynağı yok. Ben size oran vermeyeceğim. Bunun yerine bir hesap iskeleti kuracağım, kendi rakamlarınızı yerleştireceksiniz ve çıkan sayı sizin olacak. Aşağıdaki bütün varsayımlar açıkça yazılı, hiçbiri araştırma verisi değil, hepsi sizin değiştirmeniz için orada.

Modelin girdileri

Kurgu bir işletme kuralım ve açıkça kurgu olduğunu söyleyelim: üç kişilik bir satış ekibi, ayda 400 yeni talep alan, ortalama iş değeri 2.500 TL ve brüt kâr marjı %35 olan bir işletme.

Bu son üç satır, hesabın hassas noktası. "Hiç dönülmeyen talep oranı" ve "mükerrer kayıt oranı" bir tahmin değil, ölçülebilir iki sayı. Ölçmenin yolu aşağıda, veri temizliği bölümünde anlatılıyor: dosyayı normalize edip telefon numarasına göre saydığınızda mükerrer oranı otuz dakikada çıkıyor.

Üç kayıp kalemi

Birinci kalem, kaçan takip. Ayda 400 talebin %10'u yani 40 tanesi hiç dönülmemiş olsun. Bunlar takip edilseydi %12'si kapanacaktı: 4,8 iş. 4,8 × 2.500 TL = 12.000 TL ciro. Kâr etkisi 12.000 × %35 = 4.200 TL/ay.

İkinci kalem, mükerrer temas. 400 talebin %6'sı yani 24 tanesi listede iki kez duruyor ve iki temsilci ayrı ayrı ulaşıyor. Her mükerrer temas iki tarafta toplam 16 dakika yiyor (arama, konuşma, notu düzeltme). 24 × 16 = 384 dakika, yani 6,4 saat. 6,4 × 250 TL = 1.600 TL/ay. Buna müşteride bıraktığı izlenimin bedeli dahil değil, çünkü ölçülemez.

Üçüncü kalem, dosya arama. Üç kişi, günde 25 dakika, ayda 22 iş günü: 3 × 25 × 22 = 1.650 dakika, yani 27,5 saat. 27,5 × 250 TL = 6.875 TL/ay. Bu kalem çoğu işletmede en büyüğü ve en çok küçümseneni.

Toplam

Bu tablodaki hiçbir sayı ölçüm değil, hepsi yukarıdaki kurgu işletmenin varsayımlarından çıkan aritmetik. Tabloyu olduğu gibi alıp "Excel'de kalmak yılda 152.100 TL'ye mal oluyor" diye aktarmayın, çünkü öyle bir araştırma yok. Tablonun işi, dördüncü sütundaki varsayımları kendi rakamlarınızla değiştirdiğinizde sizin sayınızı vermek.

Aynı hesabı tek kişilik bir işletmede yapın: ayda 40 talep, mükerrer temas diye bir şey yok (çünkü tek kişi var), dosya arama günde 5 dakika. Toplam aylık kayıp 1.500 TL'nin altına iniyor ve bir CRM'in kurulum, aktarım ve alışma maliyetini karşılamıyor. İlk bölümdeki "elli müşteriniz varsa geçmeyin" tavsiyesi işte bu aritmetikten geliyor.

Modele koymadığım şey

Bilerek dışarıda bıraktığım bir kalem var: geç dönüşün dönüşüme etkisi. Türkçe içerikte "beş dakikada dönerseniz dönüşüm on kat artar" gibi bir cümle dolaşıyor. Bu cümlenin Türkiye'ye ait doğrulanabilir bir kaynağı yok, ABD kökenli eski çalışmaların kaynaksız çevirisi olarak yayılıyor. Ben kendi modelime kaynaksız çarpan koymam, siz de koymayın. Geç dönüşün size gerçekten neye mal olduğunu ölçmek istiyorsanız yolu şu: iki hafta boyunca gelen her talebin geliş saatini ve ilk dönüş saatini kaydedin, sonra kapanan işleri dönüş süresine göre gruplayın. Bu sizin veriniz olur ve kimsenin oranından daha değerlidir.

Türkiye genelinde tabloyu merak ediyorsanız: TÜİK'in 2025 Girişimlerde Bilişim Teknolojileri Kullanım Araştırması, 10 ve üzeri çalışanı olan girişimlerin yalnızca %12,0'ının CRM yazılımı kullandığını bildiriyor. Aynı araştırmada ERP kullanımı %28,3, ücretli bulut bilişim %20,4.

Adım 1 ve 2: envanter ve veri modeli

Buradan sonrası uygulama. On adımlık bir plan var ve sırası önemli, çünkü her adım bir öncekinin çıktısını kullanıyor. Adımı atlamak yerine küçültün.

Adım 1: mevcut dosyaların envanteri

İlk iş veriyi taşımak değil, veriyi bulmak. Şaşırtıcı gelebilir ama çoğu işletme kaç müşteri kaydı olduğunu bilmiyor, çünkü kayıtlar dört beş yerde duruyor. Bir sayfa açın ve şu tabloyu doldurun:

Bu tabloyu doldurduğunuzda üç şey ortaya çıkar. Birincisi, taşımanız gereken satır sayısı sandığınızdan az olur, çünkü aynı kişiler farklı listelerde tekrarlanıyordur. İkincisi, hangi dosyanın "ana kaynak" olduğuna karar vermek zorunda kalırsınız ve bu karar göçün en önemli kararıdır. Üçüncüsü, taşımayacağınız şeyleri de yazmış olursunuz; bu, sonradan "onu da taşıyalım" baskısını engeller.

Bir kural: ana kaynak tek olmalı. İki dosyayı birleştirerek ana kaynak yapmayın. Birini ana kaynak seçin, diğerini zenginleştirme dosyası olarak ikinci turda ekleyin. İki dosyayı aynı anda taşımak, mükerrer temizliğini göçün ortasında yapmak demektir ve orada yapılan temizlik hep eksik kalır.

Adım 2: veri modeli, yani kişi mi firma mı

Bu sorunun cevabı işinizin ne olduğuna göre değişir ve yanlış cevap altı ay sonra sizi ikinci bir göçe zorlar.

Doğrudan tüketiciye satıyorsanız (perakende, e-ticaret, kişisel hizmet) merkez kişidir. Bir kişi, bir kayıt. Firma alanı boş kalabilir. Fatura için gereken vergi bilgisi bir alan olarak kişinin üstünde durur.

İşletmeye satıyorsanız (toptan, hizmet, yazılım, ihracat) merkez firmadır ve kişiler firmaya bağlanır. "Ahmet Yılmaz" değil, "ABC Tekstil'de satın alma sorumlusu Ahmet Yılmaz" kaydını tutarsınız, çünkü Ahmet ayrılınca firma müşteriniz olmaya devam eder.

İkisini de yapıyorsanız ki Türkiye'de KOBİ'lerin çoğu ikisini de yapıyor, kişi merkezli kurun ve firmayı bir alan olarak tutun. Sebep pratik: kişi merkezli bir modeli sonradan firma merkezliye çevirmek, tersinden kolay. Bir de şu var: mesajlaşma kanalları kişiye bağlıdır. WhatsApp numarası firmanın değil, insanın.

Hangi alan zorunlu olmalı

Buradaki hata neredeyse evrensel: insanlar ilk gün çok fazla alanı zorunlu yapıyor, ekip veri giremiyor, üç hafta sonra herkes zorunlu alanlara nokta yazmaya başlıyor ve veri kalitesi Excel'dekinden kötü hâle geliyor.

Başlangıçta zorunlu alan sayısı ikiden fazla olmasın. Öneri: bir ad ve bir iletişim kimliği (telefon veya e-posta, ikisinden biri yeterli). Geri kalan her şey isteğe bağlı olarak başlasın. Altı hafta sonra hangi alanın gerçekten dolduğuna bakıp zorunlu listesini büyütürsünüz.

Özel alan neye gerek

Özel alan (standart CRM alanlarının dışında sizin tanımladığınız alan) açmadan önce şu testi uygulayın: bu alana göre filtreleyip bir iş yapacak mıyım? Cevap hayırsa o bilgi bir alan değil, bir nottur.

Örnek: "Sektör" alanı geçer, çünkü "tekstil sektöründeki müşterilere şu duyuruyu geçelim" diye bir iş var. "Referans veren kişi" alanı sınırda; not olarak da tutulabilir. "Müşterinin çocuğunun adı" alan değildir, nottur.

Türkiye'ye özgü olarak sık gereken özel alanlar şunlar: vergi dairesi, vergi numarası veya TCKN, ilçe, fatura unvanı, iletişim izni durumu ve izin tarihi. Bunların hiçbiri standart CRM alanı değildir ama Türkiye'de fatura kesen bir işletmenin hepsine ihtiyacı olur.

Adım 3: kolon eşleme tablosu

Bu, göçün en sıkıcı ve en belirleyici adımı. Yarım saat ayırırsanız sonraki üç günü kurtarır. Yapacağınız iş şu: Excel dosyanızın her sütununu tek tek elden geçirip karşısına CRM'de nereye gideceğini yazmak. Karar veremediğiniz sütunu "taşınmayacak" diye işaretleyin, sonra dönersiniz.

Son satır tartışma yaratıyor, o yüzden açayım. Ciro ve bakiye bilgisi ilk göçte taşınmamalı, çünkü o veri her gün değişiyor ve CRM'e bir kere kopyalandığı anda yanlış olmaya başlıyor. Bu bilgiyi ya muhasebe tarafıyla bir bağlantı üzerinden düzenli aktarırsınız ya da hiç taşımazsınız. Ön muhasebe defterini CRM içinde tutmayı düşünüyorsanız bu ayrı bir karar ve ön muhasebe modülünün nasıl kurulduğuna ayrıca bakmanız gerekir.

Eşleme tablosunu kim doldurmalı

Dosyayı en çok kullanan kişi. Yöneticinin doldurduğu eşleme tablosu hep eksik çıkıyor, çünkü sütunların bir kısmı kayıt dışı anlamlar taşıyor. "Not3" adlı bir sütun aslında "iade riski yüksek" demek olabilir ve bunu yalnızca dosyayı kullanan kişi bilir.

Adım 4: Türkiye'ye özgü veri temizliği

Bu bölüm yazının kalbi. Uluslararası CRM göç rehberlerinin hiçbirinde olmayan, Türkiye'de her dosyada karşınıza çıkacak sorunlar burada.

Telefon numarası normalizasyonu

Türkiye'de bir müşteri listesinde aynı numara en az beş farklı biçimde yazılmış olur. Bunları tek biçime indirmeden ne mükerrer kayıt bulabilirsiniz ne de mesaj gönderebilirsiniz.

Hedef biçim uluslararası standart olan E.164: artı işareti, ülke kodu, sonra numara, arada hiç boşluk ve ayraç olmadan. Türkiye için sonuç her zaman +90 ile başlayan 13 karakterlik bir dize olur.

Kuralı algoritma gibi yazalım, çünkü uygulayacaksınız:

1. Değerin başında artı işareti var mıydı, önce onu bir kenara not edin. Sonra rakam dışındaki her karakteri silin (boşluk, tire, parantez, nokta).
2. Kalan dize 00 ile başlıyorsa baştaki 00'ı atın; bu, artı işaretinin yazı hâlidir.
3. Kalan dize 90 ile başlıyor ve toplam 12 hane ise ülke kodu var demektir, başına + koyun.
4. Kalan dize 0 ile başlıyor ve 11 hane ise ulusal önek var demektir, sıfırı atın, başına +90 koyun.
5. Kalan dize 10 hane ise doğrudan başına +90 koyun.
6. Buraya kadar hiçbir kurala uymayan ama baştan artılı ya da 00 önekli gelen bir dize varsa bu bir yurt dışı numarasıdır. Ülke kodunu tahmin etmeye çalışmayın: başına + koyup olduğu gibi bırakın ve "yurt dışı" diye işaretleyin. Türkiye kuralları (mobil, il, ilçe) bu satırlara uygulanmaz.
7. Geriye kalan ve 10 haneden kısa olan her şey numara değildir. Silmeyin, "şüpheli" diye işaretleyip ayrı bir listeye alın.

İki nokta önemli. Birincisi, kuralları sırayla uygulayın ve ilk uyan kuralda durun; aynı dize birden fazla kuralın tarifine uyabilir. İkincisi, 2. adım dizeyi kısalttığı için hane sayısını her adımdan sonra yeniden sayın, baştaki sayıya göre karar vermeyin.

Bu kuralı elle yazmak yerine hazır bir kütüphane kullanmak istiyorsanız Google'ın libphonenumber kütüphanesi bu işin fiilî standardı ve Türkiye numara planını tanıyor. Excel içinde kalmak istiyorsanız yardımcı bir sütun açıp YERİNEKOY ve BİRLEŞTİR ile aynı sonucu üretebilirsiniz, sadece formülü yazdıktan sonra sütunu değere dönüştürmeyi unutmayın.

Sabit hat, mobil ve kurumsal numarayı ayırmak

Normalize etmek yetmez, numaranın türünü de bilmeniz gerekir, çünkü mesajlaşma kanalları yalnızca mobil numarada çalışır. Türkiye numaralandırma planında mobil numaralar operatöre tahsis edilmiş üç haneli 5XX kodlarıyla başlar; coğrafi sabit hatlar 2, 3 ve 4 ile başlayan alan kodlarını kullanır (İstanbul 212 ve 216, Ankara 312, Adana 322); 850 coğrafi olmayan, 800 ücretsiz aranan numaralardır; 444 ile başlayanlar ise alan kodu olmadan yedi haneyle aranan çağrı merkezi numaralarıdır. Kod dağılımının tamamı için Türkiye telefon numaraları listesine bakabilirsiniz.

Pratik kural: +90'dan sonraki ilk hane 5 ise mobil kabul edin, değilse "sabit" olarak işaretleyin. Sabit numaraları silmeyin, çünkü telefonla aramak hâlâ geçerli bir kanal. Sadece toplu mesaj listelerinden dışarıda bırakın.

Bir uyarı: numara taşıma yüzünden 5XX kodu size operatörü söylemez. Türkiye'de mobil numara taşınabilirliği 9 Kasım 2008'de başladı; o tarihten beri "532 ile başlıyorsa şu operatör" varsayımı geçersiz. Operatör bilgisine gerçekten ihtiyacınız varsa tek doğru kaynak taşınabilirlik veri tabanını sorgulayan bir servistir, numaranın kendisi değil.

TCKN ve VKN: 11 hane ile 10 haneyi ayırmak

Türkiye'de müşteri dosyalarının çoğunda "Vergi No / TC" diye tek bir sütun bulunur ve içinde ikisi karışık durur. Ayırmanın kuralı basit: 11 hane TCKN, 10 hane VKN. Ama iş bununla bitmiyor, çünkü Excel bu sütunu sayı olarak yorumladıysa baştaki sıfırlar silinmiş olabilir ve 10 haneli bir VKN 9 hane görünüyor olabilir. Önce sütunu metne çevirin, sonra hane sayın.

Hane sayısından sonra bir de matematiksel geçerlilik kontrolü yapabilirsiniz. TCKN'nin son iki hanesi ilk dokuz haneden türetilir:

• Numara 11 haneli olmalı ve ilk hane sıfır olamaz.
• 10. hane: 1, 3, 5, 7 ve 9. hanelerin toplamı 7 ile çarpılır, bundan 2, 4, 6 ve 8. hanelerin toplamı çıkarılır, sonucun 10'a bölümünden kalan alınır. Çıkarma sonucu eksi çıkabilir (örneğin tek haneler toplamı 1, çift haneler toplamı 36 ise sonuç eksi 29 olur). Bu durumda kalanı hesaplamadan önce sonuca 10'un katlarını ekleyip artıya taşıyın; formülü doğrudan koda geçirirseniz çoğu dilde eksi kalan döner ve geçerli numaraları hatalı sayarsınız.
• 11. hane: ilk 10 hanenin toplamının 10'a bölümünden kalandır.

Kuralı bir örnekle deneyin. Doğrulama örneklerinde kullanılan bilinen test numarası 10000000146 üzerinden gidelim: tek sıradaki hanelerin toplamı 2, çift sıradakilerin toplamı 0, yani 10. hane 2 çarpı 7 = 14'ün 10'a bölümünden kalan, yani 4. İlk on hanenin toplamı 6 olduğundan 11. hane de 6. İkisi de numaradaki hanelerle örtüşüyor, demek ki kural doğru işliyor.

VKN'nin de son hanesi bir kontrol hanesidir ve ilk dokuz haneden üretilir. Her iki kontrolün de ortak bir sınırı var, net söyleyeyim: bunlar sadece numaranın biçimsel olarak tutarlı olduğunu söyler, o numaranın gerçek bir kişiye veya kuruma ait olduğunu söylemez. Gerçekliğini yalnızca Nüfus ve Vatandaşlık İşleri ile Gelir İdaresi'nin doğrulama servisleri söyler.

Göç sırasında pratik yaklaşım: kontrol basamağı tutmayan kayıtları silmeyin, "doğrulanmadı" diye işaretleyin. Her dosyada tutmayan birkaç kayıt çıkar ve sebebi genelde kişinin yanlış numara vermesi değil, birinin Excel'de yanlış hücreye tıklamasıdır. Kaç tane çıktığı dosyaya göre değişir, bir oran vermeyeceğim; kendi dosyanızda sayarsınız.

Bir de veri koruma boyutu var, kısa keseyim ama atlamayın: TCKN kimlik verisidir. Gerçekten fatura kesmek veya sözleşme yapmak için gerekmiyorsa CRM'e hiç taşımayın. "İleride lazım olur" gerekçesiyle kimlik numarası biriktirmek, veri minimizasyonu ilkesine aykırıdır ve elinizde tutmanın hiçbir faydası yoktur.

İl ve ilçe adlarını standartlaştırmak

Bir Excel dosyasında İstanbul en az yedi biçimde yazılmış olur: "İstanbul", "Istanbul", "ISTANBUL", "istanbul", "İST", "Ist.", "34". Bunları tek biçime indirmezseniz "İstanbul'daki müşterilerime duyuru geçeyim" cümlesi hiçbir zaman doğru sonucu vermez.

Yöntem: sabit bir referans liste kullanın ve dosyadaki değerleri o listeye eşleyin. Türkiye'nin 81 ili için uluslararası bir kod standardı var: ISO 3166-2:TR. Kodlar TR-01 ile TR-81 arasında ve plaka koduyla aynı sırada ilerliyor (Adana TR-01, Ankara TR-06, İstanbul TR-34, İzmir TR-35). İl adını kodla birlikte tutmak, sonradan yazımı düzeltmenizi kolaylaştırır.

Eşleme yaparken üç kural işinizi görür. Karşılaştırmadan önce her iki tarafı da dilden bağımsız kurallarla küçük harfe indirip aksanları atın (i ve ı için i, ş için s, ç için c, ğ için g, ü için u, ö için o), böylece "Kütahya" ile "Kutahya" eşleşir. Plaka kodu yazılmışsa doğrudan koda çevirin. Eşleşmeyen değerleri silmeyin, listeye alıp elle bakın; genelde ilçe adı il sütununa yazılmış olur.

İlçe için hazır bir uluslararası standart yok ve ilçe listesi zamanla değişiyor (yeni ilçeler kuruluyor, bazıları büyükşehire bağlanıyor). Pratik çözüm: ilçeyi serbest metin olarak taşıyın ama il ile birlikte doğrulayın. "İstanbul / Çankaya" gibi bir kayıt varsa ikisinden biri yanlıştır.

Türkçe karakterlerin CSV'de bozulması

Bu, göçlerin en sık ve en can sıkıcı sorunu: dosyayı dışa aktarıyorsunuz, CRM'e yüklüyorsunuz ve isimler Ahmet Yılmaz ya da Þirket gibi çıkıyor.

Sebebi tek cümleyle: dosya UTF-8 kodlamayla yazılmış ama okuyan program onu Windows-1254 sanıyor, ya da tam tersi. UTF-8'de Türkçe karakterler iki bayt kaplar; bu iki bayt tek baytlık bir kodlamayla okunduğunda iki ayrı saçma karaktere bölünür. Bu bozulmanın adı mojibake ve imzası tanınabilir: Ã, Ä veya Å ile başlayan ikili gruplar görüyorsanız UTF-8 metin eski bir kodlamayla okunmuş demektir.

Excel'in bu işi zorlaştıran bir davranışı var: BOM adı verilen üç baytlık görünmez bir işaret dosyanın başında yoksa, Excel dosyayı açarken sistem kodlamasını varsayar. Microsoft'un UTF-8 CSV dosyalarını Excel'de doğru açma belgesi bunu açıkça söylüyor: BOM ile kaydedilmiş bir UTF-8 CSV dosyası normal şekilde açılır, BOM yoksa dosyayı çift tıklayarak açmak yerine içe aktarmanız gerekir.

Uygulanabilir çözüm sırası:

1. Dışa aktarırken: Excel'de "Farklı Kaydet" dediğinizde tür olarak "CSV UTF-8 (virgülle ayrılmış)" seçin. Sade "CSV (virgülle ayrılmış)" seçeneği sistem kodlamasını kullanır ve Türkçe karakterleri bozar.
2. İçe alırken: Dosyayı çift tıklamayın. Excel'de Veri sekmesinden Veri Al ve Metin/CSV'den yolunu izleyin, açılan pencerede "Dosya Kaynağı" alanından 65001: Unicode (UTF-8) seçin. Önizlemede Türkçe karakterleri doğru görene kadar yüklemeyin.
3. Bozulmuş dosyayı kurtarmak: Dosyayı Not Defteri veya Notepad++ ile açın, "Farklı Kaydet" deyip kodlamayı "UTF-8 (BOM ile)" seçin, tekrar deneyin.
4. Aktarmadan önce doğrulayın: Dosyada bir "ş", bir "ğ", bir "İ" ve bir "ı" içeren birer örnek kayıt bulun ve her adımdan sonra o dört kaydı gözle kontrol edin. Bu, yüz bin satırı gözden geçirmenin en ucuz alternatifi.

Ayırıcı sorunu: Türkçe Excel noktalı virgül yazar

CSV'nin adı "virgülle ayrılmış değerler" ama Türkçe Windows kurulumunda Excel'in ürettiği CSV dosyası noktalı virgülle ayrılır. Sebebi keyfi değil: Türkçe bölgesel ayarda ondalık ayırıcı virgüldür, dolayısıyla liste ayırıcısı noktalı virgül olur. Microsoft'un kendi liste ayırıcısı belgesinde bu açıkça yazıyor: "Excel, .csv dosyalarındaki sınırlayıcı için Windows liste ayırıcı karakterini kullandığından, Windows Bölgesi ayarlarında Liste ayırıcısının değiştirilmesi Virgülle ayrılmış değer (.csv) dosyasını açarken veya kaydederken kullanılan sınırlayıcıyı etkiler."

Sonuç: Türkiye'den çıkan bir CSV'yi virgül bekleyen bir sisteme yüklerseniz bütün satır tek sütunda görünür. İyi bir içe aktarma ekranı ayırıcıyı kendi tahmin eder ve size ne bulduğunu gösterir. Göstermiyorsa dosyayı bir metin düzenleyicide açıp ilk satıra bakın, hangi karakterle ayrıldığını gözle görürsünüz.

Bu arada, CSV'nin resmî bir tanımı var: RFC 4180. İçinde tırnak içine alma kuralları, satır sonu ve alan sayısı tutarlılığı tanımlanmış. Uygulamalar bu standarda tam uymuyor ama tırnak kuralını bilmek işinizi görür: bir alanın içinde ayırıcı karakter geçiyorsa o alan çift tırnak içine alınır, alanın içindeki çift tırnak da iki kez yazılarak kaçırılır. "Acme, Ltd. Şti." yazan bir firma adı tırnaksızsa satırınız iki sütuna bölünür.

Türkçe büyük ve küçük harf tuzağı

Bu, yazılımcıların bile düştüğü bir tuzak ve mükerrer kayıt temizliğinde doğrudan karşınıza çıkar. Türkçede noktalı ve noktasız olmak üzere iki ayrı i harfi, dolayısıyla dört biçim vardır: i, İ, ı, I. İngilizcede yalnızca i ve I var. Sonuç: "istanbul" kelimesini Türkçe kurallarla büyük harfe çevirirseniz "İSTANBUL", İngilizce kurallarla çevirirseniz "ISTANBUL" elde edersiniz. Tersi de geçerli: "ISTANBUL" Türkçe kurallarla küçültülürse "ıstanbul" olur, İngilizce kurallarla küçültülürse "istanbul".

Bu davranışın yazılım dünyasındaki adı noktalı ve noktasız i sorunu ve Java'dan PHP'ye, veritabanlarından işletim sistemlerine kadar birçok yerde belgelenmiş bir hata kaynağı.

Sizin için pratik sonucu şu: mükerrer kayıt ararken isimleri veya e-postaları küçük harfe çevirip karşılaştırıyorsanız, çeviriyi hangi dil kurallarıyla yaptığınıza dikkat edin. "[email protected]" ile "[email protected]" aynı adrestir; Türkçe kurallarla küçültülürse birincisi "ahmet@fırma.com" olur ve ikisi eşleşmez. E-posta ve kullanıcı adı gibi teknik alanları her zaman dilden bağımsız kurallarla küçültün. İnsan adlarını ve şehir adlarını Türkçe kurallarla düzeltin, çünkü orada doğru sonuç Türkçe olan.

Adım 5: mükerrer kayıt tespiti ve birleştirme

Mükerrer kayıt temizliği, göçün öncesinde yapılacak bir iştir. Sonrasında yapılırsa iki kayıt CRM'de ayrı ayrı yaşamaya başlar, her birine ayrı notlar düşülür ve birleştirme artık veri kaybı olmadan yapılamaz.

Eşleştirme anahtarları ve öncelik sırası

Mükerrer aramak, "hangi iki satır aynı kişiyi anlatıyor" sorusuna cevap aramaktır. Bu soruya birden fazla alan cevap verebilir ama hepsi eşit güvenilir değil. Güvenilirlik sırası şöyle:

Uygulama kuralı: yukarıdan aşağı sırayla eşleştirin, ilk eşleşen anahtar kazansın. E-postadan eşleşen iki satırı telefon farklı diye ayrı tutmayın; büyük olasılıkla kişi telefonunu değiştirmiştir. Tersi de doğru: telefondan eşleşen iki satır farklı e-posta taşıyorsa, muhtemelen kişinin iş ve kişisel adresi ayrı.

Excel'de bunu yapmanın en hızlı yolu: normalize telefon sütununu oluşturun, sonra o sütuna EĞERSAY uygulayın. Sonucu 1'den büyük olan her satır bir mükerrer adayıdır. Bu, mükerrer oranınızı ölçmenin de yolu ve maliyet hesabındaki o "%6" varsayımını gerçek bir sayıyla değiştirmenizi sağlar.

Birleştirme kuralı: hangi değer kazanır

İki satırı birleştirirken çakışan alanlar için önceden karar verin, satır satır düşünmeyin. Yoksa bin satırlık bir dosyada bin ayrı karar vermek zorunda kalırsınız.

• Boş olmayan dolu kazanır. Bir satırda firma yazıyor, diğerinde boşsa, dolu olan gider.
• İkisi de doluysa yeni tarihli kazanır. Bunun için "son güncelleme" bilgisine ihtiyacınız var; yoksa dosyadaki satır sırası genelde eskiden yeniye gider ve alttaki satır daha yenidir.
• Notlar birleşir, üzerine yazılmaz. İki notu alt alta ekleyin, birini seçmeyin. Kaybedilen not geri gelmez.
• Etiketler birleşir. İki kayıt farklı kaynaklardan geldiyse ikisinin de kaynağı korunur.
• İletişim izni bilgisinde en muhafazakâr değer kazanır. Bir satırda "izin var", diğerinde "ret" yazıyorsa sonuç "ret" olur. Bu kural tartışmasız, aşağıdaki KVKK bölümünde nedeni var.

Firma mükerrerliği: unvan gürültüsü

Türkiye'de firma adı eşleştirmenin kendine has bir zorluğu var: aynı firma dosyada beş farklı biçimde yazılmıştır. "ABC Tekstil", "ABC TEKSTİL SAN. TİC. LTD. ŞTİ.", "Abc Tekstil Ltd", "ABC Teks. San." hepsi aynı firmadır.

Karşılaştırmadan önce şu ekleri temizleyin: "A.Ş.", "Anonim Şirketi", "Ltd. Şti.", "Limited Şirketi", "San.", "Sanayi", "Tic.", "Ticaret", "ve", "İth.", "İhr.", "Koll. Şti.". Kalan çekirdek adı karşılaştırın. Bu temizlik yalnızca karşılaştırma için; tam unvanı ayrı bir alanda saklamaya devam edin, çünkü fatura kesmek için tam hâli gerekiyor.

Kesin eşleştirme istiyorsanız firmanın kimlik numarasını kullanın. Vergi kimlik numarası bunun için iyi bir anahtar. MERSİS numarası da var (16 haneli, Ticaret Bakanlığı tarafından verilen sicil kimliği) ama müşteri dosyalarında nadiren bulunur, o yüzden pratikte VKN daha kullanışlı.

Adım 6: tarih biçimi tuzağı

Bu adım numarasını ayrı anlatılabilsin diye aldı. Pratikte tarih dönüşümünü 4. adımdaki temizlikle aynı oturumda yaparsınız; aşağıdaki 30 günlük takvim de öyle kuruyor, ikisini 2. haftaya koyuyor. Mükerrer temizliği ise ancak telefonlar tek biçime indikten sonra anlamlı olduğu için sonraya kalıyor.

Tarihler, göçte sessizce bozulan alanlardır. Sessiz olmalarının sebebi şu: bozulduklarında hata vermezler, sadece yanlış tarih olurlar ve bunu aylar sonra fark edersiniz.

gg.aa.yyyy ile aa/gg/yyyy karışıklığı

Türkiye'de tarih gün, ay, yıl sırasıyla ve nokta ile yazılır: 05.03.2026 demek 5 Mart 2026 demektir. Amerikan biçiminde aynı dize 3 Mayıs anlamına gelir. İşin kötüsü, hangi biçim olduğunu dosyaya bakarak anlayamazsınız, çünkü ilk 12 günün tarihi iki biçimde de geçerli görünür.

Pratik teşhis yöntemi: sütunu tepeden tırnağa tarayın ve ilk kısmı 12'den büyük olan bir satır arayın. "25.03.2026" gibi bir değer bulduysanız biçim gün önce demektir. Hiç bulamıyorsanız ya dosyada gerçekten hiç 12'den büyük gün yoktur (çok düşük ihtimal) ya da biçim ay önce demektir.

Göçte hedef biçim tartışmasız: yıl, ay, gün sırası ve tire, yani 2026-03-05. Bu, uluslararası ISO 8601 standardıdır, hiçbir programda yanlış yorumlanmaz ve metin olarak sıralandığında bile doğru sıralanır. Aktarımdan önce bütün tarih sütunlarını bu biçime çevirin.

Excel tarihi sayıya çevirdiğinde

Excel tarihleri aslında sayı olarak tutar: 1 Ocak 1900 birinci gün sayılır ve her gün bir artar. Bir hücreyi tarih biçiminden genel biçime aldığınızda ekranda "45.717" gibi bir sayı görürsünüz. Bu bozulma değil, tarihin ham hâli. Bozulma, o sayı bir CSV'ye yazılıp karşı taraf onu tarih değil sayı sanınca oluyor.

Dışa aktarmadan önce tarih sütunlarını mutlaka metne çevirin. En güvenli yol yardımcı bir sütun açıp METNEÇEVİR(A2;"yyyy-aa-gg") formülünü uygulamak, sonucu değere dönüştürmek ve orijinal sütunu dışarıda bırakmak.

Tersi de olur: bir dosyada 1900 yılının ilk günlerine tarihlenmiş yüzlerce kayıt görürseniz, orada aslında sıfır ya da boş hücre vardı ve bir yerde sayı tarihe çevrildi. Bu kayıtları tarih olarak taşımayın, boş bırakın. Yanlış tarih boş tarihten kötüdür, çünkü boş tarih "bilmiyorum" der, yanlış tarih "biliyorum" der.

Tarih mi zaman damgası mı

Son bir ayrım: "doğum tarihi" bir tarihtir, saat dilimi taşımaz. "Son görüşme zamanı" bir zaman damgasıdır ve taşır. Excel ikisini de aynı sayı olarak tutar, CRM tarafında ise genelde ayrım vardır. Saf tarihleri saatsiz, zaman damgalarını saatiyle taşıyın ve CRM'in saat dilimi ayarını işletmenizin bulunduğu dilime kurun. Aksi hâlde akşam 21:00'de gelen bir talep raporda ertesi güne yazılır.

Adım 7: test içe aktarma, önce 20 kayıt

Bu adım tartışmaya kapalı. Bin satırlık dosyanızı tek seferde yüklemeyin. Önce 20 kayıt yükleyin, gözle bakın, düzeltin, sonra hepsini yükleyin. Yirmi kaydı temizlemek yirmi dakika sürer; bin kaydı geri almak iki gün sürer.

Test için hangi 20 kaydı seçmelisiniz

Rastgele seçmeyin, en zor 20 kaydı seçin:

• Adında Türkçe karakter olan üç kayıt (mutlaka bir "ş", bir "ğ", bir "İ" ve bir "ı" geçsin).
• Telefonu farklı biçimde yazılmış beş kayıt (biri başında sıfırlı, biri +90'lı, biri sabit hat, biri yurt dışı, biri bozuk).
• Firma adı çok uzun olan iki kayıt.
• Notu çok uzun olan iki kayıt.
• Bilerek mükerrer bıraktığınız iki çift (yani dört kayıt).
• Bir alanı boş olan üç kayıt.
• İçinde virgül veya tırnak geçen bir kayıt ("Acme, Ltd. Şti." gibi).

Yükledikten sonraki doğrulama listesi

1. Türkçe karakterler doğru mu? Dört harfi de tek tek kontrol edin.
2. Telefonlar tek biçimde mi? Hepsi +90 ile başlıyor mu?
3. Mükerrer bıraktığınız çiftler birleşti mi, yoksa iki kayıt mı oluştu?
4. Uzun metinler kırpıldı mı? Kırpıldıysa nerede kesildiğine bakın.
5. Virgüllü satır tek kayıt mı oldu, yoksa sütunlar kaydı mı?
6. Tarihler doğru gün ve ayı gösteriyor mu?
7. Boş alanlar boş mu kaldı, yoksa "0" veya "null" gibi bir değer mi yazıldı?

Yedi maddenin hepsi temizse tam aktarıma geçebilirsiniz. Biri bile takılıyorsa kaynak dosyayı düzeltip test kayıtlarını silin ve tekrar deneyin. Test turunu üç kez tekrarlamak normaldir.

Tam aktarım: parti büyüklüğü ve etiket

Tam aktarımda iki şeyi mutlaka yapın. Birincisi, aktarımı partilere bölün: bin satırlık partiler hem hata çıktığında nereye bakacağınızı gösterir hem de yarıda kesilirse ne kadarının girdiğini bilirsiniz. İkincisi, o aktarımdaki bütün kayıtlara bir etiket verin, örneğin "Göç 2026-08 ana liste". Bu etiket, aktarımı geri almanın en pratik yolu: yanlış giderse etikete göre filtreleyip topluca silersiniz.

CRM Solid tarafında bu akış Kişiler ekranındaki İçe Aktar adımından işliyor. Dosya tarayıcıda ayrıştırılıyor, ayırıcı otomatik seçiliyor (virgül, noktalı virgül, sekme ve dikey çizgi deneniyor, yani Türkçe Excel'in noktalı virgülü ayrıca ele alınıyor), dosyanın başındaki BOM işareti atılıyor ve kolon başlıkları hem Türkçe hem İngilizce adlarla eşleştiriliyor: "Ad Soyad", "GSM", "E-posta", "Firma", "Müşteri No" gibi başlıklar tanınıyor ve eşleme size önerilerek geliyor, siz onaylıyorsunuz. Eşleştirme sırası e-posta, dış kimlik, kullanıcı adı, telefon şeklinde işliyor; eşleşen bir kayıt bulunduğunda mevcut kaydın dolu alanları üzerine yazılmıyor, yalnızca boş alanlar dolduruluyor, böylece eski bir dosya CRM'de biriken bilgiyi bozamıyor. Hatalı satırlar için satır numarasıyla birlikte uyarı listesi dönüyor. Ücretsiz planda içe aktarma ayda 500 satırla sınırlı; hangi planda ne olduğuna planların karşılaştırıldığı sayfadan bakabilirsiniz. Kişi kaydının kendisi ve zaman çizelgesi hakkında ayrıntı isterseniz müşteri takip ekranını inceleyin.

Bir sınırı da olduğu gibi yazayım, çünkü yukarıdaki temizlik işini doğrudan ilgilendiriyor: telefon eşleştirmesi ayraçları attıktan sonra rakamların birebir aynı olmasına bakıyor, numarayı kendiliğinden E.164'e çevirmiyor. Yani "05321112233" ile "+905321112233" burada da iki ayrı anahtar. Normalizasyonu yüklemeden önce yapmanız bu yüzden gerçekten gerekli; hiçbir içe aktarma ekranı bu işi sizin yerinize yapmıyor, bizimki de yapmıyor.

Hangi CRM'i kullanırsanız kullanın, içe aktarma ekranında şu üç şeyi arayın: ayırıcıyı ve kodlamayı gösteren bir önizleme, kolon eşlemeyi elle değiştirme imkânı ve satır numaralı hata raporu. Bu üçü yoksa aktarım sırasında ne olduğunu asla bilemezsiniz.

Adım 8: KVKK tarafında ne yapmanız gerekiyor

Bu bölüm hukuki danışmanlık değil, uygulama notudur. Özel durumunuz için avukatınıza danışın. Ama aşağıdaki dört maddeyi atlayan bir göç, sonradan düzeltmesi zor bir eksik bırakır.

Envanter: Excel bir "veri kayıt ortamı"dır

Kişisel veri işleme envanteri, hangi veriyi hangi amaçla, hangi hukuki sebeple işlediğinizi, ne kadar süre sakladığınızı ve kime aktardığınızı gösteren tablodur. Göç, bu tabloyu güncellemek için doğal bir fırsat, çünkü zaten bütün veriyi elden geçiriyorsunuz.

Envanteri hazırlama yükümlülüğü, 6698 sayılı Kanun'un 16. maddesi gereğince Veri Sorumluları Sicili'ne (VERBİS) kayıtla yükümlü olanlara aittir. Kayıt yükümlülüğünün kapsamı Kurul kararlarıyla belirleniyor. Kurum'un kamuoyu duyurusuna göre yıllık çalışan sayısı 50'den az ve yıllık mali bilanço toplamı 100 milyon TL'den az olan, ana faaliyet konusu özel nitelikli kişisel veri işleme olmayan veri sorumluları kayıttan istisna tutuluyor. Ana faaliyeti özel nitelikli veri işlemek olanlar için 4 Eylül 2025 tarihli 2025/1572 sayılı Kurul Kararı ile ayrı bir istisna getirildi: yıllık çalışan sayısı 10'dan az ve bilanço toplamı 10 milyon TL'den az olanlar da kayıt yükümlülüğünden muaf.

Yani çoğu KOBİ VERBİS'e kayıtla yükümlü değil ve dolayısıyla envanter hazırlama zorunluluğu da yok. Buna rağmen tavsiyem envanteri hazırlamanız: kayıt yükümlülüğünüz olmasa da aydınlatma, güvenlik ve silme yükümlülükleriniz devam ediyor ve bunları envantersiz yönetmek çok zor.

Saklama süresi ve periyodik imha

Excel'de bir kayıt sonsuza kadar durur, çünkü silmek kimsenin işi değildir. CRM'de bu farklı olmalı. Kişisel Verilerin Silinmesi, Yok Edilmesi veya Anonim Hale Getirilmesi Hakkında Yönetmelik iki süre tanımlıyor. Saklama ve imha politikası hazırlamakla yükümlü olanlar için periyodik imha aralığı politikada belirlenir ve her hâlde altı ayı geçemez (madde 11). Politika hazırlama yükümlülüğü olmayan veri sorumluları ise silme yükümlülüğünün doğduğu tarihi izleyen üç ay içinde siler, yok eder veya anonim hâle getirir. Ayrıca yapılan bütün silme işlemleri kayıt altına alınır ve bu kayıtlar en az üç yıl saklanır.

Göç sırasında yapmanız gereken pratik iş: her veri kategorisi için bir saklama süresi belirleyip yazın. "Teklif verilip kapanmamış talepler: 24 ay", "Müşteri kayıtları: ticari ilişkinin bitiminden itibaren 10 yıl (yasal saklama süreleri gereği)", "Reklam kaynaklı ve hiç dönüş alınmamış talepler: 12 ay". Sonra CRM'de bu kayıtları bulup silecek bir filtre kurun ve altı ayda bir çalıştırın.

İzin durumu Excel'de yoksa ne yapılır

Çoğu Excel dosyasında "iletişim izni" diye bir kolon yoktur. Göç sırasında bu kolonu boş bırakıp sonra herkese mesaj atmak, en sık yapılan ve en pahalı hata.

Doğru yaklaşım şu: boş izin durumunu "izin var" saymayın, ayrı bir değer olarak "bilinmiyor" yazın. Sonra kayıtları üçe ayırın.

• Mevcut müşteri. Hâlihazırda ürün veya hizmet aldığı sürece, teslimat, tahsilat, borç hatırlatma, bilgi güncelleme gibi iletiler için önceden onay aranmıyor. Bu istisna Ticari İletişim ve Ticari Elektronik İletiler Hakkında Yönetmelik'in 6. maddesinde sayılı ve 6563 sayılı Elektronik Ticaretin Düzenlenmesi Hakkında Kanun'a dayanıyor. Ama dikkat: bu istisna işlemsel iletiler için, kampanya duyurusu için değil.
• Tacir veya esnaf alıcı. Aynı maddeye göre tacir ve esnaflara gönderilen iletiler için önceden onay aranmıyor. Bunun sınırları sanıldığından dar ve ret hakkı burada da geçerli; ayrıntısı için tacir ve esnaf istisnasının gerçek sınırlarına bakın.
• Geri kalan herkes. İzni bilinmeyen ve yukarıdaki iki gruba girmeyen kayıtlara pazarlama iletisi göndermeyin. Onay almanız gerekiyor ve onayın İYS'ye işlenmesi gereken kanallar (arama, SMS, e-posta) için üç iş günlük süre var. İşleyişi İYS rehberinde anlattık.

2026 yılı için geçerli idari para cezalarına bakmak isterseniz: onay almadan veya onaya aykırı ticari elektronik ileti göndermenin cezası Elektronik Ticaret Kanunu kapsamında 2.859 TL ile 14.309 TL arasında; KVKK tarafında aydınlatma yükümlülüğünü yerine getirmemenin cezası 85.437 TL ile 1.709.200 TL arasında. Tutarlar her yıl yeniden değerleme oranıyla güncelleniyor, o yüzden tarihi geçmiş bir listeye güvenmeyin.

Aydınlatma ve ortam değişikliği

Sık sorulan bir soru: veriyi Excel'den CRM'e taşımak yeni bir aydınlatma gerektirir mi? Cevap, işleme amacınız değişmediyse ve yeni bir alıcı grubuna aktarım yapmıyorsanız genelde hayır. Ama aydınlatma metninizde veri işleme yöntemi ve aktarım yapılan taraflar sayılıyorsa o metni güncellemeniz gerekir, çünkü artık bir hizmet sağlayıcı veri işleyen sıfatıyla devrede.

Aydınlatma yükümlülüğünün nasıl yerine getirileceği 10 Mart 2018 tarihli Resmî Gazete'de yayımlanan tebliğde düzenlenmiş. Tebliğ, verilecek asgari bilgileri sayıyor (veri sorumlusunun kimliği, işleme amacı, kimlere ve hangi amaçla aktarılabileceği, toplama yöntemi ve hukuki sebebi, ilgili kişinin hakları), aydınlatmanın anlaşılır, açık ve sade bir dille yapılmasını istiyor ve ispat yükünü veri sorumlusuna bırakıyor.

Bir de sunucunun nerede olduğu meselesi var. Kullanacağınız CRM verileri yurt dışında tutuyorsa bu bir yurt dışına aktarımdır ve 7499 sayılı Kanun'la değişen KVKK 9. madde rejimine tabidir. Standart sözleşme kullanılıyorsa, Kanun'un 9. maddesinin beşinci fıkrası gereği imzadan itibaren beş iş günü içinde Kurum'a bildirilmesi gerekiyor; Kurum bunu standart sözleşme bildirim modülü duyurusunda ayrıca hatırlatıyor. Ayrıntısı için yurt dışına veri aktarımı yazısına bakın; Kurum'un kendi yurt dışına aktarım sayfası da başvuru kaynağı.

Adım 9 ve 10: ekip geçişi ve geri dönüş planı

Teknik göç bir hafta sürer, insan göçü bir ay. Buradaki hatalar teknik hatalardan daha pahalıya patlıyor, çünkü ekip yeni sistemi bir kez reddettiğinde ikinci deneme çok daha zor oluyor.

Paralel kullanım süresi

Excel'i aktarımın ertesi günü kapatmayın. İki sistemi bir süre birlikte kullanmak gerekir ama bu süre iki haftadan uzun olmamalı. Sebebi şu: paralel dönem uzarsa insanlar Excel'de kalmayı seçer, çünkü tanıdık olan kolaydır ve CRM hiçbir zaman "gerçek" olmaz.

Paralel dönemde kural nettir: her kayıt her iki yere de girilir. Bu zahmetlidir ve zahmetli olması iyidir, çünkü insanları paralel dönemi bitirmeye motive eder. "Şimdilik sadece Excel'e girelim, sonra toplu aktarırız" cümlesi göçün en sık ölüm sebebidir.

Excel'i kapatma tarihi

Bir tarih belirleyin, takvime yazın ve herkese söyleyin. O gün dosyayı silmeyin ama salt okunur yapın ve adını değiştirin: "ARSIV_musteriler_2026-08-31_SALT_OKUNUR.xlsx". Ad, dosyayı yanlışlıkla açan birine ne olduğunu anlatmalı.

Kapatma tarihinden sonra dosyaya yazan biri olursa bu bir disiplin meselesi değil, bir teşhis: CRM'de o kişinin ihtiyacı olan bir şey eksik demektir. Gidip sorun, düzeltin.

Kim neyi girecek

Rolleri göçten önce yazın, sonra değil. Basit bir tablo yeterli:

Dikkat: ilk gün herkese tam yetki vermeyin. En sık yaşanan kaza, iyi niyetli birinin filtreyi yanlış kurup toplu silme yapması. Dışa aktarma yetkisini de sınırlayın; müşteri listesinin tamamını indirebilen kişi sayısı ne kadar azsa o kadar iyi. Güvenlik tarafında nelere baktığınızı bilmek isterseniz güvenlik sayfamızda yaklaşım anlatılıyor.

Geri dönüş planı

Her göçün bir geri dönüş planı olmalı, kullanmayacak olsanız bile. Plan üç maddeden ibaret:

1. Aktarımdan önceki dosyanın dokunulmamış bir kopyası. Tarih damgalı, salt okunur, ayrı bir yerde. Bu kopyaya aktarım sırasında hiç dokunulmaz.
2. Aktarım etiketi. Yukarıda anlattığım "Göç 2026-08" etiketi. Geri dönüş, bu etikete göre filtreleyip silmekten ibaret olur.
3. Dışa aktarma testi. Göçün ilk haftasında CRM'den bir tam dışa aktarma alın ve dosyayı açın. Amaç veri yedeklemek değil, çıkabildiğinizi doğrulamak. Verinizi geri alamayacağınız bir sisteme veri koymayın.

Üçüncü madde önemli, üstünde durayım. Bir CRM'i değerlendirirken herkes özelliklere bakar, kimse çıkış yoluna bakmaz. Oysa göçün ilk gününde sormanız gereken soru şu: yarın vazgeçsem bütün kişilerimi, notlarımı ve konuşma geçmişimi standart bir dosya olarak indirebiliyor muyum? Cevap net değilse başka bir yere bakın.

30 günlük geçiş takvimi

Aşağıdaki takvim üç kişilik bir ekip ve bin ile beş bin arası kayıt varsayımıyla hazırlandı. Daha büyük bir dosyanız varsa haftaları uzatın, adımları değiştirmeyin.

Takvime bir de yapılmayacaklar eklemek gerekiyor. İlk 30 gün içinde otomasyon kurmayın, yapay zekâ ajanı çalıştırmayın, raporları özelleştirmeyin. Bunların hepsi verinin oturmasını bekler. Yapay zekâ tarafını merak ediyorsanız o iş kendi başına bir proje ve önce temiz veri ister; Türkçe konuşan bir müşteri temsilcisi kurmanın ne gerektirdiğine ayrıca bakın.

Yapmayın listesi

Bu maddelerin her biri, göçü yavaşlatmakla kalmayıp başarısız kılabilecek türden.

• Her şeyi birden taşımayın. Kişiler, fırsatlar, teklifler, faturalar, geçmiş konuşmalar ve e-posta listesi aynı hafta içinde taşınmaz. Kişilerle başlayın, üstüne bir ay sonra fırsatları ekleyin. Tek seferde her şeyi taşıyan ekipler genelde hiçbirini doğru taşıyamıyor.
• Tarihsel veriyi olduğu gibi aktarmayın. Üç yıl önce bir kez teklif alıp cevap vermemiş 4.000 kaydı taşımanın hiçbir faydası yok, iki tane zararı var: aramayı yavaşlatır ve mükerrer oranını şişirir. Kural olarak son 24 ayda temas olmuş kayıtları taşıyın, gerisini arşiv dosyasında bırakın.
• İlk gün 40 özel alan tanımlamayın. Excel'de 40 sütununuz olması, CRM'de 40 alana ihtiyacınız olduğu anlamına gelmez. O sütunların çoğu bir kereliğine açılmış ve doldurulmamıştır. Beş alanla başlayın.
• Herkese tam yetki vermeyin. Özellikle silme ve dışa aktarma yetkisini. İlk ay yetkiyi dar tutup ihtiyaç doğdukça genişletmek, tersinden çok daha kolay.
• Aktarımdan önce dosyayı temizlemeden yüklemeyin. "CRM nasıl olsa düzeltir" diye bir şey yok. Kirli veriyi içeri aldığınızda kirli veriyi CRM'de temizlemek zorunda kalırsınız ve orada temizlemek Excel'de temizlemekten zordur.
• İzin bilgisi olmayan listeye kampanya göndermeyin. Göçün hemen ardından "artık toplu mesaj atabiliyoruz" heyecanıyla yapılan ilk gönderim, hem şikayet hem idari para cezası riski taşıyor. Bir hafta bekleyin, izin durumunu ayıklayın.
• Excel'i tamamen yasaklamayın. İnsanlar rapor almak, hızlı hesap yapmak ve muhasebeyle veri paylaşmak için Excel kullanmaya devam edecek. Yasaklanan şey, Excel'in ana kayıt olması olmalı, Excel'in kendisi değil.

Sık sorulan sorular

Geçmiş verinin tamamını taşımalı mıyım?

Hayır. Son 24 ayda temas olmuş kayıtları taşıyın, gerisini tarih damgalı bir arşiv dosyasında bırakın. Arşiv dosyası bir yerde durduğu sürece hiçbir şey kaybolmuş olmaz, ama günlük çalıştığınız listede olmadığı için aramayı, mükerrer oranını ve raporları bozmaz. İhtiyaç duyduğunuz eski bir kayıt olursa arşivden tek tek çekersiniz; pratikte bu ayda bir iki kez olur.

CSV yerine doğrudan Excel dosyası yükleyebilir miyim?

Çoğu sistem xlsx dosyası kabul eder ama CSV'yi tercih edin. Sebebi şu: xlsx içinde biçimler, formüller, gizli sayfalar ve hesaplanmış değerler var ve içe aktarma sırasında bunların hangisinin okunduğunu göremezsiniz. CSV düz metindir; ne yazdığını bir metin düzenleyicide açıp gözle görürsünüz. Sorun çıktığında CSV'de nerede olduğunu bulmak beş dakika, xlsx'te bulmak yarım gün sürer.

Türkçe karakterler bozulduysa dosyayı baştan mı hazırlamam gerekir?

Genelde hayır. Bozulma çoğu zaman geri döndürülebilir, çünkü baytlar kaybolmamış, sadece yanlış yorumlanmıştır. Dosyayı Not Defteri veya Notepad++ ile açıp "UTF-8 (BOM ile)" olarak yeniden kaydedin, doğru göründüğünü teyit edin, sonra tekrar deneyin. Geri döndürülemeyen tek durum, bozuk hâliyle kaydedilip üzerine yazılmış olmasıdır. Bu yüzden aktarımdan önceki dokunulmamış kopya önemli.

Mükerrer kayıtları CRM otomatik birleştirir mi?

Kısmen. İçe aktarma sırasında güvenilir bir anahtar üzerinden (e-posta, dış kimlik, normalize telefon) eşleşen kayıtlar tek kayda düşer. Ama "Ahmet Yılmaz" ile "A. Yılmaz" gibi yalnızca isimden benzer olan kayıtları hiçbir sistem güvenle birleştiremez, birleştirmemesi de doğrudur. O yüzden mükerrer temizliğinin büyük kısmı aktarımdan önce, Excel'de yapılır. Aktarımdan sonra kalanlar için CRM tarafında elle birleştirme yaparsınız ve bu sayı doğru hazırlanmış bir dosyada onlarla ifade edilir, binlerle değil.

Excel'den CRM'e taşımak KVKK açısından yeni bir işleme faaliyeti mi?

Verinin ortamının değişmesi tek başına yeni bir amaç yaratmaz. Amacınız aynı kaldığı ve yeni bir alıcı grubuna aktarım yapmadığınız sürece yeni bir hukuki sebep aramanız gerekmez. Ancak iki şey değişir: aydınlatma metninizde sayılan aktarım tarafları ve veri işleme yöntemi güncellenmelidir, bir de hizmet sağlayıcıyla aranızdaki ilişkinin yazılı bir dayanağı olmalıdır. Sunucular yurt dışındaysa ayrıca aktarım rejimi devreye girer. Bu bir hukuki görüş değil, uygulama notu; kendi durumunuz için avukatınıza danışın.

İzin bilgisi Excel'de yoksa taşıdıktan sonra mesaj atabilir miyim?

İzin bilgisinin olmaması izin olduğu anlamına gelmez. Kayıtları üçe ayırın: hâlihazırda ürün veya hizmet aldığı için işlemsel ileti gönderebileceğiniz mevcut müşteriler, tacir veya esnaf sıfatındaki alıcılar ve geri kalan herkes. Üçüncü gruba pazarlama iletisi göndermeden önce onay alın. Bir de ret kayıtlarını taşımayı unutmayın: daha önce "beni listeden çıkarın" demiş biri yeni sisteme temiz sayfa olarak girerse, bu ret hakkının ihlali olur ve ilk gönderimde şikayet olarak size döner.

WhatsApp ve Instagram'daki konuşma geçmişim de taşınabilir mi?

Kısmen ve kanala göre. Platformların çoğu geçmiş konuşmayı toplu olarak dışarı vermez; bağlantı kurulduktan sonra o andan itibaren gelen mesajlar birikmeye başlar. Yani geriye dönük tam bir arşiv beklemeyin. Pratik hedef şu olmalı: bundan sonraki bütün konuşmalar kişinin kaydına düşsün, geçmiş için de önemli olanları not olarak elle taşıyın. Bunun neye benzediğini görmek isterseniz tek gelen kutusu mantığı ve Instagram DM'den sipariş alan işletmelerin operasyonu iyi birer örnek.

Ekibim Excel'e geri dönmek isterse ne yapmalıyım?

Israrı disiplin sorunu olarak görmeyin, teşhis olarak görün. İnsanlar tanıdık aracı, yeni araç onlara bir şey vermediği için tercih eder. Gidip tek soru sorun: "Excel'de yapıp burada yapamadığın şey ne?" Cevap genelde üç şeyden biri olur: bir alan eksiktir, bir filtre yoktur ya da bir ekran çok yavaştır. Üçü de çözülebilir. Çözdükten sonra dönüş isteği kendiliğinden biter; bitmiyorsa geçişi yeterince açık anlatmamışsınız demektir, baştan anlatın.

Karar: bu hafta ne yapacaksınız

Bu yazının tavsiyesi "CRM'e geçin" değil. Tavsiye şu: bir hafta içinde envanteri çıkarın ve mükerrer oranınızı ölçün. İki iş de birer saat sürüyor ve ikisi de CRM'e geçmeye karar vermeseniz bile işinize yarıyor.

Envanter, kaç yerde müşteri kaydı tuttuğunuzu gösterir. Mükerrer oranı, dosyanızın gerçekte ne kadar güvenilir olduğunu gösterir. Bu iki sayıyı gördükten sonra karar kendiliğinden netleşiyor. Kaba bir eşik önereyim, araştırma değil, bu yazının kendi ölçütü: mükerrer oranı %2'nin altında ve kayıt tek dosyadaysa Excel'de kalın, altı ay sonra tekrar bakın. Mükerrer oranı %5'in üstündeyse ve kayıt üç ayrı yerde duruyorsa göç kararını zaten vermişsiniz, sadece henüz yazmamışsınız.

Göçe karar verdiyseniz sıra şu: envanter, veri modeli, kolon eşleme, temizlik, mükerrer, tarih, 20 kayıtlık test, tam aktarım, KVKK notları, ekip ve kapanış tarihi. Bu sırayı bozmadan ilerlerseniz bir ay yeter. Sıra bozulursa, özellikle test aktarımı atlanırsa, bir ay üç aya çıkar.

Son bir not: göçün başarısını "veri taşındı mı" diye ölçmeyin. Doğru ölçü şu: bir ay sonra ekipten biri "şu müşteriyle en son ne konuşulmuş" diye sorduğunda cevabı kaç saniyede alıyor? Excel'de bu soru dakikalar sürerdi. Otuz saniyenin altına indiyse göç başarılı olmuş demektir. İnmediyse taşıdığınız şey veri değil, dağınıklıktır. Huni aşamalarını sadeleştirmek de genelde burada işe yarıyor; satış hunisi tarafını beş aşamayı geçmeyecek şekilde kurun, sonra genişletirsiniz.