İki CRM lead’ini birleştirmeden önce aynı kişiyi temsil ettiklerini doğrulayın, hayatta kalacak kaydı seçin, korunması gereken her alanı ve etkinliği eşleyin ve birleştirmenin aşağı akışta neyi tetikleyeceğini kontrol edin. Ortak bir ad ya da şirket yalnızca araştırma nedenidir. Birleştirmek için yeterli kanıt değildir. Kimlik belirsiz kaldığında kayıtları ayrı tutun ve sonra incelenmek üzere işaretleyin.
Kayıt benzerliğiyle değil kimlikle başlayın
Mükerrer tespiti ile mükerrer çözümü farklı işlerdir. Tespit aday üretir; inceleme kayıtların tek bir gerçek kişiye ait olup olmadığına karar verir. Salesforce araçlarında aynı ayrımı tarif eder: eşleşme kuralları olası mükerrerleri belirler, mükerrer kuralları ise bu eşleşmelerin nasıl ele alınacağını belirler. Hangi CRM’i kullanırsanız kullanın otomatik eşleşmeyi hüküm değil uyarı sayın.
Kanıtı bir kişiyi ne kadar özgül tanımladığına göre sıralayın. Tam, normalleştirilmiş bir iş e-postası genellikle tam bir addan daha güçlüdür. Aynı işverenle birleşen doğrudan bir telefon numarası ikna edici olabilir. Yalnızca ad ve şirket zayıftır, çünkü meslektaşlar ad paylaşabilir, şirketlerin birkaç tüzel kişiliği olabilir ve kişiler iş değiştirir.
Karşılaştırmadan önce normalleştirin. E-posta alan adlarını küçük harfe çevirin, zararsız telefon biçimlendirmesini çıkarın, şirket alan adı takma adlarını tanıyın ve hem güncel hem tarihsel değerleri karşılaştırın. İnceleme sırasında özgün değerleri silmeyin; normalleştirme karşılaştırmaya yardım etmeli, kaynak veriyi erken yeniden yazmamalıdır.
Harekete geçmeden önce çifti sınıflandırın
Pratik bir inceleme “mükerrer” ve “mükerrer değil”ten fazlasını ister. Her aday çifti dört sonuçtan birine atayın:
| Sonuç | Kanıt örüntüsü | Eylem |
|---|---|---|
| Doğrulanmış mükerrer | Güçlü tanımlayıcılar uyuşur ve önemli olgular çelişmez | Koruma ve otomasyon kontrollerinden sonra birleştirin |
| İlişkili, mükerrer değil | Aynı şirket, hane, asistan ilişkisi ya da paylaşılan gelen kutusu; farklı kişiler | Ayrı tutun ve hesap ya da ilişki alanlarıyla bağlayın |
| Çelişen kimlik | Tam bir tanımlayıcı uyuşur ama adlar, bölgeler ya da geçmişler önemli ölçüde ayrılır | Durun ve kaynağı ya da yeniden kullanılmış olası veriyi araştırın |
| Yetersiz kanıt | Yalnızca zayıf nitelikler uyuşur | Ayrı tutun ve daha iyi veri geldiğinde inceleme planlayın |
Örneğin aynı çok uluslu şirketteki “Alex Lee” iki çalışan olabilir. Tersine, farklı soyadlı iki kayıt — örneğin bir ad değişikliğinden sonra — sabit bir iş e-postası, doğrudan numara ve etkinlik geçmişi de hizalanıyorsa tek kişiye ait olabilir. Sınıflandırma satırların görsel benzerliğini değil kanıtı izlemelidir.
Ana kaydı bilinçli seçin
En eski kayıt otomatik kazanmamalıdır. En yeni de. Hayatta kalan kaydı belgelenmiş bir öncelik sırasına göre seçin: geçerli rıza ve bastırma durumu, aktif sahiplik, açık fırsat ilişkileri, doğrulanmış iletişim ayrıntıları, eksiksiz atıf ve güvenilir kaynak kökeni.
Sonra alan alan karar verin. Doğrulanmamış bir telefon numarası yerine doğrulanmış olanı tutun; yararlıysa önceki unvanı geçmişte saklarken güncel unvanı koruyun; ana kayıtta oturan değer yerine en kesin edinim kaynağını seçin. Daha yeni diye bir abonelik iptalini, arama yapmayın durumunu ya da hukuki dayanak kaydını daha az kısıtlayıcı bir değerle asla üzerine yazmayın.
Sahiplik de açık bir kural ister. Bir kayıtta aktif bir fırsat varken diğeri yeni atanmış bir temsilciye aitse, CRM birleşik geçmişi sessizce yanlış kişiye yönlendirmesin diye birleştirmeden önce sahipliği belirleyin. Net pipeline aşama tanımları, mükerrer kayıtlar farklı aşamalardayken bu kararları kolaylaştırır.
Geçmişi, atfı ve bağlı nesneleri koruyun
Bir birleştirme görünen iletişim alanlarından fazlasını değiştirebilir. E-postaları, aramaları, toplantıları, notları, görevleri, kampanya üyeliğini, form gönderimlerini, lead kaynağı ayrıntılarını, puanlama olaylarını, fırsatları, teklifleri, biletleri, özel nesneleri, ekleri ve rıza kayıtlarını gözden geçirin. CRM’inizin her nesne türünü taşıyıp taşımadığını, birleştirip birleştirmediğini, yok sayıp saymadığını ya da silip silmediğini belirleyin.
Atfa özellikle dikkat edin. Bir kayıt bir webinardan, diğeri sonraki bir demo talebinden gelmiş olsun. Tek bir “lead source” seçmek ilk temas ile dönüşüm teması arasındaki ayrımı silebilir. Bir olayı diğerinin yerine zorlamak yerine ikisini de uygun alanlarda ya da kampanya geçmişinde koruyun.
Mükerrerin nereden çıktığını da izleyin. Tekrarlanan form gönderimleri, güncelleme yerine oluşturma kullanan bir entegrasyon, tutarsız e-posta normalleştirmesi ya da sabit dış kimlikler olmadan içe aktarmalar temizlikten sonra sorunu yeniden üretir. Form trafiği söz konusuysa alan eşlemesi ve kayıt oluşturmayı incelemek için web formundan CRM’e teşhis sürecindeki kontrollere bakın.
Birleştirme öncesi etki kontrolü çalıştırın
Birleştirmeyi onaylamadan önce hayatta kalan kayda ya da taşınan veriye tepki verebilecek her otomasyonu listeleyin. Buna atama kuralları, lead puanlama, besleme kaydı, satış dizileri, uyarılar, zenginleştirme işleri, pazarlama platformlarıyla eşitleme, bölge mantığı ve müşteri yaşam döngüsü güncellemeleri girebilir.
Güvenli bir işletim örüntüsü, prosedürü bir sandbox’ta ya da düşük riskli iç kayıtlarla test etmek, aday kayıtları dışa aktarmak ve kimliklerini yakalamaktır. Yüksek hacimli iş için önce küçük bir parti işleyin ve devam etmeden sonuçları uzlaştırın. CRM’iniz güvenilir bir geri alma sunmuyorsa dışa aktarma ve denetim günlüğü temel kurtarma referansları olur.
Birleştirmenin sahte bir “yeni lead” sinyali üretmesine izin vermeyin. Mümkün olduğunda gereksiz bildirimleri ve dizi kaydını bastırın, sonra hayatta kalan kaydın yeniden puanlanmadığını, yeniden atanmadığını ya da uygunsuz bir yaşam döngüsü aşamasına taşınmadığını doğrulayın.
Bu inceleyen kontrol listesini kullanın
- Kimlik: Mevcut tanımlayıcı kanıt, ciddi bir çelişki olmadan yeterince güçlü mü?
- Normalleştirme: E-posta, telefon, şirket ve alan adı değerleri normalleştirilmiş biçimde mi karşılaştırıldı?
- İlişki kontrolü: Bunlar meslektaş, akraba, asistan ya da paylaşılan bir gelen kutusunun kullanıcıları olabilir mi?
- Ana kayıt seçimi: Hayatta kalan kayıt yaşa ya da kolaylığa göre değil politikaya göre mi seçildi?
- Alan haritası: Her önemli alan için kazanan değer belgelendi mi?
- Kısıtlar: Tüm vazgeçmeler, rıza kanıtı ve iletişim kısıtları hayatta kalacak mı?
- Geçmiş: Etkinlikler, kampanyalar, formlar, notlar, dosyalar ve atıf erişilebilir kalacak mı?
- Gelir nesneleri: Fırsatlar, teklifler, siparişler ya da abonelikler kontrol edildi mi?
- Sahiplik: Birleştirme sonrası sahip doğru mu ve değişiklikten haberdar mı?
- Otomasyon: Birleştirme yönlendirme, puanlama, diziler ya da yaşam döngüsü değişiklikleri tetikleyebilir mi?
- Kurtarma: Özgün kimlikler, dışa aktarmalar ve inceleyenin kararı kaydedildi mi?
- Önleme: Mükerreri oluşturan süreç ya da entegrasyon belirlendi mi?
Kararı belgeleyin ve yinelenmeyi önleyin
Aday kimliklerini, incelenen kanıtı, sınıflandırmayı, ana kayıt seçimini, önemli alan kararlarını, inceleyeni ve tarihi kaydedin. Birleştirmeme için “aynı şirket, farklı kişi” gibi bir neden ekleyin ki çift ayrışmamış bir kuyruğa tekrar tekrar dönmesin.
Tespiti iyileştirmek için inceleme sonuçlarını kullanın. Çok fazla yanlış pozitif, eşleşme ölçütlerinin geniş olduğu anlamına gelebilir; kaçırılan mükerrerler normalleştirilmemiş telefon numaralarını, e-posta takma adlarını ya da eksik dış kimlikleri ortaya çıkarabilir. Otomatik ele almayı elle ele almadan ayırın: otomatik birleştirmeye hiç izin veriliyorsa bunu CRM’inizin saklama, otomasyon ve kurtarma davranışına karşı test edilmiş dar tanımlanmış durumlarla sınırlayın; belirsiz çiftleri bir inceleyene gönderin.
En güvenli kural basittir: birleştirme kozmetik bir temizlik işi değil, kimlik ve veri yönetişimi kararıdır. Kanıt güçlüyse doğru kaydı ve tam bağlamını koruyun. Kanıt zayıfsa belirsizlik geri alınamaz bir birleştirmeden daha ucuzdur.
