Satış Nitelikli Lead (SQL)
Satış Nitelikli Lead (SQL), satışın incelediği ve bir anlaşmaya doğru aktif takibi haklı çıkaracak uyum, niyet ve zamanlamaya sahip olduğunu doğruladığı bir lead'dir.
Önemli noktalar
- Bu aşamadaki kabul, tahmine giren bir fırsat kaydı yaratır; ayırt edici yanı budur.
- Her aday kabul, gerekçeli ret ya da tarihli geri dönüş olarak sonlanmalıdır.
- Kota baskısı kabulü gevşetir ve talep değişmeden pipeline'ı şişirir.
- Yazılı devir kriterleri, takdir kararını iki ekibin denetleyebileceği bir şeye dönüştürür.
- Ulaşılamadı ile niteliksiz farklı ret nedenleridir ve zıt düzeltmeler gerektirir.
Derinlemesine
SQL adımı, satış sisteminin içinde bir kişi ya da onun yerine geçen bir kural tarafından verilen bir kabul kararıdır. Aday pazarlamadan veya doğrudan bir talepten gelir, biri onu işler ve üç sonuçtan tam olarak biri çıkar: kabul edilip fırsata dönüştürülür, gerekçesi belirtilerek reddedilir ya da bir tarihle beslemeye geri verilir. Bu aşamayı öncekilerden ayıran şey, kabulün bir değer ve beklenen kapanış tarihi taşıyan, tahmine giren bir kayıt yaratmasıdır.
SQL hacmini iki güç oynatır: kabul kriterlerinin katılığı ve temsilcilerin baskı altında bunları ne kadar tutarlı uyguladığı. Kota kapsaması zayıf göründüğünde temsilciler sınırdaki adayları kabul eder, pipeline sağlıklı okunur ve talep hiç değişmediği hâlde tahmin şişer. Daha katı kriterler tahmini korur ama talep boşluğunu daha erken ortaya çıkarır; bu hem rahatsız edici hem yararlıdır. Üçüncü kaldıraç hızdır: bugün görüşmeyi kabul edecek biri gelecek hafta etmeyebilir.
Ekipler bunu yazılı devir kriterleriyle işler kılar: bir fırsat oluşmadan önce doğrulanması gereken olgular. Genellikle adı konmuş bir sorun, karar üzerinde etkisi olan bir kişi, makul bir bütçe aralığı ve bir şeyin değişmesi gereken bir tarih. Çoğu kurum pazarlama aşamasıyla bu aşama arasına, bunları kısa bir görüşmede netleştirsin diye bir SDR koyar. Scorecard quiz'i ölçek ve zaman aralığını zaten toplamışsa görüşme keşifle değil ayrıntılarla başlar.
Kabul bir takdir kararıdır ve takdir temsilciden temsilciye değişir; aynı aday aynı gün biri tarafından kabul, bir diğeri tarafından reddedilebilir. Reddedilen adaylardan örneklem denetlemek, bu sapmayı görmenin tek güvenilir yoludur. Aşama, kimsenin elle nitelendirme yapmadığı düşük fiyatlı self servis ürünlere ve on sekiz ay erken gelen gerçek bir uyumun reddedilip bir daha bakılmadığı çok uzun döngülere de kötü oturur.
Pratikte örnek
Nasıl ölçülür
Kabul oranıyla ve arkasındaki ret gerekçesi bileşimiyle başlayın. Kabul oranı sabitken gerekçe bileşiminin kayması, ana sayı değişmese bile trafiğin değiştiğini söyler. Ardından kabul edilen adayların ne kadarının gerçek bir fırsat aşamasına ulaştığını ve oradaki kazanma oranını kaynağa göre ayırarak ölçün; bir kanal, temsilcilerin isteyerek kabul ettiği ama hiç kapanmayan adaylar üretebilir.
Hız ve çaba operasyonel sinyallerdir. Devirden ilk temas denemesine geçen süreyi ve bir aday ulaşılamadı işaretlenmeden önce yapılan deneme sayısını izleyin; kötü diye silinen adayların çoğuna aslında hiç ulaşılmamıştır. Aşama yaşını da izleyin: kendi aşaması için olağan süreyi aşan fırsatlar genellikle ret olması gereken kabullerdir.
Sık yapılan hatalar
En pahalı alışkanlık, adayları gerekçe kodu olmadan reddetmektir. Kayıt yok olur ve pazarlamaya yalnızca kalitenin kötü olduğu söylenir; bu üzerine iş yapılamayacak bir bilgidir. Kısa ve kapalı bir gerekçe listesi zorunlu kılın: yanlış şirket büyüklüğü, bütçe yok, zaman aralığı yok, yanlış kişi, ulaşılamadı. Ulaşılamadıyı niteliksizden ayrı tutun; biri temas ritmi, diğeri hedefleme sorunudur.
İkincisi, kapsam yeterli görünsün diye adayları erkenden fırsata çevirmektir. Doğrulanmış bir sorunu olmayan anlaşmalar aylarca erken bir aşamada bekler, sonraki tüm dönüşüm oranlarını bozar ve tahmini okunmaz kılar. Devir kriterlerini öneri değil zorunlu alan olarak dayatın ve etkinliği ve doğrulanmış bir sonraki adımı olmayan fırsatları kapatan düzenli bir temizlik yürütün.
Sıkça sorulan sorular
Bir müşteri adayını SQL olarak nitelendiren nedir?
Bir SQL, doğrulanmış satın alma niyeti göstermeli ve yalnızca pazarlama değil satış tarafından doğrulanan bütçe, yetki, ihtiyaç ve zamanlama gibi uyum kriterlerini karşılamalıdır. Tipik tetikleyiciler arasında demo talep etmek, erişime yanıt vermek veya katı firmografik kuralları karşılamak yer alır.
Her MQL bir SQL'ye dönüşür mü?
Hayır, satış gerçek niyeti ve uyumu doğruladıktan sonra MQL'lerin yalnızca bir kısmı SQL'ye ilerler. MQL'den SQL'ye dönüşüm oranı, MQL tanımınızın ve beslemenizin satışın gerçekte kapatabileceğiyle uyumlu olup olmadığının önemli bir göstergesidir.
Quiz funnel'lar SQL oluşturmayı nasıl hızlandırır?
Bir scorecard quiz'i nitelendirici yanıtları ve demo talebi gibi niyet sinyallerini tek bir akışta topladığı için, yüksek uyumlu katılımcılar uzun besleme süreçlerini atlayabilir. Bu, en güçlü adayları neredeyse anında SQL olarak satışa yönlendirmenizi sağlar.
SQL ile fırsat arasındaki fark nedir?
SQL, satışın üzerinde çalışmayı kabul ettiği bir adaydır; fırsat ise nitelendirme doğrulandıktan sonra oluşan anlaşma kaydıdır. Birçok sistemde fırsat, kabulün hemen ardından gelir; yine de ikisini ayrı tutmak, kabul edilen adayların ne kadarının ilk temastan sağ çıktığını ölçmenizi sağlar.
SQL kararını SDR mi yoksa AE mi verir?
Genellikle SDR önerir, account executive kabul eder; bu da yararlı bir ikinci kontrol yaratır. SDR temel kriterleri görüşmede doğrular, AE anlaşmanın kendi pipeline'ında bir yere değip değmediğine karar verir ve kabul ya da ret kaydedilir. Kararı tek bir rol verdiğinde kabul standartları kota baskısıyla birlikte kayar.
Vazgeçmeden önce kaç kez temas denenmeli?
Çoğu ekibin denediğinden fazla ve tek kanalda tekrarlamak yerine kanallara yayarak. Yaygın bir düzen, bir iki hafta boyunca telefon, e-posta ve bir sosyal temasla birkaç deneme yapmak, sonra adayı ulaşılamadı olarak işaretlemektir. Deneme sayısını kaydedin; tek e-postadan sonra niteliksiz kapatılan adaylar genelde niteliksiz değildir.
Satış neden pazarlama adaylarını reddeder?
Retlerin çoğu dört nedene iner: şirketin büyüklüğü veya sektörü yanlıştır, kişinin karar üzerinde etkisi yoktur, bir zaman aralığı yoktur ya da kimse kendisine ulaşamamıştır. Yalnızca ilk üçü kalite sorunudur. Hangi nedenin geçerli olduğunu kaydetmek, verimsiz bir kalite tartışmasını çözülebilir bir hedefleme ya da temas ritmi konusuna dönüştürür.
Bir adayın SQL olması için hangi devir kriterleri gerekir?
En azından adayın çözmek istediği adı konmuş bir sorun, karar üzerinde etkisi olan bir kişi, harcamanın mümkün olduğuna dair bir işaret ve bir şeyin değişmesi gereken bir tarih. Bunları rehber değil zorunlu alan olarak yazın. Yalnızca playbook'ta duran kriterleri her temsilci farklı uygular ve sonradan denetlenemez.
Bir aday MQL aşamasını atlayıp doğrudan SQL olabilir mi?
Evet ve yüksek niyetli adaylar için bu olağandır. Demo talebi, fiyat sorusu ya da bir referans, önceki aşamanın saptamaya çalıştığı niyeti zaten taşır; bunu bir besleme rotasına sokmak fırsat penceresini harcar. Bunlar için doğrudan bir yol açık tutun ve aday bir temsilciye ulaştığında aynı kabul kriterlerini uygulayın.