Arsitektur MAP dan CRM Tanpa Solusi Tambal Sulam: Playbook Rebuild MOps

Anda membuka pengelola field dan menghitung 247 field kustom. Separuhnya dimiliki orang-orang yang keluar pada 2023. Sinkronisasi lead-ke-kontak telah rusak sejak admin terakhir "memperbaikinya" pada Q2. Dua dari picklist punya nilai teks bebas yang seharusnya tidak ada. Tahap siklus hidup ditulis oleh Marketo maupun Salesforce, jadi 14% record berkibar bolak-balik antara MQL dan Lead setiap siklus sinkronisasi.

Selamat datang di MOps.

Jika Anda baru saja mewarisi tumpukan ini, atau Anda telah menatapnya selama dua tahun sambil berjanji pada diri sendiri akan membersihkannya "setelah kampanye berikutnya", inilah playbook-nya. Inilah yang saya harap diserahkan seseorang kepada saya tiga pekerjaan lalu. Tujuannya bukan diagram yang cantik. Tujuannya adalah satu sumber kebenaran per titik data, satu pemilik per field, dan integrasi yang tidak membangunkan Anda pukul 3 pagi.

Alur Data MAP ke CRM: Kontrak yang Sebenarnya

Sebagian besar tim memperlakukan integrasi MAP-ke-CRM seperti kotak hitam. Bukan. Ia adalah sebuah kontrak, dan jika tidak ada yang menuliskan kontraknya, Anda punya solusi tambal sulam.

Kontrak itu punya empat bagian. Salah pada bagian-bagian ini dan tidak ada hal lain yang penting.

Lead vs Kontak: apa yang terbawa, apa yang mati

Ketika sebuah Lead berkonversi menjadi Kontak di Salesforce (atau apa pun yang disebut CRM Anda), Anda kehilangan data kecuali Anda telah memetakannya secara eksplisit. Perilaku default di kebanyakan CRM:

Field Lead standar dengan field Kontak yang cocok: terbawa
Field Lead kustom tanpa field Kontak yang cocok: lenyap
Riwayat aktivitas: biasanya dipertahankan, terkadang menjadi yatim
Field penilaian sisi MAP: sepenuhnya tergantung apakah MAP Anda menulis ke objek Lead-saja atau ke keduanya

Rahasia kotornya adalah 80% tim MOps menulis skor demografis dan perilaku ke objek Lead saja, lalu pura-pura terkejut ketika seorang SDR mengonversi sebuah Lead dan skornya menghilang. Jika MAP Anda adalah Marketo atau Pardot, Anda seharusnya menulis field penilaian ke Lead maupun Kontak, ATAU mengonversi Lead menjadi Kontak saat pembuatan (model "semua Kontak, tanpa Lead" yang dijadikan default oleh HubSpot).

Pilih satu. Dokumentasikan. Hentikan pendarahannya.

Tahap Siklus Hidup: MAP menulis, CRM membaca. Jangan pernah keduanya.

Inilah aturan paling penting dalam seluruh playbook ini. Jika kedua sistem bisa menulis ke tahap siklus hidup, Anda akan punya kondisi balapan. Anda akan punya record yang berkibar. Anda akan punya seorang SDR yang menutup deal pada sebuah Kontak yang baru saja diturunkan MAP kembali ke MQL karena sebuah webhook berhenti berlangganan menyala tiga menit setelah pembaruan Closed-Won.

Pilih satu penulis. MAP biasanya benar karena ia melihat sinyal perilaku lebih dulu. CRM membaca tahap siklus hidup; ia tidak memperebutkannya. Jika penjualan perlu menimpa (misalnya, menandai seseorang secara manual sebagai SAL), bangun field terpisah (sales_stage_override__c) dan biarkan sebuah otomatisasi di MAP menghormati penimpaan itu. Jangan biarkan dua sistem bertengkar tentang kolom yang sama.

Waktu sinkronisasi: real-time tidak selalu lebih baik

Dorongan default adalah "buat real-time". Ini salah sekitar separuh waktu.

Sinkronisasi real-time masuk akal untuk:

Pengisian formulir (lead harus mendarat di CRM sebelum antrean SDR menyegarkan)
Transisi tahap siklus hidup yang menggerakkan perutean
Status Closed-Won (atribusi pendapatan tidak bisa menunggu)

Sinkronisasi batch (15 menit, per jam, semalam) masuk akal untuk:

Penghitungan ulang skor secara massal
Pembalikan keanggotaan list
Pengisian ulang riwayat aktivitas
Apa pun yang menyalakan lebih dari 1.000 pembaruan record per jam

Mengapa ini penting? Karena "setiap 10 menit" adalah pengaturan terburuk yang mungkin untuk sinkronisasi penilaian. Ia cukup lambat sehingga SDR tidak bisa memercayainya, cukup cepat untuk merusak batas API Anda selama sebuah kiriman kampanye, dan cukup sering untuk membuat kondisi balapan tak terlihat sampai kueri rekonsiliasi bulanan Anda menangkapnya.

Jika Anda hanya mengingat satu hal: real-time untuk serah terima, batch untuk kebersihan.

Serah terima MQL: satu field, satu pemilik, satu definisi

Berhenti. Buka Salesforce Anda. Cari field apa pun dengan "MQL" di namanya. Saya bertaruh segelas kopi Anda punya setidaknya tiga:

MQL_Date__c (ditetapkan oleh Marketo)
Marketing_Qualified__c (ditetapkan oleh aturan workflow dari 2022)
Lifecycle_Stage = "MQL" (ditetapkan oleh HubSpot)

Pilih satu. Hapus dua lainnya. Serah terima MQL adalah satu field, satu pemilik (MOps), satu definisi (dituliskan dalam dokumen Confluence yang punya tanggal padanya). Jika penjualan tidak memercayai field-nya, itu adalah masalah definisi, bukan masalah field. Menambahkan field keempat tidak pernah memperbaiki masalah definisi.

Masalah Pembengkakan Field

Pembengkakan field adalah cara tumpukan MAP+CRM mati. Bukan satu kegagalan dramatis. Sebuah akumulasi lambat field yang tidak dimiliki siapa pun, digunakan oleh satu laporan yang tidak dibuka siapa pun, ditetapkan oleh satu workflow yang tidak didokumentasikan siapa pun.

Bagaimana Anda sampai pada 247 field kustom

Setiap field punya kisah penciptaan. Kira-kira:

30% nyata, digunakan, dimiliki. Ini baik-baik saja.
25% dibuat untuk sebuah kampanye pada 2022, masih ditulisi, dan tidak dibaca oleh apa pun.
20% dibuat oleh seorang pemimpin penjualan yang keluar, dipetakan ke sebuah dashboard yang telah ditinggalkan, tetapi field-nya masih ada di setiap tata letak halaman.
15% adalah duplikat dengan nama yang sedikit berbeda (Industry__c, industry_v2__c, Account_Industry__c).
10% adalah "field hantu" integrasi yang dibuat otomatis oleh sebuah integrasi yang diputuskan 18 bulan lalu, tetapi field-nya tetap ada.

Tidak ada yang menghapus field karena penghapusan terasa berisiko. Itulah tepatnya mengapa Anda butuh sebuah proses.

Kerangka audit field 90 hari

Jalankan ini setiap kuartal. Blokir empat jam pada hari Jumat. Inilah pekerjaan pembersihan dengan daya ungkit tertinggi di MOps.

Langkah 1: Tarik laporan penggunaan. Untuk setiap field kustom, hitung:

Berapa banyak record yang punya nilai non-null (90 hari terakhir penulisan)
Berapa banyak laporan yang merujuk field
Berapa banyak workflow/otomatisasi yang merujuk field
Berapa banyak integrasi yang menulis ke sana

Jika keempatnya nol, field itu mati. Tandai.

Langkah 2: Temukan pemiliknya. Setiap field perlu sebuah nama yang terlampir. Tarik "Created By" dan periksa apakah orang itu masih ada di perusahaan. Jika tidak, telusuri field itu melalui tim. Adakah yang mengaku memilikinya? Jika tidak ada yang mengakuinya dalam tujuh hari, ia yatim.

Langkah 3: Bangun daftar hapus. Tiga keranjang:

Hapus permanen: Nol penggunaan DAN tanpa pemilik. Hapus pada sprint berikutnya.
Ditinggalkan: Punya sebagian penggunaan tetapi pemilik setuju ia redundan. Tandai sebagai ditinggalkan dalam deskripsi, sembunyikan dari tata letak, jadwalkan penghapusan dalam 90 hari.
Dokumentasikan: Aktif, dimiliki, tanpa tindakan lebih lanjut. Tulis deskripsinya jika kosong.

Langkah 4: Buat ia menetap. Tambahkan kebijakan penciptaan field: setiap field kustom baru membutuhkan deskripsi, pemilik, dan tanggal "ditinjau pada". Tanpa deskripsi = tanpa field. Buat admin CRM menegakkannya. Jika mereka tidak mau, dapatkan hak admin untuk diri Anda sendiri untuk satu workflow itu.

Anda tidak akan sampai ke 50 field. Anda mungkin bisa sampai ke 100. Itulah tujuannya.

Konvensi Penamaan yang Bertahan dari Pergantian Karyawan

Jika admin berikutnya yang mewarisi tumpukan Anda tidak bisa menebak apa yang dilakukan sebuah field dalam lima detik, namanya salah. Ganti namanya.

Konvensi penamaan yang saya gunakan, yang telah bertahan dari tiga pergantian pekerjaan:

mkt_*: ditulis oleh MAP. Pemasaran memiliki.
sfdc_*: field Salesforce native atau field kustom milik penjualan.
ext_*: ditulis oleh integrasi eksternal (Clearbit, ZoomInfo, 6sense, dll.). Hanya-baca untuk semua orang lain.
ops_*: field operasional/terhitung (region, segmen, tier akun).
Tanpa prefiks: field standar yang tidak Anda buat.

Disiplin picklist lebih penting daripada yang Anda kira. Field negara teks bebas di mana Anda punya "USA", "U.S.A.", "United States", "US", dan "America" semuanya dalam kumpulan data yang sama akan menghancurkan pelaporan Anda. Kunci picklist. Jika penjualan berdebat, tunjukkan kepada mereka laporan segmen di mana pendapatan-USA terbelah di lima keranjang.

Aturan lima detik: jika seorang admin baru membuka pengelola field dan tidak bisa menebak apa yang dilakukan cust_dt_2_v3__c dalam lima detik, field itu salah nama. Ganti namanya. Ya, itu akan merusak dua laporan. Perbaiki laporannya. Diri-Anda di masa depan akan mengirim ucapan terima kasih.

Pemilihan MAP: Marketo vs HubSpot vs Pardot vs Rework

Separuh dari rasa sakit integrasi MAP datang dari memilih MAP yang salah untuk perusahaan. Inilah cara saya memikirkannya.

Marketo (kini Adobe)

Pilih Marketo jika:

Anda punya admin MAP yang berdedikasi (bukan "manajer pemasaran yang juga mengurus Marketo")
Program kampanye Anda benar-benar kompleks (pemeliharaan multi-sentuh, play berbasis akun, lusinan segmen)
Anda enterprise (1.000+ karyawan) atau menjalankan demand gen bergaya enterprise
Anda bisa menelan harganya dan kurva pembelajarannya

Jangan pilih Marketo jika Anda startup 50 orang. Anda akan menggunakan 8% dari platform, membayar 100% dari harga, dan integrasi ke Salesforce akan memakan satu FTE.

HubSpot

Pilih HubSpot jika:

Pemasaran memimpin motif GTM
Tim Anda hidup di UI (bukan di panggilan API dan SQL)
Anda mid-market (50 hingga 500 karyawan)
Anda ingin CRM dan MAP dari vendor yang sama dan Anda tidak masalah dengan CRM HubSpot (yang memadai untuk SMB, menjadi tipis di enterprise)

Kekuatan HubSpot adalah CRM dan MAP-nya adalah satu sistem, jadi masalah solusi tambal sulam sebagian menghilang. Kelemahannya adalah jika Anda melampaui CRM HubSpot dan menambahkan Salesforce, Anda telah menciptakan kembali masalah integrasi dengan langkah ekstra.

Pardot (Marketing Cloud Account Engagement)

Pilih Pardot jika:

Anda adalah toko Salesforce-native dan admin Salesforce juga memiliki otomatisasi pemasaran
Anda tidak butuh logika program yang mewah
Anda ingin tahap siklus hidup dan penilaian terkait erat dengan objek SFDC

Kekuatan Pardot adalah integrasi SFDC-nya native (ia hidup di dalam SFDC). Kelemahannya adalah MAP-nya sendiri ketinggalan zaman; jika tim Anda butuh UX modern, mereka akan melawan Anda.

Rework

Pilih Rework jika:

Anda B2B kecil atau menengah (20 hingga 500 karyawan)
Penjualan dan pemasaran berbagi satu pipeline dan Anda tidak ingin dua alat memperebutkannya
Anda tidak punya admin MAP yang berdedikasi dan Anda tidak menginginkannya
Anda lebih memilih punya satu CRM dengan penangkapan lead, penilaian, dan perutean bawaan daripada memelihara integrasi MAP+CRM yang terpisah

Tawaran Rework pada masalah spesifik ini: tidak ada integrasi MAP-ke-CRM untuk dipelihara karena tidak ada MAP yang terpisah. Penangkapan lead, penilaian, tahap siklus hidup, dan pipeline hidup dalam satu sistem. Anda merelakan sebagian kompleksitas program enterprise Marketo. Sebagai gantinya Anda merelakan solusi tambal sulamnya.

Untuk tim B2B SaaS 30 orang dengan satu generalis MOps, tumpukan Marketo+SFDC menghabiskan biaya mungkin $80 ribu/tahun dalam lisensi ditambah setengah FTE untuk memeliharanya. Workflow yang sama di Rework berjalan $12/pengguna/bulan pada tier CRM (sekitar $10 ribu/tahun untuk tim 30 orang) dan integrasi MAP beralih dari "pelihara" menjadi "tidak ada".

Itu bukan jawaban yang tepat untuk semua orang. Itu adalah jawaban yang tepat untuk lebih banyak tim daripada yang mau mengakuinya.

Keputusan Rebuild-dari-Nol

Pada suatu titik, menambal lebih mahal daripada membangun ulang. Bagian sulitnya adalah mengetahui kapan.

Aturan 40%: jika lebih dari 40% waktu tim MOps Anda dihabiskan untuk perbaikan integrasi, field hantu, dan kueri rekonsiliasi, dan telah begitu selama dua kuartal berturut-turut, Anda sudah melewati titik tambal. Bangun ulang.

Sinyal lainnya:

Tiga atau lebih field siklus hidup yang "dipercaya" ada dan orang-orang berdebat tentang mana yang benar
Kesalahan sinkronisasi berjalan lebih dari 0,5% record per hari
Seorang perekrutan MOps baru butuh lebih dari 90 hari untuk meluncurkan perubahan non-sepele pertamanya
Jejak audit pada field kritis adalah "tanya Sandra, dia ingat"
Integrasi MAP-CRM punya lebih dari dua komponen middleware kustom (resep Workato, zap Zapier, Apex kustom)

Rebuild bukan operasi "ledakkan semuanya". Mereka adalah pembangunan-paralel. Anda mendirikan instansi baru (atau skema bersih di instansi yang ada), bermigrasi satu kampanye pada satu waktu, memvalidasi, lalu meninggalkan yang lama. Itu butuh 90 hingga 180 hari. Itu lebih cepat daripada 18 bulan tambalan berikutnya.

Beri tahu atasan Anda bahwa ini adalah investasi, bukan proyek. Investasi berakumulasi. Tambalan tidak.

Pemantauan Kesehatan Integrasi

Integrasi MAP-CRM yang sehat punya telemetri. Jika Anda tidak bisa melihatnya, Anda tidak bisa memperbaikinya.

Tiga peringatan yang seharusnya dijalankan setiap MOps lead:

1. Peringatan tingkat kesalahan sinkronisasi. Menyala jika kesalahan sinkronisasi melebihi 0,5% dari record yang dicoba dalam jendela 1 jam. Ini menangkap masalah batas API, konflik aturan validasi, dan kegagalan middleware sebelum penjualan menyadarinya.

2. Peringatan kibasan siklus hidup. Menyala jika tahap siklus hidup record mana pun berubah lebih dari tiga kali dalam 24 jam. Ini menangkap kondisi balapan di mana dua sistem memperebutkan field yang sama.

3. Peringatan latensi formulir-ke-CRM. Menyala jika pengiriman formulir mana pun butuh lebih dari 90 detik untuk mendarat di CRM. SDR memercayai sistem berdasarkan metrik ini lebih daripada yang lain.

Sebuah kueri rekonsiliasi harian juga seharusnya berjalan setiap pagi pukul 6 dan mengirim email kepada Anda (dan hanya Anda, sampai Anda memercayainya). Kueri yang saya jalankan pada Salesforce + Marketo:

-- Record di MAP tanpa padanan CRM, 7 hari terakhir
SELECT email, lifecycle_stage, last_modified
FROM map_leads
WHERE crm_id IS NULL
  AND created > DATEADD(day, -7, CURRENT_DATE)
  AND lifecycle_stage IN ('MQL', 'SAL');

Apa pun dalam kumpulan hasil itu adalah lead yang seharusnya sampai ke sales rep tetapi tidak. Jika kueri mengembalikan lebih dari 5 baris dalam sehari, Anda punya masalah integrasi yang belum Anda ketahui.

Varian dashboard: tampilan mingguan jumlah kesalahan sinkronisasi berdasarkan jenis kesalahan, latensi serah terima MQL P50/P95, dan total record di bawah setiap tahap siklus hidup. Jadikan ia beranda ruang Confluence MOps Anda. Ketika seorang VP bertanya "apakah sistemnya sehat?" Anda menunjuk dashboard dan berkata "ya" atau "tidak" dengan data.

Satu Sumber Kebenaran, Satu Definisi MQL, Satu Pemilik

Jika playbook ini punya satu pelajaran utama, itu adalah ini: setiap titik data dalam tumpukan MAP+CRM Anda punya tepat satu sumber kebenaran, satu pemilik, dan satu definisi. Segala hal lainnya adalah solusi tambal sulam.

Ketika seorang sales rep berdebat bahwa sebuah MQL "bukan benar-benar MQL", itu bukan masalah field. Itu adalah masalah definisi. Perbaiki definisinya. Dokumentasikan. Buat pimpinan penjualan menyetujuinya secara tertulis. Lalu field-nya menjadi tidak relevan, karena semua orang setuju tentang apa artinya.

Ketika dua sistem menulis ke field yang sama, pilih satu. Yang lainnya menjadi hanya-baca atau mendapat field penimpaan terpisah. Kondisi balapan tidak menjadi lebih baik dengan lebih banyak workflow.

Ketika sebuah field kustom tidak punya pemilik, matikan. Jika ada yang menyadari ia hilang dalam tiga bulan, Anda akan tahu siapa yang sebenarnya menggunakannya. Sebagian besar waktu, tidak ada yang menyadarinya, dan Anda telah membuat sistem lebih sederhana untuk admin berikutnya yang mewarisinya.

Solusi tambal sulam berakumulasi. Setiap jalan pintas yang Anda ambil kuartal ini adalah masalah yang diwarisi penerus Anda tahun depan. Terkadang jawaban yang tepat adalah membangun ulang. Terkadang itu adalah beralih ke tumpukan yang tidak membutuhkan integrasinya sejak awal. Hampir selalu, itu adalah menghapus lebih banyak daripada yang Anda tambahkan.

Itulah pekerjaannya.

Playbook Marketing Ops