Alım sinyalinden ilk e-postaya: tetikleyici olayları seçmek ve sınamak

Tetikleyici olay, bir hesabın sattığınız şeye yakın zamanda ihtiyaç duyma ihtimalini değiştiren gelişmedir. Yeni bir satın alma direktörü, ürününüzün hizmet ettiği ekipte bir işe alım dalgası, yeni bir ülkeye açılma. Fikir eski ve sağlamdır. Yine de çoğu tetikleyici programı öngörülebilir nedenlerle hayal kırıklığı yaratır: teknik olarak haber sayılan her şey için alarm üretir, olayları yanlış hesaba bağlar ve kimse olayın gerçek, güncel ve anılmaya uygun olup olmadığını kontrol etmeden otomatik bir e-posta dizisini çalıştırır. Bu rehber önemli olayların nasıl seçileceğini, gürültünün nasıl düşük tutulacağını, her olayın doğru hesaba nasıl bağlanacağını ve olay ile temas arasında bir insanın nasıl tutulacağını anlatıyor.

Tetikleyici bir manşet değil, bir gerekçedir

Bir olay türünü eklemeden önce desteklemesi gereken cümleyi yazın: “Bu olduğu için muhtemelen şu zaman aralığında şuna ihtiyaç duyacaklar.” Üç parçayı da dolduramıyorsanız olay ilginç olabilir, ama bir tetikleyici değildir.

En iyi filtre kendi geçmişinizdir. Kazandığınız anlaşmalara bakın ve ilk temastan önceki aylarda o hesaplarda ne olduğunu sorun. Tekrar tekrar karşınıza çıkan olaylar bir kuralı hak eder; hiç çıkmayanlar bekleyebilir. Yatırım ve birleşme-satın alma olayları ayrı bir ele alışı hak eder; bunu yatırım turlarını ve satın almaları izleme rehberi anlatıyor. İşten çıkarmalar ve diğer kötü haberler ise özel bir özen ister: gerçek bir ihtiyaç olabilir, ama birinin talihsizliğiyle açılan bir mesaj nadiren iyi karşılanır.

Gürültü kontrolü

Bir tetikleyici akışı, aynı basın bülteni için beş alarm gönderdiği ilk hafta ekibin güvenini kaybeder. Gürültü birkaç tanıdık yerden gelir ve her birinin bir kontrolü vardır:

• Asla satış yapmayacağınız hesaplar. Önce hedef listenize göre süzün, sonra olay arayın. Tüm dünyada olay tarayıp uygunluğu sonradan kontrol etmek hacim üretir, satış fırsatı değil. O listeyi kurmak ayrı bir iştir; ideal müşteri profilinize uyan şirketleri bulma yazısına bakın.
• Tekrarlar. Kopya bültenler, yeniden yazımlar ve iki ayrı kurala takılan tek bir olay. Hesap, olay türü ve tarih aralığına göre tekilleştirin.
• Belirsiz kurallar. “Herhangi bir yeni iş ilanı” gürültüdür. “Satın alma operasyonları rolü için yeni bir ilan” ise bir sinyaldir.
• Bayat olaylar. Her olay türüne bir raf ömrü verin ve süresi dolan olayları otomatik olarak düşürün. Yeni bir e-postadaki eski bir tetikleyici özensiz görünür.
• Kötü zamanlama. Açık fırsatı, yakın zamanda görüşmesi ya da “iletişime geçme” işareti olan hesaplar için tetikleyicileri bastırın.
• Bölünen dikkat. Her olay için ayrı bildirim yerine her hesap sahibine günlük ya da haftalık bir özet gönderin.

Ardından önemli olan tek şeyi ölçün: hangi alarmlar birinin bir şey yapmasına yol açtı. Birkaç döngü boyunca kimsenin üzerine bir şey yapmadığı bir kural yeniden yazılmalı ya da emekliye ayrılmalıdır. Örnek bir kural:

izle      hedef listedeki hesapların kariyer sayfaları; aktif anlaşması olan hesaplar hariç
soru      hesap satın alma ya da finans operasyonlarında yeni bir pozisyon açtı mı?
önemli    bu rollerden biri için yeni ilan; kaldırılan bir ilan
yok say   metin düzeltmeleri, aynı rolün yeniden yayımlanması, bu ekipler dışındaki roller
sıklık    haftalık, pazartesi 09:00, Europe/Istanbul
bildirim  hesap sahibine haftalık özet; aday şirkete hiçbir şey gönderilmez

Olayı doğru hesaba bağlamak

Yanlış hesaba bağlanmış bir olay, hiç olay olmamasından kötüdür. İşin genellikle bozulduğu yer ad eşleştirmesidir: iki şirket aynı adı taşır, bir bağlı ortaklık ana şirketin yapmadığı bir şeyi duyurur, bir şirket marka değiştirir ya da bölgesel bir birimin kendi web sitesi vardır. Bunun yerine olayları kalıcı tanımlayıcılar üzerinden bağlayın:

1. Şirketin alan adı ve varsa sicil numarası üzerinden, ardından CRM hesap numaranız üzerinden eşleştirin.
2. Eşleşmenin nasıl yapıldığını (alan adı, sicil numarası ya da elle) olayın yanına kaydedin.
3. Belirsiz eşleşmeleri asla doğrudan satış temsilcisine değil, bir inceleme kuyruğuna gönderin.
4. Bir bağlı ortaklıktaki olayların ana şirket hesabına yansıyıp yansımayacağına açıkça karar verin. Kuralı yazın ki bir çalıştırmadan diğerine değişmesin.

Bağlanmış bir olay, temsilcinin onu birkaç saniyede kontrol etmesine yetecek bilgiyi taşımalıdır:

olay:       yeni_satin_alma_direktoru
hesap:      crm-00123 (alan adıyla eşleşti)
kaynak:     https://example.com/news/leadership-update
alinma:     YYYY-AA-GG
kanit:      Yeni Satın Alma Direktörümüzü aramızda görmekten mutluluk duyuyoruz ...
bitis:      YYYY-AA-GG
durum:      inceleme_bekliyor

Yönetim değişikliği olayları adı belli bir kişiyi içerir. Yalnızca temasın gerektirdiği bilgiyi saklayın, kaynağı tutun ve kullanımınızın KVKK ya da GDPR gibi size uygulanan gizlilik mevzuatı kapsamında hukuki bir dayanağı olduğundan emin olun.

Olaydan temasa, arada bir insanla

Akla ilk gelen tasarım tetikleyiciyi doğrudan bir e-posta dizisine bağlar: olay tespit edildi, e-posta gitti. Bu tasarım tam da en çok zarar veren durumlarda çöker. Olay yanlış şirkete atfedilmiştir, zaten eskidir ya da hassastır; veya üretilen mesaj kimsenin sahip olmadığı bir yakınlık iddia eder. Araya bir inceleme adımı koyun:

1. Alarm, kanıtı ve hesap eşleşmesiyle birlikte gelir.
2. Hesap sahibi harekete geçmeye, beklemeye ya da atmaya karar verir. Atılan alarmlar gerekçesiyle kaydedilir, çünkü hangi kuralların düzeltilmesi gerektiğini gösterirler.
3. Hesap sahibi harekete geçerse mesajın taslağını bir ajan hazırlar. Taslak olaya doğru biçimde değinir, okumadığı hiçbir şeye bağlantı vermez ve bildiklerinizi abartmaz.
4. Hesap sahibi taslağı gönderilmeden önce onaylar, düzenler ya da reddeder.
5. Sonuç tetikleyici türüne göre kaydedilir; böylece zamanla hangi tetikleyicilerin gerçek görüşmelere yol açtığını görürsünüz.

Mesaj başına bu yöntem tam otomasyondan yavaştır. Ama yanlış bir mesajın bedeli, incelemenin aldığı bir dakikadan fazladır: aday sizi artık o mesajla hatırlar, temizliği de satış temsilcisi üstlenir. Bir ajanın neden harekete geçmeden önce sorması gerektiği notu bu duraklamanın arkasındaki mantığı anlatıyor. Tetikleyicilerin hesap verisine daha geniş açıdan nasıl oturduğu için CRM hesaplarını açık web verisiyle zenginleştirme yazısına bakın.

GoCux nerede devreye girer

GoCux webde arama yapmaz ya da webi taramaz; bir tetikleyici veri sağlayıcısı da değildir. Web sayfaları bir projeye yalnızca birinin yetki verdiği bir tarama ya da dışa aktarma adımıyla girer ve özgün sayfa referansı ile alınma tarihini korur. GoCux'un incelenebilir tuttuğu şey, sinyalden gönderilen mesaja uzanan zincirdir.

FindAll, ölçütlerinizden ve sütunlarınızdan bir hedef listesi kurar; her satır kendi kanıtını taşır, kapsama sınırları gizlenmez, açıkça belirtilir. Pulse, tetikleyici sorunuzu seçtiğiniz kaynaklar üzerinde bir takvimle çalıştırır; tanımı tam bir sürüm olarak onaylanır, her çalıştırma değişiklik değişiklik incelenir ve tespit edilen bir değişiklik asla kendi başına harekete geçmez. Yanıtlar, çalışma alanından bir şey çıkmadan önce incelenmek üzere bir yanıt hazırlar; dışarı gönderim her zaman durur ve hesap sahibi onaylayabilir, güvenli bir düzenleme yapabilir ya da reddedebilir. Bu parçaları bir arada satış çözümü sayfasında görebilirsiniz.

Tetikleyici alarmlarını açmadan önce kontrol listesi

• Her olay türü için yazılmış bir “bu oldu, şu aralıkta şuna ihtiyaç duyacaklar” cümlesi var.
• Olaylar yalnızca hedef hesap listeniz içinde aranıyor.
• Tekrarlar hesap, olay türü ve tarih aralığına göre birleştiriliyor.
• Her olay türünün bir raf ömrü var ve süresi dolan olaylar hiçbir taslağa ulaşmıyor.
• Aktif anlaşmadaki, yakın zamanda temas kurulan ya da “iletişime geçme” işareti taşıyan hesaplar bastırılıyor.
• Olaylar hesaplara alan adı ya da sicil numarasıyla bağlanıyor ve eşleşme yöntemi kaydediliyor.
• Bir insan kanıtı görüp taslağı onaylamadan hiçbir mesaj gönderilmiyor.
• Kimsenin üzerine bir şey yapmadığı kurallar yeniden yazılıyor ya da emekliye ayrılıyor.