CRM Veri Zenginleştirme

Zenginleştirme, elinizde zaten bulunan bir tanımlayıcıyı kimsenin yazmadığı niteliklere çözer. CRM bir e-posta adresini veya şirket alan adını sağlayıcıya gönderir, sağlayıcı bir kişi kaydı ile bir kurum kaydı döndürür ve bir eşleme seçilen alanları hem kişiye hem de bağlı olduğu hesaba yazar. İki yazma deseni vardır: ekleme yalnızca boş alanları doldurur, üzerine yazma ise mevcut değeri değiştirir. Hangisinin hangi alanda geçerli olacağı bilinçli bir yapılandırma kararıdır, körü körüne kabul edilecek bir varsayılan değil.

Değeri eşleşme oranı ile alan önceliği belirler. Kurumsal alan adı temiz çözülür; ücretsiz e-posta adresi sağlayıcıya neredeyse hiçbir şey vermez, bu yüzden tüketici ağırlıklı listelerde kapsam incelir. Birkaç sağlayıcıyı arka arkaya çalıştırmak eşleşmeyi artırır ama kayıt başına maliyeti katlar ve birinin karar vermesi gereken çelişkili değerler üretir. İkinci kaldıraç kapsamdır: hesabı bir kez zenginleştirip nitelikleri kişilere indirmek, her kişiyi ayrı ayrı zenginleştirmekten ucuzdur ama kıdem gibi kişi düzeyi ayrıntıyı kaybettirir.

Genellikle iki iş yan yana çalışır. Bir kayıt oluşturulduğunda gerçek zamanlı bir sorgu tetiklenir, böylece yönlendirme ve skorlama anında veriye sahip olur; planlı bir tamamlama işi ise belirlenen yaştan eski kayıtları yeniden işler. Ekipler sağlayıcı çıktısını kişinin kendi yazdığı verilerden ayrı, kendi alanlarında tutar; böylece eski bir değer sessizce beyan edilmiş bir değeri itmez. Bir Pivix quizi yalnızca e-posta topladığında zenginleştirme, skorlama kurallarının okuduğu şirket büyüklüğü ile sektörü sağlar.

Zenginleştirme verisinin çoğu şirketi tarif eder ve sonra bir kişiye uygulanır; bu yüzden büyük bir işveren gösteren kayıt, satın alma yetkisi olmayan küçük departman hakkında hiçbir şey söylemez. Unvanlar diğer tüm alanlardan hızlı eskir ve eski yöneticileri sessizce karar verici segmentine taşır. Kapsam bölgeye göre değişir ve küçük yerel firmalarda en incedir. Ayrıca zenginleştirme nitelik ekler, izin değil: hiç etkileşime girmemiş birine veri eklemek entegrasyonun yanıtlamadığı bir yönetişim sorusudur.

Eşleşme oranıyla başlayın ve onu toplamda değil alan bazında ölçün, çünkü bir sağlayıcı şirketi çözüp yine de kıdem bilgisi döndürmeyebilir. Buna skorlama ve yönlendirme kurallarınızın gerçekten okuduğu alanların doluluk oranını ekleyin, çünkü davranışı yalnızca onlar değiştirir. Toplam sağlayıcı harcamasını eşleşen kayıt sayısına bölmek, ikinci bir sağlayıcıyı haklı çıkaracak birim maliyeti verir.

Doğruluk örnekleme ister: her ay birkaç düzine zenginleştirilmiş kaydı çekip unvan ve şirket büyüklüğünü kamuya açık kaynaklarla karşılaştırın. Ardından eşleşen ve eşleşmeyen leadler arasında görüşme ve kazanma oranı gibi sonuçları kıyaslayın. Son zenginleştirme tarihi yenileme aralığınızdan eski olan kayıtların payını da izleyin, çünkü fark edilmeyen eskime orada birikir.

İlk hata, sık sık boş kalan bir alan üzerinden skorlamak veya yönlendirmektir. Çalışan sayısı iki yüzün üzerinde diyen bir kural, eşleşmeyen her kaydı sessizce yanlış dala gönderir; oysa eşleşmeyen kayıtlar çoğu zaman sıra dışı alan adına sahip iyi leadlerdir. Boş değeri küçük değil bilinmiyor sayın, ona kendi dalını verin ve kuralın gerçekten dayandığı alan için formda yedek bir soru bırakın.

İkinci hata, deneme çalışması yapılmadan yürütülen toplu tamamlamadır. Biri sağlayıcıyı üzerine yazma açıkken tüm veritabanına yöneltir ve yıllarca elle düzeltilmiş unvanlar tek bir işte kaybolur. Önce bir örneklem üzerinde çalıştırın, önerilen değerleri kayıtlı olanlarla karşılaştırın ve hangi alanların üzerine yazılabileceğini teyit edin. Her zenginleştirilmiş alana sağlayıcı adı ile sorgu tarihini damgalayın.