Bahasa Indonesia

Matematika Corong: Forensik MQL ke SQL ke Peluang

Angka MQL naik 32% dari bulan ke bulan. GM senang. Tiga minggu kemudian, peluang stagnan. Anda tidak tahu mengapa, dan "kualitas MQL" bukan jawaban yang akan diterima GM Anda untuk kedua kalinya.

Inilah forensik corong penjualan. Anda bukan lagi sekadar pengunjung dashboard. Anda adalah penyelidik yang membaca matematika, mencari penyebab yang teridentifikasi (segmen, sumber, hari, serah terima) yang menjelaskan mengapa volume naik tapi pipeline tidak mengikuti.

Sebagian besar demand gen manager melaporkan tingkat konversi agregat. Yang baik melaporkan diagnosis. Ada perbedaan antara "MQL ke SQL 11%" dan "MQL ke SQL turun ke 8% pada hari Selasa, dan itu adalah kesenjangan cakupan SDR, bukan kualitas prospek." Yang satu menghasilkan anggukan kepala. Yang lain menghasilkan anggaran.

Sepakati definisi MQL dengan penjualan, termasuk aturan penolakan

Sebelum forensik apapun, selesaikan ini: dapatkah AE menolak MQL, dan berdasarkan alasan apa? Jika jawabannya "tidak" atau "tidak jelas," angka MQL Anda adalah metrik semu. Anda akan melaporkannya selama enam bulan, penjualan akan diam-diam mengabaikannya, dan suatu hari VP Sales Anda akan memberitahu GM bahwa prospek pemasaran "tidak berkonversi," dan Anda tidak punya pembelaan karena tidak ada definisi bersama.

Inilah perjanjian kerja yang bertahan. Sebuah MQL memiliki tiga hal: kesesuaian (kecocokan ICP akun), niat (ambang penilaian berdasarkan perilaku), dan kontak yang bisa dihubungi. Di bawah ambang batas, itu adalah prospek, bukan MQL. Di atas ambang batas tapi jabatan salah, ukuran perusahaan salah, geografi salah? AE memiliki 24 jam untuk menolak dengan kode alasan. Setelah 24 jam, diterima secara default dan dihitung.

Kode alasan lebih penting dari penolakan itu sendiri. Enam kode sudah cukup: ukuran perusahaan salah, jabatan/persona salah, geografi salah, pelanggan yang sudah ada, pesaing, tidak ada info kontak yang terverifikasi. Apa pun di luar keenam ini dieskalasi. Anda dan manajer AE menengahi sengketa bulanan: 30 menit, lihat 20 MQL yang disengketakan, selesaikan, perbarui model penilaian jika ada pola yang muncul.

Tanpa ini, Anda tidak bisa melakukan forensik. Debat "apakah ini MQL" menghabiskan setiap rapat dan Anda tidak pernah sampai ke kebocoran yang sebenarnya.

Membaca tingkat konversi berdasarkan sumber, persona, dan segmen

Tingkat MQL ke SQL gabungan sebesar 14% menyembunyikan segalanya. Tingkat itu menyembunyikan tingkat iklan berbayar media sosial sebesar 4% yang membakar $40 ribu sebulan dan tingkat webinar sebesar 38% yang hanya mendapat 12% anggaran. Angka gabungan adalah kebohongan paling mahal dalam dashboard Anda.

Potong corong tiga cara setiap bulan: sumber, senioritas persona, segmen. Selalu tiga cara. Bukan dua, bukan empat. Tiga.

Tolok ukur kasar MQL ke SQL B2B SaaS 2026:

Sumber Kisaran sehat Tanda bahaya di bawah
Iklan berbayar media sosial (LinkedIn, Meta) 6-10% 4%
Iklan berbayar mesin pencari (Google, Bing) 10-15% 7%
Konten / organik 10-18% 8%
Webinar (langsung) 25-40% 18%
Webinar (on-demand) 12-20% 9%
ABM-sourced (akun bernama) 30%+ 22%
Rujukan / mitra 35-50% 25%
Outbound dingin (diperlakukan sebagai MQL) 8-12% 5%

Untuk MQL ke SQL gabungan secara keseluruhan, B2B SaaS yang sehat berada di kisaran 12-15%. Di atas 20% dan penilaian Anda mungkin terlalu ketat. Di bawah 8% berarti penilaian terlalu longgar atau gerakan penjualan tidak cocok dengan prospek yang masuk.

Senioritas persona menghasilkan pemotongan yang berbeda. VP dan level C mengonversi MQL ke SQL pada 25-35%. Level Director berada di kisaran 18-25%. Level Manager turun ke 8-14%. Di bawah manager, Anda sering menemukan peneliti, bukan pembeli. Tingkat konversi turun di bawah 5% dan itu bukan kebocoran, melainkan audiens yang salah.

Pemotongan segmen pun berbeda. MQL SMB berkonversi lebih cepat tapi dengan tingkat lebih rendah dan ukuran transaksi lebih kecil. Mid-market adalah titik manis untuk sebagian besar B2B SaaS, dengan MQL ke SQL 15-22% dan siklus transaksi yang bisa diperkirakan. MQL enterprise berkonversi dengan tingkat mentah terendah (8-12%) tapi SQL yang lolos 6-10 kali lebih besar, sehingga matematikanya tetap masuk jika tim penjualan Anda memiliki staf yang memadai.

Ketika Anda melihat sebuah angka, refleks Anda harusnya: potong tiga cara. Tingkat 14% menjadi masalah iklan berbayar media sosial (4%), mesin webinar (38%), dan lantai konten/organik (12%). Sekarang Anda memiliki tiga diagnosis, bukan satu angka.

Mengapa SLA 30 hari mengubah segalanya

Pengungkit terbesar dalam corong Anda bukan kualitas prospek. Melainkan kecepatan respons prospek. Setiap studi terpercaya dalam dekade terakhir telah mengkonfirmasinya, dan ini masih mengejutkan pemimpin penjualan setiap kuartal. MQL yang dihubungi dalam 5 menit berkonversi sekitar 8 kali lebih baik daripada yang dihubungi dalam 24 jam. Turun ke 60 menit lebih dan konversi anjlok 80% dibandingkan baseline 5 menit.

SLA Anda bukan 30 hari. SLA Anda adalah 5 menit untuk permintaan demo berkualitas tinggi, 1 jam untuk MQL tingkat lebih rendah, dan 30 hari hanya untuk keluar total dari corong (titik di mana MQL yang tidak dikerjakan didaur ulang ke pemeliharaan prospek, bukan jendela pengerjaan aktif).

Bangun dashboard SLA. Dashboard tersebut membutuhkan empat hal: waktu dari MQL ke tindakan SDR pertama, waktu dari MQL ke koneksi pertama, persentase MQL yang dikerjakan dalam SLA, dan persentase yang berkonversi ke SQL, dipotong per SDR.

Potongan terakhir itulah tempat diagnosis berdasarkan nama berada. Ketika Anda melihat "MQL ke SQL turun ke 8% pada hari Selasa," Anda tidak menganggapnya sebagai kebisingan. Anda menarik roster cakupan SDR. Biasanya Anda akan menemukan salah satu dari tiga hal: rapat Senin pagi yang memakan separuh waktu pagi tim SDR, standup Selasa yang mendorong panggilan outbound ke siang hari, atau jadwal rotasi PTO yang membuat antrian inbound kurang terlayani setiap Selasa.

Namai kesenjangan itu. Jangan hanya melaporkannya. "Kesenjangan cakupan SDR hari Selasa" adalah diagnosis. "Masalah kualitas" bukan.

Menemukan tahap yang bocor

Ketika MQL ke Peluang bermasalah, ada tiga tahap yang perlu diselidiki. Selidiki dalam urutan ini, karena hampir selalu salah satu dari tiga ini yang menjadi penyebab.

Tahap 1: Keterlambatan serah terima (MQL ke kontak SDR). Tarik setiap MQL dari 90 hari terakhir. Hitung waktu hingga sentuhan pertama. Kelompokkan MQL ke dalam 0-5 menit, 5-60 menit, 1-24 jam, 1-7 hari, 7+ hari. Bandingkan konversi ke SQL dalam setiap kelompok. Jika kelompok 0-5 menit berkonversi pada 28% dan kelompok 1-24 jam berkonversi pada 9%, Anda tidak punya masalah kualitas. Anda punya masalah kecepatan. Perbaiki perutean, bukan penilaian.

Tahap 2: Ketidakcocokan persona (perusahaan tepat, jabatan salah). Kelompokkan MQL berdasarkan jabatan yang dicocokkan dengan ICP Anda. Jabatan "Manager" yang bukan pengambil keputusan akan berkonversi pada 6-10% tidak peduli seberapa cepat Anda menelepon. Peneliti dan analis berkonversi di bawah 4%. Jika 35% volume MQL Anda ada pada jabatan bukan pembeli, model penilaian Anda memberi imbalan pada perilaku yang tidak memprediksi niat pembelian. Perbarui modelnya. Tambahkan penilaian negatif untuk jabatan non-pembeli, dan wajibkan jabatan pembeli ATAU tindakan berniat tinggi (permintaan demo, kunjungan halaman harga + pengisian formulir) untuk kualifikasi.

Tahap 3: Peluruhan niat (MQL berumur 14+ hari). Beberapa MQL menumpuk di antrian. Mungkin SDR sedang mengerjakan kampanye lain, mungkin perutean gagal, mungkin cakupan tipis minggu itu. Lihat MQL berdasarkan usia saat pertama kali dihubungi. MQL yang dihubungi setelah 14 hari berkonversi pada 30-50% dari tingkat MQL segar. Itu bukan masalah kualitas prospek, itu adalah peluruhan niat. Momen riset prospek sudah berlalu.

Berikut adalah pola SQL query yang mengisolasi tahap 1 di HubSpot atau Salesforce. Sesuaikan nama kolom dengan skema Anda:

SELECT
  CASE
    WHEN time_to_first_touch_minutes <= 5 THEN '0-5 min'
    WHEN time_to_first_touch_minutes <= 60 THEN '5-60 min'
    WHEN time_to_first_touch_minutes <= 1440 THEN '1-24 hr'
    WHEN time_to_first_touch_minutes <= 10080 THEN '1-7 days'
    ELSE '7+ days'
  END AS speed_cohort,
  COUNT(*) AS mqls,
  SUM(CASE WHEN became_sql = 1 THEN 1 ELSE 0 END) AS sqls,
  ROUND(100.0 * SUM(CASE WHEN became_sql = 1 THEN 1 ELSE 0 END) / COUNT(*), 1) AS conv_pct
FROM mql_events
WHERE mql_date >= DATE('now', '-90 days')
GROUP BY speed_cohort
ORDER BY MIN(time_to_first_touch_minutes);

Jalankan ini sekali seminggu. Hasilnya adalah tabel 5 baris yang memberi tahu apakah kecepatan adalah masalah Anda sebelum Anda menghabiskan satu kuartal menulis ulang model penilaian.

Jebakan "banyak MQL, tidak ada peluang"

Volume naik. Peluang stagnan. Enam penyebab yang teridentifikasi, masing-masing bisa diuji dalam seminggu.

1. ICP yang salah di bagian atas. Kampanye top-of-funnel Anda menarik perusahaan yang salah. Uji: tarik MQL 30 hari terakhir, nilai berdasarkan rubrik ICP Anda (industri, jumlah karyawan, pendapatan, geografi, tumpukan teknologi). Jika kurang dari 60% cocok, kampanye atau penargetan audiens Anda keliru.

2. Ketidaksesuaian skrip SDR. Skrip yang ditulis 18 bulan lalu untuk penentuan posisi produk yang berbeda. Uji: amati 10 panggilan SDR. Hitung berapa kali SDR menjelaskan proposisi nilai dalam bahasa yang sesuai dengan website Anda saat ini. Jika kurang dari 70%, Anda punya masalah skrip, bukan masalah prospek.

3. AE mendiskualifikasi untuk kebersihan pipeline. AE yang berada di bawah tekanan kuota membuang SQL "marjinal" untuk menjaga tingkat konversi mereka tetap bersih. Uji: tarik SQL yang didiskualifikasi AE dan alihkan 20 ke AE yang berbeda. Jika 25%+ menjadi peluang, Anda punya masalah kebersihan yang tersamar sebagai masalah kualitas.

4. Kebocoran atribusi. MQL berkonversi ke peluang, tapi peluang tidak ditandai kembali ke sumber. Sehingga dashboard Anda terbaca "tidak ada pipeline." Uji: tarik 90 hari closed-won terakhir dan lacak masing-masing kembali ke sentuhan pertama. Jika 25%+ tidak memiliki sumber MQL yang terpasang, atribusi Anda rusak sebelum corong Anda rusak.

5. Demo tidak hadir. SQL sedang dibooking, tapi 40% demo tidak hadir. Uji: hitung booking demo vs demo yang selesai untuk 30 hari terakhir. Angka sehat adalah 70-85% penyelesaian. Di bawah 60% dan alur booking memerlukan urutan konfirmasi, pengingat kalender, dan tawaran re-book di hari yang sama.

6. Inflasi MQL dari penilaian dengan ambang batas rendah. Seseorang menurunkan ambang batas untuk "mencapai angka." Volume naik, konversi anjlok. Uji: jalankan ulang model penilaian Anda pada ambang batas kuartal lalu dan hitung ulang MQL ke SQL. Jika konversi dulu 14% dan sekarang 9%, Anda tidak mendapatkan lebih banyak MQL. Anda mendapatkan lebih banyak prospek yang dilabeli ulang sebagai MQL.

Masing-masing membutuhkan seminggu untuk diuji. Lakukan secara berurutan. Jangan jalankan keenamnya secara paralel, karena Anda tidak akan tahu perbaikan mana yang menggerakkan angkanya.

Forensik atribusi di HubSpot, Salesforce, dan Rework

Atribusi adalah tempat sebagian besar demand gen manager terjebak. Ada tiga model, dan Anda akan berdebat tentang mana yang "benar" sepanjang karier Anda.

Sentuhan pertama mengkredit kampanye yang membawa prospek ke database Anda. Baik untuk mengukur kampanye top-of-funnel. Buruk untuk mengukur kecepatan transaksi.

Sentuhan terakhir mengkredit kampanye yang mengonversi MQL ke SQL atau SQL ke peluang. Baik untuk mengukur kampanye sales-assist. Buruk untuk mengukur brand dan penciptaan permintaan.

Multi-sentuhan mendistribusikan kredit di semua titik perjalanan, tertimbang berdasarkan posisi atau model atribusi tertentu (W-shaped, U-shaped, time-decay). Paling "akurat" secara teori, paling sulit dipertahankan dalam rapat dewan karena tidak ada yang memahami pembobotannya.

Jawaban yang tepat adalah melaporkan dua tampilan (sentuhan pertama dan multi-sentuhan) dan memilih satu untuk dewan. Beritahu GM mana yang Anda pilih dan mengapa. Sebagian besar tim demand gen B2B SaaS menetap pada multi-sentuhan (W-shaped: 30% sentuhan pertama, 30% sentuhan pembuatan prospek, 30% sentuhan pembuatan peluang, 10% lainnya) karena mengkredit baik pekerjaan kesadaran maupun pekerjaan konversi. Gunakan secara konsisten selama setahun sebelum Anda mengubah model.

Perbedaan ketiga CRM:

HubSpot mengaitkan kampanye ke kontak melalui hs_analytics_first_url dan objek keanggotaan kampanye. Transisi tahap siklus hidup adalah tulang punggungnya. Bagian yang kabur adalah jendela serah terima SDR. Tidak ada stempel waktu "MQL ke SDR yang dikerjakan" secara bawaan kecuali Anda membangunnya sebagai properti kustom. Sebagian besar tim menyatukannya dengan stempel waktu penyelesaian tugas dan riwayat Tahap Siklus Hidup. Bisa berjalan, tapi bocor di tepi-tepinya.

Salesforce memiliki Campaign Influence (multi-sentuhan) dan Primary Campaign Source (sentuhan pertama) yang sudah tertanam. Kebocorannya ada di antara konversi Prospek dan pembuatan Peluang. Jika AE Anda mengonversi Prospek ke Kontak tanpa membuat Peluang di hari yang sama, koneksi kampanye ke pipeline terputus kecuali Anda telah mengonfigurasi aturan Campaign Influence untuk mengisi kembali. Sebagian besar organisasi Salesforce salah mengonfigurasi ini.

CRM Rework dibangun di sekitar timeline kontak terpadu yang mencakup status kerja SDR, peristiwa distribusi prospek, dan pembuatan peluang sebagai objek utama, bukan properti yang ditempel-tempel. Kesenjangan serah terima SDR yang dibiarkan kabur oleh HubSpot dan Salesforce ditutup secara default. Anda dapat melihat menit persis sebuah MQL ditugaskan, SDR yang mengambilnya, sentuhan pertama, dan jalur ke SQL. Untuk tim menengah (20-500 karyawan) yang menjalankan Marketing dan Sales dalam sistem yang sama, ini menutup kesenjangan atribusi tanpa proyek properti kustom. Rework CRM mulai dari $12/pengguna/bulan.

Pelacakan langsung. Pilih satu peluang closed-won. Lacak ke belakang: pembuatan peluang ke konversi SQL ke pemicu MQL ke pengisian formulir kontak pertama ke sumber sesi pertama. Jalankan pelacakan itu bersama AE dan SDR Anda. Dua kali per kuartal, lakukan secara langsung dengan GM. Ini adalah cara terbaik untuk mengajarkan GM apa arti atribusi yang sebenarnya dan untuk mengungkap di mana data Anda bocor.

Tinjauan corong bulanan bersama GM

Tinjauan corong bulanan Anda muat dalam satu halaman. Jika tidak, Anda melaporkan terlalu banyak.

Top of funnel. Total volume MQL, bauran sumber (5 sumber teratas berdasarkan volume dan berdasarkan konversi), dan satu kalimat komentar tentang penggerak terbesar.

Middle of funnel. MQL ke SQL per segmen (SMB, Mid, Enterprise), kepatuhan SLA (persentase MQL yang dikerjakan dalam SLA), dan pemotongan senioritas persona.

Bottom of funnel. SQL ke Peluang, Peluang ke Closed-Won, kecepatan rata-rata (hari MQL ke penutupan), dan kontribusi pipeline yang melekat pada sumber demand gen.

Baris diagnosis. Akhiri setiap tinjauan dengan satu hipotesis berdasarkan nama yang sedang Anda selidiki bulan ini. Bukan lima. Satu. "Kami sedang menguji apakah kesenjangan cakupan SDR hari Selasa menjelaskan penurunan MQL ke SQL sebesar 8%. Jika demikian, kami akan mengalihkan cakupan sebelum 15 Mei dan memeriksa ulang pada Juni."

Cukup itu. Satu halaman, empat bagian, satu diagnosis. GM bisa memindainya dalam 90 detik, mengajukan dua pertanyaan, dan keluar dengan mengetahui fokus Anda.

Yang tidak Anda masukkan dalam tinjauan ini: laporan kinerja tingkat kampanye (itu untuk standup pemasaran), CTR dan CPL per kreativitas iklan (itu untuk tinjauan kinerja mingguan Anda dengan tim berbayar), dan dashboard apa pun dengan lebih dari 12 angka. GM tidak menginginkan data mentah. GM menginginkan diagnosis.

Apa yang ini hasilkan untuk Anda

Volume adalah cerita yang Anda ceritakan di standup pemasaran. Forensik konversi adalah cerita yang Anda ceritakan di meja pendapatan.

Ketika Anda masuk ke tinjauan bisnis triwulanan dan berkata "volume MQL naik 32%, tapi MQL ke SQL iklan berbayar media sosial kami 4% vs. tolok ukur 12%, dan kesenjangan cakupan SDR hari Selasa menghabiskan 60 SQL per kuartal, inilah yang sedang kami uji," Anda sudah berhenti menjadi demand gen manager yang melaporkan prospek. Anda telah menjadi operator yang mendiagnosis masalah pipeline dengan ketajaman yang sama seperti yang digunakan penjualan untuk mendiagnosis kemandegan transaksi.

Itulah tempat duduk di meja tersebut. Matematikanya yang memperolehnya.

Pelajari Lebih Lanjut