Mengapa RevOps Gagal: 9 Mod Kegagalan Yang Meruntuhkan Revenue Operations

RevOps jarang gagal kerana pasukan tidak boleh membina dashboard.

Ia gagal kerana syarikat memberikan RevOps tanggungjawab tanpa kuasa. Atau bermula dengan automasi sebelum proses jelas. Atau membiarkan setiap fungsi mengekalkan definisi masing-masing. Atau menukar RevOps menjadi baris giliran tiket dan masih mengharapkannya mereka bentuk semula sistem hasil.

Gelaran jawatan itu mudah. Mandat operasi itu sukar.

Gunakan artikel ini sebagai senarai semak mod kegagalan selepas membaca Apakah Itu Revenue Operations? dan Rangka Kerja Revenue Operations.

Forrester telah menulis bahawa struktur revenue operations yang berjaya boleh terbentang daripada terdesentralisasi kepada sepenuhnya berpusat. Itu adalah peringatan berguna: kegagalan RevOps bukan disebabkan oleh pemilihan carta organisasi yang salah semata-mata. Ia biasanya disebabkan oleh peraturan operasi yang lemah.

Fakta operasi utama

• RevOps biasanya gagal disebabkan mandat lemah, kuasa tidak jelas, definisi berpecah-belah, tadbir urus data yang lemah, dan pengoptimuman tempatan merentas fungsi.
• Dashboard, automasi, dan alat tidak membaiki proses yang tidak jelas. Selalunya ia menjadikan kekeliruan lebih jelas atau lebih cepat.
• Perlindungan awal paling penting ialah piagam bertulis, RACI, model sumber kebenaran, dan irama operasi.
• Kegagalan perlu didiagnosis mengikut gejala operasi: keputusan perlahan, angka bercanggah, kebocoran serah tugas, ketidakpercayaan ramalan, atau lebihan bebanan tertunggak.

1. RevOps mempunyai tanggungjawab tanpa kuasa

Ini adalah kegagalan paling biasa.

RevOps diarahkan untuk memperbaiki kualiti data, tetapi tidak boleh menguatkuasakan medan wajib. Ia diarahkan untuk memperbaiki ketepatan ramalan, tetapi tidak boleh mengubah definisi peringkat. Ia diarahkan untuk menyelaraskan pemasaran dan jualan, tetapi tidak boleh mentadbir urus peraturan kitaran hayat.

Kerja itu menjadi sekadar pertunjukan. RevOps bertanggungjawab ke atas hasil yang tidak dapat dikawalnya.

Baikinya dengan menulis Piagam RevOps. Piagam itu perlu mentakrifkan skop, hak keputusan, laluan eskalasi, dan apa yang RevOps boleh ubah tanpa perlu bertanya setiap pemimpin fungsi.

Jadual diagnosis kegagalan

Gunakan gejala untuk mengenal pasti mod kegagalan.

Jadual ini membantu mengelakkan nasihat generik. "RevOps sedang gagal" terlalu luas untuk dibaiki. Gejala operasi memberitahu anda sama ada pembaikan pertama itu ialah kuasa, definisi, irama, data, atau pemilikan.

2. Syarikat bermula dengan dashboard

Dashboard kelihatan seperti kemajuan. Ia jelas, boleh dikongsi, dan mesra eksekutif.

Tetapi dashboard yang dibina di atas peringkat yang tidak jelas dan medan yang buruk hanya menjadikan data buruk lebih mudah dilihat.

Jika "pipeline dijana" bermaksud satu perkara kepada jualan dan perkara lain kepada pemasaran, dashboard tidak akan menyelesaikan pertikaian itu. Jika peringkat peluang bersifat subjektif, dashboard ramalan tidak akan menjadikan ramalan itu boleh dipercayai.

Baiki definisi sebelum carta. Takrifkan peringkat kitaran hayat, kriteria kemasukan, pemilik, dan peraturan sumber kebenaran. Kemudian bina pelaporan.

3. Sales Ops dinamakan semula RevOps

Sales Ops adalah bernilai, tetapi menamakannya semula tidak mencipta kuasa merentas fungsi.

Jika pasukan masih hanya memiliki laporan jualan, peringkat jualan, dan pentadbiran CRM, maka ia adalah Sales Ops dengan gelaran yang lebih luas. RevOps memerlukan kuasa merentas pemasaran, jualan, CS, kewangan, data, dan sistem.

Lihat RevOps vs Sales Ops untuk perbezaan itu.

4. Setiap pasukan mengekalkan sumber kebenaran sendiri

Pemasaran melapor daripada MAP. Jualan melapor daripada CRM. CS melapor daripada platform kejayaan pelanggan. Kewangan melapor daripada pengebilan dan hamparan.

Setiap sistem mungkin berguna secara tempatan, tetapi syarikat tidak boleh menjalankan hasil daripada empat kebenaran yang bercanggah.

Kegagalan ini muncul dalam mesyuarat kepimpinan. Pemasaran berkata satu kempen mempengaruhi satu deal. Jualan berkata sumber peluang itu adalah outbound. Kewangan berkata tiada angka yang sepadan dengan laporan tempahan. Mesyuarat itu menjadi penyesuaian data berbanding pembuatan keputusan.

Baikinya dengan Sumber Kebenaran untuk Data Hasil dan Kamus Data Hasil.

5. Automasi mengembangkan proses yang rosak

Automasi bukan pengganti reka bentuk operasi.

Jika peraturan kelayakan lead tidak jelas, penghalaan automatik mencipta kekeliruan yang lebih cepat. Jika kriteria peringkat lemah, pemarkahan ramalan automatik menghasilkan bunyi yang yakin. Jika data serah tugas tidak lengkap, automasi aliran kerja menghantar rekod tidak lengkap dengan lebih cepat.

Automasi yang baik menguatkuasakan peraturan yang jelas. Automasi yang buruk menyembunyikan peraturan yang tidak jelas.

Baiki aliran kerja dahulu. Automasikan kemudian. Mulakan dengan Model SLA Full-Funnel, Kriteria Keluar Peringkat, dan Automasi RevOps.

6. RevOps menjadi baris giliran tiket

Permintaan medan. Permintaan laporan. Permintaan dashboard. Permintaan import. Permintaan integrasi.

Semua kerja itu mungkin perlu, tetapi jika ia menggunakan semua kapasiti, RevOps tidak dapat memperbaiki sistem itu. Ia menjadi meja bantuan.

Gejalanya ialah setiap minggu sibuk dan tiada apa-apa yang bersifat sistemik bertambah baik. Masalah data yang sama berulang. Isu serah tugas yang sama berulang. Mesyuarat yang sama menghasilkan aduan yang sama.

Lindungi kapasiti proaktif. Peta jalan RevOps yang sihat perlu merangkumi tadbir urus, penambahbaikan proses, kualiti data, dan kerja irama, bukan hanya permintaan.

7. Irama dikelirukan dengan mesyuarat

Lebih banyak mesyuarat tidak mencipta disiplin operasi.

Irama hasil memerlukan tujuan, pek data, pemilik keputusan, dan laluan susulan. Panggilan ramalan perlu memeriksa risiko hasil. Semakan funnel perlu memeriksa penukaran dan kelajuan. Semakan tadbir urus sistem perlu meluluskan atau menolak perubahan.

Jika mesyuarat berakhir tanpa keputusan, pemilik, atau perubahan tingkah laku, ia bukan irama. Ia adalah perbincangan.

Baiki percambahan mesyuarat dengan mereka bentuk Irama Hasil.

8. Kualiti data dianggap sebagai pembersihan

Data CRM yang buruk bukan masalah pembersihan suku tahunan. Ia adalah masalah operasi berterusan.

Penyelidikan Salesforce mendapati jurujual menghabiskan kebanyakan masa mereka pada tugas bukan jualan. Jika penangkapan data terlalu menyakitkan atau tadbir urus lemah, CRM merosot semula selepas setiap pembersihan.

Baiki proses penangkapan, medan wajib, peraturan pendua, dan model penerimaan. Lihat Kebersihan Data CRM, Model Operasi Penerimaan CRM, dan Medan Wajib vs Medan Berguna.

9. RevOps diukur hanya berdasarkan output

Jika RevOps diukur berdasarkan bilangan laporan yang dihantar atau tiket yang ditutup, pasukan itu akan mengoptimumkan untuk aktiviti.

Ukuran yang lebih baik termasuk ketepatan ramalan, kebersihan peringkat, pematuhan SLA, kelengkapan serah tugas, keterlihatan sumber-ke-hasil, kelengkapan medan, dan pengurangan kerja pelaporan manual.

Gunakan Metrik RevOps untuk mentakrifkan ukuran tersebut.

Corak kegagalan

Kebanyakan kegagalan RevOps mengikut urutan yang sama:

1. Kepimpinan melihat geseran hasil merentas fungsi.
2. Seorang individu atau pasukan RevOps ditugaskan.
3. Pasukan itu diminta membaiki laporan dan sistem dengan pantas.
4. Hak keputusan kekal tidak jelas.
5. Pasukan fungsi mengekalkan kawalan tempatan ke atas definisi yang dikongsi.
6. RevOps menjadi baris giliran permintaan.
7. Dashboard bertambah baik, tetapi sistem operasi tidak.

Pembaikannya bukan bekerja lebih keras. Ia adalah menetapkan semula mandat.

Cara mengesan kegagalan lebih awal

Kegagalan RevOps biasanya muncul sebelum eksekutif menamakannya.

Perhatikan isyarat ini:

• Pemimpin hasil meminta laporan yang sama berulang kali kerana mereka tidak mempercayai dashboard itu.
• Pemasaran dan jualan berdebat tentang definisi dalam setiap semakan funnel.
• Kewangan mengekalkan fail ramalan berasingan.
• CS berkata isu serah tugas pelanggan adalah "masalah disiplin jualan" tetapi tiada perubahan aliran kerja.
• RevOps menghabiskan lebih separuh minggunya pada permintaan sekali sahaja.
• Medan CRM ditambah lebih cepat daripada dinyahtauliahkan.
• Automasi ditambah kepada aliran kerja yang tiada sesiapa dokumenkan.
• Kepimpinan memuji aktiviti RevOps tetapi tidak dapat menamakan proses hasil mana yang telah bertambah baik.

Isyarat ini tidak bermaksud pasukan itu buruk. Ia bermaksud model operasi itu lemah.

Apa yang perlu pemimpin lakukan secara berbeza

Eksekutif sering menyebabkan kegagalan RevOps tanpa disengajakan.

Mereka meminta dashboard sebelum definisi. Mereka meminta automasi sebelum bersetuju tentang serah tugas. Mereka mempertanggungjawabkan RevOps untuk kualiti data sambil membenarkan setiap fungsi mengubah medan. Mereka menyebut RevOps sebagai strategik tetapi menghalakan setiap permintaan laporan mendesak kepada pasukan yang sama.

Pembaikan kepimpinan itu mudah tetapi tidak selesa: berikan RevOps hak keputusan sebenar.

Itu termasuk hak untuk berkata:

• Tidak kepada medan tanpa pemilik.
• Tidak kepada dashboard berdasarkan definisi yang tidak jelas.
• Tidak kepada automasi sebelum reka bentuk proses.
• Tidak kepada perubahan sistem yang merosakkan pelaporan yang dikongsi.
• Tidak kepada permintaan mendesak yang sepatutnya memasuki irama tadbir urus.

RevOps tidak boleh menjadi kedua-dua pemilik kualiti operasi hasil dan meja perkhidmatan tanpa had. Pemimpin perlu memilih peranan mana yang lebih penting.

Contoh pemulihan

Pertimbangkan sebuah syarikat di mana ramalan tidak dipercayai.

Respons lemah ialah meminta RevOps untuk dashboard ramalan yang lebih baik. Respons lebih kukuh ialah mendiagnosis mengapa ramalan itu lemah:

• Adakah peringkat berasaskan bukti?
• Adakah tarikh tutup lapuk?
• Adakah kriteria commit jelas?
• Adakah pengurus memeriksa langkah seterusnya?
• Adakah medan wajib lengkap?
• Adakah kewangan bersetuju dengan kategori ramalan?

Pembaikan mungkin melibatkan Tadbir Urus Ramalan, Kriteria Commit, dan Irama Pemeriksaan Pipeline. Dashboard datang selepas peraturan operasi.

Mod kegagalan mengikut peringkat syarikat

RevOps gagal secara berbeza pada peringkat yang berbeza.

Pembaikan perlu sepadan dengan peringkat itu. Syarikat awal mungkin memerlukan kurang tadbir urus dan lebih kejelasan. Syarikat matang mungkin memerlukan kawalan perubahan yang lebih kukuh dan disiplin pengambilan yang lebih baik.

Rupa RevOps yang sihat sebaliknya

RevOps yang sihat mempunyai beberapa ciri yang dapat diperhatikan:

• Pemimpin menggunakan definisi hasil yang sama.
• Panggilan ramalan adalah tentang risiko, bukan pembersihan asas.
• Serah tugas mempunyai pemilik dan data wajib.
• Dashboard dikaitkan dengan keputusan.
• Perubahan CRM mempunyai laluan tadbir urus.
• RevOps mempunyai kapasiti peta jalan setiap bulan.
• Pasukan fungsi tahu bila mereka boleh bertindak secara tempatan dan bila mereka memerlukan kelulusan.

Ujian paling ringkas: apabila sesuatu rosak antara pasukan, adakah semua orang tahu siapa memiliki pembaikan itu? Jika tidak, RevOps masih kekurangan kuasa atau kejelasan yang diperlukannya.

Apa yang perlu diukur semasa pemulihan

Jangan ukur pemulihan berdasarkan jumlah aktiviti.

Jejaki sama ada sistem operasi menjadi lebih sihat:

• Kelengkapan medan wajib bertambah baik.
• Sebab penolakan MQL ditangkap secara konsisten.
• Masa pembersihan ramalan berkurangan.
• Kelengkapan serah tugas closed-won meningkat.
• Kadar rekod pendua menurun.
• Lebih sedikit laporan memerlukan penyesuaian manual.
• Mesyuarat hasil menghasilkan keputusan berbanding perdebatan data.

Ukuran ini menunjukkan sama ada RevOps membaiki punca masalah. Sebuah pasukan boleh menutup banyak tiket dan masih meninggalkan sistem itu lemah. Usaha pemulihan perlu menjadikan kerja masa depan lebih mudah, bukan hanya membersihkan bebanan tertunggak semasa.

Semak ukuran ini setiap bulan bersama CRO, kewangan, dan pemimpin fungsi. Jika ukuran itu tidak bertambah baik selepas satu suku tahun, pelan pemulihan itu berkemungkinan merawat gejala sahaja. Itulah titik untuk menyemak semula hak keputusan, saluran pelaporan, dan peraturan pengambilan berbanding meminta pasukan RevOps yang sama bekerja lebih pantas.

Semakan itu perlu berterus terang. Jika pemimpin terus meluluskan pengecualian tempatan yang melemahkan definisi yang dikongsi, RevOps tidak akan pulih. Jika setiap permintaan dashboard mendesak melangkau tadbir urus, kualiti pelaporan tidak akan bertambah baik. Pemulihan memerlukan tingkah laku kepimpinan berubah, bukan hanya tingkah laku RevOps merentas syarikat.

Itulah ujian sebenar.

Pelan pemulihan

Jika RevOps sudah gagal, jangan mulakan dengan dashboard atau alat baharu.

Mulakan di sini:

Urutan ini memberikan RevOps kuasa dan fokus yang diperlukannya sebelum menambah lebih banyak kerja.

Pengajaran pelan pemulihan

RevOps biasanya gagal atas sebab operasi, bukan kerana ideanya lemah. Fungsi itu memerlukan mandat, hak keputusan, keutamaan yang bersih, dan cara yang jelas untuk menghubungkan data, proses, sistem, dan irama kepimpinan.

Tanpa bahagian-bahagian itu, RevOps menjadi pasukan yang membantu tanpa kuasa ke atas sistem yang diharapkan untuk diperbaikinya. Fungsi RevOps yang gagal perlu dibaiki dengan menjelaskan pemilikan dahulu, kemudian membaiki serah tugas dengan kebocoran tertinggi dan masalah sumber kebenaran.

Kerja pembaikan itu perlu jelas.

Pemimpin perlu melihat keputusan pemilikan mana yang berubah, serah tugas mana yang bertambah baik, dan laporan mana yang menjadi boleh dipercayai semula.

Tindakan pemulihan Isnin

Jika RevOps sudah bergelut, mulakan dengan set kecil tindakan yang jelas.

Tindakan ini bukan transformasi penuh. Ia mencipta kawalan yang mencukupi untuk melihat masalah sebenar.

Penjujukan pemulihan

Jangan pulih dengan membina semula setiap alat dan dashboard sekali gus.

Gunakan urutan ini:

1. Jelaskan mandat dan penaja.
2. Hentikan pengambilan bernilai rendah.
3. Baiki definisi kitaran hayat.
4. Stabilkan serah tugas berisiko tertinggi.
5. Pilih satu dashboard eksekutif yang dipercayai.
6. Tambah kawalan perubahan sistem.
7. Bina semula irama di sekitar keputusan.
8. Kembangkan peta jalan hanya selepas kepercayaan bertambah baik.

Urutan ini berkesan kerana kegagalan RevOps biasanya bersifat kumulatif. Kuasa yang lemah mencipta pengambilan yang lemah. Pengambilan yang lemah menghalang kerja proses. Proses yang lemah menjadikan dashboard tidak dipercayai. Dashboard yang tidak dipercayai mencipta lebih banyak permintaan manual. Pemulihan perlu memecahkan gelung itu.

Soalan Lazim

Mengapa pasukan RevOps gagal?

Kebanyakan gagal kerana mandat tidak jelas. Mereka diminta memperbaiki prestasi hasil merentas fungsi tanpa kuasa untuk mentadbir urus definisi, data, sistem, atau serah tugas.

Apakah tanda pertama RevOps sedang gagal?

Tanda pertama biasanya ialah keruntuhan kepercayaan. Pemimpin berhenti mempercayai dashboard, pasukan menggunakan hamparan bayang, dan mesyuarat menjadi pertengkaran tentang data berbanding keputusan.

Bagaimana anda membaiki fungsi RevOps yang gagal?

Tulis semula piagam, jelaskan hak keputusan, permudahkan definisi kitaran hayat, bersihkan model data teras, dan lindungi kapasiti RevOps untuk kerja sistem yang proaktif.

Adakah kegagalan RevOps biasanya masalah manusia?

Biasanya tidak. Ia lebih kerap merupakan masalah model operasi: pemilikan tidak jelas, tadbir urus lemah, data buruk, atau saluran pelaporan yang memberikan RevOps tanggungjawab tanpa kuasa.

Ketahui lebih lanjut

• Rangka Kerja Revenue Operations
• RACI RevOps
• Tadbir Urus Medan CRM
• Tadbir Urus Ramalan