Bila Perlu Mengambil RevOps: Isyarat Sistem Hasil Anda Memerlukan Pemilik

Kebanyakan syarikat mengambil RevOps selepas kesakitan itu sudah mahal.

Pemasaran dan jualan bertengkar tentang kualiti lead. Panggilan ramalan penuh dengan peluang lapuk. Kejayaan pelanggan menerima konteks closed-won yang tidak lengkap. Kewangan membina semula laporan hasil di luar CRM. Syarikat akhirnya memutuskan ia memerlukan "seseorang RevOps."

Pengambilan itu membantu, tetapi sistem sudah bercelaru.

Masa yang lebih baik untuk mengambil RevOps ialah apabila pergerakan hasil telah menjadi terlalu merentas fungsi untuk dijalankan melalui penyelarasan tidak formal.

RevOps bukan pengambilan operasi pertama yang diperlukan setiap syarikat. Ia adalah pengambilan yang anda perlukan apabila sistem hasil telah menjadi cukup dikongsi sehingga tiada satu fungsi pun boleh membaikinya seorang diri.

Model tanggungjawab revenue operations Forrester merangka RevOps di sekitar penjajaran merentas enjin pertumbuhan. Itulah tujuan pengambilan ini: bukan untuk menambah seorang lagi pelapor, tetapi untuk memberikan sistem yang dikongsi itu seorang pemilik.

Fakta operasi utama

• Ambil RevOps apabila masalah hasil melangkaui sempadan pasukan: kitaran hayat, sumber kebenaran, penghalaan, serah tugas, ramalan, pengembangan pelanggan, atau kepercayaan pelaporan.
• Mengambil terlalu awal boleh mencipta jawatan tanpa mandat. Mengambil terlalu lewat mencipta hutang pembersihan.
• Pengambilan RevOps pertama perlu mempunyai kuasa ke atas sistem operasi yang dikongsi, bukan hanya tanggungjawab untuk dashboard.
• Jika kesakitan itu semata-mata dalam satu fungsi sahaja, Sales Ops, Marketing Ops, atau CS Ops mungkin pengambilan pertama yang lebih baik.

Jawapan ringkas

Ambil RevOps apabila masalah hasil tidak lagi kepunyaan satu pasukan secara bersih.

Isu proses jualan boleh ditangani oleh Sales Ops. Operasi kempen boleh ditangani oleh Marketing Ops. Proses onboarding boleh ditangani oleh CS Ops. RevOps menjadi perlu apabila masalah itu terletak antara pasukan: definisi kitaran hayat, serah tugas, sumber kebenaran, kepercayaan ramalan, atribusi, dan irama hasil.

Untuk perbezaan peranan, lihat RevOps vs Sales Ops dan RevOps vs Marketing Ops vs Sales Ops.

Ujian keputusan pengambilan

Gunakan ujian ini sebelum membuka jawatan tersebut.

Peranan itu perlu sepadan dengan kesakitan sistem. Jangan ambil RevOps kerana jawatan itu kedengaran matang. Ambil RevOps kerana syarikat memerlukan seorang pemilik operasi hasil yang dikongsi.

Isyarat pengambilan yang kuat

Anda sudah bersedia untuk RevOps apabila beberapa perkara ini benar:

• Pemasaran dan jualan tidak bersetuju tentang apa yang dikira layak.
• Peraturan penghalaan lead tidak jelas atau lapuk.
• Wakil jualan tidak mempercayai pemarkahan lead.
• Pengurus tidak mempercayai data peringkat peluang.
• Kewangan menggunakan hamparan bayang untuk ramalan atau pelaporan hasil.
• Kejayaan pelanggan menerima maklumat serah tugas yang tidak lengkap.
• ROI kempen tidak dapat dikaitkan dengan bersih kepada hasil.
• Medan CRM ditambah tanpa tadbir urus.
• Keputusan alat dalam satu pasukan menjejaskan pasukan lain.
• Mesyuarat hasil kebanyakannya penyesuaian data.

Ini bukan masalah "lebih banyak dashboard." Ini adalah masalah pemilikan operasi.

Panduan berasaskan peringkat

Saiz syarikat kurang penting berbanding kerumitan. Sebuah syarikat SaaS perusahaan bersaiz 40 orang mungkin memerlukan RevOps lebih awal berbanding syarikat 200 orang dengan pergerakan layan diri yang mudah.

Gunakan kerumitan operasi sebagai isyarat sebenar.

Pencetus 1: serah tugas lead membocorkan hasil

Pencetus biasa pertama ialah kegagalan serah tugas lead.

Pemasaran mencipta lead. Jualan tidak membuat susulan secara konsisten. SDR menolak lead tanpa sebab berstruktur. Peraturan penghalaan tidak sepadan dengan strategi wilayah atau segmen. Laporan kempen menunjukkan jumlah, tetapi laporan pipeline menunjukkan sedikit pergerakan.

Pada tahap ini, isu tersebut bukan sahaja kualiti pemasaran atau disiplin jualan. Ia adalah sistem serah tugas.

RevOps boleh mentakrifkan:

• Kriteria MQL dan SQL
• Peraturan pemberian lead
• Aliran kerja penerimaan dan penolakan
• Laluan SLA dan eskalasi
• Pelaporan sumber-ke-peluang
• Semakan kualiti lead bulanan

Jika proses lead-ke-peluang adalah pertengkaran berulang, syarikat berkemungkinan memerlukan pemilikan RevOps.

Pencetus 2: kepercayaan ramalan semakin runtuh

Pencetus kedua ialah ketidakpercayaan ramalan.

Jualan berkata ramalan itu realistik. Kewangan mengenakan potongan. CEO meminta pandangan berasingan. Pengurus menghabiskan panggilan ramalan membersihkan tarikh tutup dan nama peringkat. Pasukan mempunyai cukup pipeline di atas kertas, tetapi angka itu tidak ditutup.

Ini jarang diselesaikan dengan hamparan yang lebih baik. Kualiti ramalan bergantung pada definisi peringkat, kebersihan tarikh tutup, kriteria commit, pemeriksaan pengurus, dan kualiti data CRM.

CIO Dive merumuskan penyelidikan Gartner yang menunjukkan kurang daripada separuh pemimpin jualan dan jurujual mempunyai keyakinan tinggi terhadap ketepatan ramalan. RevOps membantu dengan merawat kualiti ramalan sebagai masalah sistem, bukan sekadar masalah pertimbangan jualan.

Pencetus 3: kejayaan pelanggan mewarisi konteks yang buruk

Jika kejayaan pelanggan berulang kali berkata, "Kami tidak tahu ini telah dijanjikan," syarikat memerlukan tadbir urus operasi selepas jualan yang lebih kukuh.

Closed-won bukan penghujung hasil. Ia adalah permulaan onboarding, penerimaan, pembaharuan, dan pengembangan. RevOps perlu memastikan konteks pelanggan yang dijual oleh jualan menjadi data berstruktur yang boleh digunakan oleh CS.

Itu termasuk:

• Kes penggunaan
• Kriteria kejayaan
• Pihak berkepentingan
• Skop kontrak
• Janji yang dibuat
• Risiko pelaksanaan
• Tarikh pembaharuan
• Isyarat pengembangan

Ini berkait terus dengan Penjajaran Jualan-CS dan RevOps dan Kejayaan Pelanggan.

Pencetus 4: kewangan tidak mempercayai data hasil

Ketidakpercayaan kewangan adalah isyarat serius.

Jika kewangan membina semula pipeline, tempahan, atribusi, atau angka ramalan di luar sistem hasil, syarikat mempunyai masalah sumber kebenaran. Masalah itu akan menjadi lebih teruk apabila syarikat berkembang.

RevOps tidak menggantikan kewangan. Kewangan memiliki pelan dan pelaporan kewangan. RevOps memiliki data dan proses operasi yang menjadikan pelan itu boleh diperiksa.

Lihat RevOps dan Kewangan untuk model perkongsian.

Mengambil terlalu awal

Mengambil terlalu awal mencipta masalah yang berbeza: overhead proses sebelum syarikat belajar cukup.

Anda mungkin terlalu awal jika:

• Seorang pengasas masih memiliki kebanyakan jualan.
• Pemasaran belum lagi menjadi saluran pemerolehan sebenar.
• CRM mempunyai kurang daripada beberapa ratus rekod bermakna.
• Proses jualan berubah setiap bulan.
• Kepimpinan masih memerlukan penemuan lebih daripada tadbir urus.

Dalam kes itu, gunakan Rangka Kerja Revenue Operations yang ringan tetapi jangan membina secara berlebihan.

Pemilik operasi pertama mungkin seorang generalis Sales Ops, kontraktor marketing ops, atau operator pengasas. Matlamatnya ialah untuk mengekalkan sistem itu jelas tanpa mencipta tadbir urus yang tidak perlu.

Mengambil terlalu lewat

Mengambil terlalu lewat adalah lebih biasa.

Isyarat lewat termasuk:

• Ramalan tersasar dipersalahkan kepada pertimbangan wakil jualan, tetapi definisi peringkat lemah.
• Pertikaian lead berlaku setiap bulan.
• Tiada sesiapa boleh menjelaskan prestasi sumber-ke-hasil tanpa pembersihan.
• Analisis churn CS tidak pernah sampai kepada peraturan kelayakan.
• Pemimpin hasil tidak lagi mempercayai data operasi.

Pada peringkat ini, pengambilan RevOps pertama menghabiskan berbulan-bulan mengurai kekusutan sejarah sebelum mereka boleh memperbaiki sistem itu.

Pengambilan lewat adalah mahal kerana setiap definisi yang rosak menjadi tertanam dalam laporan, dashboard, aliran kerja, dan tabiat pasukan.

Jenis pengambilan apa yang anda perlukan?

Bukan setiap pengambilan RevOps menyelesaikan masalah yang sama.

Jika anda memerlukan seseorang untuk mereka bentuk model operasi, jangan ambil hanya penganalisis dashboard. Jika anda memerlukan pembersihan CRM, jangan ambil hanya pemimpin strategi. Padankan pengambilan dengan kesesakan itu.

Ujian sebelum-dan-selepas

Ujian yang berguna ialah menggambarkan apa yang sepatutnya kelihatan berbeza secara jelas enam bulan selepas pengambilan.

Jika jawapannya hanya "kami akan mempunyai dashboard yang lebih baik," peranan itu berkemungkinan kurang skop. Dashboard memang penting, tetapi ia adalah hasil daripada definisi yang lebih jelas, medan yang lebih baik, serah tugas yang lebih kukuh, dan irama yang memaksa pemeriksaan.

Ujian sebelum-dan-selepas RevOps yang sebenar mungkin kelihatan seperti ini:

Ujian ini mengekalkan keputusan pengambilan berkait dengan perubahan perniagaan. Ia juga melindungi pengambilan pertama daripada menjadi meja perkhidmatan reaktif.

Senarai semak masa pengambilan

Gunakan senarai semak ini apabila syarikat tidak pasti sama ada untuk mengambil sekarang atau menunggu:

• Adakah sekurang-kurangnya tiga pemimpin hasil bergantung pada data yang sama?
• Adakah kesilapan serah tugas mencipta pipeline hilang, kelewatan, risiko churn, atau kerja semula yang boleh diukur?
• Adakah mesyuarat berulang kali mengunjungi semula definisi berbanding keputusan?
• Adakah perubahan sistem mencipta kesan hiliran yang tiada sesiapa memiliki?
• Adakah pelaporan manual mengambil masa yang cukup untuk melewatkan perancangan atau keputusan pengurusan?
• Adakah seorang pemilik merentas fungsi akan mengurangkan geseran merentas lebih daripada satu pasukan?

Jika kebanyakan jawapan adalah ya, menunggu berkemungkinan akan menelan kos lebih daripada mengambil.

Jika hanya satu pasukan merasai kesakitan itu, selesaikan jurang operasi tempatan dahulu. Itu mungkin bermaksud Sales Ops, Marketing Ops, pentadbir CRM, atau kontraktor. RevOps perlu tiba apabila pemilikan operasi dikongsi menjadi kekangan.

Kos menunggu

Menunggu tidak selalu salah. Tetapi menunggu mempunyai kos apabila kesakitan itu sudah merentas fungsi.

Soalan pengambilan bukan hanya sama ada RevOps akan berguna. Ia adalah sama ada syarikat sudah membayar untuk pemilikan operasi yang lemah melalui masa pengurusan yang terbuang, penukaran hilang, keputusan ramalan tertangguh, dan kerja semula serah tugas pelanggan.

Bukti 30 hari sebelum mengambil

Jika kepimpinan tidak pasti, jalankan bukti 30 hari berbanding membahaskan gelaran jawatan.

Tugaskan seorang pemilik, walaupun sambilan, untuk menghasilkan empat output:

1. Peta kitaran hayat daripada lead hingga pembaharuan.
2. Senarai lima pertikaian serah tugas atau pelaporan berulang teratas.
3. Audit rekod merentas lead, peluang, deal closed-won, dan pelanggan berisiko pembaharuan.
4. Peta jalan RevOps diutamakan dengan anggaran impak perniagaan.

Jika projek singkat ini mendedahkan kekeliruan merentas fungsi yang tiada fungsi semasa memilikinya, kes RevOps menjadi lebih kukuh. Jika penemuan kebanyakannya tempatan kepada jualan, pemasaran, atau CS, ambil atau tugaskan peranan operasi yang lebih sempit dahulu.

Ambil sekarang, tunggu, atau sempitkan peranan

Gunakan jadual keputusan ini.

Langkah terburuk ialah mengambil RevOps dengan hanya mandat dashboard sambil mengharapkan hasil merentas fungsi. Itu mencipta kekecewaan pada kedua-dua belah pihak.

Apa yang perlu dimasukkan dalam deskripsi jawatan

Banyak deskripsi jawatan RevOps terlalu luas. Mereka meminta pentadbiran sistem, business intelligence, reka bentuk pampasan, ramalan, strategi GTM, operasi kempen, kejuruteraan data, enablement, dan pelaporan eksekutif dalam satu peranan.

Itu mungkin menggambarkan fungsi dari semasa ke semasa. Ia tidak sepatutnya menggambarkan satu pengambilan pertama.

Deskripsi jawatan yang lebih bersih perlu merangkumi:

• Pergerakan hasil yang akan disokong oleh individu tersebut
• Masalah operasi utama yang akan mereka warisi
• Sistem yang akan mereka tadbir urus
• Serah tugas yang akan mereka perbaiki
• Metrik yang akan menilai mereka
• Hak keputusan yang akan mereka miliki
• Hasil 90 hari pertama yang dijangkakan

Sebagai contoh, jika masalah sebenar ialah kebocoran lead, katakan begitu. Jika masalah sebenar ialah kepercayaan ramalan, katakan begitu. Jika masalah sebenar ialah tadbir urus CRM, katakan begitu. Calon terkuat mahukan masalah operasi sebenar, bukan senarai tanggungjawab RevOps generik yang digilap.

Deskripsi jawatan juga perlu menyatakan apa yang RevOps tidak akan miliki. Pemimpin hasil masih memiliki kuota, penjanaan pipeline, kadar kemenangan, pengekalan, dan strategi pengembangan. RevOps memiliki sistem operasi yang menjadikan hasil itu jelas dan boleh ditadbir urus.

Kes perniagaan

Kes perniagaan RevOps biasanya bukan "ambil seseorang untuk membina laporan."

Ia adalah:

• Kurangkan kebocoran pipeline.
• Perbaiki kepercayaan ramalan.
• Pendekkan mesyuarat hasil.
• Perbaiki penerimaan lead.
• Kurangkan pelaporan manual.
• Perbaiki kualiti serah tugas closed-won.
• Jadikan data hasil boleh digunakan untuk perancangan.

Kes perniagaan terkuat mengaitkan kerja RevOps dengan beberapa kebocoran yang boleh diukur. Sebagai contoh: lead yang melebihi SLA, peluang dengan tarikh tutup lapuk, deal closed-won yang kehilangan data onboarding, atau laporan pipeline yang memerlukan penyesuaian manual.

Untuk pasukan peringkat awal, satu kes perniagaan yang kuat ialah masa pengurus. Jika setiap mesyuarat hasil memerlukan pemimpin menyesuaikan laporan sebelum perbincangan sebenar bermula, syarikat itu membayar orang kanan untuk mengimbangi reka bentuk operasi yang lemah. Pengambilan RevOps perlu menghapuskan kerja berulang itu dengan menjadikan sistem cukup jelas supaya pemimpin boleh memeriksa keputusan, bukan membina semula bukti.

Apa rupa kejayaan selepas enam bulan

Enam bulan pertama yang baik bukan pembinaan semula sepenuhnya. Ia adalah sebilangan kecil penambahbaikan berkepercayaan tinggi yang mengubah cara pasukan hasil berjalan.

Tanda-tanda kuat termasuk:

• Satu peta kitaran hayat yang dipersetujui daripada lead hingga pembaharuan
• Piagam RevOps ringkas dengan hak keputusan yang jelas
• Lebih sedikit perubahan medan dan aliran kerja yang tidak ditadbir urus
• Panggilan ramalan yang lebih bersih dengan lebih sedikit perdebatan data
• Dashboard yang digunakan pemimpin tanpa meminta pembersihan manual
• Serah tugas closed-won yang didokumenkan
• Peta jalan diutamakan berbanding senarai permintaan tertunggak

Perubahan paling penting ialah kepercayaan. Pemimpin mungkin masih tidak bersetuju tentang strategi, tetapi mereka perlu berhenti bertengkar tentang apa yang dimaksudkan oleh angka tersebut.

Itulah sebabnya masa pengambilan RevOps penting. Ambil sebelum syarikat mempunyai sebarang proses yang boleh diulang, dan peranan itu mencipta overhead. Ambil selepas sistem operasi sudah tidak dipercayai, dan peranan itu bermula dalam mod pembaikan. Masa terbaik ialah apabila kerumitan itu nyata, kesakitan itu merentas pasukan, dan kepimpinan bersedia memberikan seorang pemilik mandat untuk membaiki sistem.

Soalan Lazim

Patutkah pengambilan RevOps pertama bersifat teknikal?

Mereka memerlukan kefasihan sistem yang mencukupi untuk memahami CRM dan aliran data, tetapi pengambilan pertama perlu menjadi operator dahulu. Reka bentuk proses, hak keputusan, dan kepercayaan merentas fungsi lebih penting daripada kemahiran pentadbiran semata-mata.

Bolehkah Sales Ops menjadi RevOps?

Ya, jika mandat berkembang. Individu itu memerlukan kuasa merentas pemasaran, jualan, CS, kewangan, dan sistem, bukan hanya jawatan baharu.

Kepada siapa RevOps patut melapor?

Biasanya CRO, COO, CEO, atau pemimpin merentas fungsi lain. Melapor hanya kepada jualan atau pemasaran melemahkan kenetralan.

Apakah risiko menunggu?

Semakin lama anda menunggu, semakin banyak definisi rosak, hamparan bayang, kerja pintasan manual, dan ketidakpercayaan pelaporan menjadi tingkah laku operasi biasa.

Ketahui lebih lanjut

• Pengambilan RevOps Pertama Anda
• Struktur Pasukan RevOps
• Piagam RevOps
• Automasi Penghalaan Lead