Bahasa Melayu

RevOps sebagai Perekat Penjajaran: Mengapa Revenue Operations Menjadikan Smarketing Benar-Benar Berfungsi

RevOps sebagai lapisan operasional yang menghubungkan pemasaran, jualan, dan kejayaan pelanggan

Inisiatif penjajaran pemasaran-jualan gagal pada kadar yang boleh diramalkan. Bukan kerana orang yang terlibat tidak mahu bekerjasama. Kebanyakan mahu. Bukan kerana strateginya salah. Biasanya tidak. Ia gagal kerana penjajaran itu hidup dalam mesyuarat dan merosot di antara mesyuarat.

Syarikat dengan fungsi RevOps yang berdedikasi berkembang pendapatan 2.4x lebih pantas daripada mereka yang bergantung pada operasi jualan, pemasaran, dan CS yang diasingkan, dan mencapai kadar kemenangan jualan 36% lebih tinggi, menurut Tinjauan Revenue Operations Forrester dan Laporan Keadaan Revenue Operations LeanData. Jurang prestasi itu tidak dijelaskan oleh perbezaan strategi — pasukan tanpa RevOps sering mempunyai pelan go-to-market yang setanding. Ia dijelaskan oleh konsistensi pelaksanaan: pasukan yang dibolehkan RevOps tidak bergantung pada orang yang mengingati untuk melakukan perkara yang betul.

Kedua-dua pasukan bersetuju pada takrifan MQL pada bulan Januari. Menjelang Mac, hanyutan pemarkahan telah mengikisnya. Mereka bersetuju pada SLA Handoff pada Q1. Menjelang Q2, tiada siapa yang menjejak pematuhan. Mereka bersetuju bahawa kedua-dua pasukan akan menggunakan papan pemuka yang sama. Menjelang Q3, jualan menjalankan ulasan Pipeline dari CRM dan pemasaran melaporkan dari MAP, dan tiada nombor yang sepadan.

Tanpa pemilik operasional, perjanjian adalah komitmen lisan. RevOps adalah yang mengubah komitmen lisan menjadi proses yang dikuatkuasakan. Bukan dengan menambah birokrasi, tetapi dengan membina sistem yang menjadikan penjajaran sebagai lalai, bukan pengecualian. Panduan RevOps Gartner menggambarkan operasi pendapatan sebagai model hujung-ke-hujung yang menyatukan penglibatan pelanggan merentasi fungsi dan mengintegrasikan orang, proses, dan teknologi merentasi perniagaan.

Fakta Utama: RevOps dan Penjajaran Pendapatan

  • Syarikat dengan fungsi RevOps yang berdedikasi berkembang pendapatan 2.4x lebih pantas daripada mereka yang bergantung pada operasi jualan, pemasaran, dan CS yang diasingkan, menurut Tinjauan Revenue Operations Forrester.
  • Organisasi dengan RevOps mencapai kadar kemenangan jualan 36% lebih tinggi dan pendapatan pengembangan akaun 28% lebih tinggi, menurut Laporan Keadaan Revenue Operations LeanData.
  • 75% daripada syarikat pertumbuhan tertinggi menggunakan model RevOps, berbanding hanya 37% daripada syarikat pertumbuhan purata, berdasarkan Tinjauan Strategi GTM B2B Gartner 2024.
  • Hasil utama yang disebut oleh syarikat dari pelaksanaan RevOps ialah "penjajaran pemasaran-jualan yang lebih baik", disebut oleh 65% responden mengatasi penyatuan teknologi atau pengurangan kos, menurut Kajian Impak RevOps HubSpot.
  • Syarikat tanpa RevOps melaporkan bahawa pemasaran dan jualan menggunakan sumber data yang berbeza untuk perbincangan Pipeline 68% daripada masa, mencipta geseran yang menambah purata 11 hari kepada kitaran jualan, menurut penyelidikan penjajaran SiriusDecisions.

Apa Sebenarnya RevOps (dan Apa Bukan)

Mulakan di sini, kerana "RevOps" digunakan secara longgar dengan cara yang mencipta kekeliruan tentang apa yang sebenarnya dilakukan fungsi itu dan siapa yang harus memilikinya.

RevOps bukan ops jualan dengan tajuk baharu. Ops jualan wujud untuk menjadikan pasukan jualan lebih berkesan: ketepatan ramalan, reka bentuk wilayah, penetapan kuota, produktiviti wakil. Kerja itu tidak hilang dalam model RevOps. Ia hanya menjadi satu kepingan fungsi yang lebih luas.

RevOps bukan peranan teknologi. Pentadbiran CRM, konfigurasi MAP, dan perolehan alatan adalah aktiviti yang mungkin dilakukan atau diawasi oleh RevOps. Tetapi jika RevOps menghabiskan 80% masanya pada tiket IT dan penyelenggaraan medan Salesforce, ia kurang dimanfaatkan. Nilai operasional ada dalam reka bentuk proses dan pengukuran, bukan pentadbiran sistem. Penyelidikan operasi pendapatan Forrester menawarkan rangka kerja praktikal tentang cara pasukan pada tahap kematangan yang berbeza harus mengskop fungsi itu.

RevOps adalah pemilik sistem pendapatan: data, proses, alatan, dan pengukuran yang merentangi kitaran hayat pemerolehan dan pengekalan pelanggan penuh, dari sentuhan pemasaran pertama kepada perjanjian yang ditutup kepada pelanggan yang dikekalkan.

Tiga fungsi yang direntangi RevOps ialah operasi pemasaran (pendandan yang menjadikan kempen boleh diukur dan data lead bersih), operasi jualan (proses yang menjadikan wakil yang membawa kuota lebih produktif dan ramalan lebih tepat), dan operasi kejayaan pelanggan (sistem yang menjejak kesihatan akaun, masa pembaharuan, dan pencetus pengembangan). Dalam organisasi yang matang, ketiga-tiganya melaporkan ke fungsi RevOps yang dipusatkan dan bukannya ke ketua pasukan masing-masing.

Pemusatan itulah yang menjadikan RevOps mekanisme penjajaran. Apabila ops pemasaran melaporkan kepada CMO dan ops jualan melaporkan kepada VP Jualan, setiap fungsi mengoptimumkan untuk metrik pasukan sendiri. Gartner meramalkan bahawa 75% daripada syarikat pertumbuhan tertinggi akan menggunakan model RevOps — tepat kerana operasi yang dipusatkan menghapuskan masalah pengoptimuman tersilo itu. Apabila kedua-duanya melaporkan kepada RevOps, sasaran pengoptimuman menjadi sistem pendapatan penuh, bukan papan pemuka mana-mana pasukan tunggal.

Mengapa Penjajaran Memerlukan Pemilik Operasional

Perbezaan antara "kami bersetuju untuk sejajar" dan "sistem memerlukan penjajaran" adalah perbezaan antara RevOps tidak wujud dan RevOps wujud.

Tanpa RevOps, penjajaran dikekalkan oleh usaha manusia. Ketua demand gen dan pengurus SDR bersetuju untuk mengadakan panggilan mingguan. Mereka melakukannya selama empat minggu, kemudian seseorang bermusafir, kemudian yang lain sibuk dalam pelancaran kempen, dan panggilan itu berlaku tiga minggu tanpa berlaku. Perjanjian itu nyata. Pelaksanaannya merosot.

Dengan RevOps, SLA Handoff bukan perjanjian lisan. Ia adalah automasi CRM yang memadamkan amaran apabila lead telah dalam status MQL selama lebih 24 jam tanpa aktiviti wakil. Panggilan kualiti lead mingguan masih berlaku, tetapi RevOps menyediakan tarikan data supaya tiada pasukan menghabiskan 45 minit sebelum mesyuarat untuk mendapatkan nombor yang betul. Papan pemuka bersama bukan cadangan. Ia adalah satu-satunya sumber kebenaran yang dimiliki RevOps dan kedua-dua pasukan dilatih untuk menggunakannya dalam perbualan Pipeline.

Ini bukan tentang ketidakpercayaan. Ia tentang mereka bentuk sistem yang berfungsi dalam keadaan biasa pasukan go-to-market yang sibuk, di mana orang berlari pantas, keutamaan berubah, dan ingatan tidak boleh dipercayai. Penjajaran terbaik adalah jenis yang tidak memerlukan mana-mana pasukan untuk mengingati melakukan sesuatu. Ia hanya berlaku kerana proses memerlukannya.

5 Tuas Penjajaran RevOps

Rangka kerja 5 Tuas Penjajaran menggambarkan mekanisme operasional khusus di mana RevOps menukar penjajaran pemasaran-jualan dari komitmen lisan kepada sistem yang dikuatkuasakan. Setiap tuas mensasarkan mod kegagalan berbeza yang menyebabkan penjajaran merosot antara mesyuarat.

Tuas 1: Miliki takrifan. Takrifan MQL dan SQL bukan dokumen — ia adalah parameter operasional yang tertanam dalam medan CRM, peraturan pemarkahan, dan logik penghalaan. RevOps memiliki proses perubahan: apabila data penolakan menandakan bahawa takrifan telah hanyut, RevOps menarik data, memodelkan ambang baharu, menyelaraskan semakan antara pemasaran dan jualan, mengemas kini sistem, dan menyampaikan perubahan kepada wakil. Tanpa pemilikan ini, takrifan merosot secara senyap.

Tuas 2: Automatikkan Handoff. Penguatkuasaan SLA oleh peringatan gagal dalam keadaan operasi biasa: orang bermusafir, peti masuk melimpah, pemberitahuan terkumpul dan diabaikan. RevOps menggantikan peringatan dengan automasi — lead yang melanggar SLA respons auto-eskalasi sebagai tugasan CRM, bukan ping Slack. SLA dikuatkuasakan oleh sistem, bukan oleh ingatan manusia.

Tuas 3: Bina sumber kebenaran bersama. Dua pasukan yang menggunakan dua papan pemuka tidak boleh mengadakan perbualan Pipeline yang produktif. RevOps membina dan menyelenggara satu papan pemuka milik RevOps dengan takrifan yang dipersetujui untuk setiap metrik. Kedua-dua pasukan dilatih untuk menggunakannya. Apabila pemasaran mempersembahkan ROI kempen dan jualan mempersembahkan Pipeline, mereka melihat nombor yang sama.

Tuas 4: Miliki lapisan penghalaan. Peraturan penghalaan lead mesti kekal disegerakkan dengan strategi go-to-market semasa. Apabila segmen baharu ditambah, wakil meninggalkan, atau ICP berubah, RevOps mengemas kini penghalaan sebelum lead pertama yang terjejas tiba. Kegagalan penghalaan — lead yang jatuh ke dalam limbo, pergi ke wakil yang salah, atau tua — adalah kerosakan penjajaran yang paling kelihatan, dan semuanya boleh dikesan kepada logik penghalaan yang tidak segerak.

Tuas 5: Kekalkan kualiti data sebagai operasi berterusan. Atribusi hanya boleh dipercayai apabila data asas bersih. RevOps memiliki peraturan pengesahan medan, penyahduplikatan berkala, pemantauan kesihatan integrasi, dan konfigurasi pengayaan lead. Tanpa lapisan ini, setiap perbincangan atribusi menjadi perbahasan tentang kebolehpercayaan data dan bukannya keputusan tentang perbelanjaan.

Analisis Rework: 5 Tuas Penjajaran tidak bebas — ia bergabung. Pasukan yang hanya melaksanakan Tuas 3 (papan pemuka bersama) tanpa Tuas 2 (automasi Handoff) atau Tuas 5 (kualiti data) mendapati bahawa papan pemuka bersama mereka menjadi sumber pertikaian berbanding resolusi, kerana data asas tidak konsisten. Tuas berfungsi kerana ia menangani kedua-dua punca tingkah laku ketidaksepadanan (orang memerlukan peringatan, takrifan hanyut) dan punca sistemik (data tidak boleh dipercayai, penghalaan tidak segerak). Melaksanakan kelima-lima, walaupun pada skop awal yang minimum, adalah yang menjadikan penjajaran berkekalan berbanding episodik.

Lima Cara RevOps Menjadikan Penjajaran Berkekalan

Ini adalah lima mekanisme khusus di mana pasukan RevOps yang berfungsi mengubah penjajaran dari cita-cita kepada sistem.

1. Memiliki takrifan MQL/SQL dan mengemas kininya apabila metrik hanyut.

Takrifan MQL bukan dokumen. Ia adalah parameter operasional. Apabila model pemarkahan mempromosikan lead yang salah, apabila kadar penolakan melonjak, atau apabila ICP berkembang selepas perubahan produk, ambang MQL perlu berubah. RevOps memiliki proses perubahan itu: menarik data penolakan, memodelkan ambang baharu, menyelaraskan semakan antara pemasaran dan jualan, mengemas kini medan CRM dan peraturan pemarkahan, dan menyampaikan perubahan kepada wakil.

Tanpa RevOps, perubahan takrifan MQL berlaku secara ad hoc, biasanya apabila CRO cukup kecewa untuk memanggil mesyuarat silang-fungsi. Dengan RevOps, ia berlaku pada kekerapan semakan suku tahunan sebelum kekecewaan menjadi pemangkin. Gelung maklum balas penolakan MQL memberikan RevOps data yang diperlukan untuk mencetuskan semakan itu pada masa yang tepat.

2. Menguatkuasakan SLA Handoff melalui automasi CRM, bukan peringatan.

Pendekatan standard untuk penguatkuasaan SLA adalah peringatan: pemberitahuan Slack apabila lead pergi 12 jam tanpa aktiviti, amaran pengurus pada 24 jam. Peringatan berfungsi sehingga semua orang berhenti membacanya. Ia berfungsi sehingga wakil berada dalam mesyuarat. Ia berfungsi sehingga volum pemberitahuan cukup tinggi sehingga semua orang belajar mengabaikannya.

Automasi menguatkuasakan SLA secara berbeza. Apabila lead melebihi ambang SLA tanpa aktiviti, ia auto-eskalasi ke pengurus wakil, bukan sebagai pemberitahuan tetapi sebagai tugasan yang ditugaskan. Atau ia dihalakan ke wakil seterusnya dalam pusingan. Atau ia menjana tugasan CRM yang muncul pada papan pemuka wakil sama ada mereka semak Slack atau tidak. RevOps mereka bentuk dan menyelenggara automasi ini. SLA dikuatkuasakan oleh sistem, bukan oleh ingatan manusia.

3. Membina dan menyelenggara papan pemuka bersama yang dipercayai oleh kedua-dua pasukan.

Kepercayaan dalam data adalah asas penjajaran. Apabila pemasaran menggunakan satu model atribusi dan jualan menggunakan yang lain, setiap ulasan Pipeline menjadi rundingan tentang nombor mana yang betul. Apabila kedua-dua pasukan menggunakan papan pemuka yang diselenggarakan RevOps dengan takrifan yang dipersetujui untuk setiap metrik (apa yang dikira sebagai lead bersumber pemasaran, bila MQL menjadi SQL, apa maksud "Pipeline yang dipengaruhi pemasaran"), perbualan beralih dari "nombor siapa?" kepada "apa maksud nombor?"

RevOps membina papan pemuka ini sekali, mengemas kininya apabila takrifan berubah, dan menyelenggaranya sebagai sumber kebenaran untuk kedua-dua pasukan. Ini tidak bermakna satu orang menguruskan hamparan selama-lamanya. Ia bermakna takrifan didokumentasikan, sumber data bersih, dan kedua-dua pasukan dilatih untuk menggunakan pandangan yang sama. 8 papan pemuka bersama untuk pasukan pendapatan merangkumi apa yang harus dikandungi oleh setiap lapisan pelaporan.

4. Mengurus peraturan penghalaan lead supaya tiada lead terlepas.

Penghalaan lead adalah penjajaran operasional dalam bentuk paling tulennya. Siapa yang mendapat lead? Bila? Berdasarkan logik apa? Apabila peraturan penghalaan diselenggarakan oleh pemasaran dalam satu alatan dan jualan dalam yang lain, ketidakkonsistenan muncul. Lead jatuh ke dalam limbo. Wilayah wakil berubah tetapi peraturan penghalaan tidak. Segmen ICP ditambah kepada sasaran tetapi tiada siapa yang mengemas kini penghalaan untuk mengendalikannya.

RevOps memiliki lapisan penghalaan sebagai sistem tunggal. Apabila ICP berkembang ke vertikal baharu, RevOps mengemas kini peraturan penghalaan lead dalam CRM sebelum kempen pertama pemasaran mencapai vertikal tersebut. Apabila wakil meninggalkan, RevOps mengagihkan semula lead mereka sebelum tua. Logik penghalaan sentiasa segerak dengan strategi go-to-market semasa kerana satu fungsi memiliki kedua-duanya.

5. Menjalankan lapisan kualiti data yang menjadikan atribusi boleh dipercayai.

Atribusi hanya boleh dipercayai apabila data asas bersih. Jika 30% rekod kenayan CRM anda tidak mempunyai sumber lead, model atribusi anda tidak dapat memberitahu pemasaran kempen mana yang mendorong pendapatan. Jika nama syarikat dimasukkan secara tidak konsisten, atribusi berasaskan akaun rosak. Jika segerak CRM-MAP mempunyai pemetaan medan yang rosak, data kempen tidak mengalir kembali ke rekod kenayan.

RevOps memiliki kualiti data sebagai tanggungjawab operasional berterusan: menetapkan peraturan pengesahan medan, menjalankan penyahduplikatan berkala, memantau kesihatan integrasi, dan mentakrifkan proses pengayaan untuk lead baharu. Tanpa lapisan ini, pelaporan gelung tertutup menghasilkan data yang tidak boleh dipercayai dan perbincangan atribusi runtuh menjadi perbahasan tentang metodologi berbanding keputusan tentang perbelanjaan.

Model Organisasi RevOps mengikut Saiz Syarikat

Struktur kurang penting daripada kejelasan pemilikan. Tetapi berikut cara RevOps biasanya berkembang apabila syarikat berskala.

Di bawah 50 pekerja: Seorang generalis ops. Pada peringkat ini, anda tidak mampu pengkhususan. Satu orang, kadangkala Pengurus Ops Jualan atau pengurus Ops Pemasaran dengan mandat yang lebih luas, memiliki ketiga-tiga fungsi dalam amalan. Mereka memakai topi ops pemasaran (penjejakan kempen, konfigurasi MAP, pemarkahan lead), topi ops jualan (kebersihan CRM, peraturan wilayah, data ramalan), dan topi ops CS (penjejakan pembaharuan, persediaan skor kesihatan) tanpa tajuk rasmi merangkumi ketiga-tiganya.

Kunci pada peringkat ini bukan struktur. Ia adalah kejelasan pemilikan. Sesiapa yang memiliki ops mesti mempunyai kuasa eksplisit untuk membuat keputusan proses merentasi ketiga-tiga fungsi. Jika mereka memerlukan kelulusan dari kedua-dua CMO dan VP Jualan sebelum menukar medan dalam CRM, fungsi itu tidak dapat bergerak cukup pantas untuk berguna.

Pengambilan RevOps pertama untuk dibuat: seseorang yang selesa menjadi satu-satunya orang ops selama sekurang-kurangnya 18 bulan, yang boleh menulis SQL atau bekerja dengan alatan BI untuk menarik data mereka sendiri, dan yang pernah melihat rupa integrasi CRM-MAP yang berfungsi. Kemahiran khusus datang kemudian.

50-200 pekerja: Pengurus RevOps berdedikasi. Pada peringkat ini, beban kerja ops merentasi pemasaran, jualan, dan CS terlalu besar untuk seorang generalis. Pengurus RevOps berdedikasi, biasanya melaporkan kepada CRO, VP Jualan, atau CFO, mula membina fungsi yang dipusatkan. Mereka mungkin mempunyai seorang pakar yang melaporkan kepada mereka (biasanya pentadbir CRM atau pakar ops pemasaran yang mengendalikan MAP).

Talian pelaporan penting pada peringkat ini. Jika RevOps melaporkan kepada VP Jualan, pasukan pemasaran akan berhenti mempercayai papan pemuka. Model atribusi terasa condong ke arah Pipeline bersumber jualan. Takrifan MQL terasa dikalibrasi mengikut pilihan jualan. Sama ada kerja itu sebenarnya berat sebelah atau tidak, persepsi berat sebelah sudah cukup untuk memecahkan kepercayaan data bersama yang sepatutnya dibina oleh RevOps. Talian pelaporan paling bersih ialah kepada CRO atau COO, pemimpin silang-fungsi yang tidak memiliki belanjawan mana-mana pasukan.

200+ pekerja: Pasukan RevOps dengan pakar. Di atas 200 pekerja, fungsi biasanya berpecah kepada pakar berdedikasi: ketua ops pemasaran, ketua ops jualan, ketua ops CS, dan fungsi data/analitik, semua melaporkan ke VP atau Ketua RevOps. VP RevOps memegang perspektif silang-fungsi dan membuat keputusan apabila tiga fungsi mempunyai keutamaan yang bersaing.

Pada saiz ini, RevOps juga biasanya memiliki semakan tumpukan teknologi, pengurusan vendor untuk CRM dan MAP, dan model ramalan pendapatan yang digunakan oleh CRO untuk pelaporan lembaga. Asas ramalan memberikan asas dalam metodologi yang perlu dimiliki RevOps pada peringkat ini.

Apa Yang Tidak Dimiliki RevOps

Penghadang adalah sama pentingnya dengan mandat.

RevOps tidak menetapkan strategi. Ia mengoperasikan strategi yang dipersetujui oleh pemasaran dan jualan. Jika CMO dan VP Jualan memutuskan untuk mensasarkan vertikal baharu, RevOps mengkonfigurasi penghalaan, pemarkahan, dan papan pemuka untuk menyokong strategi itu. Tetapi RevOps tidak memutuskan vertikal mana untuk disasarkan atau segmen mana untuk dijeda. Itu adalah panggilan strategi yang tergolong kepada pemimpin pendapatan.

RevOps tidak memiliki ICP. Ia menguatkuasakan takrifan ICP dalam sistem. Jika CRO dan CMO bersetuju bahawa syarikat dengan kurang daripada 20 pekerja berada di luar ICP, RevOps mengemas kini model pemarkahan untuk mencerminkan ambang itu. Tetapi keputusan tentang di mana hendak meletakkan sempadan ICP tergolong kepada pemimpin go-to-market, bukan kepada ops.

RevOps tidak menjalankan panggilan kualiti lead mingguan. Ia membekalkan data untuknya. Panggilan kualiti lead mingguan adalah perbualan pemasaran-jualan, dimiliki oleh ketua demand gen. RevOps menyediakan pecahan penolakan, kadar penerimaan, dan metrik masa-ke-sentuhan-pertama. Tetapi tafsiran dan satu perubahan yang dikomit pada akhir panggilan tergolong kepada peserta pemasaran dan jualan.

Penghadang ini menghalang RevOps daripada terlalu jauh dan menjana kebencian dari pasukan yang disokongnya. Saat RevOps dilihat membuat panggilan strategi, ia kehilangan kenetralan yang menjadikannya berkesan sebagai fungsi penjajaran.

Corak Anti RevOps Biasa Yang Memecahkan Penjajaran

RevOps melaporkan hanya kepada jualan. Apabila RevOps berada di bawah VP Jualan, pasukan pemasaran berhenti mempercayai papan pemuka. Model atribusi terasa condong ke arah Pipeline bersumber jualan. Takrifan MQL terasa dikalibrasi mengikut pilihan jualan. Sama ada kerja itu sebenarnya berat sebelah atau tidak, persepsi berat sebelah sudah cukup untuk memecahkan kepercayaan data bersama yang sepatutnya dibina RevOps. Penyelesaian: alihkan RevOps ke talian pelaporan silang-fungsi.

75% daripada syarikat pertumbuhan tertinggi menggunakan model RevOps, berbanding hanya 37% daripada syarikat pertumbuhan purata, berdasarkan Tinjauan Strategi GTM B2B Gartner 2024 — jurang penggunaan semakin melebar apabila kelebihan prestasi operasi pendapatan yang dipusatkan dapat diukur dalam data kohort berbilang tahun.

Pasukan RevOps berpecah mengikut fungsi. Sesetengah organisasi mempunyai pasukan ops jualan di bawah CRO dan pasukan ops pemasaran di bawah CMO dan menamakannya "RevOps." Tetapi itu bukan RevOps. Ia adalah ops tersilo dengan label kolektif. Analisis HBR mengenai ketidaksepadanan pemasaran-jualan menganggarkan bahawa jurang antara kedua-dua fungsi merugikan perniagaan lebih daripada $1 trilion setiap tahun — nombor yang didorong oleh tepat jenis pengoptimuman tersilo yang dicipta corak anti ini. Kerja penjajaran berlaku pada jahitan antara pasukan, dan apabila setiap pasukan mempunyai fungsi ops sendiri yang mengoptimumkan untuk metrik sendiri, jahitan itu adalah tepat di mana sesuatu pecah. Penyelesaian: pusatkan ke dalam fungsi tunggal dengan keterlihatan silang-pasukan dan pemilikan yang jelas bagi sistem bersama.

RevOps menjadi barisan tiket. Apabila RevOps terutamanya reaktif, menambah medan yang diminta wakil, menarik laporan yang diminta pengurus, membetulkan integrasi apabila rosak, ia tidak pernah membina asas operasional proaktif yang menjadikan penjajaran berkekalan. Fungsi itu menghabiskan semua kapasitasnya pada penyelenggaraan dan tiada pada reka bentuk proses. Penyelesaian: dedikasikan sekurang-kurangnya 40% kapasiti RevOps kepada projek proaktif (automasi SLA, pembangunan papan pemuka, pemantauan kesihatan integrasi) bukan hanya tiket reaktif.

Cara Mengetahui Jika RevOps Anda Berfungsi untuk Penjajaran

Tiga ujian yang tidak memerlukan model kematangan RevOps.

Kedua-dua pemasaran dan jualan menggunakan papan pemuka yang sama untuk perbualan Pipeline. Apabila VP Jualan mempersembahkan Pipeline kepada CRO, mereka melihat data sumber-ke-tutup yang sama yang digunakan pemasaran untuk ROI kempen. Tiada siapa yang berkata "well, nombor kami menunjukkan..." kerana hanya ada satu set nombor.

Sebab penolakan MQL dirakam dalam CRM, bukan dalam e-mel atau Slack. Apabila wakil menolak MQL, mereka memilih sebab dari senarai juntai. Sebab itu ada dalam CRM. Pemasaran boleh menariknya dalam laporan tanpa meminta sesiapa. Jika data penolakan masih berada dalam mesej Slack dan e-mel SDR-ke-demand-gen, penjajaran itu tidak formal dan rapuh. Itulah tepat masalah yang direka bentuk oleh proses maklum balas menang-kalah untuk diselesaikan pada peringkat perjanjian.

Penghalaan lead tidak menyebabkan soalan "ke mana lead ini pergi?" dalam 30 hari. Apabila peraturan penghalaan diselenggarakan dengan baik, lead tidak jatuh ke dalam limbo. Wakil tahu apa yang dijangkakan. Pemasaran tahu ke mana lead mereka pergi. Jika soalan penghalaan terakhir adalah lebih dari sebulan yang lalu, sistem berfungsi.

Membina ke Arah RevOps Apabila Anda Belum Memilikinya

Kebanyakan pasukan pasaran pertengahan menambah RevOps lebih lewat daripada yang sepatutnya. Jika anda beroperasi tanpanya sekarang, berikut adalah laluan ke hadapan.

Fasa 1: Tugaskan pemilik ops bersama. Walaupun ia adalah komitmen separuh masa dari seseorang yang kini juga merangkumi ops jualan, menjadikan pemilikan eksplisit adalah langkah pertama. Pemilik ops bersama menghadiri panggilan kualiti lead mingguan, menarik laporan penolakan, dan menyelenggara integrasi CRM-MAP. Ini bukan fungsi RevOps penuh. Ini adalah infrastruktur penjajaran minimum yang boleh dilaksanakan.

Fasa 2: Dokumentasikan proses pendapatan semasa. Petakan kitaran hayat lead penuh dari sentuhan pertama kepada perjanjian yang ditutup: sistem mana yang memiliki setiap peringkat, pasukan mana yang bertanggungjawab untuk setiap Handoff, di mana data melintasi dari MAP ke CRM, dan di mana atribusi dirakam. Strategi pengagihan lead adalah tempat yang baik untuk mengaudit dahulu — di situlah kekaburan pemilikan paling kerap menyebabkan lead menjadi sejuk. Dokumentasi ini mendedahkan jurang: Handoff di mana data hilang, peringkat di mana tiada siapa yang mentakrifkan pemilikan, integrasi yang wujud di atas kertas tetapi rosak dalam amalan.

Fasa 3: Kenal pasti tiga titik geseran terbesar dan milikinya. Jangan cuba membetulkan segalanya. Pilih tiga tempat di mana lead terlepas, atribusi tidak boleh dipercayai, atau SLA Handoff secara konsisten terlepas. Betulkan ketiga-tiga itu dengan reka bentuk proses dan automasi. Dapatkan kemenangan yang didokumentasikan. Gunakan mereka untuk membuat kes untuk pengambilan RevOps berdedikasi.

Laluan ke RevOps penuh melalui tiga fasa ini. Anda tidak perlu mengambil VP RevOps pada hari pertama. Anda perlu menetapkan pemilikan, memahami keadaan semasa, dan membetulkan jurang dengan impak tertinggi. Kemudian bina dari sana.

Soalan Lazim

Apa itu Revenue Operations (RevOps)?

Revenue Operations adalah fungsi yang dipusatkan yang memiliki data, proses, alatan, dan pengukuran merentangi kitaran hayat pelanggan penuh — dari sentuhan pemasaran pertama melalui perjanjian yang ditutup kepada pelanggan yang dikekalkan dan dikembangkan. RevOps menyatukan apa yang sebelumnya adalah pasukan operasi tersilo (ops pemasaran, ops jualan, ops kejayaan pelanggan) di bawah mandat silang-fungsi tunggal. Tujuan pentakrifannya adalah untuk menjadikan penjajaran sebagai lalai berbanding pengecualian, dengan membina sistem yang menguatkuasakan kerjasama berbanding bergantung pada ingatan manusia dan niat baik.

Apa yang sebenarnya dilakukan RevOps hari ke hari?

RevOps memiliki lima domain operasional: takrifan MQL/SQL dan kemas kininya, automasi SLA Handoff, papan pemuka Pipeline bersama, logik penghalaan lead, dan kualiti data merentasi integrasi CRM-MAP. Hari ke hari, itu diterjemahkan kepada: menarik data penolakan untuk panggilan kualiti lead mingguan, menyelenggara pemetaan medan CRM-MAP supaya atribusi boleh dipercayai, mengemas kini peraturan penghalaan apabila strategi go-to-market berubah, menjalankan semakan ambang MQL suku tahunan, dan membina papan pemuka yang digunakan oleh kedua-dua pemasaran dan jualan untuk perbualan Pipeline.

Bila sepatutnya sebuah syarikat mengambil orang RevOps pertama mereka?

Kebanyakan pasukan mengambil RevOps terlalu lewat. Pencetus biasa adalah kesakitan ketidaksepadanan — pemasaran dan jualan dalam konflik terbuka tentang kualiti lead, nombor atribusi tidak sepadan, atau ramalan Pipeline secara konsisten salah. Pencetus yang lebih baik ialah skala: apabila anda mempunyai lebih daripada 150 MQL sebulan, pasukan jualan berdedikasi empat atau lebih wakil, dan pasukan pemasaran yang menjalankan pelbagai kempen serentak, overhead penyelarasan sudah melebihi apa yang penjajaran tidak formal boleh kendalikan. Pada ketika itu, menunggu krisis untuk mengambil RevOps lebih mahal daripada pengambilan.

Di mana RevOps harus melaporkan dalam struktur organisasi?

RevOps harus melaporkan kepada pemimpin pendapatan silang-fungsi — CRO, COO, atau CEO — bukan kepada CMO atau VP Jualan. Apabila RevOps melaporkan kepada VP Jualan, pasukan pemasaran berhenti mempercayai papan pemuka dan model atribusi (sama ada kerja itu sebenarnya berat sebelah atau tidak, persepsi berat sebelah memecahkan kepercayaan data bersama). Apabila ia melaporkan kepada CMO, jualan mempunyai kebimbangan yang sama secara terbalik. Talian pelaporan CRO atau COO menyediakan kenetralan yang menjadikan RevOps berfungsi sebagai mekanisme penjajaran berbanding lanjutan agenda satu pasukan.

Apakah perbezaan antara RevOps dan Ops Jualan?

Ops Jualan wujud untuk menjadikan pasukan jualan lebih berkesan: ketepatan ramalan, reka bentuk wilayah, penetapan kuota, analisis produktiviti wakil. RevOps mengandungi ops jualan dalam mandat yang lebih luas yang juga merangkumi operasi pemasaran dan operasi kejayaan pelanggan. Perbezaan struktural ialah pelaporan dan skop: ops jualan melaporkan kepada pemimpin jualan dan mengoptimumkan untuk metrik pasukan jualan; RevOps melaporkan kepada pemimpin silang-fungsi dan mengoptimumkan untuk sistem pendapatan penuh. Dalam model RevOps yang matang, ops jualan menjadi fungsi khusus dalam RevOps, bukan pasukan yang berasingan.

Apakah tiga pengambilan pertama untuk membina pasukan RevOps?

Untuk syarikat yang berskala dari satu generalis ops kepada pasukan kecil, urutannya biasanya ialah: (1) Pengurus atau Pengarah Revenue Operations yang boleh mereka bentuk proses dan memiliki mandat silang-fungsi — orang ini menetapkan model operasi untuk fungsi itu; (2) pentadbir CRM atau Pakar Operasi Pemasaran yang mengendalikan kerja konfigurasi teknikal (penyelenggaraan medan, kesihatan integrasi, kualiti data) yang sebaliknya akan menghabiskan kapasiti pengurus; (3) Penganalisis Data atau Pakar BI yang memiliki lapisan pelaporan dan membina papan pemuka bersama yang digunakan oleh kedua-dua pemasaran dan jualan. Tambah liputan operasi kejayaan pelanggan keempat, sebaik sahaja infrastruktur penjajaran pemasaran-jualan stabil.

Bagaimana anda tahu jika RevOps anda berfungsi?

Tiga ujian: Pertama, kedua-dua pemasaran dan jualan menggunakan papan pemuka yang sama untuk perbualan Pipeline — tiada siapa yang berkata "well, nombor kami menunjukkan..." kerana hanya ada satu set nombor. Kedua, sebab penolakan MQL dirakam dalam CRM sebagai data berkategori, bukan dalam mesej Slack atau e-mel. Ketiga, penghalaan lead tidak menjana soalan "ke mana lead ini pergi?" dalam lebih dari 30 hari. Tiga ujian ini tidak memerlukan model kematangan RevOps atau audit formal — ia boleh diperhatikan dalam satu ulasan Pipeline.

Berapa kos RevOps berbanding kesan pendapatannya?

Penyelidikan Gartner menunjukkan bahawa syarikat dengan fungsi RevOps yang berdedikasi berkembang pendapatan 2.4x lebih pantas daripada mereka yang tanpanya, dan pemacu ROI utama yang disebut oleh syarikat bukan penyatuan teknologi atau pengurangan kos — ia adalah peningkatan kadar kemenangan (36% lebih tinggi) dan pendapatan pengembangan akaun (28% lebih tinggi). Untuk syarikat pasaran pertengahan dengan ARR $10J-$50J, pasukan RevOps tiga orang pada kos jumlah $400K-$600K biasanya menghasilkan kesan pendapatan yang melebihi kosnya dalam 12-18 bulan, terutamanya melalui pengurangan kebocoran Pipeline (lead yang menjadi sejuk, kegagalan penghalaan, pelanggaran SLA) dan peningkatan ROI kempen dari atribusi yang boleh dipercayai.

Ketahui Lebih Lanjut