CRM’de aynı kişinin kayıtları çoğalabilir; ortak santral numarası kullanan iki çalışan ise yanlışlıkla tek kişi sanılabilir. Yapay zekâ, otomatik birleştiren otorite değil, kanıtıyla inceleme adayı öneren yardımcı olmalıdır. Yanlış birleştirme iletişim izni, teklif geçmişi ve sorumluluk bilgilerini etkileyebilir.

Bu rehber, benzer CRM satırlarını silmek yerine, kesin ve belirsiz adayları insan onayına ayıran yapay zekâ destekli bir akış kurmayı anlatır. CRM kapsamı için dijital pazarlama hizmetleri sayfasını inceleyebilirsiniz.

Önce kararın ne olduğunu tanımlayın

“Mükerrer”, aynı kişi, şirket veya satış fırsatı anlamına gelebilir; bu kararları karıştırmayın. Yalnız benzer adları arayan sistem, hangi kaydın tekilleştirileceğini cevaplamaz. Başta karar nesnesini sabitleyin: bu yazıda kişi kaydı çifti inceleniyor.

Ardından her aday çifti için dört sonuç tanımlayın: “aynı varlık”, “muhtemelen aynı, insan incelemesi gerekli”, “farklı varlık” ve “yetersiz kanıt”. Sonuçların anlamı ekipçe yazılı hale getirildiğinde, modelden istenen şey de ölçülebilir olur. Örneğin aynı telefon numarasını paylaşmak tek başına “aynı kişi” kararı değildir; bu yalnızca kontrol edilmesi gereken bir sinyal olabilir.

Kaydı değil, karşılaştırma alanlarını hazırlayın

Analizden önce her kaydın değişmeyen iç kimliğini saklayın. İsim, telefon, e-posta, şirket, kaynak form, kayıt tarihi ve son güncelleme gibi alanları ayrı tutun. Ham değeri silip yalnızca normalize edilmiş değeri bırakmayın. Telefonu ülke koduna göre standartlaştırmak veya e-postadaki boşlukları temizlemek karşılaştırmayı kolaylaştırabilir; ancak özgün değerin korunması, sonradan neden eşleşme önerildiğini anlamayı sağlar.

Alanların yanında kaynak, görülme tarihi ve doğrulayan rolü bulunsun; eski kayıt her zaman güncel değildir. Eksik alanları tahmin ettirmek yerine “bilinmiyor” olarak bırakın.

Kişisel veriyi modele göndermeden önce gerçekten gerekli olan alanları belirleyin. Deneme için sentetik kayıtlar veya yeterince maskelenmiş örnekler kullanın; maskeleme yaparken iki kayıt arasındaki ilişkiyi farkında olmadan bozmadığınızı kontrol edin. Örnek veri hazırlama konusundaki maskelenmiş örneklerde kişi ve kayıt ilişkisini koruma rehberi, bu kontrolü planlamaya yardımcı olur. Kullanılan hizmetin veri işleme, saklama ve erişim ayarlarını da kurumunuzun kurallarına göre ayrıca inceleyin.

Eşleşme sinyallerini birlikte değerlendirin

Güvenilir bir aday listesi tek bir alanın benzerliğine dayanmaz. Ad ve soyadın yazım yakınlığı, doğrulanmış e-posta, telefon, şirket ilişkisi, adres, son temas zamanı ve kayıtların nasıl oluştuğu birlikte ele alınabilir. Her sinyalin neden yararlı olduğu açıklanmalı; birbiriyle çelişen bilgiler de görünür kalmalıdır. Modelin “aynı kişi” demesi, dayanak alanlarını göstermediği sürece inceleyen kişiye yeterli kanıt sunmaz.

Ortak kullanılan santral, mağaza hattı veya aile telefonu yanlış pozitif yaratabilir. Aynı şirket alan adı da çalışanları tek kişi yapmaz. Öte yandan e-postadaki küçük bir yazım farkı, takma ad ya da eski soyadı gerçek bir eşleşmeyi gizleyebilir. Bu nedenle tek bir evrensel puan eşiği aramayın. Kurumun veri yapısı, kayıt türü ve bir yanlış birleştirmenin sonucu değiştikçe kabul edilebilir eşik de değişir.

Öneri çıktısında eşleşme nedenini kısa ve denetlenebilir biçimde isteyin: hangi alanlar aynı, hangileri farklı, hangi bilgi eksik, hangi çelişki kararı durdurmalı? Sonucun yanında kaynak alanları ve özgün kayıt kimlikleri gösterilmelidir. Uydurulmuş gerekçe veya görünmeyen “güven puanı” tek başına karar kanıtı sayılamaz.

Üç inceleme kuyruğu kurun

İlk kuyruk, birkaç bağımsız ve güncel alanı uyuşan yüksek güvenli adaylardır. Bunlar dahi otomatik olarak birleştirilmemeli; yetkili kişi iki kaydı ve işlem geçmişini görüp onaylamalıdır. İkinci kuyruk, ad benzerliği olup e-posta veya şirket bilgisi uyuşmayan, ya da bir alanı eksik olan çiftlerdir. Bu kayıtlar “beklemede” kalmalı; gerektiğinde sorumlu ekipten doğrulama istenmelidir.

Üçüncü kuyruk, aynı şirketteki farklı çalışanlar gibi açıkça ayrı kayıtları içerir. Bunlar yanlış eşleşme örneği olarak testte tutulmalı; veriye erişim ve saklama kuralları kurum içinde belirlenmelidir. Model, izin veya politika kararı veremez.

Her karar için “birleştir”, “ayrı bırak”, “daha fazla bilgi iste” ve “incelemeden çıkar” gibi açık eylemler sunun. Kayıt birleştirmek kullanıcı iletişimini veya izin durumunu etkileyebilecekse, yalnız kişi benzerliğine göre bu alanları taşımayın. Hangi alanın hangi kaynaktan geldiği ve hangi kaydın yetkili kaynak sayıldığı ayrıca belirlenmelidir.

Yapay zekâya verilecek görevi sınırlandırın

İstekte karar nesnesini kişi kaydı çifti olarak sabitleyin: “İki kaynak kayıt kimliği aynı kişiye mi ait, farklı kişilere mi ait, muhtemelen aynı ama inceleme mi gerekli, yoksa kanıt yetersiz mi? Bu dört sonuçtan birini seç. Yalnız verilen alanlardan dayanak göster; ortak telefon veya şirket alan adını tek başına eşleşme sayma. Çelişki veya eksik kanıtta birleştirme önerme. Her iki kaynak kimliğini, dayanak alanlarını, çelişkiyi ve sonraki adımı ver. Alan değiştirme, bilgi uydurma.”

Bu istek, modelin eşleştirmeyi uygulama izni değildir. Sistem yalnız adayları inceleme kuyruğuna bırakmalı; canlı CRM’de kayıt birleştirme yetkisi ayrı, sınırlı ve kayıt altına alınan bir işlem olmalıdır. Model çıktısı beklenen biçime uymuyorsa veya gerekçesi kaynak alanlarla doğrulanamıyorsa, çıktıyı otomatik işleme sokmayın.

Temsili örneklerle hata türlerini ölçün

Denemeye kolay tekrarların yanında ortak şirket telefonu kullanan çalışanlar, yazımı değişen adlar, aynı isimli farklı kişiler, boş e-posta ve eski telefon gibi zor çiftleri katın. CRM’yi bilen biri doğru sonucu önceden etiketlesin; modelin önerisi kendi ölçütünü belirlemesin.

Doğru adayları, yanlış eşleşme adaylarını ve kaçırılan tekrarları ayrı sayın. Yanlış birleştirmeler kritik olabileceğinden çözümsüz kalan çiftleri ve inceleme süresini de izleyin. Başarı, çok öneri değil, ekibin güvenle karar verebildiği öneridir.

Testleri aynı sabit örnek setinde tekrarlayın ve model, istem, ayar veya veri hazırlığı değiştiğinde sonuçları karşılaştırın. Değişiklikleri not edin; eşik değerini sessizce değiştirip önceki performansla aynıymış gibi sunmayın. Bir test, gerçek çalışma koşullarını temsil etmiyorsa kapsamını açıkça sınırlayın. Ürün veya teslimat kayıtlarını başka türde eşleştirmeniz gerekiyorsa, sipariş, teslimat ve fatura satırlarını kanıtla eşleme rehberi farklı bir mutabakat problemine odaklanır.

Birleştirmeyi aşamalı ve geri alınabilir yapın

Önce gerçek verinin kopyasında yalnız öneri üretin; CRM yazma yetkisini kapalı tutun. İlk canlı pilot birleştirmesinden önce yalıtılmış kopyada birleştirmeyi geri alma yöntemini deneyin; bağlı kayıtların da döndüğünü doğrulayın. Geri alma kanıtlanamıyorsa canlıya yazmayın, aday incelemesiyle sınırlı kalın. Ekranda iki kaydın kaynak alanlarını ve çelişkilerini yan yana gösterin; tek puan uyuşmazlığı gizlemesin.

Geri alma testi başarılı olduktan sonra, yetkili onayıyla küçük pilotu başlatın. İki kaynak kimliğini, seçilen ana kaydı, alan kararlarını, onaylayanı ve zamanı kaydedin. Pilot sonunda müşteri geçmişi, izin, sorumlu kişi ve kampanya ilişkilerini kontrol edin. Bir anormallikte işlemi durdurup test edilmiş geri alma yolunu kullanın.

Yetkiyi rol bazında ayırın: aday görme, öneriyi onaylama ve gerçek birleştirme farklı kişilerde ya da açık izin seviyelerinde olabilir. Toplu işlemden önce kayıt sayısı, etkilenen alanlar ve örnek çiftler için son onay alın. Sistem belirsiz veya alışılmadık bir örnek gördüğünde “karar yok” diyebilmeli; bu, başarısızlık değil güvenli durma davranışıdır.

Bir çözümü seçerken neyi karşılaştırmalı?

Programları aday sayısıyla değil; kaynak alanı ve gerekçe göstermesi, yanlış adayı işaretleme, inceleme geçmişini dışa aktarma ve veri erişimini sınırlama imkânlarıyla karşılaştırın.

Veri işleme, saklama ve erişim koşullarını kurumunuzla inceleyin; belgelenmeyen özellikleri varsaymayın. “Yapay zekâ destekli” sözü denetim izi veya geri alma garantisi değildir. Kapsam ve sınırları karşılaştırmak için ürün farkları rehberine bakabilirsiniz.

Başlamadan önce karar kapısı

Pilot öncesi kayıt türünü, etkilenen alanları, örnekleri etiketleyecek rolü, modele gidecek veriyi, onay yetkisini ve durdurma ölçütünü yazın. Bunlar belli değilse otomasyondan önce veri tanımını netleştirin.

Pilot sonunda reddedilenleri, belirsiz çiftleri ve geri alınan kararları inceleyin. Ekip akışı anlayamıyorsa daha fazla otomasyon eklemeyin. Sistem karar sahibini ve kanıtı göstermeli, belirsizliği bildirmeli, yetkili onayı olmadan geri dönüşü zor değişiklik yapmamalıdır.

Sık Sorulan Sorular

İki kayıtta aynı telefon numarası varsa otomatik olarak birleştirilebilir mi?

Hayır. Numara santral, mağaza hattı, aile telefonu veya eski kayıt olabilir. Telefonu güçlü bir sinyal olarak değerlendirin, ancak kişi adını, e-posta veya şirket ilişkisini ve güncellik bilgisini de kontrol edin. Çelişki varsa kayıtları ayrı tutup insan incelemesine gönderin.

Yalnızca isim benzerliği üzerinden aday listesi üretmek yeterli midir?

İsim benzerliği ilk taramayı başlatabilir ama birleştirme kararı için yeterli kanıt değildir. Aynı isimli farklı kişiler bulunabilir; aynı kişi de farklı yazımlarla kayıtlı olabilir. Öneri ekranında en az birden fazla bağımsız alanı ve uyuşmazlıkları birlikte gösterin.

Modelden her kayıt çifti için bir güven puanı istemeli miyim?

Puan tek başına karar kuralı değildir. Modelin hangi alanlara dayandığını, hangi çelişkileri gördüğünü ve neden incelemeye ihtiyaç olduğunu da istemek gerekir. Eşiği sabit örneklerde test edin; farklı kayıt türlerinde aynı puanın aynı anlamı taşıdığını varsaymayın.

İnceleme kümesini nasıl oluşturmalıyım?

Doğru tekrarlar kadar yanlış benzerlikleri ve kararsız vakaları da ekleyin. Ortak telefon kullanan çalışanlar, aynı isimli farklı kişiler, değişen e-posta ve eksik alan gibi örnekleri CRM’yi bilen kişiler etiketlesin. Sentetik veya maskeli örneklerde ilişki yapısının bozulmadığını doğrulayın.

Model çıktısını doğrudan CRM’de birleştirme komutuna bağlayabilir miyim?

Model çıktısını doğrudan merge komutuna bağlamayın. Öneri ayrı kuyruğa düşsün; yetkili kişi kaynakları ve alan çakışmalarını görsün. Geri alma yöntemi yalıtılmış kopyada kanıtlanmadıysa canlı pilot da yalnız aday incelemesiyle sınırlı kalsın.

Birleştirme sırasında hangi kayıt korunmalı?

Her alan için hangi kaynağın yetkili olduğunu belirleyin; yalnız daha eski veya daha yeni olduğu için bir değeri seçmeyin. İzin durumu, sorumlu ekip ve işlem geçmişi ayrı kurallara tabi olabilir. Seçilen ana kayıt ve taşınan alanlar işlem kaydında görünmelidir.

Belirsiz adayları silmek mi, bekletmek mi gerekir?

Silmek yerine “yetersiz kanıt” veya “inceleme bekliyor” durumunda tutun. Böylece ekip daha sonra ek bilgi geldiğinde çifti yeniden değerlendirebilir ve yanlış negatifleri görebilir. Belirsiz vakaların sayısını ayrı izlemek, sistemin sınırlarını anlamaya yardımcı olur.

Bir pilotun başarılı sayılması için hangi ölçüleri izlemeliyim?

Yanlış eşleşme adayları, kaçırılan tekrarlar, insan incelemesine giden çiftlerin oranı, karar süresi ve geri alınan birleştirmeleri birlikte takip edin. Tek bir doğruluk oranı, riskli yanlış birleştirmeleri gizleyebilir. Kurumunuzun kabul edebileceği hata sınırını testten önce yazın ve değişiklikleri kaydedin.

Kişisel verileri nasıl test etmeliyim?

İlk denemelerde gerekli olmayan alanları çıkarmayı, sentetik veya uygun biçimde maskelenmiş örnekleri kullanmayı değerlendirin. Kullanılan programın veri işleme ve erişim koşullarını sorumlu ekiplerle inceleyin. Kurumunuzun saklama ve gizlilik kurallarını varsaymayın; bunları sistem seçiminden önce netleştirin.