Apakah Revenue Operations? Sistem Operasi untuk Pertumbuhan Boleh Diramal

Tanda pertama bahawa sesebuah syarikat memerlukan Revenue Operations biasanya bukan dashboard yang hilang.

Ia lebih kedengaran seperti ini: pemasaran mengatakan jumlah lead meningkat, jualan mengatakan kualiti lead menurun, kejayaan pelanggan mengatakan pelanggan baharu tiba dengan janji yang tidak dapat disokong oleh produk, dan kewangan mengatakan ramalan sudah tidak lagi sepadan dengan realiti.

Setiap pasukan bekerja keras. Setiap pasukan mempunyai versi kebenaran yang munasabah. Masalahnya ialah sistem hasil tidak mempunyai satu pemilik operasi tunggal.

Revenue Operations, biasanya diringkaskan sebagai RevOps, adalah fungsi yang mereka bentuk, mentadbir, mengukur, dan menambah baik keseluruhan sistem operasi hasil daripada sentuhan pertama hingga pembaharuan. Ia menghubungkan pemasaran, jualan, kejayaan pelanggan, kewangan, data, dan sistem supaya syarikat boleh menjalankan satu motif hasil yang boleh diukur berbanding beberapa motif yang terputus.

Gartner menerangkan Revenue Operations sebagai model hujung ke hujung yang menyatukan penglibatan pelanggan merentas fungsi dan mengintegrasikan orang, proses, dan teknologi merentas perniagaan. Itulah titik permulaan yang betul. RevOps bukan pasukan pelaporan. Ia bukan pasukan pentadbir CRM. Ia bukan jawatan baharu untuk Sales Ops. Ia adalah lapisan operasi yang menjadikan hasil lebih mudah dijalankan, diperiksa, diramal, dan ditambah baik.

Definisi Revenue Operations

Revenue Operations adalah disiplin merentas fungsi yang bertanggungjawab atas proses, data, sistem, metrik, dan irama operasi yang menyokong pertumbuhan hasil merentas keseluruhan kitaran hayat pelanggan.

Secara praktikal, RevOps memiliki tisu penghubung:

• Bagaimana lead memasuki sistem
• Bagaimana lead dikelayakkan, dihalakan, dan diterima
• Bagaimana peluang dicipta dan diperiksa
• Bagaimana ramalan dibina dan dipercayai
• Bagaimana deal closed-won bergerak ke onboarding
• Bagaimana isyarat pembaharuan dan pengembangan mengalir semula ke dalam perancangan
• Bagaimana kepimpinan melihat satu versi prestasi hasil

Skop itulah yang menjadikan RevOps berbeza daripada pasukan operasi khusus fungsi. Sales Ops menambah baik pelaksanaan jualan. Marketing Ops menambah baik pelaksanaan kempen. CS Ops menambah baik pelaksanaan pengekalan. RevOps menambah baik sistem hasil yang dikongsi oleh pasukan tersebut. Garisan itu lebih kabur dengan GTM Operations vs Revenue Operations, di mana kedua-dua peranan sering bertindih.

Bagi sebuah syarikat dengan seorang pengasas, seorang jurujual, dan corong yang mudah, perbezaan itu mungkin belum penting. Pengasas boleh menyimpan sistem itu dalam kepalanya. Sebaik sahaja pemasaran, jualan, kejayaan pelanggan, dan kewangan semuanya bergantung kepada data pelanggan, serah tugas, input ramalan, dan dashboard yang sama, sistem itu memerlukan pemilik operasi.

Kenapa RevOps wujud

RevOps wujud kerana kerja hasil merentasi sempadan pasukan, sedangkan kebanyakan syarikat disusun dalam silo khusus pasukan.

Pemasaran memiliki penjanaan permintaan, tetapi bukan kerja penukaran jualan yang membuktikan sama ada permintaan itu berguna. Jualan memiliki pipeline, tetapi bukan data kempen atau definisi kitaran hayat yang mencipta pipeline tersebut. Kejayaan pelanggan memiliki pengekalan, tetapi mewarisi jangkaan pelanggan yang ditetapkan semasa jualan. Kewangan memiliki pelan, tetapi bergantung kepada input ramalan daripada CRM yang mungkin tidak lengkap, lapuk, atau tidak konsisten.

Hasilnya ialah geseran yang boleh diramal.

Sesuatu lead dipanggil berkelayakan dalam platform automasi pemasaran, tetapi jualan tidak bersetuju. Sesuatu deal berada dalam commit, tetapi tarikh tutup telah berubah tiga kali. Seorang pelanggan churn kerana pelaksanaan tidak pernah menerima kes penggunaan asal. Laporan lembaga pengarah menunjukkan satu angka pipeline manakala ramalan jualan menunjukkan angka lain.

Tiada satu pun kegagalan itu dimiliki secara bersih oleh satu pasukan. Ia wujud antara pasukan. Itulah sebab ia berterusan.

Harvard Business Review telah menulis tentang kos ketidaksepadanan pemasaran dan jualan, menganggarkan jurang itu merugikan perniagaan lebih daripada $1 trilion setiap tahun. RevOps adalah satu jawapan kepada jurang tersebut: berikan sistem hasil dikongsi seorang pemilik dengan kuasa untuk menyeragamkan definisi, menguatkuasakan serah tugas, dan mengekalkan lapisan data.

Fakta utama tentang RevOps

Fakta Utama: Revenue Operations

• Gartner mendefinisikan RevOps sebagai model hujung ke hujung yang menyatukan penglibatan pelanggan merentas fungsi dan mengintegrasikan orang, proses, dan teknologi.
• Forrester membingkaikan revenue operations di sekitar penjajaran merentas tanggungjawab operasi pemasaran, jualan, rakan kongsi, dan kejayaan pelanggan.
• HBR menganggarkan ketidaksepadanan jualan dan pemasaran merugikan perniagaan lebih daripada $1 trilion setiap tahun.
• Kajian Salesforce melaporkan bahawa wakil jualan hanya menghabiskan 28% daripada masa mereka untuk menjual, yang menjadi salah satu sebab pasukan RevOps memberi tumpuan besar kepada geseran proses, kebersihan CRM, dan kualiti aliran kerja.

Angka-angka itu penting, tetapi implikasi operasinya lebih penting. Syarikat bergerak ke arah RevOps kerana kerumitan hasil melebihi penyelarasan tidak formal.

Lapisan operasi RevOps

Cara yang berguna untuk memahami RevOps ialah memecahkannya kepada enam lapisan operasi.

Apabila RevOps lemah, lapisan tersebut berselerak. Pemasaran memiliki satu definisi. Jualan memiliki definisi lain. Kewangan membina hamparan untuk menyelaraskan kedua-duanya. Kejayaan pelanggan menyimpan risiko pembaharuan dalam alat berasingan.

Apabila RevOps kukuh, lapisan tersebut menjadi sistem operasi dikongsi. Proses pengurusan lead berhubung secara bersih dengan automasi penghalaan lead. Pipeline jualan dibina daripada peringkat yang jelas. Asas ramalan bergantung kepada data yang dipercayai orang. Penjajaran pemasaran dan jualan menjadi satu sistem, bukan rundingan berulang.

Apa yang dimiliki RevOps

RevOps sepatutnya memiliki aset operasi yang bergantung kepadanya oleh pelbagai pasukan hasil.

Definisi. Peringkat kitaran hayat, MQL, SQL, peluang, closed-won, churn, pengembangan, pipeline bersumber, pipeline dipengaruhi, dan kategori ramalan memerlukan satu definisi dikongsi. Tanpa itu, setiap laporan menjadi perdebatan.

Aliran kerja. RevOps mereka bentuk aliran kerja yang menggerakkan rekod, tugas, dan akauntabiliti antara pasukan. Ini termasuk penghalaan lead, SLA penugasan, pergerakan peringkat peluang, serah tugas closed-won, amaran pembaharuan, dan laluan eskalasi.

Dashboard. RevOps sepatutnya memiliki lapisan pelaporan dikongsi. Itu tidak bermakna setiap pasukan kehilangan dashboard fungsian mereka. Ia bermakna kepimpinan menjalankan keputusan hasil daripada satu paparan dikongsi yang dipercayai.

Kualiti data. Kesempurnaan medan, pendua, rekod lapuk, pengayaan, dan kesihatan integrasi bukan tugas pembersihan pentadbiran. Ia adalah infrastruktur hasil.

Tadbir urus sistem. RevOps menentukan bagaimana sistem hasil berhubung dan pasukan mana yang boleh menukar medan, automasi, peraturan pemarkahan, dan logik pelaporan.

Irama operasi. Semakan pipeline mingguan, semakan corong bulanan, perancangan suku tahunan, pemeriksaan ramalan, dan semakan pengekalan sepatutnya masing-masing mempunyai tujuan, pakej data, pemilik, dan output keputusan yang jelas.

Apa yang tidak dimiliki RevOps

RevOps gagal apabila ia cuba menjadi pemilik strategi untuk setiap keputusan komersial.

RevOps tidak menggantikan kepimpinan pemasaran. CMO atau pemimpin pemasaran masih memiliki positioning, saluran, kempen, dan strategi permintaan.

RevOps tidak menggantikan kepimpinan jualan. VP Sales masih memiliki pelaksanaan kuota, bimbingan, pengambilan pekerja, strategi wilayah, dan pengurusan deal.

RevOps tidak menggantikan kepimpinan kejayaan pelanggan. CS masih memiliki kualiti onboarding, penerimaan, perbualan pembaharuan, dan strategi pengembangan.

RevOps tidak menggantikan kewangan. Kewangan masih memiliki pelan syarikat, pengiktirafan hasil, bajet, dan pelaporan kewangan.

RevOps menjadikan fungsi-fungsi tersebut lebih mudah dijalankan dengan menjadikan sistem dikongsi boleh dipercayai. Ia mengoperasikan strategi. Ia tidak mencipta strategi secara berasingan.

Bila sesebuah syarikat memerlukan RevOps

Keperluan untuk RevOps muncul apabila kos penyelarasan mula mengurangkan kualiti pertumbuhan.

Anda mungkin memerlukan pemilik RevOps apabila beberapa perkara berikut benar:

• Pemasaran dan jualan tidak bersetuju tentang kualiti lead setiap bulan.
• Pemimpin jualan tidak mempercayai data pipeline CRM.
• Kewangan mengekalkan ramalan berasingan kerana ramalan CRM tidak boleh dipercayai.
• Kejayaan pelanggan mengatakan terlalu ramai pelanggan tiba dengan nota serah tugas yang tidak lengkap.
• Atribusi kempen lebih banyak diperdebatkan berbanding ditindak.
• Peraturan penghalaan lead sudah lapuk atau tidak jelas.
• Pengurus menghabiskan panggilan ramalan membersihkan data dan bukan membuat keputusan.
• Keputusan alat dalam satu fungsi merosakkan pelaporan dalam fungsi lain.
• Syarikat sedang menambah bilangan kakitangan tetapi kualiti proses hasil semakin buruk.

Masalah ini tidak selalu memerlukan pasukan RevOps penuh. Kadangkala langkah pertama ialah menugaskan seorang pemilik yang jelas kepada proses hasil dikongsi. Tetapi mengabaikan masalah tersebut biasanya menjadikan setiap pengambilan pekerja masa depan kurang produktif.

Lima peringkat kematangan RevOps

Kebanyakan syarikat tidak beralih daripada tiada RevOps kepada sistem operasi yang matang dalam satu suku tahun. Fungsi ini biasanya berkembang melalui lima peringkat.

Kesilapannya ialah melangkau peringkat. Sebuah syarikat dengan definisi peringkat yang lemah tidak sepatutnya bermula dengan ramalan prediktif. Sebuah syarikat tanpa SLA serah tugas tidak sepatutnya mengautomasikan penghalaan sebelum peraturan penerimaan jelas.

Gunakan model kematangan RevOps untuk mendiagnosis di mana kedudukan syarikat sebelum memutuskan apa yang perlu dibina seterusnya.

Model operasi RevOps mengikut peringkat syarikat

RevOps sepatutnya kelihatan berbeza apabila syarikat berkembang. Sebuah syarikat 30 orang tidak memerlukan model operasi yang sama seperti syarikat 500 orang dengan pelbagai produk, wilayah, dan motif pembaharuan.

Pandangan peringkat ini mengekalkan RevOps praktikal. Matlamatnya bukan menjadikan fungsi ini kelihatan matang pada carta organisasi. Matlamatnya ialah menyepadankan disiplin operasi dengan jumlah penyelarasan yang kini diperlukan oleh sistem hasil.

Bagaimana memulakan RevOps tanpa membina berlebihan

Pusingan RevOps pertama sepatutnya menjadikan sistem lebih mudah diperiksa. Ia tidak sepatutnya mencipta proses kelulusan yang berat untuk setiap perubahan kecil.

Mulakan dengan empat langkah.

Petakan kitaran hayat daripada rekod sebenar. Tarik lead terkini, peluang, deal closed-won, pelanggan yang churn, dan peluang pengembangan. Untuk setiap rekod, tanya: siapa memilikinya sekarang, peringkat apa ia berada, bukti apa menyokong peringkat tersebut, dan tindakan apa yang sepatutnya berlaku seterusnya? Rekod sebenar mendedahkan kekeliruan lebih pantas berbanding gambar rajah bengkel.

Tulis definisi dikongsi. Tentukan lead, MQL, SQL, peluang, commit, closed-won, telah di-onboard, risiko pembaharuan, churn, dan pengembangan. Kekalkan setiap definisi ringkas. Jika seorang pengurus tidak boleh menggunakannya semasa pemeriksaan, ia tidak cukup jelas.

Pilih serah tugas berisiko tertinggi. Kebanyakan syarikat sepatutnya bermula dengan penugasan lead, MQL ke SQL, penciptaan peluang, atau closed-won ke onboarding. Baiki satu serah tugas secara mendalam sebelum menulis semula setiap aliran kerja.

Cipta satu paparan operasi dipercayai. Bina dashboard kecil yang benar-benar digunakan oleh pemimpin: penukaran peringkat, SLA yang tidak dicapai, liputan pipeline, kualiti ramalan, kesempurnaan serah tugas, dan kesempurnaan medan wajib. Paparan 10 metrik yang dipercayai mengatasi dashboard 40 carta yang tidak ditindak oleh sesiapa.

Di sinilah panduan 90 Hari Pertama dalam RevOps menjadi berguna. RevOps memperoleh kepercayaan dengan menukar kesakitan yang kelihatan kepada perubahan operasi, bukan dengan menerbitkan roadmap raksasa.

Apa yang diubah RevOps dalam kerja harian

RevOps yang baik kelihatan dalam tingkah laku operasi kecil.

Nilainya bukan penjajaran abstrak. Nilainya ialah kurang perdebatan yang boleh dielakkan, diagnosis lebih pantas, serah tugas lebih bersih, dan keyakinan perancangan lebih baik.

Hasil suku tahun pertama RevOps yang baik

Suku tahun pertama yang realistik sepatutnya menghasilkan beberapa aset dipercayai tinggi, bukan pembinaan semula total.

Pada akhir suku tahun pertama, seorang pemilik RevOps baharu sepatutnya dapat menunjukkan:

• Satu peta kitaran hayat daripada lead hingga pembaharuan.
• Senarai pendek definisi yang dipersetujui.
• Jadual serah tugas dengan pemilik, SLA, medan diperlukan, dan laluan pengecualian.
• Peta source of truth untuk metrik hasil utama.
• Roadmap RevOps yang diutamakan dikaitkan dengan risiko hasil.
• Semakan operasi yang lebih bersih di mana pemimpin menghabiskan kurang masa menyesuaikan data.

Jika suku tahun pertama hanya menghasilkan laporan baharu, mandat itu terlalu sempit. Laporan berguna, tetapi ujian sebenar ialah sama ada syarikat telah mengubah bagaimana kerja hasil bergerak antara pasukan.

Bagaimana RevOps menghubungkan perpustakaan hasil Rework

RevOps berguna kerana ia menghubungkan kerja yang biasanya didokumenkan dalam playbook berasingan.

Pengurusan lead menentukan bagaimana permintaan memasuki sistem. Pengurusan pipeline menentukan bagaimana hasil berpotensi diperiksa. Penutupan deal menentukan bagaimana komitmen menjadi pelanggan. Pengurusan selepas jualan menentukan bagaimana pelanggan membaharui, berkembang, atau churn. Penjajaran pemasaran-jualan dan penjajaran jualan-CS menentukan serah tugas antara fasa-fasa tersebut.

RevOps menjadikan perpustakaan tersebut satu sistem.

Sumber lead sepatutnya mengalir ke dalam pelaporan penukaran corong. Peraturan kelayakan sepatutnya menjejaskan penghalaan dan kapasiti jualan. Janji jualan sepatutnya muncul dalam onboarding pelanggan. Sebab churn sepatutnya memaklumkan ICP dan sasaran kempen. Ramalan yang tidak tercapai sepatutnya mencetuskan semakan proses, bukan sekadar penjelasan pengurus.

Itulah sebab rangka kerja SaaS RevOps paling kukuh apabila ia merangkumi pemerolehan, penukaran, pengekalan, dan pengembangan bersama-sama. RevOps bukan pasukan yang memiliki satu peringkat. Ia adalah pasukan yang memastikan setiap peringkat boleh menyampaikan data dan akauntabiliti yang boleh digunakan kepada peringkat seterusnya.

Diagnostik RevOps praktikal

Tanya soalan berikut dalam semakan operasi seterusnya anda:

1. Bolehkah pemasaran, jualan, CS, dan kewangan menjelaskan peringkat kitaran hayat yang sama dengan perkataan yang sama?
2. Adakah setiap serah tugas mempunyai pemilik, SLA, dan laluan pengecualian?
3. Adakah CRM cukup dipercayai untuk menjalankan ramalan tanpa hamparan bayangan?
4. Bolehkah pemimpin melihat penukaran mengikut sumber, segmen, dan peringkat tanpa pembersihan manual?
5. Adakah deal closed-won tiba di onboarding dengan maklumat yang diperlukan oleh CS?
6. Adakah panggilan ramalan tentang risiko dan tindakan, atau tentang membaiki data lapuk?
7. Adakah seseorang memiliki perubahan sistem hasil merentas alat?
8. Adakah dashboard dikaitkan dengan keputusan, atau ia hanya artifak pelaporan?
9. Adakah isyarat churn dan pengembangan memberi maklum balas kepada ICP dan peraturan kelayakan?
10. Adakah RevOps menghabiskan kebanyakan masanya menambah baik sistem, atau bertindak balas terhadap tiket?

Jika jawapannya kebanyakannya tidak jelas, syarikat itu bukan hanya memerlukan laporan yang lebih baik. Ia memerlukan revenue operations yang lebih kukuh.

Di mana platform seperti Rework sesuai

RevOps memerlukan sistem di mana rekod, aliran kerja, pemilikan, dan data aktiviti boleh ditadbir secara konsisten. Platform CRM atau aliran kerja seperti Rework boleh menyokong asas tersebut dengan menjadikan penghalaan lead, status kitaran hayat, pemilikan tugas, dan rekod serah tugas kelihatan di satu tempat. Alat itu sendiri tidak mencipta RevOps. Peraturan operasi datang dahulu. Platform itu menguatkuasakannya sebaik sahaja ia jelas.

Soalan Lazim

Apakah Revenue Operations dalam istilah mudah?

Revenue Operations adalah fungsi yang menjadikan keseluruhan proses hasil berfungsi merentas pemasaran, jualan, kejayaan pelanggan, kewangan, dan sistem. Ia memiliki definisi dikongsi, aliran kerja, kualiti data, dashboard, dan irama operasi.

Adakah RevOps sama seperti Sales Ops?

Tidak. Sales Ops menambah baik pelaksanaan jualan. RevOps menambah baik keseluruhan sistem hasil. Sales Ops mungkin berada dalam RevOps sebagai lorong pakar, tetapi RevOps mempunyai mandat merentas fungsi yang lebih luas.

Kepada siapa RevOps sepatutnya melapor?

RevOps biasanya berfungsi paling baik di bawah pemimpin merentas fungsi seperti CRO, COO, atau CEO. Jika ia hanya melapor kepada jualan atau hanya kepada pemasaran, pasukan lain mungkin tidak mempercayai keputusan dan dashboardnya.

Bila sesebuah syarikat sepatutnya mengambil RevOps?

Ambil atau tugaskan seorang pemilik RevOps apabila serah tugas hasil, kepercayaan CRM, kualiti ramalan, atribusi, atau serah tugas selepas jualan mula rosak merentas pasukan. Itu selalunya berlaku sebelum pemimpin berasa bersedia untuk jabatan RevOps penuh.

Apakah projek RevOps pertama?

Mulakan dengan definisi kitaran hayat dan serah tugas. Jika syarikat tidak dapat menentukan lead, MQL, SQL, peluang, closed-won, onboarding, pembaharuan, dan churn secara konsisten, setiap dashboard dan automasi akan mewarisi kekeliruan tersebut.

Ketahui lebih lanjut

• Revenue Operations Framework
• RevOps vs Sales Ops
• RevOps Team Structure
• RevOps Metrics
• RevOps as Alignment Glue