Blog
CRM Veri Kalitesini Toparlamanin uc Temeli

CRM Veri Kalitesini Toparlamanın Üç Temeli

CRM projelerinde “en pahalı hata” çoğu zaman yazılım seçimi değildir. Asıl maliyet, veri kalitesi bozulduğunda ortaya çıkar. Çünkü CRM ne kadar iyi kurulursa kurulsun, içerideki kayıtlar dağınık, eksik ve mükerrerlerle doluysa ekipler bir süre sonra sistemi ciddiye almamaya başlar. Satış temsilcisi aynı müşteriyi iki farklı kayıtta görür, pazarlama aynı kişiye tekrar tekrar iletişim gönderir, servis geçmişi parça parça kalır. Yönetim rapora güvenmediği an, CRM bir “tek gerçek” olmaktan çıkar ve herkesin farklı yorumladığı bir tabloya dönüşür.

Veri kalitesinin zor kısmı şudur: Kimse CRM’i bilerek bozmaz. Veri genelde küçük hatalarla aşınır. Bir entegrasyon aynı firmayı farklı bir isimle açar, bir kullanıcı aramada bulamadığı için yeni kayıt oluşturur, biri “İST.” yazar, diğeri “İstanbul” yazar. Üç ay sonra her şey hâlâ çalışıyor gibi görünür ama raporların doğruluğu tartışmalı hale gelir. Altı ay sonra da “CRM işe yaramıyor” cümlesi dolaşmaya başlar.

Bu yazıda CRM veri kalitesini ayakta tutan üç temel konuyu, gerçek hayatta işe yarayan bir düzen içinde ele alacağız. Birincisi mükerrer kayıtların kontrol altına alınması. İkincisi veri standardizasyonu. Üçüncüsü de sahiplik modeli. Bu üçü birlikte kurulmadığında yapılan temizlik kalıcı olmaz; sistem tekrar kirlenir.

CRM Veri Kalitesi Neden Bu Kadar Kritik

CRM’in değeri, ekipleri aynı müşteri gerçeğinde buluşturmasından gelir. Satış fırsatları, pazarlama segmentleri, servis geçmişi, teklif notları ve görüşme kayıtları aynı yerde durduğunda ekipler birbirinin ayağına basmadan ilerler. Bu düzen bozulduğunda ise sorunlar domino taşı gibi devrilir.

Örneğin aynı firmaya iki farklı kayıt üzerinden gidildiğinde, iki farklı temsilci iki farklı vaat verebilir. Pazarlama tarafında mükerrer kontaklar “aynı kişiye birden fazla ileti” olarak geri döner ve hem müşteri deneyimini bozar hem de iletişim performansını (açılma, tıklama, dönüşüm) anlamsızlaştırır. Servis tarafında ise geçmişin parçalanması en büyük zarardır. Müşteri “geçen hafta aradım” der, ekip kaydı bulamaz; güven duygusu zedelenir.

Bu yüzden CRM veri kalitesini temizlik” gibi değil, işin operasyonel bir parçası gibi görmek gerekir. CRM’in yatırım geri dönüşünü yükselten şey, çoğu zaman yeni bir modül değil; verinin güvenilir hale gelmesidir.

Veri Kalitesini Anlamak İçin Dört Basit Ölçüt

Veri kalitesi konuşulurken konu kolayca teorikleşir. Pratikte işleri kolaylaştıran yaklaşım, kaliteyi dört ölçütle okumaktır.

Doğruluk, kaydın gerçeği yansıtmasıdır. Telefon eksik haneyse, e-posta hatalıysa, vergi numarası yanlışsa bu kayıt sadece “çirkin” değil; operasyonu bozan bir kayıttır. Tamlık ise gerekli alanların dolu olmasıdır. Sektör, şehir, müşteri tipi gibi alanlar boş kaldığında raporlar çalışır ama şirketi doğru anlatmaz.

Tutarlılık daha sinsi bir problemdir. Aynı bilgiyi farklı formatta tutmak raporları böler. İstanbul, İstanbul, İST. gibi yazımlar basit gibi görünür ama segment ve raporlamada parçalanma yaratır. Daha kritik olanı kavramların ekipler arasında farklı anlama gelmesidir. Satışın “müşteri” dediği şey servis için “destek alan firma”, finans için “cari kart” olabilir. Tanımlar netleşmezse CRM tek gerçeği değil, üç ayrı gerçeği taşır.

Güncellik ise verinin bayatlamamasıdır. Kontak firmadan ayrılmıştır ama hâlâ aktif görünür. Fırsat aylarca aynı aşamada bekler ama pipeline şişer. Bu noktada çoğu zaman sorun “kimin güncelleyeceği belli değil” problemine çıkar. Yani güncellik, sahiplik modeliyle doğrudan bağlantılıdır.

Mükerrer Kayıt Sorunu Neden Bu Kadar Yıpratıcı

Mükerrer kayıt, aynı firma ya da aynı kişi için birden fazla kayıt olmasıdır. Etkisi, beklenenden büyüktür çünkü CRM’deki her şey ilişkilerle bağlıdır. Bir kopyada aktiviteler, diğer kopyada fırsatlar, başka bir kopyada servis kayıtları birikir. Bu durumda mükerrer artık basitçe “sil” denecek bir şey olmaktan çıkar.

Mükerrerler genelde üç yoldan oluşur. İlki kullanıcı davranışıdır. Temsilci aramada firmayı bulamaz; çünkü farklı yazılmıştır, kısa adla açılmıştır veya kaydın sahibi başka bir ekiptir. “Neyse yenisini açayım” refleksi ortaya çıkar. İkincisi entegrasyonlardır. ERP’den gelen cari kart, web formundan gelen lead, e-ticaret kaydı… Her biri aynı firmayı farklı anahtarlarla oluşturabilir. Üçüncüsü de veri taşıma sürecidir. Eski sistemden Excel’den data taşınırken tekilleştirme yapılmazsa kopyalar bir defada içeri girer.

Burada kritik nokta şu: Dedupe, bir defalık temizlik işi değildir. Dedupe, kirlenmeyi azaltan bir “süreç” haline gelmezse CRM birkaç ay içinde tekrar aynı noktaya gelir.

Dedupe Yaparken Silme Mi Birleştirme Mi

Dedupe’un en tehlikeli kısmı yanlış kararların geri dönüş maliyetidir. Boş bir kaydı silmek genelde güvenlidir. Ama içinde e-posta aktiviteleri, toplantılar, fırsatlar, teklifler veya servis geçmişi olan bir kaydı yanlış silmek tarihçeyi kaybettirir. Yanlış birleştirme yapmak da ilişkileri bozar ve “bu müşteri aslında kim?” sorusunu büyütür.

Bu yüzden en doğru yaklaşım, önce basit bir ayrım yapmaktır. Kopyalardan biri hiç kullanılmamışsa ve ilişki taşımıyorsa silme düşünülebilir. İki kayıtta da geçmiş varsa genelde birleştirme gerekir. Birleştirmede de “ana kayıt hangisi” sorusu kritiktir. Vergi numarası gibi benzersiz alanlar varsa eşleştirme kolaylaşır. Yoksa şirket adı, e-posta domaini, şehir gibi alan kombinasyonları devreye girer.

Bir başka önemli konu da holding ve şube yapılarıdır. Aynı isimli ama farklı tüzel kişilikler olabilir. Bu tip senaryolarda otomatik kurallar yanıltıcı olabilir ve insan onayı gerekebilir. Bu yüzden dedupe yaklaşımını “tam otomatik” değil, gerektiğinde kontrol noktası olan bir düzen şeklinde kurmak daha sağlıklıdır.

Standardizasyon Olmadan Dedupe Kalıcı Olmaz

Dedupe’u sadece temizlik olarak ele alırsanız, kısa süre sonra tekrar başa dönersiniz. Çünkü mükerrer üretiminin ana nedeni “aynı şeyi farklı yazmak” ve “bulamayıp yeniden açmak”tır. Standardizasyon bu yüzden dedupe’un sigortasıdır.

Pratikte en hızlı fark yaratan standardizasyon alanları; firma adı yazım kuralı, telefon formatı, e-posta doğrulaması, adres alanları ve seçimli sözlük alanlarıdır. Serbest metin arttıkça farklı yazım artar. Bu da hem aramayı bozar hem eşleştirmeyi zorlaştırır. Seçimli alanları artırmak ve kritik alanlarda basit doğrulamalar koymak veri kalitesini ciddi biçimde yükseltir.

Standardizasyonun bir diğer faydası raporlama tarafında ortaya çıkar. Sektörler farklı yazılmıyorsa, şehirler tek formatta tutuluyorsa, müşteri tipi tutarlıysa raporlar bölünmez. Yönetim raporlara güvenmeye başlar. Güven geri gelince CRM kullanımı da hızlanır.

Sahiplik Modeli Olmadan Veri Güncel Kalmaz

Verinin güncel kalmasının temel şartı, sorumluluğun net olmasıdır. “Bu hesabın sahibi kim?” sorusu cevapsızsa, kimse güncellemez. Bu durumda kontaklar bayatlar, fırsatlar şişer, pipeline gerçekliği kaybolur. Owner modeli bu yüzden veri kalitesinin operasyonel omurgasıdır.

Sahiplik kurgusunda netleşmesi gereken birkaç temel karar vardır. Hesap sahipliği bireysel mi ekip bazlı mı olacak? Yeni lead dağıtımı hangi kuralla yapılacak? Müşteri el değiştirince süreç nasıl işleyecek? Kapanan fırsattan sonra hesap kimin portföyünde kalacak? Servis sahipliği satış sahipliğiyle aynı kayıtta mı yönetilecek?

Bu soruların cevabı netleştiğinde veri kalitesi otomatik olarak yükselmez; ama düşmesi zorlaşır. Çünkü artık “sahipsiz” kayıt yoktur. Sahiplik netleşince, mükerrer oluştuğunda da doğru kişi devreye girer. Güncellik problemi çıktığında da kimin aksiyon alacağı bellidir.

Uygulamada İşe Yarayan Basit Bir Yol Haritası

Veri kalitesini bir günde mükemmel yapmaya çalışmak genelde başarısız olur. Daha gerçekçi ve sürdürülebilir yöntem, önce en yüksek etkiyi veren alanlara odaklanmaktır. İlk adım, raporlamayı ve iletişimi doğrudan etkileyen kritik alanları seçmektir. Ardından arama ve kayıt açma deneyimini iyileştirip benzer kayıt uyarılarını devreye almak gelir. Sonra mükerrer raporu çıkartıp en çok tekrar eden firmalardan başlayarak birleştirme kurallarını oturtmak gerekir. Paralelde owner modeli yazılı hale getirilir. En sonunda da haftalık kısa bir veri kontrol rutini tanımlanır.

Bu yaklaşımın gücü şuradan gelir: İlk temizlikten sonra sistem yeniden kirlenmez. Dedupe, standardizasyon ve sahiplik birlikte çalıştığı için veri kalitesi “proje” olmaktan çıkıp “işletim” haline gelir.

Sık Sorulan Sorular

Mükerrer kayıtları silmek mi birleştirmek mi daha doğru

Kayıtlardan biri kullanılmamış ve ilişki taşımıyorsa silme düşünülebilir. İki kayıtta da aktivite, fırsat, teklif veya servis geçmişi varsa genelde birleştirme daha doğru olur. Amaç tek bir ana kayıtta tarihçeyi korumaktır.

Dedupe için en iyi eşleştirme anahtarı nedir

Vergi numarası gibi benzersiz alanlar varsa en güvenli eşleştirme budur. Yoksa e-posta domaini, firma adı ve şehir gibi alan kombinasyonlarıyla kural seti oluşturulur.

Standardizasyonu nereden başlatmak gerekir

En hızlı etki eden yerler firma adı, telefon formatı, e-posta doğrulaması, şehir ülke alanları ve seçimli sözlük alanlarıdır. Bu alanlar hem aramayı hem raporlamayı doğrudan etkiler.

Owner modeli olmazsa ne olur

Kayıtlar sahipsiz kalır, veri güncellenmez, mükerrer üretimi artar ve pipeline gerçeği yansıtmaz. Owner modeli, veri kalitesinin sürdürülebilir kalmasını sağlar.

Leave a comment

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Tıkla Ara