Mükerrer müşteriler: birleştirmeden önce ne karşılaştırılmalı?

Mükerrer müşterileri incelemek için önce her kaydın kimliğini ve işlevini karşılaştırın; ardından birleştirmenin gerekli olup olmadığına karar verin. Satışta bir kayıt ve faturalandırmada başka bir kayıt doğru olabilir. Eksik olan şey belki de ikisi arasında güvenilir bir eşleştirmedir.

Sorun, yönetim benzer iki geçmiş bulduğunda ve birisi “en eksiksiz olanı” saklamayı teklif ettiğinde ortaya çıkar. Bir kayıt mevcut kişiyi içerebilir; diğeri ise bir entegrasyon tarafından kullanılan referansları. Doldurulan alan sayısına göre seçim yapmak bu çatışmayı çözmez. Bu kılavuz, durumu değiştirmeden önce incelemek için bir matris ve bir karar kaydı sunar.

Her araç için bir kayıt doğru olabilir

İki sistemde temsil edilen aynı varlık ile bir sistem içindeki gereksiz yere yinelenen iki kayıt arasında ayrım yapın. İlk durum bir eşleştirme haritasına ihtiyaç duyabilir; ikincisi ise mükerrer kaydın kökeni hakkında bir araştırmaya. Hiçbiri bir satırı adına göre silme yetkisi vermez.

Her kaydın neyi temsil ettiğini de tanımlayın: kuruluş, ilgili kişi, şube veya ticari hesap. Bir şirkette çalışan bir kişi, o şirketin bir mükerreri değildir. İki şube de, işletmeniz onları ayrı ayrı ele almayı gerektiriyorsa birleştirilmemelidir.

Bu inceleme bir geçişin hazırlanmasına (İngilizce) uyar, ancak araç değiştirmeden de kullanılabilir. Sonucu, iki kaydı korumak ve ilişkilerini açıklamak olabilir.

Normalleştirmeden önce kaynağı koruyun

Salt okunur bir kopya üzerinde çalışın. Her satır için sistem, çalışma alanı, kayıt türü, orijinal tanımlayıcı ve çıkarma tarihini kaydedin. CRM / W1 / account / A17, BILL / W1 / account / A17’den farklı bir şeyi tanımlar: numarayı tekrarlamak, aynı müşteri olduğunu kanıtlamaz.

Orijinal değerleri koruyun ve boşlukları, büyük harfleri veya bilinen ad varyantlarını karşılaştırmak için yardımcı sütunlar oluşturun. Varlıkları ayırt edebilecek sonekleri, departmanları veya referansları silmeyin. Boş bir alan “veri yok” anlamına gelir, “başka bir boşla eşleşiyor” anlamına gelmez.

Her sinyalin nereden geldiğini not edin. Ortak bir kod, kimin atadığını biliyorsanız ve eşleştirmesini doğruladıysanız daha değerlidir. Hatalı bir içe aktarmada kopyalanan bir kod, aynı hatayı iki kayda da yayabilir. Son düzenleme tarihi de bir değeri otomatik olarak doğruya çevirmez.

Üç sonuç ve dört durum içeren bir matris

Aşağıdaki örnek tamamen kurgusaldır. Tüm kayıtlar W1 alanına aittir; ORG ve EV kodları alıştırma referanslarıdır, vergi kimlikleri veya müşteri verileri değildir. Açıklanan kanıtların yalnızca akıl yürütmeyi göstermek için mevcut olduğu varsayılır.

Uydurma güven yüzdeleri atamayın. “Olası”, bir incelemeyi başlatır: onaylanmış bir birleştirme değildir. “Belirsiz”, engellemeyi korur ve neyin eksik olduğunu açıklar. Kimliği onayladığınızda bile, bir şeyi değiştirmenin gerekli olup olmadığına karar vermek kalır.

Bir kayıtta sipariş olmaması da fazlalık olduğunu kanıtlamaz: yakın zamanda oluşturulmuş bir kayıt veya başka bir işlevi temsil ediyor olabilir. Kanıtlarla sınıflandırın, boş alan sayısıyla değil.

Takma ad haritası bir birleştirme gerçekleştirmez

Sorumlunun ilk durumu çözdüğünü varsayalım: A17 ve B62, ORG-07’yi temsil ediyor, ancak her iki araç da kendi kaydına ihtiyaç duyuyor. Karar, bunları korumak ve eşleştirmelerini kaydetmektir. Ayrı bir sayfada, ENTITY-F07 çalışma referansınız olabilir:

system,workspace,record_type,source_id,entity_key,review_id
CRM,W1,account,A17,ENTITY-F07,R-01
BILL,W1,account,B62,ENTITY-F07,R-01

Bu sütunlar kendi şablonunuzdur, Frihet’in bir içe aktarma formatı veya bir bağlayıcı için bir komut değildir. entity_key incelenmiş kimlikleri gruplandırır; source_id orijinal referansı korur. Bir takma ad, bir sayfada var olduğu için araçları değiştirmez.

Kişileri, şirketleri ve şubeleri aynı anahtar altında düzleştirmeyin. Ve incelemeden geçişlilik yoluyla birleştirmeyin: eğer A, B’ye benziyor ve B, C’ye benziyorsa, A ve C’nin aynı olduğunu henüz kanıtlamamışsınız demektir.

Başka birinin inceleyebileceği bir karar kaydedin

Her çift için bu kaydı kopyalayın. Karar değiştiğinde önceki öneriyi koruyun, yerine yeni bir sürüm koyarak.

İnceleme: R-01 / sürüm 1
Tam Referanslar: CRM/W1/account/A17; BILL/W1/account/B62
Kanıt: EV-01; ORG-07 eşleştirmesi sorumlu tarafından doğrulandı
Çakışma: sorumlu kişi farklı; EV-05'te mevcut değer doğrulandı
Karar: her iki kaydı da koru ve ENTITY-F07 eşleştirmesini kaydet
İnceleme Sorumlusu: ROLE-OPS
Araçlardaki Eylem: hiçbiri
Bekleyen: bağlayıcının bu eşleştirmeyi nasıl kullandığını incele
Yerine geçtiği: önceki inceleme yok

Kodlar kurgusaldır. Gerçek kullanımda, incelemeyi yapacak kişinin erişebileceği kanıtlara başvurun ve gereksiz kişisel verileri sayfaya kopyalamaktan kaçının. Daha sonra bir değişikliğe izin verilirse, uygulayıcıyı, zamanı, önceki referansları ve gözlemlenen sonucu ayrı ayrı kaydedin. “Onaylandı”, “uygulandı” ve “doğrulandı” farklı durumlardır.

Bu geçmiş incelenebilir, ancak geri alma garantisi değildir. Yazılı bir kararı düzeltmek, zaten değiştirilmiş verileri otomatik olarak yeniden oluşturmaz.

Birleştirmeden önce sağlayıcıda neleri kontrol etmeli

Davranış ürüne ve kayıt türüne bağlıdır. HubSpot, bir birleştirmenin geri alınamayacağını ve tanımlayıcıların, özelliklerin ve ilişkilerin belirli kurallara uyduğunu belgeler. Ana olarak işaretlediğiniz kimliğin her zaman sağlam kalacağını varsaymayın.

Shopify da işlemin geri alınamaz olduğunu ve abonelik sözleşmeleri olan veya olmuş belirli profilleri hariç tuttuğunu belirtir. Bu örnekler Frihet’in veya diğer sağlayıcınızın davranışını tanımlamaz.

Geri döndürülemez herhangi bir işlemden önce şu soruların yanıtlandığından emin olun:

• Bu tür kombinasyonu destekleniyor mu ve uygun izinlere sahip misiniz?
• Hangi değerler korunur, hangileri atılır ve sonuç hangi kimliğe sahip olur?
• Geçmiş, ilişkiler ve dış referanslara ne olur?
• Senkronizasyon ne yapacak: değişikliği tanıyacak mı, bir kayıt yeniden oluşturacak mı yoksa başarısız mı olacak?
• Gerçekte hangi kurtarma mevcut ve kopyanız neyi kapsamıyor?

Entegrasyonların kapsamını (İngilizce) okuyun ve kullanılan bağlayıcının belgelenmiş davranışını kontrol edin. Bir okuma işlevi, birleştirmeleri yaymayı bildiğini kanıtlamaz.

Kaynağını da kontrol ederek durumu kapatın

Bir birleştirmeye izin verilirse, önce bağlı sistemler üzerindeki etkilerini nasıl sınırlayacağınızı kararlaştırın. Uyumlu bir test ortamında sentetik verilerle deney yapın; böyle bir ortam yoksa, sağlayıcıyla belirsizlikleri çözene kadar engellemeyi sürdürün. Tek başına bir dışa aktarım, her şeyi geri yükleyebileceğinizi kanıtlamaz.

Yetkilendirilmiş bir değişiklikten sonra, alanları ve referansları beklenilenle karşılaştırın ve partiyi genişletmeden önce bir sonraki senkronizasyonu gözden geçirin. Sonuç belirsizse, eylemi tekrarlamadan önce araştırın.

Frihet müşteri yönetimi bölümünde listenin CSV olarak dışa aktarımı mevcuttur. Bu, bir incelemeye giriş olarak hizmet edebilir; bu şablonun içe aktarılmasını veya müşterilerin otomatik olarak birleştirilmesini varsaymaz.

Mükerrer kaydın neden ortaya çıktığını not ederek kapatın: manuel giriş, içe aktarım veya bağlayıcı kuralı, eğer kanıt varsa. Henüz bilmiyorsanız, bir sorumlu ve bekleyen bir kontrol bırakın. Açık bir ilişkiyle korunan iki kayıt geçerli bir sonuçtur; açıklanabilir geçmişi olmayan daha kısa bir liste geçerli değildir.

14 Eylül 2026 tarihinde başvurulan kaynaklar. İşlem yapmadan önce sağlayıcınızın mevcut belgelerini inceleyin.