Piagam RevOps: Cara Menentukan Mandat, Skop, dan Hak Membuat Keputusan

Piagam RevOps ialah dokumen yang menghalang Revenue Operations daripada bertanggungjawab ke atas segalanya tetapi tidak diberi kuasa untuk mengubah apa-apa.

Tanpa piagam, RevOps akan menjadi apa sahaja yang dikehendaki oleh pihak berkepentingan yang paling lantang pada minggu tersebut: pasukan dashboard, barisan tugas admin CRM, fungsi pembersihan ramalan, atau laluan eskalasi untuk kekecewaan silang fungsi.

Piagam memberikan mandat kepada fungsi ini.

Kajian model operasi RevOps oleh Forrester menjelaskan isu teras: kejayaan RevOps bergantung kepada reka bentuk operasi, bukan sekadar nama pasukan. Panduan Gartner mengenai pengurangan kerumitan pengupayaan hasil menunjukkan masalah yang sama dari sudut jualan: inisiatif yang terputus hubungan mencipta kekeliruan melainkan seseorang menguruskan model bersama itu.

Piagam menterjemahkan model itu ke dalam bahasa yang mudah. Ia memberitahu pemimpin apa yang dimiliki oleh RevOps, apa yang dipengaruhinya, apa yang tidak dimilikinya, dan bagaimana keputusan dibuat.

Fakta operasi utama

• Piagam RevOps menentukan mandat, skop, hak membuat keputusan, irama tadbir urus, kuasa ke atas sistem, metrik, dan laluan eskalasi.
• Piagam sepatutnya melindungi RevOps daripada bertanggungjawab ke atas segalanya sekali gus tidak diberi kuasa untuk mengubah apa-apa.
• Piagam yang kukuh memisahkan pemilikan prestasi fungsian daripada pemilikan sistem operasi bersama.
• Piagam perlu disemak semula apabila syarikat mengubah pendekatan GTM, sistem, kepimpinan, keperluan pelaporan, atau struktur RevOps.

Apa yang perlu terkandung dalam piagam RevOps

Piagam perlu cukup ringkas untuk dibaca oleh pemimpin dan cukup spesifik untuk menyelesaikan pertikaian.

Sebab RevOps memerlukan piagam

RevOps sering bermula kerana seseorang mahir mencari susunan dalam sistem yang bercelaru. Mereka membersihkan laporan, membaiki medan, menterjemah antara pemasaran dan jualan, dan membantu kewangan memahami apa yang berlaku dalam corong.

Kegunaan itu mencipta permintaan. Tidak lama kemudian, semua orang mahukan sesuatu daripada RevOps.

Pemasaran mahukan pembersihan atribusi. Jualan mahukan perubahan wilayah. CS mahukan medan serah tugas yang lebih baik. Kewangan mahukan keyakinan ramalan. Kepimpinan mahukan dashboard. Pasukan sistem mahukan lebih sedikit permintaan aliran kerja yang tergesa-gesa. Setiap permintaan mungkin munasabah, tetapi beban gabungan boleh mengubah RevOps menjadi sekadar barisan tugas.

Piagam menghalang hanyutan itu.

Ia menjawab lima soalan praktikal:

• Apa yang RevOps di sini untuk perbaiki?
• Bahagian mana dalam sistem hasil yang dimilikinya?
• Keputusan mana yang boleh dibuatnya?
• Keputusan mana yang memerlukan kelulusan eksekutif?
• Bagaimana pemimpin akan tahu sama ada RevOps berfungsi dengan baik?

Tanpa jawapan tersebut, RevOps mendapat tanggungjawab tanpa kuasa. Itulah salah satu sebab fungsi ini gagal walaupun pasukannya berbakat.

Jadual keputusan piagam

Piagam perlu memudahkan keputusan biasa.

Di sinilah piagam menjadi praktikal. Ia bukan sekadar menggambarkan RevOps dengan bahasa yang luas. Ia perlu membantu pemimpin menyelesaikan keputusan yang biasanya mencetuskan konflik.

Kenyataan misi

Kenyataan misi RevOps yang berguna berbunyi seperti ini:

RevOps memiliki sistem operasi yang menjadikan hasil boleh diramal merentasi pemasaran, jualan, kejayaan pelanggan, kewangan, data, dan sistem.

Misi itu berkait langsung dengan Apakah Revenue Operations?. Ia meletakkan RevOps sebagai pemilik sistem, bukan sekadar barisan tugas.

Skop

RevOps sepatutnya memiliki:

• Takrifan kitaran hayat hasil
• Serah tugas silang fungsi
• Dashboard hasil bersama
• Tadbir urus CRM dan data hasil
• Tadbir urus proses ramalan
• Irama operasi hasil
• Kawalan perubahan sistem untuk aliran kerja hasil

RevOps tidak sepatutnya memiliki:

• Strategi pemasaran
• Bimbingan jualan dan pelaksanaan deal
• Pengurusan hubungan kejayaan pelanggan
• Pemilikan pelan kewangan
• Keputusan roadmap produk

Piagam perlu menjelaskan perkara ini secara terang. RevOps melaksanakan strategi secara operasi. Ia tidak menggantikan kepimpinan fungsian.

Sempadan skop

Bahagian paling sukar dalam menulis piagam ialah menentukan apa yang tidak akan dilakukan oleh RevOps.

Piagam yang menyatakan RevOps memiliki "pertumbuhan hasil" adalah terlalu luas. Pertumbuhan hasil ialah hasil daripada strategi, permintaan pasaran, produk, harga, pelaksanaan jualan, kejayaan pelanggan, dan perancangan kewangan. RevOps boleh memperbaiki sistem di sebalik hasil itu, tetapi ia tidak sepatutnya dipertanggungjawabkan ke atas setiap keputusan komersial.

Sempadan yang lebih jelas kelihatan seperti ini:

Sempadan ini melindungi kedua-dua pihak. Pemimpin fungsian mengekalkan pemilikan prestasi. RevOps mendapat kuasa ke atas lapisan operasi bersama.

Hak membuat keputusan

Hak membuat keputusan ialah bahagian paling penting dalam piagam.

Tentukan siapa yang boleh meluluskan:

• Peringkat kitaran hayat baharu
• Perubahan medan CRM
• Takrifan metrik dashboard
• Perubahan peraturan penghalaan
• Peraturan kategori ramalan
• Keperluan serah tugas
• Alat atau integrasi hasil baharu

Untuk reka bentuk pemilikan yang terperinci, lihat RevOps RACI.

Templat hak membuat keputusan

Hak membuat keputusan perlu ditulis sebagai jadual, bukan tersembunyi dalam perenggan.

Nama sebenar boleh berubah, tetapi prinsip tidak boleh berubah. RevOps hanya boleh memiliki kualiti sistem jika ia mempunyai hak kelulusan ke atas perubahan yang menjejaskan kualiti sistem.

Irama operasi

Piagam juga perlu menentukan mesyuarat yang dikendalikan atau disokong oleh RevOps.

Irama biasa termasuk:

• Pemeriksaan pipeline mingguan
• Semakan ramalan mingguan atau dwi-mingguan
• Semakan corong bulanan
• Semakan kualiti data bulanan
• Semakan perubahan sistem bulanan
• Semakan takrifan kitaran hayat dan dashboard suku tahunan
• Semakan roadmap RevOps suku tahunan

Matlamatnya bukan lebih banyak mesyuarat. Matlamatnya ialah lebih sedikit eskalasi ad hoc.

Apabila irama tiada, setiap percanggahan pendapat menjadi mesyuarat khas. Apabila irama wujud, pemimpin tahu di mana untuk membangkitkan isu, bagaimana keputusan akan dibuat, dan bila perubahan akan disemak.

Untuk rentak operasi yang lebih luas, lihat Revenue Cadence.

Tadbir urus sistem

Kebanyakan piagam RevOps gagal kerana kurang menentukan tadbir urus sistem secara terperinci.

Jika CRM ialah teras operasi, maka perubahan medan, aliran kerja, integrasi, data wajib, penghalaan lead, peraturan peringkat, dan takrifan dashboard tidak boleh diubah sewenang-wenangnya. Perubahan kecil mencipta kesan hiliran.

Piagam perlu menentukan:

• Siapa yang boleh meminta perubahan
• Maklumat apa yang perlu disertakan dalam permintaan
• Bagaimana RevOps menilai impak
• Siapa yang meluluskan perubahan berisiko tinggi
• Bagaimana perubahan didokumentasikan
• Bagaimana pengguna dimaklumkan
• Bagaimana penerimaan diperiksa selepas pelancaran

Ini amat penting apabila beberapa pasukan berkongsi objek yang sama. Medan yang membantu segmentasi pemasaran mungkin melambatkan kemasukan data jualan. Aliran kerja yang membantu penghalaan jualan mungkin menjejaskan serah tugas CS. Takrifan dashboard yang membantu CRO mungkin bercanggah dengan pelaporan kewangan.

RevOps tidak perlu menyekat perubahan. Ia perlu menjadikan perubahan itu jelas kelihatan sebelum ia merosakkan sesuatu.

Pelancaran piagam

Jangan terbitkan piagam sebagai dokumen siap dan mengharapkan penerimaan begitu sahaja.

Pelancaran perlu menjadi proses penjajaran kepimpinan:

1. RevOps merangka piagam berdasarkan titik kesakitan semasa.
2. Pemimpin fungsian menyemak skop dan hak membuat keputusan.
3. Kewangan menyemak takrifan metrik dan titik sentuh perancangan.
4. Sistem atau IT menyemak tadbir urus platform.
5. Penaja eksekutif menyelesaikan konflik.
6. Piagam akhir dikongsi dengan pengurus hasil.
7. RevOps menggunakan piagam dalam pengambilan kerja, keutamaan, dan semakan roadmap.

Piagam perlu cukup ringkas untuk digunakan dalam keputusan sebenar. Jika tiada sesiapa membukanya selepas pelancaran, ia terlalu teoretikal.

Contoh bahasa piagam

Gunakan bahasa yang mudah:

RevOps memiliki sistem operasi hasil bersama merentasi pemasaran, jualan, kejayaan pelanggan, kewangan, dan sistem. RevOps mentadbir urus takrifan kitaran hayat, serah tugas, kualiti data CRM, pelaporan sumber-kebenaran, proses ramalan, irama hasil, dan impak perubahan sistem. Pemimpin fungsian memiliki prestasi pasukan, strategi, bimbingan, dan pelaksanaan pelanggan. RevOps mempunyai kuasa untuk meluluskan atau menolak perubahan yang menjejaskan data hasil bersama, aliran kerja, dashboard, dan serah tugas, dengan eskalasi eksekutif apabila pertukaran ganti menjejaskan keutamaan peringkat syarikat.

Perenggan itu tidak menyelesaikan setiap pertikaian, tetapi ia memberikan syarikat titik permulaan. Ia juga menjadikan fungsi ini konkrit. RevOps bukan "penjajaran." Ia ialah pemilik lapisan operasi yang ditentukan.

Metrik

RevOps perlu diukur berdasarkan kesihatan sistem, bukan jumlah tiket.

Metrik yang baik termasuk:

• Ketepatan ramalan
• Pematuhan SLA
• Kesempurnaan serah tugas
• Kesempurnaan medan wajib
• Keterlihatan sumber-ke-hasil
• Kepercayaan terhadap dashboard
• Pengurangan pelaporan manual
• Pengurangan penuaan peringkat

Gunakan RevOps Metrics sebagai asas metrik.

Aliran kerja kelulusan piagam

Piagam RevOps perlu diluluskan melalui lensa silang fungsi yang sama seperti yang akan ditadbir urusnya.

Proses kelulusan penting kerana piagam ialah dokumen kuasa. Ia menentukan siapa yang boleh meluluskan atau menolak perubahan yang menjejaskan kebenaran hasil bersama. Jika hanya RevOps yang meluluskannya, pasukan lain mungkin menganggapnya sebagai keutamaan dalaman berbanding polisi operasi syarikat.

Cara menggunakan piagam dalam permintaan sebenar

Piagam perlu mengubah tingkah laku harian.

Jika piagam tidak dapat menjawab permintaan biasa ini, ia terlalu kabur. Ketatkan hak membuat keputusan sebelum menambah lebih banyak proses.

Cara mengekalkan piagam supaya kekal relevan

Piagam RevOps perlu berubah apabila syarikat berubah.

Semak semula apabila:

• Syarikat menambah pendekatan GTM baharu
• Pemasaran, jualan, atau CS menyusun semula struktur
• Barisan pelaporan RevOps berubah
• CRM atau sistem hasil utama baharu diperkenalkan
• Kewangan mengubah model perancangan
• Syarikat beralih daripada tumpuan perniagaan baharu kepada tumpuan pembaharuan dan pengembangan
• Kepimpinan mula mengeskalasi konflik pemilikan yang sama berulang kali

Jangan tulis semula piagam setiap bulan. Tetapi jangan biarkan ia menjadi artifak daripada model operasi lama. Piagam yang lapuk lebih buruk daripada tiada piagam kerana ia memberi orang kejelasan palsu.

Piagam terbaik ialah alat yang hidup: dirujuk dalam semakan roadmap, tadbir urus sistem, keputusan pengambilan kerja, dan pertikaian silang fungsi.

Peraturan pengambilan kerja

Piagam perlu mengubah cara RevOps menerima kerja.

Tanpa peraturan pengambilan kerja, setiap permintaan kelihatan sama-sama mendesak:

• "Bolehkah anda tambah medan ini?"
• "Bolehkah anda bina dashboard ini?"
• "Bolehkah anda baiki penghalaan?"
• "Bolehkah anda tarik laporan ini untuk mesyuarat lembaga?"
• "Bolehkah anda automasikan susulan ini?"

RevOps memerlukan cara untuk memisahkan tugas sokongan daripada keputusan operasi.

Borang pengambilan kerja yang mudah perlu bertanya:

Piagam perlu membenarkan RevOps menolak atau menangguhkan kerja apabila permintaan tidak mempunyai pemilik, keputusan, atau laluan penerimaan yang jelas. Ini tidak bermakna RevOps menjadi tidak membantu. Ia bermakna fungsi ini melindungi sistem daripada perubahan berkualiti rendah.

Corak yang perlu dielakkan

Perhatikan kesilapan piagam ini:

Piagam hanya kenyataan misi. Kenyataan misi berguna, tetapi ia tidak menentukan kuasa. Piagam memerlukan skop, keputusan, metrik, dan eskalasi.

RevOps memiliki setiap masalah hasil. Ini mencipta kekesalan dan kegagalan. Pemimpin fungsian masih memiliki strategi dan pelaksanaan.

Hak membuat keputusan kabur. Jika piagam menyatakan RevOps "bekerjasama dalam" segalanya, tiada sesiapa tahu bila RevOps boleh menolak.

Tadbir urus sistem tiada. Perubahan medan, aliran kerja, dan dashboard ialah tempat kualiti operasi sering rosak.

Piagam hanya diluluskan oleh RevOps. Piagam memerlukan sokongan eksekutif. Jika tidak, ia hanya senarai harapan.

Piagam tidak pernah digunakan dalam pertukaran ganti roadmap. Jika pemimpin meluluskan piagam tetapi masih mengeskalasi setiap permintaan di sekelilingnya, piagam itu tidak mempunyai kuasa.

Piagam pertama yang praktikal

Piagam RevOps pertama tidak perlu merangkumi setiap kes khas.

Untuk syarikat peringkat pertumbuhan, versi pertama boleh menjadi perjanjian operasi dua muka surat:

• Misi
• Sistem dan proses yang dimiliki
• Tanggungjawab yang tidak dimiliki
• Jadual hak membuat keputusan
• Peraturan pengambilan kerja
• Laluan eskalasi
• Lima metrik kesihatan utama
• Tarikh semakan suku tahunan

Itu sudah memadai untuk bermula. Dokumen ini perlu bertambah baik apabila RevOps mempelajari di mana konflik sebenar berlaku.

Perkaranya bukan tadbir urus sempurna pada hari pertama. Perkaranya ialah berhenti berpura-pura bahawa kerja hasil silang fungsi boleh berjalan berdasarkan muhibah tidak formal selama-lamanya.

Senarai semak kesediaan piagam

Sebelum menganggap piagam selesai, periksa sama ada ia dapat menjawab pertikaian operasi sebenar:

• Bolehkah RevOps menolak permintaan medan yang menjejaskan kualiti data?
• Bolehkah pemimpin mengenal pasti dashboard mana yang menjadi sumber kebenaran?
• Bolehkah kewangan melihat dari mana metrik perancangan berasal?
• Bolehkah jualan dan pemasaran menyelesaikan pertikaian takrifan kitaran hayat tanpa eskalasi khas?
• Bolehkah CS meminta data serah tugas tanpa berunding bagi setiap deal?
• Bolehkah pasukan sistem melihat perubahan aliran kerja hasil mana yang memerlukan semakan?

Jika jawapannya tidak, piagam itu mungkin masih terlalu lembut. Ketatkan jadual hak membuat keputusan sebelum pelancaran.

Soalan Lazim

Siapa yang menulis piagam RevOps?

RevOps perlu merangkanya, tetapi CRO, CEO, kewangan, pemasaran, jualan, dan pemimpin CS perlu menyemak dan meluluskannya.

Berapa panjang piagam RevOps sepatutnya?

Biasanya dua hingga empat muka surat. Ia perlu spesifik, bukan terlalu formal seperti dokumen undang-undang.

Berapa kerap ia perlu dikemas kini?

Semak setiap suku tahun atau apabila syarikat mengubah pendekatan GTM, barisan pelaporan, sistem, atau proses hasil utama.

Ketahui lebih lanjut

• RevOps Team Structure
• Why RevOps Fails
• Revenue Cadence
• CRM Change Management