Lead-Hesap Eşleştirme
Lead-hesap eşleştirme, bireysel bir lead'i CRM'deki doğru şirket (hesap) kaydına otomatik olarak bağlayan ve kişileri ait oldukları kurumların altında gruplayan süreçtir.
Önemli noktalar
- Eşleştirme; alan adından normalleştirilmiş ada ve zenginleştirme kimliğine uzanan güven sıralı bir şelaledir.
- Belirsiz sonuçlar inceleme kuyruğuna aittir, çünkü hatalı birleşmeyi geri almak pahalıdır.
- Kayıt oluşurken eşleştirmek yönlendirmeyi doğru tutar; gece toplu işleri sahibi geç atar.
- Tek bir kurum satın almalar ve ülke siteleri nedeniyle çoğu zaman birden çok alan adı kullanır.
- Başarılı bir eşleşme yalnızca kimliği doğrular, hesabın değerli olduğunu asla göstermez.
Derinlemesine
Eşleştirme, her biri kendi güven düzeyini taşıyan bir kurallar şelalesi olarak çalışır. İlk geçiş, e-posta alan adını bilinen hesaplara bağlı alan adlarıyla karşılaştırır. İkincisi, gönderilen şirket adını normalleştirir; karşılaştırmadan önce hukuki ekleri, noktalama işaretlerini ve büyük küçük harf farklarını temizler. Üçüncüsü, marka değişikliklerinden ve ülke alan adlarından etkilenmeyen bir zenginleştirme sağlayıcısının şirket kimliğini kullanır. Yüksek güvenle çözülen kayıt otomatik bağlanır; belirsiz sonuçlar tahmin edilmek yerine bir inceleme kuyruğuna düşer, çünkü yanlış bağlamayı geri almak eksik bırakmaktan zordur.
Doğruluk, işletmenin denetlemediği girdilere bağlıdır. Alıcıların kurumsal e-posta kullandığı bir pazarda eşleştirme temiz çalışır; kişisel webmail kullanılan bir pazarda alan adı kuralının üzerinde çalışacağı hiçbir şey kalmaz. Holding yapıları ve satın almalar, tek bir kurumun yanıt verdiği alan adı sayısını çoğaltır. Asıl denge bulanık katmandadır: ad benzerliği eşiğini gevşetmek kapsamayı artırır ama iki alakasız şirketi tek bir kayıtta birleştiren hatalı eşleşmeler üretir; eşiği sıkılaştırmak ise bu kez gerçek bir satın alma komitesini ikiye bölen yinelenen hesaplar bırakır.
Pratikte en önemli kural, eşleştirmeyi gece toplu işinde değil kaydın oluşturulduğu anda çalıştırmaktır; çünkü yönlendirme hemen devreye girer ve yanlış sahibe atanmış bir aday nadiren düzeltilir. Bu yüzden ekipler her hesap için alternatif alan adlarının açık bir haritasını tutar ve inceleme kuyruğuna sorumlu bir kişi ayırır. Aynı satın alma komitesinden birkaç kişi aynı skorkartı doldurduğunda, onların ayrı puanlarını tek bir hesap altında toplayan şey eşleştirmedir; böylece hesabın sahibi beş kopuk katılımcı yerine tek bir satın alma komitesi görmüş olur.
Eşleştirme kimliği çözer; hesabın peşine düşmeye değip değmediği hakkında hiçbir şey söylemez. Başarılı bir eşleşmeyi niteleme sinyali saymak bu ikisini karıştırmaktır. Çok küçük ya da tek kişilik işletmelerin olduğu pazarlarda da değer kaybeder; orada hesap katmanı arkasında komite olmayan bir yapı ekler. Genel ticari adların bol olduğu sektörlerde de zorlanır. Hatalı birleşmeler ayrı bir dikkat ister: iki alakasız şirket bir kez tek kaydı paylaşmaya başladığında faaliyet geçmişi, sahiplik ve raporlama yalnızca yavaş ve tamamen elle çözülebilecek biçimde kirlenmiş olur.
Pratikte örnek
Nasıl ölçülür
Ana sayı eşleşme oranıdır: yeni oluşturulan aday kayıtlarından insan müdahalesi olmadan bir hesaba bağlananların payı. Tek başına yanıltıcıdır, çünkü gevşek bir kural bu oranı şişirir; bu yüzden yanına, eşleşmiş kayıtlardan örneklem alıp elle kontrol ederek ölçülen kesinliği koyun. Elle inceleme gerektiren eşleşmelerin payını da ekleyin; bu, mevcut kural setinin her hafta ne kadar insan kapasitesi tükettiğini gösterir.
Eşleşme oranının gizlediğini sonraki sinyaller açığa çıkarır. Ayda kaç yeni yinelenen hesap oluştuğunu sayın; yinelenen kayıtlar, başarısız eşleşmelerin doğrudan bedelidir. Bir aday geldikten sonraki ilk günlerde yapılan sahip değişikliklerini izleyin; böyle bir değişiklik genellikle kaydın yanlış hesaba ya da hiçbir hesaba bağlanmadığı anlamına gelir. Bir eşleştirme kuralı gerçekten iyileştiğinde bu iki sayının da birlikte düşmesi beklenir.
Sık yapılan hatalar
Yalnızca e-posta alan adına güvenmek alışılmış başlangıç hatasıdır. Bir alıcı kişisel adres girene kadar işe yarar; o noktada kayıt ya eşleşmeden kalır ya da daha kötüsü, paylaşılan bir webmail alan adı yüzlerce alakasız kişiyi barındıran bir hesaba dönüşür. Alan adı kontrolünün arkasına normalleştirilmiş şirket adı kuralı ile bir zenginleştirme kimliği ekleyin ve kamuya açık webmail alan adlarının hiçbir hesabı oluşturmasına veya hesaba katılmasına izin vermeyin.
İkinci hata, bulanık ad benzerliğinin eşik ve insan kontrolü olmadan otomatik birleştirme yapmasına izin vermektir. Benzer ticari adlara sahip iki alakasız firma kaynaşır ve ortaya çıkan kayıt karışmış faaliyetleri, yanlış bir sahibi ve bozulmuş bir geçmişi taşır. Otomatik eşleştirme için net bir güven alt sınırı belirleyin, bu sınırın altındaki her şeyi inceleme kuyruğuna yönlendirin ve otomatik eşleşmelerden alınan aylık bir örneklemi elle denetleyin ki sapma birikmeden fark edilsin.
Sıkça sorulan sorular
Lead-hesap eşleştirmede hangi sinyaller kullanılır?
En yaygın sinyaller e-posta alan adı, şirket adı ve firmografik gibi üçüncü taraf zenginleştirme verileridir. Gelişmiş sistemler; bağlı şirketleri, takma adları ve ücretsiz e-posta alan adlarını ele almak için bulanık eşleştirme ve normalleştirme kullanır.
Lead-hesap eşleştirme ABM için neden önemlidir?
Hesap bazlı pazarlama bireyleri değil kurumları hedefler; bu nedenle bir şirketten gelen her kişinin tek bir hesap kaydına bağlı olması gerekir. Doğru eşleştirme, satışa tam bir satın alma komitesi görünümü verir ve parçalı erişimi önler.
Eşleştirme, gmail.com gibi ücretsiz alan adlarını nasıl ele alır?
Genel alan adları bir şirketi tanımlayamadığı için eşleştirme; belirtilen şirket adına, zenginleştirme verilerine ya da manuel incelemeye başvurur. Birçok ekip, ücretsiz alan adlı lead'leri bir hesaba atamadan önce ek niteleme için işaretler.
Lead-hesap eşleştirme pratikte nasıl çalışır?
Bir dizi kural, kişiyi bir şirket kaydına bağlamaya çalışır: önce e-posta alan adı, sonra normalleştirilmiş şirket adı, ardından bir zenginleştirme sağlayıcısından gelen şirket kimliği. Her kural bir güven düzeyi taşır. Yüksek güvenli sonuçlar otomatik bağlanır, düşük güvenli olanlar inceleme kuyruğuna gider ve hesap, o kişinin geçmişini tutan kapsayıcı haline gelir.
Neden yalnızca alan adı eşleştirmesi yeterli değildir?
Çünkü gönderimlerin kayda değer bir kısmı kişisel webmail adresleri kullanır ve bir kurum satın almalar sonrası veya ülkeler arasında sık sık birden fazla alan adına sahiptir. Alan adı eşleştirmesi ayrıca ikisi de aynı alan adını kullanıyorsa bir bağlı şirketi ana şirketten ayıramaz. Şelalenin tek kuralı değil ilk kuralı olmalı, webmail alan adları da dışlanmalıdır.
Adaylar ana şirkete mi bağlı şirkete mi eşlenmeli?
Sözleşmeyi imzalayan ve ticari ilişkiyi taşıyan tüzel kişiye eşleyin, sonra bunu bir hesap hiyerarşisiyle ana şirkete bağlayın. Böylece sahiplik ve gelir doğru kayıtta kalırken tüm grup üzerinden toplu raporlama da mümkün olur. Her şeyi doğrudan küresel ana şirkete eşlemek genelde kimsenin çalışamayacağı devasa tek bir hesap üretir.
Ücretsiz e-posta adresleriyle ne yapılmalı?
Kamuya açık webmail alan adlarını alan adı tabanlı eşleştirmenin tamamen dışında tutun, ardından formdaki şirket adı alanına veya kişi üzerinden yapılan bir zenginleştirme sorgusuna başvurun. İkisi de çözmezse kaydı bir yer tutucu hesaba bağlamak yerine eşleşmemiş bırakın. Şirket adını doğrudan formda sormak bu sorunun büyük kısmını daha başlamadan ortadan kaldırır.
Bunun için bir zenginleştirme sağlayıcısı şart mı?
Başlangıç için değil. Alan adı eşleştirmesi ile normalleştirilmiş şirket adları, kurumsal e-posta trafiğinin büyük bölümünü kapsar ve CRM içindeki kurallarla kurulabilir. Bir zenginleştirme sağlayıcısı, marka değişikliklerinden etkilenmeyen kalıcı bir şirket kimliği ve grup hiyerarşileri ekler; bu da özellikle hesap bazlı programlar ve karmaşık yapılar için önemlidir.
Eşleştirilemeyen adaylara ne olmalı?
Onları görünmez biçimde bekletmek yerine, sahibi ve düzenli gözden geçirme ritmi olan tanımlı bir eşleşmemiş durumda tutun. Bir şirket adı ya da zenginleştirilmiş bir ayrıntı geldiğinde çoğu çözülür. Kaçınılması gereken alternatif, her eşleşmeyen aday için otomatik yeni hesap açmaktır; bu, veri tabanını sonradan birleştirilmesi gereken tek kişilik hesaplarla doldurur.