CRM Veri Aktarımı ve Geçiş Rehberi: Excel'den ve Eski Sistemden Taşıma

Bir işletme yeni bir CRM’e geçmeye karar verdiğinde, ekibin çoğu zaman aklındaki ilk soru “hangi CRM’i seçelim” ya da “nasıl kurarız” olur. Ama işin gerçek zorluğu genellikle orada değildir — asıl kritik eşik, yıllar içinde Excel dosyalarına, Google Sheets sekmelerine, eski bir CRM’e ya da birkaç kişinin kişisel notlarına dağılmış müşteri ve lead verisinin, yeni sisteme temiz, doğru ve eksiksiz biçimde taşınmasıdır. Bu adım gözden kaçırıldığında ya da aceleye getirildiğinde, yeni CRM ilk günden itibaren “kirli” başlar: mükerrer kayıtlar, boş alanlar, tutarsız telefon formatları, kaybolmuş geçmiş notlar. Ekip birkaç hafta içinde yeni sisteme güvenmemeye başlar ve eski Excel dosyasına geri döner — bu da tüm geçiş projesinin başarısız sayılması demektir.

Bu yazı doğrudan bu soruna odaklanıyor: mevcut müşteri/lead verinizi (Excel, Google Sheets ya da eski bir CRM’den) yeni bir CRM’e nasıl aktarırsınız, veriyi taşımadan önce nasıl temizlersiniz, alanları nasıl eşleştirirsiniz, mükerrer kayıtları nasıl tespit edip birleştirirsiniz ve geçiş sırasında veri kaybını nasıl önlersiniz. Hangi CRM’in seçileceği veya genel kurulum/danışmanlık süreci bu yazının konusu değil — o konuda CRM kurulum ve danışmanlık rehberimize bakabilirsiniz. Kommo’ya özel kurulum adımları için de Kommo CRM kurulumu yazımıza yönlenebilirsiniz. Bu yazı, hangi CRM’e geçerseniz geçin, verinizi oraya nasıl sağlıklı taşıyacağınızı anlatıyor.

Neden Veri Aktarımı Kurulumdan Daha Kritik?

Bir CRM’in ekranları, otomasyonları ve entegrasyonları ne kadar iyi kurulursa kurulsun, içindeki veri güvenilmezse sistem işe yaramaz hale gelir. Satış temsilcisi bir müşteriyi aradığında CRM’de yanlış telefon numarası görürse, ya da aynı müşteri için üç farklı kayıt varsa ve hangisinin güncel olduğu belirsizse, ekip hızla CRM’e güvenmeyi bırakır ve eski alışkanlıklarına (Excel, not defteri, hafıza) geri döner. Bu, teknik bir sorun gibi görünse de aslında bir benimseme (adoption) sorunudur — ve benimseme sorunlarının kökeninde neredeyse her zaman kötü yapılmış bir veri aktarımı vardır.

Veri aktarımının kalitesini belirleyen üç temel unsur vardır:

1. Doğruluk — aktarılan verinin kaynağındaki gerçek durumu yansıtması (yanlış eşleştirilmiş alan, bozulmuş tarih formatı gibi hatalar olmaması)
2. Bütünlük — hiçbir kaydın, notun ya da geçmiş etkileşimin kaybolmadan taşınması
3. Temizlik — mükerrer kayıtların birleştirilmiş, boş/anlamsız verinin ayıklanmış, tutarsız formatların standartlaştırılmış olması

Bu üç unsurdan biri eksik kalırsa, yeni CRM kurulumu ne kadar profesyonel olursa olsun, ekip “bu sistem hatalı” algısıyla başlar ve bu algıyı geri kazanmak, doğru kurulan bir sistemi ilk günden doğru vermekten çok daha zordur.

Aktarımı proje olarak ele almanın maliyeti nedir?

Küçük işletmeler genellikle veri aktarımını “birkaç saatlik iş” olarak görür ve genellikle bu beklenti gerçekleşmez. Birkaç yüz satırlık, düzenli tutulmuş tek bir Excel dosyasından yapılan basit bir aktarım gerçekten birkaç saat sürebilir. Ama gerçek hayatta karşılaşılan tipik durum şudur: birden fazla dosya, farklı kişiler tarafından farklı zamanlarda farklı kurallarla doldurulmuş, aynı müşterinin birden fazla dosyada farklı biçimlerde geçtiği, telefon numaralarının bir kısmının +90 ile bir kısmının 0 ile bir kısmının hiç ülke koduyla başlamadığı bir veri yığını. Bu durumda aktarım, birkaç saatlik değil, birkaç günlük — bazen bir-iki haftalık — planlı bir proje haline gelir.

Adım 1: Kaynak Veriyi Envanterleme ve Değerlendirme

Aktarıma başlamadan önce, elde ne olduğunu net biçimde ortaya koymak gerekir. Bu adım atlanırsa, süreç ortasında “meğer bir Excel dosyası daha varmış” gibi sürprizlerle karşılaşılır ve zaman kaybı katlanır.

Kaynak envanteri kontrol listesi

• Kaç ayrı dosya/kaynak var (Excel dosyaları, Google Sheets sekmeleri, eski CRM export’u, e-posta pazarlama aracı listeleri, kartvizit taramaları)?
• Her kaynaktaki toplam kayıt sayısı yaklaşık ne kadar?
• Kaynaklar arasında örtüşme var mı (aynı müşteri birden fazla kaynakta mı geçiyor)?
• Her kaynağın en son ne zaman güncellendiği biliniyor mu?
• Hangi kaynak “otorite” kabul edilecek — yani aynı müşteri için çelişen bilgi varsa hangisine güvenilecek?
• Geçmiş notlar, görüşme kayıtları, teklif/fatura bağlantıları gibi “ilişkisel” veri var mı, yoksa sadece iletişim bilgisi mi?
• Eski bir CRM’den geçiliyorsa, o sistemin export özellikleri (CSV, Excel, API) neleri destekliyor?

Eski bir CRM’den geçişte ek karmaşıklık

Excel/Sheets’ten geçiş genellikle “düz” bir veri yapısıyla uğraşmak anlamına gelir — satır ve sütunlar. Eski bir CRM’den (örneğin başka bir CRM’den Kommo’ya ya da tersine) geçişte ise durum daha katmanlıdır, çünkü eski sistemde şu ilişkisel yapılar da bulunabilir:

• Lead/fırsat aşamaları (pipeline stage geçmişi)
• Görev ve hatırlatma kayıtları
• E-posta/mesaj geçmişi ve dosya ekleri
• Kullanıcı/temsilci atamaları ve sahiplik geçmişi
• Özel alanlar (custom fields) ve bunların değer listeleri

Bu ilişkisel verinin ne kadarının yeni sisteme taşınacağına, aktarım başlamadan önce karar verilmelidir. Her şeyi birebir taşımaya çalışmak çoğu zaman gereksiz karmaşıklık yaratır; bunun yerine “hangi veri gerçekten operasyonel değer taşıyor” sorusuna göre bir kapsam belirlemek daha sağlıklıdır. Örneğin iki yıl önce kapanmış ve bir daha temas edilmeyecek fırsatların tüm aşama geçmişini taşımak yerine, bu tür eski kayıtları özet bir notla arşivlemek çoğu zaman yeterlidir.

Adım 2: Veri Temizleme — Aktarımdan Önce Yapılması Gerekenler

CRM veri temizleme hizmeti kapsamında en çok zaman alan aşama genellikle burasıdır, çünkü kaynak veri neredeyse hiçbir zaman “temiz” gelmez. Temizlik, aktarımdan sonra değil, öncesinde yapılmalıdır — kirli veriyi yeni sisteme taşıyıp orada temizlemeye çalışmak, hem daha zahmetlidir hem de yeni CRM’in otomasyonlarının (örneğin telefon numarasına göre eşleştirme yapan entegrasyonların) baştan yanlış çalışmasına yol açar.

Temizlik sürecinin adımları

1. Format standardizasyonu — telefon numaralarının tek bir formata (örneğin +90 ile başlayan uluslararası format) çevrilmesi, e-posta adreslerinin küçük harfe normalize edilmesi, tarih alanlarının tutarlı bir formata (GG.AA.YYYY veya ISO 8601) getirilmesi.
2. Boş ve anlamsız verinin ayıklanması — “test”, “deneme”, “xxx”, tamamen boş satırlar, açıkça hatalı girilmiş (örneğin telefon alanına “yok” yazılmış) kayıtların işaretlenmesi.
3. Zorunlu alan kontrolü — yeni CRM’de bir kaydın “geçerli” sayılması için hangi alanların dolu olması gerektiğine karar verilmesi (örneğin isim + en az bir iletişim kanalı) ve bu kriteri karşılamayan kayıtların ayrı bir “gözden geçir” listesine alınması.
4. Tutarsız değerlerin birleştirilmesi — aynı kategoriyi ifade eden farklı yazımların (“İstanbul”, “istanbul”, “İST”, “Istanbul”) tek bir standarda indirgenmesi. Bu özellikle şehir, kaynak (lead source) ve durum (status) gibi kategorik alanlarda kritik önem taşır.
5. Mükerrer kayıtların tespiti ve birleştirilmesi — bir sonraki bölümde ayrıntılı ele alınıyor.
6. Gereksiz/eskimiş kayıtların arşivlenmesi — yıllar önce tek seferlik iletişime geçmiş, bir daha dönüş olmamış kayıtların ana listeden ayrı bir arşive alınması, böylece yeni CRM baştan gereksiz hacimle şişmez.

Sık görülen kirlilik türleri ve etkileri

Pratik öneri: Temizlik adımını atlamak kısa vadede zaman kazandırır gibi görünür ama orta vadede çok daha pahalıya mal olur — çünkü kirli veri yeni sistemde fark edildiğinde, artık “kaynak Excel’i düzenleme” değil, “canlı CRM içinde yüzlerce kaydı tek tek düzeltme” işine dönüşür.

Adım 3: Alan Eşleştirme (Field Mapping)

Kaynak veri temizlendikten sonra, her bir sütun/alanın yeni CRM’deki karşılığına eşlenmesi gerekir. Bu, Excel’den CRM’e geçiş sürecinin teknik omurgasıdır ve genellikle sanıldığından daha fazla karar noktası içerir.

Alan eşleştirme süreci

1. Kaynak alan listesinin çıkarılması — kaynaktaki (Excel/Sheets/eski CRM) tüm sütun başlıklarının tam bir listesinin çıkarılması.
2. Hedef alan listesinin çıkarılması — yeni CRM’de standart olarak var olan alanların (isim, telefon, e-posta, şirket vb.) ve oluşturulması gereken özel alanların (custom fields) belirlenmesi.
3. Bire bir eşleştirme — kaynaktaki her sütunun hedefteki hangi alana karşılık geleceğinin bir eşleştirme tablosunda netleştirilmesi.
4. Eşleşmeyen alanlar için karar — kaynakta olup hedefte doğrudan karşılığı olmayan alanlar için ya yeni bir özel alan oluşturulur, ya bu bilgi bir nota/açıklamaya taşınır, ya da bilinçli olarak aktarılmaz (ve bu karar belgelenir).
5. Veri tipi uyumunun kontrolü — kaynakta serbest metin olan bir alanın hedefte açılır liste (dropdown) olması durumunda, kaynaktaki tüm farklı değerlerin hedef listedeki seçeneklerle eşleştirilmesi gerekir.
6. Test aktarımı — küçük bir örneklem (örneğin 20-50 kayıt) ile deneme aktarımı yapılıp sonuçların manuel kontrol edilmesi, tam aktarıma geçmeden önce hataların yakalanması.

Örnek alan eşleştirme tablosu

Özellikle son satırdaki gibi durumlar — kaynaktaki kategori sayısının hedeftekinden farklı olması — sıkça gözden kaçar. Bu tür bir uyumsuzluk önceden çözülmezse, aktarım sırasında bazı kayıtlar hiçbir aşamaya düşmez ya da yanlışlıkla varsayılan bir aşamaya atılır.

Adım 4: Mükerrer Kayıt Tespiti ve Birleştirme

”CRM müşteri kayıtları mükerrer” sorunu, özellikle birden fazla kaynaktan veri birleştirilirken neredeyse kaçınılmazdır. Aynı müşteri hem eski bir Excel dosyasında hem güncel bir Google Sheets listesinde hem de bir e-posta pazarlama aracında farklı biçimlerde kayıtlı olabilir — bazen isim farklı yazılmış (Mehmet Yılmaz / M. Yılmaz), bazen telefon formatı farklı, bazen e-posta adresi güncellenmiş ama eski kayıt silinmemiş.

Mükerrer tespiti için kullanılan yöntemler

1. Tam eşleşme kontrolü — aynı telefon numarası veya aynı e-posta adresi birden fazla satırda geçiyorsa, bu en güvenilir mükerrer sinyalidir.
2. Normalize edilmiş eşleşme — telefon numaraları farklı formatlarda yazılmış olsa bile (0532… vs +90532…), normalize edildikten sonra aynı numarayı işaret ediyorsa mükerrer olarak işaretlenir.
3. Bulanık eşleşme (fuzzy matching) — isim benzerliğine dayalı kontrol (örneğin “Mehmet Yılmaz” ile “M. Yılmaz” arasındaki benzerlik oranı). Bu yöntem yanlış pozitif üretebileceğinden, otomatik birleştirme yerine “gözden geçir” listesine düşürülerek insan onayına bırakılmalıdır.
4. Kombine sinyal kontrolü — isim tam eşleşmese bile şirket adı ve telefon numarasının aynı olması gibi birden fazla zayıf sinyalin birlikte güçlü bir eşleşme oluşturması.

Mükerrer kayıtlar tespit edildiğinde birleştirme kuralı

Mükerrer kayıtlar bulunduğunda, hangi kaydın “kazanan” (yani ana kayıt olarak kalacak) kabul edileceğine dair net bir kural gerekir. Önerilen yaklaşım şu şekildedir:

• En son güncellenmiş kaynaktaki bilgi, iletişim bilgileri (telefon, e-posta) için önceliklidir.
• En eski kaynaktaki not/geçmiş bilgisi, kronoloji için korunur ve yeni kayda not olarak eklenir — silinmez.
• Birden fazla kaynakta çelişen bir bilgi (örneğin iki farklı şirket adı) varsa, bu otomatik karara bağlanmaz; manuel kontrol listesine alınır.
• Birleştirme sonrası, birleştirilen kayıtların kaynak referansı (hangi dosyadan geldiği) bir süre daha saklanır, böylece bir hata fark edildiğinde geri dönüş yapılabilir.

Pratik öneri: Küçük veri setlerinde (birkaç yüz kayda kadar) mükerrer tespiti manuel olarak, sıralama ve filtreleme ile makul sürede yapılabilir. Birkaç bin kaydı aşan setlerde ise otomatik normalize edilmiş eşleştirme + bulanık eşleşme kombinasyonu olmadan bu iş pratik olarak tamamlanamaz; bu ölçekte profesyonel bir CRM veri aktarım hizmeti almak, hatalı birleştirmelerin yol açacağı geri dönüşlerden çok daha ucuza gelir.

Adım 5: Google Sheets ve Excel’den Aktarım — Pratik Yol

Çoğu küçük ve orta ölçekli işletme için asıl kaynak bir eski CRM değil, doğrudan Excel dosyaları ya da Google Sheets tablolarıdır. Bu senaryo için pratik bir yol haritası şu şekildedir:

Excel/Sheets kaynağından aktarım adımları

1. Tüm dosyaları tek bir çalışma alanında toplama — farklı kişilerin bilgisayarlarında, e-posta eklerinde ya da eski Google Drive klasörlerinde dağınık duran tüm dosyaların tek bir yerde birleştirilmesi.
2. Sütun başlıklarının standartlaştırılması — her dosyada farklı yazılan başlıkların (örn. “Tel”, “Telefon No”, “GSM”) tek bir isimlendirmeye getirilmesi.
3. Tek bir ana tabloda birleştirme — tüm dosyaların, adım 3’teki eşleştirme mantığıyla tek bir ana tabloya konsolide edilmesi.
4. Temizlik ve mükerrer ayıklama uygulanması — adım 2 ve 4’teki süreçlerin bu ana tablo üzerinde uygulanması.
5. CRM’in içe aktarma (import) formatına uygun CSV hazırlama — çoğu CRM, belirli sütun sırası/başlığı bekleyen bir CSV şablonu sağlar; verinin bu şablona uyacak şekilde biçimlendirilmesi.
6. Küçük parti (batch) test aktarımı — tüm veriyi tek seferde yüklemeden önce, küçük bir grupla deneme yapılması ve içe aktarma sonrasında alanların doğru yerlere düştüğünün kontrol edilmesi.
7. Tam aktarım ve doğrulama — test başarılıysa tüm verinin aktarılması, ardından kayıt sayısının kaynak ile hedef arasında eşleştiğinin (ya da aradaki farkın bilinçli olarak elenen mükerrer/geçersiz kayıtlarla açıklanabildiğinin) doğrulanması.

Bu süreçte özellikle Google Sheets CRM entegrasyonu kurulacaksa (yani tek seferlik bir aktarım değil, Sheets’in CRM ile sürekli senkronize kalması isteniyorsa), bu iki farklı ihtiyacın birbirine karıştırılmaması gerekir: bir kerelik veri taşıma ayrı bir iştir, Sheets’i CRM’e sürekli bağlı bir veri kaynağı olarak kullanmak ayrı bir iştir. İkincisi genellikle bir entegrasyon/otomasyon katmanı gerektirir ve tek başına bu yazının kapsamı dışındadır; ama aktarım sırasında hangi ihtiyacın söz konusu olduğu netleştirilmelidir, çünkü bu, hazırlanacak veri yapısını doğrudan etkiler.

Adım 6: Eski CRM’den Yeni CRM’e Geçiş — Ek Dikkat Noktaları

Eski CRM’den Kommo’ya geçiş ya da benzer bir CRM-to-CRM geçişinde, Excel/Sheets aktarımına kıyasla birkaç ek karmaşıklık ortaya çıkar. (Kommo’nun kendi kurulum adımları için Kommo CRM kurulumu yazımıza bakabilirsiniz — burada yalnızca veri geçişine özgü noktalara odaklanıyoruz.)

CRM-to-CRM geçişte dikkat edilmesi gerekenler

• Export formatı sınırlamaları — bazı eski CRM’ler tam veri export’una izin vermez ya da yalnızca belirli alanları dışa aktarır; bu durumda API üzerinden veri çekmek gerekebilir, bu da ek teknik çaba anlamına gelir.
• Pipeline/aşama uyumsuzluğu — eski sistemdeki satış aşamaları (örneğin 8 aşamalı bir huni) yeni sistemdeki yapıyla (örneğin 5 aşamalı) birebir örtüşmeyebilir; bu eşleştirme önceden netleştirilmelidir.
• Kullanıcı/temsilci ataması — eski sistemdeki kayıt sahipliklerinin yeni sistemde kime karşılık geleceği (özellikle ekip değişmişse) belirlenmelidir.
• Ek dosyalar ve ekler — teklif PDF’leri, sözleşmeler, kartvizit görselleri gibi eklerin bazı CRM’lerde standart export’a dahil olmaması; bu tür dosyaların ayrı bir arşive alınıp yeni kayıtlara manuel bağlanması gerekebilir.
• Otomasyon/entegrasyon geçmişi taşınmaz — eski sistemdeki otomasyon kuralları, entegrasyon ayarları ve web formu bağlantıları veri değildir, bunlar yeni sistemde sıfırdan kurulmalıdır; bu nedenle geçiş planında yalnızca “veri” değil “yapılandırma” için de ayrı zaman ayrılmalıdır.
• Geçiş dönemi çakışma riski — iki sistem paralel çalıştığı sürede (eski sistem hâlâ kullanılırken yeni sisteme veri de akıyorsa), aynı yeni kaydın iki kez oluşmaması için hangi sistemin “canlı” kabul edildiği net biçimde ekibe duyurulmalıdır.

Adım 7: Veri Kaybını Önleme — Güvenlik Ağı Kurmak

Aktarım sürecinin en kritik prensibi şudur: kaynak veri, aktarım tamamlanıp doğrulanana kadar asla silinmez veya üzerine yazılmaz. Bu basit kural, çoğu geri dönüşü olmayan veri kaybının önüne geçer.

Veri kaybını önleme kontrol listesi

• Aktarıma başlamadan önce tüm kaynak dosyaların ayrı, değiştirilemez bir yedeği alınıyor mu (örneğin salt-okunur bir klasörde tarih damgalı kopya)?
• Aktarım, kaynak veriyi silen değil, kaynaktan okuyan bir işlem olarak mı tasarlanıyor?
• Test aktarımı (küçük örneklem) yapılmadan tam aktarıma geçilmiyor mu?
• Aktarım sonrası kayıt sayısı doğrulaması yapılıyor mu (kaynak satır sayısı - bilinçli elenen kayıt sayısı = hedef kayıt sayısı)?
• Rastgele seçilmiş bir örneklem (örneğin 20-30 kayıt) manuel olarak kaynak ile hedef arasında tek tek karşılaştırılıyor mu?
• Kritik alanların (telefon, e-posta gibi iletişim bilgileri) aktarım sonrası boş kalıp kalmadığı toplu olarak kontrol ediliyor mu?
• Aktarım sürecinin her adımı (hangi dosya, ne zaman, kaç kayıt) belgeleniyor mu, böylece bir sorun çıkarsa kaynağına inilebiliyor mu?
• Geçiş dönemi boyunca eski sistem/dosyalar, en az birkaç hafta silinmeden saklanıyor mu?

Bu adımların hiçbiri karmaşık değildir; asıl zorluk, aktarım sürecinde acele edilip bu kontrol adımlarının atlanmasıdır. Özellikle “hızlıca bitirip yeni sisteme geçelim” baskısı altında, doğrulama adımları ilk feda edilen kısım olur — oysa doğrulamayı atlamak, aktarımdan haftalar sonra fark edilen ve o noktada düzeltilmesi çok daha zor olan hatalara yol açar.

Yapay Zeka Destekli Veri Temizleme ve Eşleştirme

2026 itibarıyla, büyük dil modeli tabanlı araçlar CRM veri aktarım sürecinin belirli adımlarını önemli ölçüde hızlandırabiliyor. Bu, sürecin insan denetiminin tamamen ortadan kalktığı anlamına gelmez, ama belirli görevlerde ciddi zaman tasarrufu sağlar:

• Serbest metin ayrıştırma — “not” gibi tek bir serbest metin alanına yıllar içinde yazılmış telefon numarası, e-posta, adres gibi bilgilerin yapay zeka destekli metin analiziyle ayrı alanlara çıkarılması, manuel taramaya göre çok daha hızlıdır.
• Bulanık eşleştirme desteği — isim/şirket benzerliği temelli mükerrer aday listelerinin oluşturulmasında, klasik string benzerliği algoritmalarına kıyasla dil modeli tabanlı yaklaşımlar daha isabetli sonuç verebiliyor (örneğin “Yılmaz İnşaat Ltd.” ile “Yılmaz İnş. San. Tic.” arasındaki bağlantıyı daha güvenilir yakalayabiliyor).
• Kategori normalizasyonu — şehir, sektör, lead kaynağı gibi serbest yazılmış kategorik verinin standart bir listeye eşlenmesinde öneri üretme.
• Alan eşleştirme önerisi — kaynak sütun başlıklarına bakarak hedef CRM alanlarıyla olası eşleşmeleri önceden önerme, böylece manuel eşleştirme süresi kısalır.

Bununla birlikte, yapay zeka destekli araçların önerdiği her eşleştirme ve birleştirme, özellikle iletişim bilgisi gibi kritik alanlarda, insan onayından geçmeden nihai kabul edilmemelidir. Otomasyon burada hızlandırıcı bir katman olarak değerlidir, ama son karar mekanizması olarak kullanılması, özellikle mükerrer birleştirme gibi geri alınması zor işlemlerde risklidir.

Vaka Kurgusu: Üç Kaynaktan Tek CRM’e Geçiş

Yerel hizmet sektöründe faaliyet gösteren, 4 kişilik satış ekibine sahip kurgusal bir işletme örneği üzerinden süreci somutlaştıralım.

Başlangıç durumu: İşletmenin müşteri/lead verisi üç ayrı kaynakta dağınık haldeydi — 2 yıllık bir Excel dosyası (yaklaşık 1.800 satır), güncel bir Google Sheets tablosu (son 6 ayın leadleri, yaklaşık 650 satır) ve eski, artık kullanılmayan bir CRM’in CSV export’u (yaklaşık 2.400 satır). Üç kaynak arasında ciddi örtüşme vardı; aynı müşterilerin hem Excel’de hem eski CRM’de farklı biçimlerde kayıtlı olduğu tahmin ediliyordu ama kimse tam sayıyı bilmiyordu.

Uygulama: Önce üç kaynak da tek bir çalışma tablosunda birleştirildi ve her kaynağa bir “köken” etiketi eklendi (hangi dosyadan geldiği kaybolmasın diye). Telefon numaraları tek formata normalize edildi, e-posta adresleri küçük harfe çevrildi. Normalize edilmiş telefon numarasına göre tam eşleşme kontrolü yapıldığında 740 kayıt doğrudan mükerrer çıktı. Buna ek olarak isim + şirket benzerliğine dayalı bulanık eşleştirme ile 95 kayıt daha “olası mükerrer” olarak işaretlendi ve bunlar manuel olarak tek tek gözden geçirildi; bunlardan 61’i gerçekten mükerrer çıktı, 34’ü farklı kişiler olduğu için ayrı bırakıldı. Alan eşleştirmesi yapılırken, eski CRM’deki 8 aşamalı pipeline yeni sistemdeki 5 aşamalı yapıya eşlendi; bu eşleştirme satış ekibiyle birlikte, hangi eski aşamanın hangi yeni aşamaya karşılık geldiği tartışılarak netleştirildi. Küçük bir test aktarımı (50 kayıt) yapılıp sonuçlar kaynakla karşılaştırıldıktan sonra tam aktarıma geçildi.

Sonuç penceresi: Üç kaynaktaki toplam 4.850 ham satır, temizlik ve mükerrer birleştirme sonrasında 4.049 benzersiz, geçerli kayda indi (yaklaşık 800 kayıt mükerrer birleştirme yoluyla tekilleştirildi, kalan fark boş/geçersiz kayıtların ayıklanmasından kaynaklandı). Aktarım sonrası ilk ay içinde satış ekibi, aynı müşteriyi iki kez arama şikayetinin neredeyse tamamen ortadan kalktığını bildirdi. Pipeline eşleştirmesinin ekiple birlikte önceden netleştirilmiş olması, geçiş sonrası “bu lead şimdi hangi aşamada” karmaşasını önledi. (Vaka temsilidir.)

Sık Yapılan Hatalar

1. Temizliği aktarımdan sonraya bırakmak. Kirli veriyi önce CRM’e taşıyıp orada düzeltmeye çalışmak, hem daha yavaştır hem de yeni sistemin otomasyonlarının baştan yanlış veriyle çalışmasına yol açar. Temizlik her zaman aktarımdan önce yapılmalıdır.
2. Test aktarımı yapmadan doğrudan tam veriyi yüklemek. Küçük bir örneklemle önce denemeden binlerce kaydı tek seferde yüklemek, bir alan eşleştirme hatası fark edildiğinde tüm veriyi yeniden işlemeyi gerektirebilir.
3. Mükerrer kayıtları otomatik ve toptan birleştirmek. Özellikle bulanık eşleştirmeyle bulunan “olası” mükerrerleri insan onayı olmadan otomatik birleştirmek, aslında farklı iki kişinin kaydının yanlışlıkla tek kayda dönüşmesine (ve bir müşterinin bilgilerinin kaybolmasına) yol açabilir.
4. Kaynak dosyaları aktarım sırasında silmek veya üzerine yazmak. Aktarım doğrulanana kadar kaynak veri değiştirilmemeli, mümkünse salt-okunur bir kopyası ayrıca saklanmalıdır.
5. Pipeline/aşama eşleştirmesini satış ekibine danışmadan tek taraflı yapmak. Aşama isimleri teknik bir detay gibi görünse de, ekibin günlük iş akışını doğrudan etkiler; bu eşleştirme ekiple birlikte netleştirilmelidir.
6. Ekleri (dosya, teklif, sözleşme) veri aktarımının otomatik kapsayacağını varsaymak. Birçok export/import süreci yalnızca metin alanlarını taşır; dosya ekleri genellikle ayrı bir planlama gerektirir.
7. Aktarım sonrası doğrulamayı atlamak. Kayıt sayısı karşılaştırması ve örneklem kontrolü yapılmadan “aktarım bitti” denilmesi, haftalar sonra fark edilen ve düzeltilmesi çok daha maliyetli hatalara yol açar.
8. Geçiş dönemi boyunca hangi sistemin “canlı” olduğunu netleştirmemek. İki sistem paralel kullanılırken bu netlik olmazsa, aynı lead iki sistemde ayrı ayrı işlenip mükerrer kayıt sorunu yeni sistemde yeniden başlar.

Sonuç

CRM veri aktarımı, bir “kopyala-yapıştır” işi değil, kendi başına planlanması, doğrulanması ve — özellikle birden fazla kaynak ve birkaç bin kayıt söz konusu olduğunda — dikkatle yürütülmesi gereken bir projedir. Sürecin başarısı, hangi CRM’in seçildiğinden çok, kaynak verinin ne kadar iyi envanterlendiğine, temizlendiğine, alanların doğru eşleştirildiğine ve mükerrer kayıtların sağlıklı biçimde birleştirildiğine bağlıdır. Bu adımlar atlanmadan yürütüldüğünde, yeni CRM ilk günden itibaren ekibin güvendiği, doğru çalışan bir sistem olarak hayata başlar; atlandığında ise en iyi CRM bile kısa sürede “güvenilmez” damgası yer ve eski alışkanlıklara dönüş kaçınılmaz hale gelir.

Kendi veri setinizin karmaşıklığını (kaynak sayısı, tahmini mükerrer oranı, ilişkisel veri miktarı) bu yazıdaki kontrol listeleriyle değerlendirerek, aktarımı kendi ekibinizle mi yürüteceğinize yoksa profesyonel destek mi alacağınıza karar verebilirsiniz. Verinizin hacmi ve karmaşıklığı arttıkça, uçtan uca planlanmış bir aktarım süreci, sonradan ortaya çıkacak veri kaybı ve mükerrer kayıt sorunlarının maliyetinden çok daha ucuza gelir.

Mevcut müşteri/lead verinizi yeni bir CRM’e temiz ve eksiksiz biçimde taşımak için destek almak isterseniz, yapay zeka ve otomasyon hizmetlerimize göz atabilirsiniz.