Template Perjanjian MQL/SQL: Kontrak Copy-Paste antara Marketing dan Sales

VP Sales mengatakan leads tidak memenuhi syarat. CMO mengatakan sales tidak menindaklanjuti. Keduanya benar, dan keduanya salah, dan tidak ada yang bisa membuktikan kasus mereka karena tidak ada perjanjian tertulis yang mendefinisikan apa arti "memenuhi syarat" atau apa yang dibutuhkan oleh "tindak lanjut."
Ini terjadi di sebagian besar organisasi revenue. Alignment ada sebagai kenangan dari sebuah percakapan, biasanya Q1 kickoff di mana kedua tim mengangguk pada slide deck dan kemudian kembali beroperasi berdasarkan definisi mereka sendiri.
Alignment verbal tidak bertahan saat kuartal pertama meleset. Pada saat deals ditutup dan seseorang perlu menetapkan kesalahan, percakapan yang terjadi tujuh bulan lalu di ruang konferensi tidak berarti apa-apa. Apa yang Anda butuhkan adalah dokumen yang ditandatangani kedua pihak, yang mendefinisikan MQL, mendefinisikan SQL, dan mendefinisikan dengan tepat apa yang menjadi kewajiban setiap tim di batas handoff.
Itulah yang diberikan artikel ini: template lengkap, siap untuk di-copy.
Fakta Kunci: Biaya Definisi yang Tidak Selaras
- Perusahaan dengan proses marketing dan sales yang selaras secara formal mengalami pertumbuhan pendapatan 24% lebih cepat selama tiga tahun dibandingkan organisasi yang tidak selaras (Aberdeen Group).
- 87% istilah yang digunakan oleh tim marketing dan sales untuk menggambarkan leads berbeda antara kedua departemen di perusahaan yang sama (SiriusDecisions).
- Tim yang selaras mencapai retensi pelanggan 36% lebih tinggi dan win rate 38% lebih tinggi (MarketingProfs).
- Organisasi dengan perjanjian definisi leads yang terdokumentasi menyelesaikan perselisihan MQL 55% lebih cepat dan melihat 20% lebih sedikit MQL yang ditolak dalam dua kuartal (Demand Gen Report).
- Tim revenue dengan perjanjian MQL/SQL tertulis mengkalibrasi scoring model 2,4x lebih sering dibandingkan tim yang mengandalkan norma verbal, menurut riset alignment Forrester.
Apa Itu Perjanjian MQL/SQL (dan Apa Bukan)
Perjanjian MQL/SQL adalah komitmen bersama antara marketing dan sales yang mendefinisikan kosakata bersama, kriteria bersama, dan akuntabilitas bersama di batas handoff leads. Ini ditinjau secara kuartalan dan ditandatangani oleh kedua pemimpin.
Ini bukan dokumen pengawasan. Marketing tidak menggunakannya untuk mempermalukan sales karena acceptance rate yang rendah. Sales tidak menggunakannya untuk menuntut kesempurnaan dari marketing sebelum menyentuh leads. Ini adalah dokumen referensi. Kedua tim menunjuknya ketika ada ketidaksepakatan, dan kedua tim memperbaruinya ketika realitas berubah.
Ini juga bukan kebijakan statis. Perjanjian MQL/SQL harus menjadi dokumen yang berkembang dengan nomor versi dan jadwal review. Framework ICP bersama Anda berubah. Scoring model leads bersama Anda berubah. Tim Anda berkembang. Perjanjian harus mencerminkan realitas saat ini, bukan dunia sebagaimana adanya di kickoff tahun lalu.
Mengapa Tim Dengan Perjanjian Bertanda Tangan Mengungguli Tim Tanpa Perjanjian
Riset konsisten: artefak alignment tertulis menghasilkan hasil revenue yang terukur. Definisi Wikipedia tentang service-level agreement menyoroti prinsip yang sama — SLA yang efektif mengharuskan para pihak untuk bertemu secara teratur, menerapkan mekanisme akuntabilitas, dan memberi ruang untuk revisi berkala. Itulah persis yang dilakukan perjanjian MQL/SQL yang terstruktur dengan baik. Tetapi mekanismenya bukan sihir. Ini adalah spesifisitas.
Ketika kedua tim telah menyepakati minimum score threshold 65 (bukan "sekitar angka tinggi"), acceptance window 4 jam kerja (bukan "cukup cepat"), dan daftar rejection reason code 6 item (bukan "cukup beri tahu kami alasannya"), setiap percakapan tentang leads tertentu menjadi perbandingan terhadap standar. Argumen tentang leads individual diselesaikan dengan cepat karena standarnya jelas. Argumen tentang standar itu sendiri bersifat produktif. Mereka menghasilkan kalibrasi, bukan saling menyalahkan.
Perjanjian ini juga menciptakan fondasi untuk alat dan proses di sekitarnya: daftar dokumentasi handoff, aturan lead routing, taksonomi penolakan, dan feedback loop semuanya bekerja lebih baik ketika definisi yang mendasarinya dibagikan dan dituliskan.
Analisis Rework: Tim dengan perjanjian MQL/SQL bertanda tangan menyelesaikan perselisihan leads 55% lebih cepat dibandingkan tim yang mengandalkan norma verbal, menurut riset Demand Gen Report. Mekanismenya adalah spesifisitas: ketika kedua tim telah menyepakati score threshold 65 (bukan "sekitar angka tinggi") dan acceptance window 4 jam kerja (bukan "cukup cepat"), setiap percakapan tentang leads yang ditolak menjadi perbandingan terhadap standar tertulis daripada perdebatan tentang ingatan. Perjanjian ini juga menciptakan fondasi definitif yang membuat setiap alat alignment lainnya — dokumentasi handoff, aturan routing, rejection codes, weekly lead quality call — menjadi koheren secara operasional. Tanpanya, setiap alat tersebut dibangun di atas seperangkat asumsi yang berbeda yang tidak terucapkan. Dalam analisis Rework sendiri terhadap konfigurasi tim revenue, ada atau tidaknya perjanjian MQL/SQL tertulis adalah prediktor terkuat tunggal apakah lead quality review sebuah tim menghasilkan peningkatan scoring model atau menghasilkan siklus saling menyalahkan.
TEMPLATE — Perjanjian MQL/SQL
Copy bagian di bawah ini, isi nilai organisasi Anda di mana tanda kurung muncul, dan presentasikan kepada kedua pemimpin untuk persetujuan. Template ini dirancang untuk tim B2B SaaS SMB dan mid-market dengan ICP yang terdefinisi dan workflow leads berbasis CRM.
PERJANJIAN MQL/SQL
Organisasi: [Nama Perusahaan] Tanggal Efektif: [Tanggal] Versi: 1.0 Jadwal Review: Kuartalan (review berikutnya: [Tanggal + 90 hari]) Pemilik Dokumen: [RevOps Lead atau VP Revenue]
BAGIAN A — PIHAK DAN TUJUAN
Perjanjian ini dibuat oleh:
- Tim Marketing, diwakili oleh [Nama CMO / VP Marketing]
- Tim Sales, diwakili oleh [Nama CRO / VP Sales]
- Revenue Operations, sebagai saksi dan pemilik proses, diwakili oleh [Nama RevOps Lead]
Tujuan: Untuk menetapkan definisi bersama tentang Marketing Qualified Lead (MQL) dan Sales Qualified Lead (SQL), mendefinisikan kewajiban kedua tim di batas handoff, dan menciptakan proses terstruktur untuk feedback dan kalibrasi.
Perjanjian ini menggantikan semua pemahaman verbal atau informal sebelumnya mengenai kriteria kualifikasi leads.
BAGIAN B — DEFINISI MQL DAN KRITERIA
Leads mencapai status MQL ketika semua kondisi berikut terpenuhi:
B.1 — Kriteria Minimum ICP Fit (semua diperlukan)
| Dimensi ICP | Kriteria Minimum |
|---|---|
| Ukuran perusahaan | [mis., 20–500 karyawan] |
| Industri | [mis., SaaS, Professional Services, E-commerce — lihat dokumen ICP] |
| Geografi | [mis., AS, Kanada, Inggris, Australia] |
| Jabatan / peran | [mis., level VP, Director, atau Manager; fungsi Ops, Revenue, atau Marketing] |
| Kesesuaian teknologi | [mis., menggunakan CRM; tidak menggunakan produk kompetitor di bawah kontrak] |
B.2 — Minimum Score Threshold
Lead score harus mencapai [mis., 65] atau lebih tinggi pada skor fit + behavior gabungan.
Bobot sub-skor fit: [mis., 40%] Bobot sub-skor perilaku: [mis., 60%]
B.3 — Behavioral Trigger yang Diperlukan
Setidaknya satu dari behavioral signals berikut harus ada dalam [mis., 30] hari terakhir:
- Meminta demo atau free trial
- Mengunjungi halaman pricing [mis., 2+] kali
- Melihat halaman integrasi atau dokumentasi teknis
- Menghadiri live webinar atau product event
- Membuka dan mengklik [mis., 3+] email marketing dalam jangka waktu 14 hari
- Mengajukan form kontak dengan pertanyaan atau use case spesifik
B.4 — Pengecualian MQL
Leads berikut tidak memenuhi syarat sebagai MQL terlepas dari skor:
- Pelanggan yang sudah ada (teruskan ke CSM)
- Leads dengan opportunities aktif yang terbuka (teruskan ke AE yang bertanggung jawab)
- Kompetitor (teruskan ke antrian competitive intelligence)
- Pencari kerja, mahasiswa, atau institusi akademik
- Domain email pribadi (gmail.com, yahoo.com, dll.) kecuali nama perusahaan dan telepon diverifikasi
- Kontak yang ditandai sebagai unsubscribed atau do-not-contact
BAGIAN C — DEFINISI SQL DAN KRITERIA PENERIMAAN
Leads mencapai status SQL ketika sales rep mengonfirmasi semua hal berikut:
C.1 — Kriteria Penerimaan
| Kriteria | Definisi |
|---|---|
| ICP dikonfirmasi | Ukuran perusahaan, industri, dan geografi sesuai kriteria di Bagian B.1 |
| Kontak diverifikasi | Email langsung dikonfirmasi dapat dikirim; nomor telepon dapat dihubungi |
| Minat dikonfirmasi | Kontak telah menyatakan minat aktif dalam percakapan discovery atau demo |
| Tidak ada pemblokiran aktif | Tidak diketahui ada kontrak dengan kompetitor langsung; tidak ada closed-lost aktif dalam [mis., 90] hari terakhir |
C.2 — Acceptance Window
Sales harus menerima atau menolak setiap MQL dalam [mis., 4] jam kerja setelah notifikasi handoff.
Untuk Tier 1 MQL (demo requests, kunjungan halaman pricing): penerimaan atau penolakan dalam [mis., 1] jam kerja.
C.3 — Cara Penerimaan Dicatat
Penerimaan dicatat dengan mengubah status leads dari "MQL — Pending" menjadi "SQL — Accepted" di [Nama CRM].
Jika rep tidak dapat menghubungi kontak dalam [mis., 3] hari kerja menggunakan persyaratan contact persistence di Bagian E.2, status leads berubah menjadi "SQL — Unresponsive" dan dikembalikan ke marketing untuk keputusan.
BAGIAN D — KEWAJIBAN HANDOFF: MARKETING
Marketing berkomitmen untuk memberikan hal-hal berikut pada setiap handoff MQL:
D.1 — Kelengkapan Data
| Field | Diperlukan | Sumber |
|---|---|---|
| Nama lengkap | Ya | Form + enrichment |
| Jabatan | Ya | Form + enrichment |
| Email langsung (tervalidasi) | Ya | Verifikasi enrichment |
| Telepon langsung | Ya (jika tersedia) | Enrichment |
| URL profil LinkedIn | Disukai | Enrichment |
| Nama perusahaan (dinormalisasi) | Ya | Form + enrichment |
| Jumlah karyawan perusahaan | Ya | Enrichment |
| Vertikal industri | Ya | Enrichment |
| Tier ICP fit | Ya | Scoring model |
| Lead score + breakdown | Ya | MAP |
| Penjelasan score trigger | Ya | Catatan otomatis |
| 5 behavioral touchpoints terakhir | Ya | Sinkronisasi aktivitas MAP |
| Atribusi kampanye / sumber | Ya | Data UTM + form |
| Status pencocokan akun CRM | Ya | Pencarian CRM saat handoff |
D.2 — Timing Handoff
MQL trigger ke handoff CRM: dalam [mis., 15] menit untuk rute otomatis. Routing jam kerja: segera. Routing di luar jam kerja: paling lambat [mis., pukul 8 pagi waktu setempat] hari kerja berikutnya.
D.3 — Routing Trigger
Leads yang memenuhi kriteria MQL di Bagian B secara otomatis diteruskan berdasarkan aturan routing yang didokumentasikan di [tautan dokumen Aturan Routing].
Marketing akan memberi tahu RevOps dalam 1 hari kerja dari kampanye mana pun yang diharapkan menghasilkan >50 MQL dalam satu hari, untuk memungkinkan perencanaan kapasitas rep.
BAGIAN E — KEWAJIBAN HANDOFF: SALES
Sales berkomitmen untuk hal-hal berikut pada setiap MQL yang diterima:
E.1 — SLA Respons berdasarkan Tier
| Tier Leads | Definisi | SLA Percobaan Pertama |
|---|---|---|
| Tier 1 | Demo request, halaman pricing (2+ kunjungan), inbound langsung | Dalam [mis., 15] menit selama jam kerja |
| Tier 2 | Peserta event, inbound skor tinggi, sinyal intent | Dalam [mis., 2] jam kerja |
| Tier 3 | Content download, click-through newsletter | Dalam [mis., 1] hari kerja |
Jam kerja didefinisikan sebagai: [mis., 8 pagi–6 sore, Senin–Jumat, di zona waktu setempat leads].
E.2 — Persyaratan Contact Persistence
Sebelum menandai leads sebagai "Unresponsive," sales harus melakukan minimal:
- [mis., 6] percobaan kontak selama [mis., 10] hari kerja
- Setidaknya [mis., 2] percobaan telepon
- Setidaknya [mis., 3] percobaan email
- Setidaknya [mis., 1] pesan LinkedIn atau InMail (untuk leads mid-market dan enterprise)
- Percobaan harus dilakukan pada [mis., 3+] hari yang berbeda — tidak semua dalam satu hari
E.3 — Persyaratan Penolakan
Jika leads ditolak:
- Rep harus memilih reason code di [Nama CRM] sebelum penolakan diproses
- Reason code yang valid: Tidak cocok ICP | Tidak ada sinyal anggaran | Kontak salah | Timing buruk | Masalah kualitas data | Pelanggan yang sudah ada / opportunity terbuka
- Catatan free-text opsional tersedia untuk konteks
- Tidak ada penolakan diam — leads tidak dapat diabaikan tanpa disposisi
E.4 — Feedback ke Marketing
- Hadiri weekly lead quality call ([tautan rapat atau undangan kalender])
- Kirimkan [mis., 2] catatan win/loss per bulan menggunakan [form Win/Loss atau channel Slack]
- Tandai anomali scoring (leads dengan skor tinggi yang konsisten gagal kualifikasi) dalam [mis., 3] hari kerja ke RevOps
BAGIAN F — ATURAN RECYCLING
F.1 — Disposisi Penolakan berdasarkan Reason Code
| Rejection Code | Disposisi Default | Kriteria Re-entry |
|---|---|---|
| Tidak cocok ICP | Arsip — jangan recycle | T/A kecuali definisi ICP berubah |
| Tidak ada sinyal anggaran | Long-cycle nurture (track [mis., 6-bulan]) | Sinyal anggaran baru + periode pendinginan 30 hari |
| Kontak salah | Temukan kontak yang benar; re-route | Kontak baru diidentifikasi + behavioral trigger baru |
| Timing buruk | Short-cycle re-nurture (track [mis., 90-hari]) | Trigger engagement baru setelah periode pendinginan |
| Masalah kualitas data | Enrich dan re-qualify | Enrichment selesai + lulus pemeriksaan data |
| Sudah menjadi pelanggan | Teruskan ke CSM | T/A — dihapus dari nurture marketing |
F.2 — Persyaratan Re-Entry
Leads yang di-recycle hanya dapat re-kualifikasi sebagai MQL ketika:
- Periode pendinginan telah berlalu (minimal [mis., 30] hari; [mis., 90] hari untuk "Tidak cocok ICP")
- Behavioral trigger baru telah terjadi (bukan kelanjutan dari aktivitas sebelum penolakan)
- Leads yang di-recycle lebih dari dua kali memerlukan tinjauan manusia oleh marketing ops sebelum masuk kembali ke antrian MQL
F.3 — Timeline Penugasan Nurture
Marketing berkomitmen untuk menempatkan leads yang di-recycle ke jalur nurture yang sesuai dalam [mis., 5] hari kerja setelah penolakan.
BAGIAN G — REVIEW DAN AMANDEMEN
G.1 — Quarterly Review
Perjanjian ini ditinjau setiap kuartal. Pemilik rapat review: [RevOps Lead]. Peserta: CMO/VP Marketing + CRO/VP Sales + RevOps. Agenda: Tren rejection rate, data konversi recycling, proposal kalibrasi skor, amandemen definisi apa pun.
G.2 — Proses Amandemen
Salah satu pihak dapat mengusulkan amandemen dengan mengajukan permintaan tertulis kepada pemilik RevOps dengan data pendukung. Amandemen diratifikasi ketika kedua penandatangan di bawah ini menyetujui secara tertulis (konfirmasi email dapat diterima).
Perubahan berlaku efektif [mis., 30] hari setelah ratifikasi untuk memungkinkan pembaruan sistem.
G.3 — Kontrol Versi
Semua versi diarsipkan di [tautan shared drive atau wiki]. Versi saat ini selalu dapat diakses di [tautan].
TANDA TANGAN
| Peran | Nama | Tanda Tangan | Tanggal |
|---|---|---|---|
| CMO / VP Marketing | [Nama] | ||
| CRO / VP Sales | [Nama] | ||
| RevOps Lead (Saksi) | [Nama] |
Cara Menyesuaikan Template
Template di atas ditulis untuk tim B2B SaaS SMB atau mid-market tipikal dengan 3-15 rep, ICP yang terdefinisi, dan stack CRM + MAP. Berikut cara mengadaptasinya untuk situasi Anda:
Jika Anda adalah tim single-product berkecepatan tinggi (di bawah 50 karyawan): Sederhanakan Bagian B dan C. Anda mungkin tidak memerlukan sub-scores atau behavioral triggers selain "demo diminta." Pertahankan acceptance window yang ketat: di bawah 2 jam untuk segalanya.
Jika Anda adalah tim multi-product: Tambahkan field lini produk ke Bagian B.1 dan catatan routing ke Bagian D.3. Rep yang mengkhususkan diri pada Produk A tidak boleh menerima leads Produk B secara default.
Jika Anda menjalankan enterprise motion dengan siklus panjang: Longgarkan acceptance window di Bagian C.2 (4-8 jam bagus untuk enterprise). Perkuat contact persistence di Bagian E.2 (8-12 percobaan selama 15-20 hari). Tambahkan nurture re-entry trigger untuk penolakan timing "siklus anggaran" di Bagian F.
Jika Anda memiliki tim partner atau channel: Tambahkan Bagian H untuk leads yang bersumber dari partner dengan aturan routing dan penerimaan yang terpisah. Leads partner sering melibatkan kewajiban co-selling yang tidak dicakup oleh aturan standar.
Cara Membuat Kedua Tim Menandatanganinya
Pendekatan fasilitasi sama pentingnya dengan dokumen. Dua pilihan:
Joint workshop (direkomendasikan untuk perjanjian pertama kali): Sesi dua jam dengan kedua pemimpin dan RevOps. Bahas setiap bagian bersama-sama. Di mana Anda tidak sepakat (biasanya score threshold, acceptance window, atau granularitas rejection code), bekerjalah dari data. Ambil data MQL dan penolakan 90 hari terakhir dan biarkan angka-angka memandu negosiasi.
Redline asynchronous (untuk pembaruan perjanjian yang sudah ada): Edarkan draf, biarkan setiap tim memodifikasi bagian mereka, bawa istilah yang bertentangan ke dalam keputusan 30 menit. Bekerja dengan baik untuk amandemen kuartalan ketika hubungan sudah terbentuk.
Titik Hambatan Negosiasi yang Umum
Pertarungan score threshold. Marketing ingin 60. Sales ingin 80. Jawaban jujurnya adalah tidak ada pihak yang tahu. Anda membutuhkan data. Ambil MQL 90 hari terakhir dan hitung conversion rate berdasarkan score band dalam kenaikan 5 poin. Score threshold jatuh secara alami di titik di mana conversion rate berubah secara bermakna. Analisis MQL score thresholds Anda menyediakan benchmark referensi untuk negosiasi ini.
Perdebatan acceptance window. Sales mengatakan mereka tidak bisa merespons dalam 2 jam karena mereka sedang dalam demo sepanjang hari. Solusinya adalah bertingkat: 15 menit untuk Tier 1 (demo requests), 2 jam untuk Tier 2, 1 hari untuk Tier 3. Beri rep window yang realistis untuk leads low-intent tanpa mengorbankan kecepatan respons pada leads high-intent.
Granularitas rejection reason. Sales ingin satu field: "leads buruk." Marketing ingin 20 kode. Sepakati 5-7 kode yang secara bermakna memisahkan penolakan yang dapat ditindaklanjuti (timing, kontak salah) dari yang tidak dapat ditindaklanjuti (tidak cocok ICP). Apa pun di luar 7 kode mengurangi kepatuhan. Rep berhenti memilih dengan cermat ketika daftarnya panjang.
Setelah Penandatanganan: Membuat Perjanjian Menjadi Operasional
Simpan perjanjian yang ditandatangani di wiki bersama, knowledge base CRM, atau drive tim: di suatu tempat yang ditautkan oleh kedua tim dari dokumen onboarding mereka. Referensikan di agenda weekly lead quality call.
Ketika perselisihan muncul, buka dokumen dan temukan bagian yang relevan sebelum argumen meningkat. Sebagian besar perselisihan diselesaikan di teks. Seseorang beroperasi berdasarkan versi perjanjian yang berbeda dalam pikiran mereka.
Tanda Peringatan Perjanjian Sudah Usang
- Rejection rate untuk reason code tertentu melonjak di atas 30% selama dua bulan berturut-turut
- Score threshold menghasilkan volume MQL yang secara konsisten di atas atau di bawah target
- Rep secara rutin menerima MQL dan kemudian segera menandai mereka sebagai "Unresponsive" tanpa mencoba menghubungi (tanda bahwa acceptance window terlalu ketat relatif terhadap kapasitas nyata)
- Marketing mengubah kampanye atau scoring model tanpa memberi tahu RevOps; setiap perubahan scoring yang menggeser volume MQL lebih dari 15% harus memicu emergency review
Pertanyaan yang Sering Diajukan
Bagaimana cara meluncurkan perjanjian MQL/SQL tanpa menjadi pertarungan politik?
Framing sebagai alat kalibrasi, bukan dokumen kepatuhan. Pendekatan rollout yang paling efektif adalah joint workshop dua jam dengan kedua pemimpin dan RevOps, membahas setiap bagian menggunakan data MQL dan penolakan 90 hari terakhir Anda. Di mana tim tidak sepakat — biasanya pada score threshold dan acceptance window — biarkan data konversi yang memutuskan, bukan senioritas. Tim yang bernegosiasi dari data daripada pendapat mencapai kesepakatan 3-4x lebih cepat dan menghasilkan perjanjian yang bertahan lebih lama karena kedua pihak melihat angka yang sama.
Bagaimana jika sales tidak mau menandatangani perjanjian MQL/SQL?
Resistensi sales biasanya menandakan salah satu dari dua hal: score threshold terasa terlalu rendah (sales tidak mempercayai leads), atau acceptance window terasa tidak realistis mengingat kapasitas rep saat ini. Keduanya dapat diselesaikan dengan data. Untuk resistensi score threshold, tarik conversion rate berdasarkan score band dalam kenaikan 5 poin — diskusi threshold menjadi empiris. Untuk resistensi acceptance window, buat persyaratan bertingkat: 15 menit untuk demo requests, 4 jam untuk segalanya. Menandatangani SLA bertingkat lebih mudah dari pada SLA umum. Jika resistensi berlanjut, minta sales untuk mengusulkan threshold mereka sendiri dengan data pendukung. Tindakan membangun kasus sering menggeser dinamika dari oposisi menjadi co-ownership.
Seberapa sering perjanjian MQL/SQL harus ditinjau ulang?
Quarterly review adalah minimum. Tetapi tiga kejadian harus memicu review out-of-cycle yang segera: perubahan kampanye atau scoring model yang menggeser volume MQL lebih dari 15%, lonjakan rejection rate di atas 30% untuk reason code tertentu selama dua bulan berturut-turut, dan perubahan ICP signifikan apa pun (segmen baru ditambahkan, segmen yang ada de-prioritaskan). Quarterly review untuk penyesuaian. Review yang dipicu untuk menangkap drift sebelum menjadi kuartal yang terlewat.
Siapa yang memiliki dokumen perjanjian MQL/SQL?
RevOps memiliki dokumen, kontrol versi, dan kalender review. Marketing dan sales masing-masing memiliki bagian mereka. RevOps lead adalah pemilik proses yang menjalankan quarterly review, mengelola permintaan amandemen, dan memegang kedua pihak pada jadwal yang disepakati. Tanpa pemilik yang netral, perjanjian diperbarui secara sepihak oleh siapa pun yang berada di bawah tekanan lebih — yang mengalahkan tujuannya sebagai referensi bersama.
Berapa seharusnya score threshold ditetapkan?
Tidak ada threshold universal. Ambil deals closed-won 90 hari terakhir dan telusuri kembali masing-masing ke lead score asli mereka pada saat handoff MQL. Temukan score band di mana conversion rate naik secara bermakna di atas rata-rata keseluruhan Anda — titik infleksi itu adalah anchor threshold empiris Anda. Tim dengan data kurang dari 90 hari harus mulai dari 60 dan menyesuaikan berdasarkan feedback rejection rate setelah satu bulan penuh. Rejection rate di atas 35% menunjukkan threshold terlalu rendah. Rejection rate di bawah 10% menunjukkan mungkin terlalu longgar (terlalu banyak leads yang tidak memenuhi syarat lolos).
Pelajari Lebih Lanjut

Senior Operations & Growth Strategist
On this page
- Apa Itu Perjanjian MQL/SQL (dan Apa Bukan)
- Mengapa Tim Dengan Perjanjian Bertanda Tangan Mengungguli Tim Tanpa Perjanjian
- TEMPLATE — Perjanjian MQL/SQL
- PERJANJIAN MQL/SQL
- Cara Menyesuaikan Template
- Cara Membuat Kedua Tim Menandatanganinya
- Titik Hambatan Negosiasi yang Umum
- Setelah Penandatanganan: Membuat Perjanjian Menjadi Operasional
- Tanda Peringatan Perjanjian Sudah Usang
- Pertanyaan yang Sering Diajukan
- Bagaimana cara meluncurkan perjanjian MQL/SQL tanpa menjadi pertarungan politik?
- Bagaimana jika sales tidak mau menandatangani perjanjian MQL/SQL?
- Seberapa sering perjanjian MQL/SQL harus ditinjau ulang?
- Siapa yang memiliki dokumen perjanjian MQL/SQL?
- Berapa seharusnya score threshold ditetapkan?
- Pelajari Lebih Lanjut