SaaS'ta Aday Puanlama: MQL'den SQL'e Geçiş

MQL ve SQL tanımlarını kurumunuza göre yazın

MQL, Marketing Qualified Lead; SQL ise Sales Qualified Lead ifadesinin kısaltmasıdır. MQL pazarlama ölçütleriyle satış değerlendirmesine uygun bulunan, SQL satış değerlendirmesinde uygunluğu doğrulanan aday olarak kullanılabilir. Yalnız satış ekibinin bir kaydı açması veya arama denemesi yapması SQL olduğu anlamına gelmez. Kurumunuz bu uygunluğu hangi bilgiyle belirliyorsa açıkça yazın.

Ürün uyumu, kullanım sinyali ve doğrudan görüşme talebinin hangi aktarımı başlatacağını belirleyin. Her aday önce MQL olmak zorunda değildir; doğrudan satışa gelen uygun bir talep başka yoldan ilerleyebilir. Puan eşiği bir değerlendirme kuyruğu açabilir, SQL statüsünü kendiliğinden kanıtlamaz. Satışın kabul, bekletme ve geri çevirme nedenlerini ayrı kaydedin.

Şirket uyumu ile kişi davranışını ayrı izleyin

Şirketin ideal müşteri profiline uyumunu davranış puanından ayrı izleyin. Toplam skor üretseniz bile bileşenler görülebilsin. Aynı şirkette birden fazla kullanıcı varsa hesap düzeyinde hangi sinyallerin birleştiğini ve tekrarların nasıl sayıldığını belirtin. E-posta açılışları gizlilik özellikleri ve otomatik yüklemelerden etkilenebildiği için tek başına güçlü niyet sinyali sayılmamalıdır.

Hangi davranışlar izlenmeli?

Ürün karşılaştırma ve fiyat bilgisi inceleme, denemede değerli bir işlem tamamlama, ekip daveti, demo talebi ve entegrasyon sorusu izlenebilecek sinyallerdir. Bir hesabın fiyat sayfasına gelmesi öğrenci araştırması veya mevcut müşterinin kontrolü de olabilir. Tekrarlayan oturumun gerçekten değerli kullanım anlamına gelip gelmediğini ürünün iş akışıyla değerlendirin.

Ağırlıkları kazanılan ve kazanılmayan hesapların, satın alma öncesinde mevcut olan verileriyle karşılaştırın. Satıştan sonra ortaya çıkan bilgiyi geçmişte varmış gibi skora katmayın. Az veri varsa basit bir başlangıç kuralını varsayım olarak kullanıp sonuç geldikçe test edin. Davranışın etkisinin zamanla azalmasını, otomatik trafik ve tekrar olayları da değerlendirin.

Negatif sinyalleri de puanlayın

Geçersiz iletişim veya doğrulanmış ürün uyumsuzluğu değerlendirmeyi etkileyebilir. Hareketsizlik ise izin, sezon veya teknik sorunla ilişkili olabilir. İletişimden çıkma talebini yalnız negatif puan yapmayın; ilgili iletişim akışını durduran ayrı bir kural olarak ele alın. Gerekçesi doğrulanmayan davranışla hesabı kalıcı olarak dışlamayın.

Skor eşiği ve satış ekibine aktarım

Eşiği geçmiş uygunluk ve satış sonuçlarıyla sınayın; eşik altında kalan değerli hesapları da örneklemle inceleyin. Ekip kapasitesi yanıt süresi ve öncelik sırasını etkileyebilir, ancak kapasite yetmediği için uygunluk tanımını değiştirmek raporu çarpıtır. Yüksek puanın satış olasılığına karşılık geldiğini varsaymadan, grupların gerçekleşen sonuçlarını karşılaştırın.

Aktarım anını da tanımlayın: skor eşiği aşıldığında lead satış ekibine hangi kanaldan iletiliyor, satış ekibi lead'i ne kadar sürede değerlendiriyor, değerlendirme sonucu (SQL olarak kabul ya da pazarlamaya geri dönüş) CRM'de nasıl işaretleniyor? Bu akış tanımlı değilse, skorlama sistemi ne kadar iyi olursa olsun adaylar arada kaybolur. Aktarım akışını CRM'de bir otomasyonla desteklemek, insan hatasını azaltır.

MQL'den SQL'e dönüşüm oranını izleyin

Aynı dönemde MQL olan hesapların belirlenen izleme süresi içinde kaçının SQL olarak kabul edildiğini hesaplayın. Henüz incelenmeyen ve bekleyenleri raporda koruyun. Oranın yükselmesi tek başına iyi sonuç değildir; daha az uygun adayı kabul etmiş olabilirsiniz. Uygun fırsat sayısı, satış sonucu ve kaçırılan adaylarla birlikte değerlendirin. Ağırlık değişikliğinin tarihini kaydedin; önce-sonra farkını tek başına nedensellik saymayın.

Ölçüm altyapısını kurmak

Skorlama için web analitiği, ürün olayları ve CRM verisinden gerekli olanları seçin. GA4 web ve uygulama ölçümünü destekler; Measurement Protocol sunucudan veya çevrimdışı olaylarla mevcut ölçümü tamamlayabilir. GA4 kullanmak skorlama için zorunlu değildir. Kişi-hesap eşleştirmesini yetkili sistemlerinizde tanımlayın; her anonim ziyaretçinin hangi lead olduğunu bildiğinizi varsaymayın.

Olay sözlüğüne anlam, zaman, kaynak ve tekilleştirme kuralını yazın. Analitik parametrelere e-posta, telefon, parola veya serbest metin taşımayın. İzin ve veri işleme koşullarını tasarıma dahil edin. Kontrollü sentetik adayla tekrar olay, eksik kimlik ve yanlış hesap eşleşmesini test edin. Özel yazılım geliştirme sırasında aktarımın hata durumlarını ve yeniden denemelerini de planlayın.

Çevrimdışı satış sonucunu geri beslemek

Satış, telefon ya da yüz yüze görüşmede kapanıyorsa bu sonuç, reklam ve pazarlama ölçümüne geri beslenebilir. Google Ads'in çevrimdışı dönüşüm aktarımı, çevrimdışı iş sonuçlarını reklamlarla ilişkilendirmek için seçenekler sunar; bu aktarımın çalışması için eşleştirme koşulları ve veri işleme gereksinimleri karşılanmalıdır. Geri besleme yapmadan önce CRM kayıtlarını temizleyin: tekrar kayıtları, tutarsız aşama adları ve eksik tarih bilgisi, aktarımın güvenilirliğini bozar.

Kontrol listesi: skorlama sistemini yayına almadan önce

SaaS satış sürecinde skoru kararın gerekçesiyle birlikte izleyin. İlk kabulde şu maddeleri tamamlayın.

• MQL, değerlendirme kuyruğu ve SQL koşullarını ayırın.
• Şirket uyumu ile kişi/hesap davranışını ayrı izleyin.
• Skora yalnız karar anında mevcut bilgiyi dahil edin.
• Tekrar, otomatik trafik ve eski sinyallerin etkisini kontrol edin.
• İletişim tercihlerini puandan bağımsız uygulatın.
• Aktarım ve değerlendirme sorumlusunu belirleyin.
• Düşük puanlı ama uygun adayları da kontrol örneklemine alın.
• Kişisel bilgilerin analitik parametrelere sızmadığını doğrulayın.
• Sonuçları açık kalan kayıtları gizlemeden raporlayın.

Sonuç

Lead puanlamasını uygunluk, davranış ve değerlendirme sonucunu görünür kılan bir önceliklendirme aracı olarak kurun. Skoru otomatik satış kararı yerine inceleme gerekçesiyle birlikte kullanın. Aktarımın çalışması, verinin doğruluğu ve kaçırılan adayların kontrolü, yüksek bir MQL–SQL oranından daha kapsamlı bir değerlendirme sağlar.