MQL ve SQL Arasındaki Farklar

MQL ve SQL neyi ifade eder

MQL, Marketing Qualified Lead ifadesinin kısaltmasıdır: pazarlamanın belirlenmiş uygunluk ve ilgi kriterlerine göre satış değerlendirmesine hazır bulduğu aday. Bir form doldurmak veya e-posta açmak otomatik olarak MQL olmak anlamına gelmez. Kurum, hangi profil ve davranış birleşiminin bu aşamaya karşılık geldiğini yazmalıdır.

SQL, Sales Qualified Lead, satış ekibinin potansiyel müşteri olarak nitelediği adayı ifade eder. HubSpot yaşam döngüsü belgesi de bu iki aşamayı ayrı tanımlar. Her SQL’in önce MQL olması zorunlu değildir; doğrudan satış teması veya mevcut ilişkiyle gelen bir aday farklı yoldan nitelendirilebilir. Bütçenin tamamının açıklanması ya da yüz yüze görüşme gibi ek şartlar kurumun kendi kriteridir.

Araya başka aşamalar eklenebilir: görüşme planlandı, görüşme yapıldı, teklif gönderildi. Bunlar işletmenin gerçek takibine göre tanımlanır; her işletmenin aşama listesi birebir aynı olmak zorunda değildir. Gereksiz uzun aşama zinciri takibi zorlaştırır, gereksiz kısa zincir bilgi kaybettirir.

Aynı adayı iki kez saymamak

MQL’den SQL’e geçen aynı kayıt, yeni bir kişi veya talep yaratmaz. Dönem içinde bu aşamalara ulaşan sayıları toplamak toplam aday sayısını vermez. Toplamı seçtiğiniz tekil kayıt tanımıyla hesaplayın; henüz MQL olmayan adaylar ve doğrudan satıştan gelenler de bulunabilir. Aynı şirketteki iki kişi ile aynı kişinin iki farklı talebi ayrı ilişkilerdir.

Geçiş kriteri: MQL'den SQL'e ne zaman geçilir

Geçiş kriteri işletmeye özgü tanımlanır ve yazılı olur. Yaygın kriter kümesi üç başlıkta toplanır: profil uygunluğu (şirketin hedef sektör ve ölçekte olması), niyet (talebin belirli bir ürün veya hizmetle ilgili olması) ve temas (adayın satış görüşmesine katılmayı kabul etmesi).

Geçiş kriterini örnek kayıtlarla sınayın: ürünle ilgilenen ama kapsam dışındaki bir aday, uygun şirketten gelen genel bir bilgi isteği ve belirli ihtiyaçla demo isteyen kişi aynı durumda değildir. Satışın kabul etmediği kayıt için gerekçe tutulması, sorunun hedeflemede mi, beklentide mi, eksik bilgide mi olduğunu ayırır.

Kriteri ilk günde mükemmel kurmaya çalışmayın. İlk tanımı yapın, yeterli gözlem süresi bulunan gerçek aday akışında hangi MQL'lerin SQL'e dönüştüğüne bakın ve kriteri gerçek dönüşlerle güncelleyin. Kriter, sabit bir evrensel ölçüt değil işletmenin kendi satış davranışından öğrenilen bir tanımdır.

Tabloyu yana kaydırarak inceleyin.

Ekip sorumluluğu ve geçiş onayı

Otomatik puanlama adayı satış inceleme kuyruğuna taşıyabilir; bu, satışın gerçekten kabul ettiği anlamına gelmez. İnceleme, kabul ve SQL tanımlarını ayrı iş kurallarıyla düzenleyin. Puanlama ile satış değerlendirmesi çeliştiğinde hangi kararın geçerli olacağını ve düzeltmenin kimde olduğunu belirleyin.

Sorumluluğu yazmadan kurulan sistemde MQL'ler satış kuyruğunda bekler ve ilk dönüş süresi uzar. Bu yüzden iki karar birlikte verilir: kim niteler ve ne kadar sürede ilk temas yapılır. İlk temas süresi işletmenin talep hacmine göre belirlenir; sabit bir saat eşiği her işletme için uygun değildir.

Perakende, toptan ve kurumsal alıcı ayrımı müşteri segmentidir; MQL ve SQL ise nitelendirme aşamalarıdır. Toptan alıcı olmak tek başına MQL sayılmak için yeterli değildir. Worgoo Kurumsal kapsamında planlanan bir talep akışında segment ve aşama ayrı alanlarda tutulmalıdır.

Geri dönüşler nasıl işlenir

Zamanlaması uygun olmayan, kapsam dışı kalan ve iletişimden çekilen adayları tek bir geri dönüş durumuna sıkıştırmayın. Yeniden takip, uygun değil ve kapandı gibi durumları gerekçeleriyle ayırabilirsiniz. Geçmiş aşama zamanlarını silmeden durum değişikliğini kaydedin; geri dönüş sayısı tek başına kriterin doğru veya yanlış olduğunun kanıtı değildir.

Ölçüm: MQL ve SQL raporunu nasıl kurarsınız

MQL’den SQL’e geçiş için bir kohort belirleyin: örneğin aynı ay ilk kez MQL olan kayıtlar. Bu grubun seçilmiş gözlem penceresinde SQL’e geçen tekil kayıt sayısını, grubun toplamına bölün. Örnek olarak 100 MQL’den 25’i 60 gün içinde SQL olmuşsa oran %25’tir; bu temsili hesapta 60 gün ve %25 başarı hedefi değildir.

Yalnız kapanan adayları payda almak bekleyenleri dışarıda bırakır ve sonucu çarpıtabilir. Henüz gözlem süresini tamamlamamış kohortları işaretleyin; güncel anlık durum ile tamamlanmış gözlem penceresini ayırın. Satış kazanımını da SQL nitelemesinden ayrı izleyin: nitelikli aday her zaman sözleşmeye dönüşmez.

Özel yazılım veya hazır CRM entegrasyonunda kabul senaryosu, örnek kaydın aşama değişimini baştan sona göstermelidir. Aynı aday tekrar form gönderince yeni niteleme olayı mı oluşuyor, mevcut kayıt mı güncelleniyor? Satış sorumlusu değişince zaman çizgisi korunuyor mu? Bu testleri rapordaki toplamları karşılaştırmadan önce tamamlayın.

• MQL tanımını ve SQL geçiş kriterini yazılı belgeye bağlayın.
• Her MQL kaydının hangi kanaldan geldiğini ayrı alan olarak tutun.
• Aynı MQL kohortunun belirlenmiş gözlem süresindeki SQL geçişini hesaplayın; bekleyenleri paydadan çıkarmayın.
• Ret, yeniden takip ve ulaşılamama nedenlerini ayrı raporlayın.
• Kriter sürümünü ve değişim tarihini kaydedin; karşılaştırmalarda tanım değişikliğini belirtin.

Sonuç

MQL ve SQL arasındaki fark, iki aşamanın kim tarafından ve hangi kriterle onaylandığıdır. Tanımı yazılı tutmak, geçiş kriterini gerçek aday akışından öğrenmek, geri dönüşleri kriter güncellemesine bağlamak ve oranları payda ve dönem belirterek raporlamak, pazarlama ile satışın aynı adayı aynı saymasını sağlar.